3GPP TSG-RAN WG2 Meeting #130	R2-2503344
St.Julians, Malta, May 19th – 23rd, 2025	

Agenda item:		8.2.3
Source:		Futurewei
Title:		Open issues on A-IoT random access
Document for:		Discussion and Decision

Conclusions
Observation. If padding for OFDM symbol-alignment is also left for MAC layer to take care of, it is possible that MAC padding cannot ensure that the MAC PDU is byte-aligned and the corresponding PHY signal is OFDM symbol-aligned at the same time.
Therefore, we propose the following:
Proposal 1. RAN2 assume the Message Type field is included in the new R2D Trigger message unless RAN1 concludes to use L1 signaling.
Proposal 2. The X and Y values are indicated only in the paging message sent for a CBRA procedure, not in the R2D Trigger message.
Proposal 3. R2D trigger message is not sent in CFRA procedure.
Proposal 4. RAN2 follow up with RAN1’s conclusion on how to provide padding to ensure OFDM symbol-alignment of PHY signals with various M values for OOK-4 waveform.
Proposal 5. If RAN1 leaves the padding for OFDM symbol-alignment to the MAC layer, RAN2 reconsider whether MAC PDU byte-alignment can always be achieved.
Proposal 6. If the reader has assigned an AS ID to a device in Msg2 and the reader fails to receive the Msg3 from the device, the reader can send a NACK Feedback message to the device to cause the device to re-access, by including the RN16 value and the assigned AS ID value in both separate fields (e.g., RN16 field and ASID field) in the NACK Feedback message.  
Proposal 7. A device receiving its Msg2 correctly and with an AS ID assigned to it shall use its stored ID to compare with the value in the ASID field in the NACK Feedback message received after sending its Msg3.
Proposal 8. A device not receiving its Msg2 promptly shall use its stored ID to compare with the value in the RN16 field in the NACK Feedback message received after not receiving its Msg2, e.g., after an estimated end of the otherwise would-be Msg3 transmission.
Proposal 9. The RN16 field is a mandatory field in the NACK Feedback message, while the ASID field is an optional field in the NACK Feedback message and is present only if the reader has assigned an AS ID to the device and the assignment is still valid.

3GPP TSG-RAN WG2 Meeting #130   	       	R2-2503405
St Julian’s, Malta, 19th – 23rd, May 2025			
Source:	vivo
Title:	Random Access Procedure for A-IoT Device
Agenda Item:	8.2.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss further details about CBRA and CFRA and have the following observations:
R2D trigger should be no smaller than 6 bits according to RAN1 CRC-6 requirement.
The multiplexing MSG2 format without resource index may be invalid and not workable for RN16 value collision and AS ID re-assignment cases.
The device that does not successfully receive its MSG2 needs not to detect an MSG3 NACK indication, and re-access also occurs due to contention resolution failure determination.
The reader can always trigger an MSG3 NACK indication without differentiation between MSG2 and MSG3 failure.
The upper layer command transmission may cross the next R2D trigger slot since CN’s authentication, security, and response round trip may need a little longer time, and multi-process operations with multiple devices in the A-IoT radio interface are beneficial to resource efficiency.
The upper layer command transmission may also cross the next paging re-access round since there may be a short-paging round case or an initialized paging round for access parameter adjustment before previous round termination.
CFRA for multi-devices is not in R19 WI scope according to SA2 and RAN agreements.
If previous CFRA MSG1 fails, the device may receive a retransmitted CFRA paging trigger for recovery/re-access.
Based the above discussions and observations, we have the following proposals:
MSG0 for 3-step CBRA 
The paging message directly indicates the start of the first set of MSG1 resources, i.e., no separate R2D trigger before the first set of MSG1 resources. If not agreed, send LS to RAN1 for feasibility evaluation.
From the second set of MSG1 resources, the R2D trigger indicates the start of the following set of MSG1 resources.
The number of MSG1 occasions in each resource set in Time Domain and/or Frequency Domain (i.e., X value and Y value in RAN1 agreements) is consistent and only indicated in the paging message, and the R2D trigger should not carry any RO parameter.
The R2D trigger (i.e., Access Occasion Trigger message in MAC running CR) is byte alignment, e.g., 1-byte.
MSG1 for 3-step CBRA 
RAN2 to decide how the device randomly selects one MSG1 resource:
One-step: directly select a random number from the total MSG1 resources in one paging round, e.g. from the range of [0, X*Y*Z-1];
Two-step: firstly, select a random resource set, e.g., from the range of [0, Z-1], and secondly, select a random MSG1 occasion in that set, e.g., from the range of [0, X*Y-1];
Note: X is the number of MSG1 resources in the Time Domain and Y is the one in the Frequency Domain in each resource set; Z is the number of resource sets in this paging round.
The index and order of ROs in each MSG1 resource set must be predefined or specified in MAC/RAN1 spec.
MSG2 for 3-step CBRA 
Failure of contention resolution is determined on the device side when the device does not receive the MSG2 carrying its RN16 same as MSG1, until the next R2D trigger.
Multiplexing MSG2 format should indicate the corresponding MSG1 resource index, e.g., via bitmap.
After successful reception of its MSG2, the device should only store its AS ID (i.e., instead of RN16), which is the confirmation of RN16 or re-assigned by the reader for following scheduling and indication.
MSG3 for CBRA 
MSG3 NACK indication should carry the AS ID of failure device(s).
Only the device that successfully receives its MSG2 and stores AS ID needs to process an MSG3 NACK indication carrying its AS ID.
The end of CBRA procedure 
The end of the procedure is indicated by an explicit R2D Release message in addition to the implicit start of consequent paging with a new transaction ID.
CFRA 
RAN2 to confirm that CFRA for multi-devices is not supported in R19.
The R2D trigger is not supported in the CFRA case.
Device always responds with MSG1 for CFRA paging and transaction ID is omitted in the CFRA paging message.
After AS ID is successfully allocated with the MSG2 command, the end of the procedure is indicated by an explicit R2D Release message or implicitly by the start of consequent new paging, i.e., unified between CFRA and CBRA.

3GPP TSG-RAN WG2 Meeting #130	                                                                    R2-2503420
St.Julians, Malta, May 19th – 23rd, 2025

Source:	CATT
Title:	Discussion on the Random Access for A-IoT
Agenda Item:	8.2.3
Document for:	Discussion and Decision

Conclusion
In this paper, we discuss the RACH-related issues for A-IoT. The observations and proposals of this paper are summarized as follows,
Observation 1: The AS ID and the Msg3 scheduling resource should be associated with the corresponding RN16 to the echoed device.
Remaining issues on CBRA
Proposal 1: (2-1) RAN2 to not specify the details of the random selection of the access occasion for CBRA unless there is additional requirement on FDMA by RAN1.
Proposal 2: (2-2) For CBRA, the A-IoT paging message is used to determine the start of the first access occasion configured by this A-IoT paging with consideration of the Toffset1 defined by RAN1.
Proposal 3: (2-3) No need to make byte-align for the R2D trigger message.
Proposal 4: (2-4) RAN2 to consider the following two cases as the contention resolution failure,
Case 1 – the device receives the A-IoT Msg2 but not including the echoed RN16 before receiving the subsequent A-IoT paging;
Case 2 – the device misses the A-IoT Msg2 due to the R2D reception failure before receiving the subsequent A-IoT paging.
Proposal 5 (2-5): No need to include the A-IoT Msg1 resource index related parameter in the A-IoT Msg2.
Proposal 6: (2-6) The number of multiplexed RN16 in A-IoT Msg2 is explicitly indicated to the device. A bitmap is introduced with the same length as the number of multiplexed RN16 to indicate the allocated AS ID associated with the corresponding RN16.
Remaining issues on CFRA
Proposal 7: (2-2) For CFRA, the A-IoT paging is used to determine the start of the resource configured in the A-IoT paging for A-IoT Msg1 transmission.
Proposal 8a: (2-8) It is up to reader implementation to not send the NACK feedback if CFRA is triggered by the reader.
Proposal 8b: (2-8) In CFRA, it is up to reader implementation to re-send the R2D message (A-IoT paging or R2D Upper Layer Data Transfer) to trigger the data re-transmission. No further spec impact is found.
On the NACK feedback indication
Proposal 9: (2-10) RAN2 to confirm that only the subsequent A-IoT paging can trigger the access occasion for re-access purpose, regardless of re-access due to NACK feedback or contention resolution failure.
Proposal 10: (2-12) Support the multiplexing of multiple devices in the NACK message.

3GPP TSG-RAN WG2 Meeting #130	R2-2503482
Malta, 19th – 23rd May 2025

Agenda Item:	8.2.3
Source: 	Xiaomi
Title:  	Remaining open issues on access procedure for A-IOT
Document for:	Discussion and decision

Conclusions
Based on the above discussion, we propose following proposals:
Subgroup: Subgroup: R2D trigger message and Msg1 related (issue 2-1, 2-2, 2-3)
Proposal 1 (Issue 2-1): Same as current TP, the A-IoT device randomly selects an access occasion among the access occasions configured in A-IoT Paging message. The details, e.g., count down or increase the number are left to Device implementation. No additional spec impacts. The issue 2-1 can be closed. 
Proposal 2 (Issue 2-2): The start of the first set of MSG1 resources is indicated by Paging message directly instead of the new R2D trigger messages.
Proposal 3 (Issue 2-2): The new R2D trigger message is not applied for CFRA.
Proposal 4 (Issue 2-3): RAN2 to agree that byte alignment is not required for new R2D trigger message.  
Subgroup: CBRA procedure related (issue 2-4)
Proposal 5 (Issue 2-4): In the CBRA procedure, after transmitting Msg 1, the device determines that the CBRA has failed if it receives either a new RAR trigger message or an A-IoT paging message prior to receiving the RAR. 

Subgroup: Msg2 content (issue 2-5)
Proposal 6 (Issue 2-5): To address the RN16 collision issue, i.e., introduce 3 bits in Msg 2 to indicate the frequency of the access slot together with responded RN16.

Subgroup: CFRA procedure specific (issue 2-8. 2-9)
Proposal 7 (Issue 2-8): For CFRA, NACK based feedback and re-access is not supported. The reader triggers the re-access by retransmitting the Paging message with the same device ID. “transaction ID”, “the number of access occasions”, “Indication of Paging ID present/absence” are not contained in the Paging message for CFRA (Same as issue 1-5).  
Proposal 8 (Issue 2-9): RAN2 confirms that the reader only performs the CFRA for a single device at a time, i.e., do not support multiple device scenario for CFRA.

Subgroup: NACK feedback (issue 2-10)
Proposal 9 (Issue 2-10): The NACK shall be sent within the same access slot, i.e., between two new R2D trigger messages. 
Proposal 10 (Issue 2-12): multiplexing is support for NACK message.

3GPP TSG RAN WG2 Meeting #130                                                            R2-2503519
St Julian's, Malta, May 19th - 23rd, 2025
Agenda item:	8.2.3
Source:	Ofinno
Title:	Discussion of issues 2-4, 2-6, 2-11, 1-4 and a new issue
Document for:	Discussion and decision

Conclusion
The observations captured are the following: 
Observation 1.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] For CFRA, after sending D2R message, it is unclear whether the A-IoT device can consider this transmission immediately as successful. For CBRA, after sending Msg3, the A-IoT device might be in a limbo/stuck scenario if it misses the corresponding failure/re-access indication.
Observation 2.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] For CBRA, network could request, to the device, different behaviours upon detecting a failure of Msg1/Msg3: (1) re-access (i.e., retransmission of Msg1), or (2) retransmission of Msg3. For scenario (2), the usage of retransmitted Msg2 is already agreed. The open question is how re-access is informed to the device (which seems preferable to create a new R2D NACK message instead of other means e.g., also reusing Msg2).
Observation 3.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] A guard time  is defined by RAN1 as the time that the device does not need to monitor for R2D message after transmission of D2R message. This was discussed in relation to Msg1/2 but RAN1 agreement/TS seems general for any D2R message.

The proposals captured are the following:
Proposal 1.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] To determine the success or failure of a transmitted Msg3, to consider whether to define a timer-based approach and/or Msg.2-based approach.
Proposal 2.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] [Timer-based approach] To consider defining a new short timer (TD2R_ACK) to determine the success (as well as failure) of previously transmitted Msg3 which works as follows:
Proposal 2.1.	Point (A) Upon transmission of the Msg3, TD2R_ACK is started immediately or after certain time (TOffset). FFS on TOffset (if it’s needed and its relationship with  defined in TS 38.291).
Proposal 2.2.	Point (B) While TD2R_ACK is running, the device’s behaviour upon reception of the applicable R2D messages (e.g., Msg2 or paging) is defined case by case in A-IoT specification (including for both, failure and success).
Proposal 2.3.	Point (C) Upon expiry of TD2R_ACK, the A-IoT device considers previous Msg3 as successful or failed.
Proposal 2.4.	Point (D) To also apply this TD2R_ACK to any D2R messages sent as part of the A-IoT inventory and command procedure (including Msg1).
Proposal 3.	[Issue 2-4] [Issue 2-11] [new issue] [Success/failure of Msg3] [Msg.2-based approach] To consider defining the usage of retransmitted Msg2 to determine the success (as well as failure) of previously transmitted Msg3 which works as follows:
Proposal 3.1.	Msg2 is used to indicate success or failure of previously transmitted Msg3 (per UE basis). FFS whether this success indication can also be defined per group of devices and/or implicit.
Proposal 4.	[Issue 1-4] [Msg1 resource information] To define “D2R scheduling info” (provided in the A-IoT paging message) in terms of (a) the total number of access occasions, (b) the total number of TDMed access occasions, and/or (c) the total number of FDMed access occasions.
Proposal 5.	[Issue 2-6] [Issue 4-1] [Msg1/2 association] To discuss the association or mapping between an access occasion for A-IoT Msg1 and the corresponding A-IoT Msg2 in a PRDCH corresponding to multiple A-IoT Msg1 received from different devices. For this, to discuss if A-IoT Msg2 includes option (1) bitmap indication, or option (2) an indication (or index) time-frequency resource of an access occasion for the A-IoT Msg1.

3GPP TSG-RAN WG2 #130 	R2-2503527
St Julian’s, Malta, 19th - 23rd May 2025

Agenda Item:	8.2.3
Source:	KT Corp.
Title:	Discussion on random access aspects of Ambient IoT
Document for:	Discussion/Decision
WID/SID:	Ambient_IoT_solutions
1	

Conclusion
Based on the discussion in the previous sections we propose the following:
Proposal 1	In order to reduce the collision probability, RAN2 support including indication bit in new R2D message to instruct the device(s) how to select the one resource among access occasions.
Proposal 2	RAN2 to discuss the monitoring windows for receiving the (re-)Msg2 such as Random Access Response (RAR).
4	

TDoc file reading error

3GPP TSG-RAN WG2 #130	R2-2503642
Malta, 19th – 23rd May 2025
Source:	NTT DOCOMO, INC.
Title:	On remaining issues on A-IoT Random Access
Document for:	Discussion
Agenda Item:	8.2.3

Summary and proposal
Proposal 1.	(Issue 2-2) Paging message includes information of access occasions with the same contents as R2D trigger message.
Proposal 2.	(Issue 2-4) The device considers contention resolution as failed from the time it sends Msg1 until it receives Msg2 including random ID that the device sent.
Proposal 3.	(Issue 2-5) RAN2 does not specify anything specific for resolution of random ID collision within a Msg2.
Proposal 4.	(Issue 2-6) Field for number of random IDs is not needed in paging message.
Proposal 5.	(Issue 2-6) Random ID is generated between 1 and 65536.
Proposal 6.	(Issue 2-9) Do not consider scenario to use CFRA to target multiple specific devices.
Proposal 7.	All devices are assumed to support both 3-step CBRA and CFRA.

3GPP TSG-RAN WG2 Meeting #130                           R2-2503664
St.Julians, Malta, May 19th – 23rd , 2025


Source:	China Telecom
Title:	Further discussions on A-IoT random access
Agenda Item:	8.2.3
Document for:	Discussion and Decision

Conclusion
Based on the above analysis, the following proposals are given for A-IoT random access procedure.
Proposal 1: The device may include assistance information (e.g., data size) to indicate the resource for Msg3 via Msg1.
Proposal 2: The reader allocates the time-frequency resource for Msg3 via Msg2.
Proposal 3: Access Occasion Trigger message only needs to include a message type field.
Proposal 4: A one-bit field can be used to indicate the presence of the AS ID assigned by the reader through Msg2.
Proposal 5: If Proposal 4 is supported, one bit indication can also indicate whether to reuse random ID as AS ID or not. (e.g., when it indicates the AS ID is absent, it also indicates the reuse of the random ID as the AS ID).
Proposal 6: The NACK mechanism can also be applied to command response messages for subsequent re-access.
Proposal 7: A NACK indication can include the ID information of multiple failed devices.
Proposal 8: For CFRA, the reader may trigger a new CFRA procedure when the previous Msg1 transmission fails.
Proposal 9: A one-bit re-access indication may be included in the subsequent paging message.
Proposal 10: A new R2D message should be defined to trigger re-access during the initial access round.
Proposal 11: RAN2 to define the mapping relationship between the random ID and the Msg1 resource selection.
Proposal 12: Regarding the Msg2 format, it is proposed to group {Echoed Random ID, Assigned AS ID, D2R scheduling info} for the same device.

3GPP TSG-RAN WG2 Meeting #130	R2-2503721
St. Julians, Malta, 19-23 May 2025
                                 
Agenda item:	8.2.3
Source:	Apple
Title:	Discussion on Random Access for Ambient IoT
WID/SID:	Ambient_IoT_solutions – Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss the Random-Access design for Ambient IoT, and have the following proposals:
Proposal 1 	NACK-based feedback (e.g., a list of failed AS IDs) is optionally included as part of the R2D message to trigger re-access. No separate NACK message type needed.
Proposal 2 	The device release the AS ID assigned by the reader after receiving the NACK-based feedback.
Proposal 3	It is up to reader to decide whether it is worth to trigger re-access or not after Msg3 failure.
Proposal 4 	Re-access is allowed only after the device receives subsequent paging message, not R2D trigger message.
Proposal 5 	For CFRA-based transactions, there is no need to discuss the end-of-procedure .
Proposal 6 	A-IoT device only handles one ongoing CBRA-based “transaction” at a time and deems the previous procedure ended after it moves to a new “paging” transaction ID .
Proposal 7 	In the multiplexed Msg2 transmission, each individual Msg2 is associated with a dedicated D2R transmission resource. FFS how this is done in A-IoT MAC Msg format design.
Proposal 8 	Multiple device scenario for CFRA is not considered in Re-19.
4 

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130	R2-2503825
St Julian’s, Malta, May 19th – 23rd, 2025
Agenda Item:	8.2.3
Source:	NEC
Title:	Open issues on random access for Ambient IoT devices
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following observations and proposals:

Observations:
Observation 1	(MAC 2-9) Multiple device scenarios may exist during Command Request procedure.
Observation 2	(MAC 1-4) Both TDMA and FDMA are supported for Msg1 for Rel-19 A-IoT CBRA.
Observation 3	(MAC 1-4) RAN1 has agreed to use 1 bit to indicate the value of X time domain resources for Msg1 transmission.
Observation 4	(MAC 2-5) To correctly indicate the reader’s decision (whether to reuse the generated random ID or to use the new assigned AS ID) to devices which generate the same random ID, Msg2 needs to include the Msg1 resource index.

Proposals:
Proposal 1 (MAC 3-5) RAN2 to determine whether to support message type for D2R message containing upper layer data in Rel-19 for forward compatibility.
Proposal 2	(MAC 2-9) RAN2 confirm that AS ID is sufficient for addressing the device in R2D command message for the multiple device scenario during Command Request procedure.
Proposal 3 (MAC 1-4) Access Occasion Set is defined as a set of access occasions, i.e., an access occasion set hosts X*Y access occasions.
Proposal 4 (MAC 1-4) The new R2D message introduced for A-IoT devices to determine Msg1 resources indicates the start of an access occasion set. It is named the "Access Occasion Set Trigger message."
Proposal 5	(MAC 1-4) RAN2 confirm that all access occasion sets triggered by an A-IoT paging message have the same number of time domain resources (X) and frequency domain resources (Y).
Proposal 6 (MAC 1-4) The number of Msg1 resources included in the A-IoT paging message is represented by the following parameters:
- the number of Access Occasion Sets in time domain (M)
- the number of time domain resources within an access occasion set (X)
- the number of frequency domain resources within an access occasion set (Y)
Proposal 7	(MAC 2-1) RAN2 to discuss the following options for the A-IoT device to select resource (i.e., access occasion) for Msg1 transmission upon receiving A-IoT paging message for CBRA on selection of Msg1 resources
Option1: randomly picks three random values within the ranges (1, M), (0, X-1), and (0, Y-1) to select the access occasion set and the time and frequency resources within the chosen access occasion set. 
Option 2: firstly, randomly choose an access occasion set from all available sets (i.e., M sets) and then randomly choose an access occasion from the available ones within that access occasion set (i.e., X*Y resources). 
Option-3: randomly choose a value among (0, (M*X*Y-1)) and map that random value to an access occasion among all of the available access occasions.
Proposal 8	(MAC 2-1) One counter is needed for counting the Access Occasion set (similar to the slot counter in RFID).
Proposal 9	(MAC 2-1) The expected device behavior upon receiving the “Access Occasion Set Trigger message” is:
- decrement of its Access Occasion Set counter by 1.
- if the Access Occasion Set counter equals to 0 after the decrement, reply to the A-IoT paging message immediately using the randomly picked time/frequency domain resources within the current Access Occasion Set.
Proposal 10 (MAC 2-2) RAN2 confirm that the R2D trigger message used to indicate the start of AO sets is not needed for CFRA paging and the first AO set in CBRA paging.
Proposal 11 (MAC 2-5) Support to include the Msg1 resource index at least in A-IoT Msg2 containing one echoed random ID.
Proposal 12 (MAC 2-6) No need to indicate the number of random ID(s) in the multiplexed Msg2 assuming all the other parts in Msg2 (i.e. message type, scheduling info if any) have fixed length and are put in the beginning of the MAC PDU, and the device can decode the random ID one by one.
Proposal 13 (MAC 2-10) RAN2 confirm that for CBRA, NACK based mechanism is applied only to Msg3.
Proposal 14 (MAC 2-10) RAN2 confirm the RAN2#129 agreement to reuse the A-IoT paging message to trigger re-access. No other R2D message is supported for triggering or determining re-access.
Proposal 15 (MAC 2-12) Support a NACK indication that contains multiple AS IDs.
Proposal 16 (MAC 2-8) Device always responds to a CFRA if it is identified by the CFRA without considering whether it has responded before or not.

3GPP TSG-RAN WG2 Meeting #130	R2-2503863
St. Julians, Malta, 19 – 23 May 2025		

Agenda item:	8.2.3
Source:	Nokia
Title:	Aspects on random access for AIoT
WID/SID:	Ambient_IoT_solutions - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations and proposals:
Observation 1: The WID states that forward compatibility should be included when designing (at least) paging messages.
Observation 2: The usage of AS ID ensures forward compatible multi-devices paging in CFRA without the need to use the full device ID.
Observation 3: If AS ID is assigned using the read or write command, the later devices in a multi-device CFRA procedure ends up waiting a significant time before the msg1 resources are provided.
Proposal 1: A separate AS ID assignment command shall be adopted to support multiple device scenario. FFS whether this can be multiplexed with a read/write command.
Proposal 2: RAN2 to discuss whether CFRA takes precedence over CBRA in any given case i.e. a device may interrupt any ongoing CBRA initiated procedure when a CFRA paging has the device ID. FFS on whether this is applicable during a segmented command.
Proposal 3: The R2D transmission determining the Msg1 resources will indicate at least number of frequency resources per time slot to the device.
Proposal 4: The device should not be expected to store the frequency index in which it sent Msg1, i.e. reader must always indicate current resources.
Proposal 5: RAN2 to design a procedure for a reader to assign a dedicated frequency resource for a device within Msg1.
Proposal 6: RAN2 to discuss whether the frequency index provided in Msg1 is persistent for all subsequent D2R communication within the transaction or whether each R2D transmission providing a D2R resource will provide also a frequency index.

3GPP TSG-RAN WG2 Meeting#130        			                                                               R2-2503868
St.Julians, Malta, May 19th – 23th, 2025

Agenda item:	8.2.3
Source:	ETRI
Title:	Discussion on Msg1 transmission for random access
Document for:	Discussion and Decision

Conclusions
Based on the discussion in the contribution, we have the following observation and proposals: 

Observation 1. One or more Msg1 transmissions can be supported on D2R transmission resource(s) for a single random access procedure. 


Proposal 1. Indicating D2R resources for Msg1 transmission can be achieved by either assigning a unique resource index to each resource or representing the resource location as coordinates.
Proposal 2. For CFRA, the device ID maps to the dedicated D2R resource for Msg1 transmission, as indicated in the paging message.
Proposal 3. For CBRA, the device ID(s) maps to the shared D2R resource pool for Msg1 transmission in the paging message, and a 'Q' is also provided to the devices for random resource selection within shared D2R resource pool
Proposal 4. Different D2R resource sizes may be configured for Msg1 transmission for CFRA and CBRA.
Proposal 5. The R2D trigger should be designed as MAC message.
Proposal 6. The D2R resource configuration for Msg1 transmissions within a single paging round have identical.
Proposal 7. For CFRA, the device transmits Msg1 on the dedicated resource indicated by the paging message.
Proposal 8. For resource selection for Msg1 transmission in CBRA, the device selects a random value from the range 0 to 2Q − 1 using the Q value provided in the paging message.
Proposal 9. For CBRA, the device decrements the selected random value ‘q’ by 1 each time a D2R resource for Msg1 transmission becomes available. When the random value reaches 0, the device transmits Msg1 (RN16).
Proposal 10. The message type is not included in Msg1.

3GPP TSG RAN WG2 #130          						R2- 2503879 
Malta, Malta, May 19th – 23rd, 2025

Source:	Tejas Networks Ltd.
Title:	Discussion on A-IoT message format for CBRA and CFRA
Agenda item:	8.2.3
Document for:     Discussion and Decision

Conclusion
This work includes unified message structure of the A-IoT Msg0 and Msg1 content/format for contention-based and contention-free random access for all the paging query types. We have made the following observations and proposals related to these aspects:

Observation 1: The R2D transmission as a part of paging message or the msg0 can be a unique or unified message structure for all query/paging types for both CBRA and CFRA.

Proposal 1: The field parameters of msg0 includes:
Message type
Transaction ID
Reader ID (if required)
Paging ID presence indicator
Paging ID length
Paging ID
CBRA/CFRA
Number of R2D triggers
Time domain resources (X=1 or X=2)
Frequency domain resources
Proposal 2: Msg0 signal may carry 1-bit to convey the number of time domain resources for an R2D trigger to the device. Bit ‘1’ indicates X=1 within two R2D triggers. Bit ‘0’ indicates X= 2 within two R2D triggers. 
Proposal 3: Msg0 should contain the Frequency domain resources for msg1 either implicitly or explicitly:
Option 1: List of frequency resources (F1 … FY)
Option 2: Total number of frequency resources 
Observation 2: The D2R transmission to send msg1 can be a unique or unified message structure for all query/paging types for both CBRA and CFRA.
Proposal 4: RAN2 to consider a unified msg1 structure for both 2-step and 4-step random access as well as rel-19 and rel-20 devices.
Proposal 5: The field parameters of msg0 includes:
Random ID
Message type
Data size
Device energy status
Data presence indicator
Upper layer data
Observation 3: In case of CFRA Msg1 may also carry the device random ID to support future AIoT communications, where a reader can send command to multiple devices simultaneously. Reader may use this random ID to send command to the specific devices.
Proposal 6: For 2-step process, msg1 contains the device generated unique random ID, data size (size of upper layer data present in msg1), device energy status, 1-bit data presence indicator (set to ‘1’), and upper layer data. 
Proposal 7: For 4-step process, msg1 contains the device generated unique random ID, data size (size of upper layer data to be conveyed through msg3), device energy status, 1-bit data presence indicator (set to ‘0’), data field is not present.
Proposal 8: The device can transmit the device energy status to the reader through msg1 to inform the energy status of the device, which the reader can use for prioritizing/ deprioritizing the device for scheduling. If the energy available at the device is below certain threshold, reader may choose not to allocate resource to that device.

3GPP TSG-RAN WG2 Meeting #130	R2-2503890
St. Julian, Malta, May 19th – 23rd, 2025

Agenda Item:	8.2.3
Source:	Panasonic
Title: 	Discussion on A-IoT random access procedure
Document for:	Discussion

Conclusion
Time domain and frequency domain resource configuration
Observation 1: For R2D messages triggering resource sets within one paging round (associated with one A-IoT paging message), whether each R2D message can indicate different X values when triggered for each resource set in time domain must be further discussed.
Proposal 1: RAN2 to discuss if the 1 bit to indicate the value of X (X=1 or X=2) will be configured with one of the below configuration options. 
Option 1: A-IoT paging message configures X value of each R2D message which triggers a resource set, to keep the size of all the resource sets constant within the same paging round.
Option 2: R2D message which triggers one resource set can indicate the X value, possibly to trigger different X values within the same paging round.
Proposal 2:  A-IoT paging message configures the frequency domain resources for each resource set triggered within the same paging round. Which means all the R2D messages sent to trigger a resource set in a paging round carries same number of frequency domain resources.
Number of resource sets in single paging round
Proposal 3: RAN2 to discuss if A-IoT paging message configures a fixed number of resource sets in a paging round, or whether the number of resource sets can be varied during the ongoing paging round.
Random selection approach for the device
Observation 2: Resource set sequencing monitored and maintained by the device to search for the selected resource, increases device side complexity and results in missed opportunities to transmit Msg1 in the same paging round, in case of failure of one or more R2D messages.
Observation 3: More discussion may be necessary to understand the assumption related to not including slot/ count down numbering in R2D message to trigger a set of resources. Or whether the device is expected to maintain sequencing of the received R2D messages to perform random selection and identifying the selected resource among the one or more set of resources.
Proposal 4: RAN2 to discuss and adopt a random selection approach (for Msg1 resource selection) where the device shall not maintain any sequencing of the transmitted messages in R2D (i.e. R2D messages which indicates the start of the set of resources).

3GPP TSG-RAN WG2 Meeting #130						R2-2503904
St Julian, Malta, May. 19th – 23rd, 2025

Agenda item:		8.2.3
Source:			Lenovo
Title:		Discussion on random access for Ambient IoT
Document for:	 	Discussion and Decision

Conclusion
In this contribution we have discussed A-IoT random access procedure and made the following observations and proposals:
A-IoT Msg0
R2D trigger message
Observation 1: RAN1 concludes not to use L1 signaling for any scheduling information related to resource allocation, but indicated by higher-layer signaling.
Proposal 1: Confirm a new R2D message other than the paging message is introduced for A-IoT device determining MSG1 resources.
Proposal 2: R2D trigger message may contain following information according to RAN1 agreement, the discussion on format and the size of the R2D trigger message can wait for RAN1 further progress.
1 bit to indicate X value (X=1 or X=2) time domain resource(s) for Msg1 transmission(s)
Toffset1: the starting time for the first Msg1 time domain resource, if explicitly indicated
Toffset2: 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, if explicitly indicated
Proposal 3: RAN2 is suggested to discuss whether to support interleaved R2D trigger message transmission before Msg2 transmission (acc. to example 3 in figure 1).
A-IoT Msg1
Observation 2: Depending on 1-bit X value is indicated in which message
If in paging message, X value corresponding to all R2D trigger message in the same paging round is same
If in R2D trigger message, X value corresponding to each R2D trigger message in the same paging round could be different.
Proposal 4: The device behavior for Msg1 transmission has minor difference, consider 1-bit X value indication is in paging message or R2D trigger message:
In paging message, the device obtains X value once, and determines access and updates counter based on the obtained X value
In R2D trigger message, the device obtains X value for each R2D trigger message, and determines access occasion and updates counter based on the obtained X value corresponding to each R2D trigger message.
A-IoT Msg2
Msg2 Multiplexing
Proposal 5: RAN2 to discuss whether all following three Msg2 cases are supported
Separate Msg2
Partial Msg2
Common Msg2
Contention resolution determination for A-IoT device
Proposal 6: A-IoT device determines contention resolution success only when it received matched RN16 in all Msg2(s) corresponding to the R2D trigger message.
Proposal 7: A-IoT device determines corresponding Msg2(s) in following two options
Option 1: Msg2 includes same flag as in R2D trigger message
Option 2: All Msg2(s) before subsequent R2D transmission. Here R2D transmission could be R2D trigger message or paging message.
RN16 Collision Problem
Observation 3: The maximum probability that at least two RN16 is same in one Msg2 is 1.8‰, assuming X=2 and Y=8. The maximum probability considering three R2D trigger messages is 1.7%.
Proposal 8: If there has consensus that the observed RN16 collision probability in one Msg2 (≤1.8‰, or ≤1.7% considering three R2D trigger messages) is low enough, the RN16 collision in one Msg2 can be seen as a rare case and rely on the reader’s implementation and A-IoT device re-access to solve the problem.
Observation 4: RAN2 agreed for CBRA, it is up to Reader to decide whether to reuse the random ID as the AS ID or to assign a new AS ID. One motivation of the reader to assign a new AS ID is when RN16 collision problem may happen in one Msg2 message.
Proposal 9: If there assumes RN16 collision may happen in one A-IoT Msg2 message, AS ID assignment in the Msg2 for collided RN16(s) needs to be identified by the device.
Proposal 10: Introduce Msg1 resource index indication in Msg2 when assigning new AS ID for A-IoT device when RN16 collision happens in one A-IoT Msg2. Two options to determine the Msg1 resource index are as following:
Option 1: A-IoT device determines Msg1 resource index based on the order of the allocated Msg1 resource in paging message.
Option 2: A-IoT device determines Msg1 resource index based on the indicated resource index by the reader in paging message.
AS ID field in Msg2 for multiplexing case
Proposal 11: A-IoT Msg2 contains one or multiple Msg1 response(s), each Msg1 response may contain following information
1 bit to indicate the presence of new AS ID (mandatory)
Echoed RN16 (mandatory)
New AS ID (optional)
Proposal 12: A-IoT device determines to use RN16 as AS ID if 1 bit indicates no new AS ID is included in matched Msg1 response in Msg2.
Proposal 13: A-IoT device determines to use new AS ID as AS ID if 1 bit indicates new AS ID is included in matched Msg1 response in Msg2.
Msg3 scheduling
Proposal 14: The discussion on time-frequency resource information included in A-IoT Msg2 for A-IoT Msg3 waits for RAN1 further progress.
Msg2 Monitoring Window
Proposal 15: The discussion on Msg2 monitoring window waits for RAN1’s further progress.
NACK Indication
NACK indication for CBRA
Observation 5: If subsequent R2D message for NACK indication reception is R2D trigger message, Msg1/2 scheduling flexibility is restricted.
Proposal 16: For A-IoT Msg3, rely on whether the device receives NACK indication before subsequent paging message to determine re-access.
Addressing for NACK indication in CBRA
Proposal 17: NACK indication contains one or multiple NACKs for one or multiple A-IoT devices.
Proposal 18: When the reader is indicated by CN that the service type is inventory + command, AS ID is used for NACK indication for address the A-IoT device(s).
Proposal 19: When the reader is indicated by CN that the service type is inventory only, RN16 is used for NACK indication for address the A-IoT device(s).
NACK indication for CFRA
Proposal 20: R2D trigger message is also supported for CFRA procedure, which is used to indicate the start of inventory response resource
Proposal 21: The reader may transmit same paging message again to schedule retransmission of inventory response from A-IoT device.
Proposal 22: The A-IoT device always responds to the paging which target for itself and indicate CFRA, ignore transaction id if transaction id is included.
Proposal 23: Transaction id is not included in paging message for CFRA. 

3GPP TSG-RAN WG2 Meeting #130	R2-2503952
St.Julians, Malta, 19th –23rd May, 2025

Agenda Item:	8.2.3
Source:	Huawei, HiSilicon
Title:	A-IoT random access procedure
Document for: Discussion and Decision 
1	

Conclusion
This contribution makes the following proposals:
Observation 1:	RAN2 has assumed that the Msg1 transmission related configurations are provided in paging message, while R2D trigger message does not configure the parameters.
Observation 2:	A-IoT device does not support autonomously re-access, which can only be triggered by subsequent paging from reader. Therefore, it is necessary to have early determination on contention resolution failure before subsequent paging.
Observation 3:	The random ID collision among Msg2 due to no Msg2 reception window is as low as 1%.
Observation 4:	If the Msg2 timer is not supported, the low complexity of device is more attractive, compared to the performance degradation caused by random ID collision among Msg2s.
Observation 5:	The probability of random ID collision in Msg2 is below 0.1%, which can be considered as sufficiently low.
Observation 6:	In case there is a collision of random IDs among devices in different access occasions, the reader can identify it and avoid echoing the ambiguous random ID in Msg2 by implementation.
Observation 7:	From RAN2 perspective, Msg2 does not require the information referring to the time-frequency resource of Msg1, i.e., the contained random ID alone is sufficient for the device to determine the response for its Msg1.
Observation 8:	Assuming all the other parts in Msg2 have fixed length and are put in the beginning of the MAC PDU, the device can decode the random ID (and the associated AS ID if present) one by one till the end of Msg2.
Observation 9:	It makes no difference for device behaviour whether the subsequent R2D message is “QueryRep-like” message or the paging message.

R2D trigger message and Msg1 related (2-1, 2-2, 2-3)
Proposal 1:	(Issue 2-3) The R2D trigger message (i.e., Access Occasion Trigger message) only contains the message type field, i.e., just 3 or 4-bit MAC PDU.
Proposal 2:	(Issue 2-2) The start of the first set Msg1 resource(s) is indicated by the paging message, rather than by the Access Occasion Trigger message, for both CBRA and CFRA, i.e., combine the first R2D trigger message with paging message.
Proposal 3:	(Issue 2-1) RAN2 to discuss the following options for the TP about Msg1 resource selection:
Option 1: Msg1 resource selection details are left to device implementation, since it is not testable, i.e., no need to capture the details in the MAC specification;
Option 2: consider the above TP for Msg1 resource selection procedure (e.g., capture the countdown behaviour in the MAC specification).
CBRA procedure related (2-4)
Proposal 4:	(Issue 2-4) Similarly to the NACK feedback discussion, the device detects contention resolution failure by checking whether its random ID is received before paging, i.e., no need of timer.
Msg2 content (2-5, 2-6, 2-7)
Proposal 5:	(Issue 2-5) RAN2 to discuss the following options for devices to determine the corresponding response in Msg2 for its Msg1:
Option 1: only use the random ID itself;
Option 2: use frequency index of Msg1 to reference each random ID.
Proposal 6a:	(Issue 2-7) Use 1-bit field, following each echoed random ID, to indicate whether an associated AS ID is assigned or not.
Proposal 6b:	(Issue 2-6) No need to indicate the number of the included random IDs in Msg2, if proposal 6a is agreed.
Proposal 7:	(Issue 2-6) The maximum number of random IDs in one Msg2 is Y, based on RAN1 conclusion, i.e., max value of frequency resources.
Proposal 8a:	RAN2 confirms that the device is allowed not to store the random ID anymore once an AS ID is stored, i.e., only one ID is stored.
Proposal 8b:	To determine the associated D2R scheduling information for Msg3 retransmission, if the device has the stored AS ID (i.e., Msg2 was successfully received previously) and upon receiving the retransmitted Msg2, the device compares the stored AS ID with for each entry of the echoed random ID(s) in Msg2:
Use the assigned AS ID field, if present; 
Use the echoed random ID field, otherwise. 
CFRA procedure specific (2-8, 2-9)
Proposal 9:	(Issue 2-8) Paging message for CFRA does not include the transaction ID. The device always responds to the paging for CFRA, as long as the paging identifier is matched.
Proposal 10:	(Issue 2-9) For CFRA, there is no need to further include any other information other than the AS ID in R2D command message, assuming the reader will not trigger multiple devices in CFRA.
NACK feedback (2-10, 2-11, 2-12)
Proposal 11:	(Issue 2-10) The device determines whether to perform re-access based on the reception of the NACK feedback indication before subsequent paging message.
Proposal 12:	(Issue 2-11) The "NACK feedback indication" is carried by one separate R2D message, using the AS ID to indicate the failed device.
Proposal 13:	(Issue 2-12) The "NACK feedback indication" can be one broadcast R2D message, which can include multiple AS IDs of the devices that failed.
4	

3GPP TSG-RAN WG2 Meeting #130	R2-2503960
St Julian’s, Malta, May 19th – 23rd, 2025

Agenda item:	8.2.3
Source:	Spreadtrum, UNISOC
Title:	Discussion on A-IoT random access
Document for:	Discussion and Decision
1 

Conclusion
In this contribution we discuss the random access procedure of A-IoT device, with the following proposals:
Proposal 1: The Random ID of device should be carried in NACK indication.
Proposal 2: If NACK indication is received from the reader before subsequent R2D trigger message, device determine to re-access.
Proposal 3: In CFRA, if Msg1 is not received successfully by reader, reader can resend Msg0 to trigger device retransmit Msg1. 

3GPP TSG-RAN WG2 Meeting #130						        											R2-2503969
St.Julians, Malta, May 19 – 23, 2025			 
Source: 			ZTE Corporation, Sanechips
Title: 	Open issues for A-IoT random access
Agenda item:	8.2.3
Document for: Discussion and Decision

Conclusion
The following observations and proposals are made: 

MSG1 transmission details
Proposal 1 (Issue 2-1): A MSG1 slot consists of X time domain (X = 1 or 2) and Y frequency domain AOs
Proposal 2 (Issue 2-1): The paging message indicates the total number of MSG1 slots (Q) and the number of AOs in time domain (X) and number of AOs in frequency domain (Y) within each MSG1 slot
Proposal 3 (Issue 2-1): The device selects a random number Qd: between 1 and Q 
Proposal 4 (Issue 2-1): The device decrements Qd value by 1 for each R2D trigger message received by the device and when Qd = 0, the device selects the MSG1 slot for transmission of Random ID
Proposal 5 (Issue 2-1): The device transmits the Random ID in a randomly chosen AO within the selected MSG1 slot
MSG2 aspects
Observation 1: The collision probability for MSG3 will increase progressively towards the end of the paging frame if MSG2 transmission/retransmission is allowed at any point before the next paging message. 
Proposal 6 (Issue 2-4, 2-5): RAN2 should discuss and agree one of the following options for MSG2, if option B is adopted for the overall MAC procedure: 
Option 1: MSG2 transmission and any retransmission of MSG2 happens within a predefined time window or
Option 2: MSG2 transmission and any retransmission of MSG2 happens before the subsequent trigger message from the reader
CFRA aspects
Proposal 7 (Issue 2-8): transaction ID is included in the paging message for CFRA
Proposal 8 (Issue 2-8, 2-10): NACK based retransmission for inventory report is also supported for CFRA 

Proposal 9 (Issue 2-9): If multiple device scenario for CFRA is to be supported for command use case, the reader may indicate follow-on command in the paging message and send the R2D message with ASID immediately after receiving the inventory response
Proposal 10 (Issue 2-2): R2D trigger message is used to determine the starting point for MSG1 resource for CFRA. 

3GPP TSG RAN WG2 Meeting #130			R2-2504062
St. Julians, Malta, May 19th – 23rd    2025

Agenda Item: 	8.2.3
Source:		Sony
Title:			Considerations on RACH msg 2 configuration
Document for:	Discussion & Decision

Summary
In this contribution, we have discussed our views on aspects related to msg 2 monitoring configuration.

Proposal 1 – RAN2 to include early information about Msg2 content, i.e. its transmission to Msg1 is associated to one or multiple devices, in either the paging message or in the newly introduced R2D message following the paging message.

Proposal 2 – To support selecting of Msg2 monitoring window in association to Msg2 content to allow for a more cost-efficient monitoring window in terms of power consumption and delay.

TDoc file reading error

3GPP TSG-RAN WG2 #130	R2-2504159
St Julian’s, Malta, 19-23 May 2025

Agenda Item:	8.2.3
Source:	Ericsson
Title:	UL multiple access for Ambient IoT
Document for:	Discussion/Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	On each access occasion determined by one Access Occasion Trigger message, X time domain resource(s) are available where X is indicated by the reader. In addition, Y frequency domain resource(s) with the same data rate can be available.
Observation 2	Different devices which have chosen same random number in the same access occasion can be differentiated based on their resource indices in Msg2.
Observation 3	For CFRA, it is assumed that the reader knows at least the number of devices (e.g., provided by CN) to allocate contention free resources corresponding to the number of devices.
Observation 4	The device can find its resource in the resource list included the paging message according to an implicit mapping rule, e.g., the device can locate its resource in the resource list according to the position of its device ID in the device ID list.
Based on the discussion in the previous sections we propose the following:
Proposal 1	The Access Occasion Trigger message doesn’t include Msg1 resource allocation.
Proposal 2	Upon reception of a paging message, the device randomly selects Msg1 resources that are allocated by the paging message.
Proposal 3	The paging message includes the first Access Occasion Trigger message in CBRA,
Proposal 4	The Access Occasion Trigger message is 1 byte.
Proposal 5	Device determines CBRA failure in the current access round if one of the below conditions is met:
i.	No successful reception of Msg2 after transmission of Msg1.
ii.	Reception of Msg2(s) not including its random ID after transmission of Msg1.
iii.	Reception of a NACK message addressed to the device.
Proposal 6	In case there are multiple resources configured, reader signals to the devices a mapping between resources indices and received random IDs in Msg2. FFS on how to index resources in the same access occasion determined by one Access Occasion Trigger message
Proposal 7	Msg2 need not contain an indication of the number of random IDs.
Proposal 8	Include one bit indicating AS ID presence/absence for each entry of the random ID included in Msg2.
Proposal 9	If the AS ID is absent for a random ID in Msg2, the corresponding device assumes that the reader will use the random ID to address the device.
Proposal 10	For CFRA, the reader may trigger the device to perform retransmissions by retransmitting the R2D message or sending a new paging indicating CFRA.
Proposal 11	Support CFRA for multiple devices triggered by a single paging message.
Proposal 12	For CFRA, the AS ID assignment for multiple devices occur in separate device-specific R2D messages.
Proposal 13	For CBRA, device determines to re-access if device receives NACK message when the device receives the subsequent Access Occasion Trigger message.
Proposal 14	For CBRA, it is up to reader implementation to send an additional Access Occasion Trigger message to devices.
Proposal 15	For CBRA, support a new R2D message type for the NACK message.
Proposal 16	Multiplexing of information for multiple devices in NACK message is supported.

4	

3GPP TSG-RAN2 Meeting #130	R2-2504221
St. Julians, Malta, May 19th – 23rd, 2025	

Agenda item:	8.2.3
Source:	Qualcomm Incorporated
Title:	Views on Random Access Aspects of Ambient IoT 
WID/SID:	Ambient_IoT_solutions – Release 19
Document for:	Discussion and Decision

Conclusion
We have the following observations, and we’d recommend RAN2 to discuss and adopt the following proposals:
Proposal 1: Use A-IoT Msg1 and A-IoT Msg2 as message names in the CBRA procedure.
Proposal 2: For the new R2D message indicating the start of a set of MSG1 resources that were configured in the paging message, keep the name ‘R2D trigger message’ (i.e. no need to change to ‘Access Occasion Trigger message’).
Proposal 3: The A-IoT device randomly selects the access occasion from the A-IoT access resources configured by the A-IoT paging message. The resource selection is not based on the R2D trigger message.
Proposal 4: No D2R scheduling information is included in the R2D trigger message. 
Proposal 5: Only the message type is included in the R2D trigger message.
Proposal 6: The first set of A-IoT access occasions for Msg1 can be directly indicated from the A-IoT access resource configuration in the A-IoT paging message. The R2D trigger message indicates the start of the subsequent set(s) of A-IoT Msg1 access occasion(s).
Proposal 7: If no echoed random ID is received in A-IoT Msg2 or A-IoT Msg2 is not received, A-IoT device considers the contention resolution as failed and performs A-IoT re-access upon receiving next A-IoT paging message.
Proposal 8: During a CBRA procedure, the TB size is the same for all A-IoT Msg3 access occasions indicated by a single A-IoT Msg2 (i.e. A-IoT Msg2 can include a single TB size indication even for the case when contention is resolved for multiple devices by a single Msg2).
Proposal 9: The R2D trigger message for CFRA is not supported.
Proposal 10: The ‘re-access’ of contention-free A-IoT access is achieved by Reader sending the paging message again to the target A-IoT device.
Proposal 11: In Rel-19, for multiple devices contention-free A-IoT access, it can be achieved by Reader implementation to trigger each A-IoT device in sequence.
Proposal 12: Reader can trigger A-IoT Msg3 retransmission by retransmitting A-IoT Msg2 with the previously used ID (either the random ID or AS ID, if assigned in A-IoT Msg2).
Proposal 13: The A-IoT device should retransmit the A-IoT Msg3 if the A-IoT Msg2 including the random ID or AS ID is received again.
Proposal 14: A-IoT Msg2 does not include additional information other than the echoed random ID to address the contention resolution of A-IoT devices.
Proposal 15: The R2D trigger message is not used for A-IoT re-access. Only the subsequent A-IoT paging message is used for re-access.
Proposal 16: An explicit ACK indication is introduced to indicate the end of the whole procedure for the particular A-IoT device.
Proposal 17: NACK feedback indication can be sent before the next R2D trigger message.
Proposal 18: The NACK indication can include ID information of multiple failed A-IoT device(s).

3GPP TSG-RAN2 Meeting #130			R2- 2504372
Location, Country, Date

Agenda item:	8.2.3
Title:	Further consideration on A-IoT random access
Source:	CMCC
Document for:	Discussion

Conclusion
Based on the abovementioned analysis and observations, the following is proposed.
Overall:
Observation 1: It’s beneficial to keep R2D messages which are supposed to be sent massively, e.g., CBRA R2D trigger message and A-IoT Msg2 short and compact to reduce the signaling and energy overhead and accelerate random access procedure.
Proposal 1: Byte alignment is not mandatory at least for R2D message that will be frequently transmitted, e.g., R2D trigger message and A-IoT Msg2.
Proposal 2: RAN2 agrees the following WA on CBRA D2R grant, which can be revisited if RAN1 does otherwise:
D2R resource indication for A-IoT Msg1 is preconfigured in A-IoT paging message and activated by R2D trigger message.
D2R resource indication for A-IoT Msg3 is indicated in A-IoT Msg2 by default.
CFRA for multiple devices:
Proposal 3: CFRA for multiple devices is not supported in Rel-19.
CFRA trigger message:
Proposal 4: As CFRA does not need randomization, i.e., device to random select resource and generate random ID, the A-IoT paging message can be reused as the CFRA trigger message.
CFRA failure detection:
Observation 2: In CFRA, reader can use a D2R time threshold, e.g., TD2R_max, CRC and energy detection to detect any D2R or R2D failure.
Proposal 5a: In case reader detects a failure in CFRA, reader can resend the CFRA paging message to initiate a new round of CFRA procedure unless CN indicates otherwise.
Proposal 5b: The maximum number of resending for the CFRA paging message, if not configured by CN, can be determined by implementation.
Proposal 5c: As a baseline, it is recommended to allow at least 5 times of paging message resending in case of CFRA failure. FFS it can also be applied to A-IoT Msg3 retransmission triggered by A-IoT Msg2.
CBRA trigger message:
Observation 3a: Devices in CBRA need some time to randomly select an access occasion and generate a random ID. Merging the trigger message into the paging message may require a longer response time threshold.
Observation 3b: RAN1 may need to define a new time threshold specifying the interval of paging message and A-IoT Msg1 if paging message is also the first CBRA trigger message.
Proposal 6: To minimize specification impact, the first CBRA R2D trigger message is suggested not to merge into the paging message.
Observation 3c: Devices that miss their access occasions due to CBRA R2D trigger message failure can be addressed by reader sending additional trigger messages and offering more access occasions.
Proposal 7: The CBRA R2D trigger message should be short and simple for efficiency.
Proposal 8: For simplicity, reader should indicate X=1 and X=2 for time domain resources in the A-IoT paging message, making it effective for the entire paging round.
A-IoT Msg1:
Proposal 9a: A-IoT shall implement a (pseudo-)random number generator (RNG) to randomly select access occasion and generate the 16-bit random ID, RAN2 may specify some requirements, e.g., uniformity and independence later.
Proposal 9b: To avoid the devices that generate the same random ID also select the same access occasion and thus A-IoT Msg3 collides, device should generate 2 independent random numbers for access occasion selection and random ID.
Proposal 9c: Device shall generate a new random ID for every selected paging round to avoid random ID collision.
Observation 4: In FDM or TDM with X=2, random ID collision in A-IoT Msg1 can be identified by A-IoT Msg3 failure and reader can use the NACK message to initiate re-access for random ID collided devices.
Proposal 10a: The random ID collision can be addressed by existing re-access mechanism triggered by NACK message after A-IoT Msg3.
Proposal 10b: For endorsement, any further enhancement or optimization to address random ID collision should be postponed to Rel-20.
A-IoT Msg2:
Proposal 11a: A-IoT Msg2 may consist of multiple A-IoT MAC RARs.
Proposal 11b: A-IoT MAC RAR may consist of an A filed indicating the presence of AS ID, echoed Random ID, and D2R grant for A-IoT Msg3 whose details is up to RAN1.
A-IoT Msg3:
Proposal 12a: A-IoT Msg3 should consist of device ID only.
Observation 5: For current RAN2 agreements, the devices that generate the same random ID and select the same access occasion will also be assigned with the same AS ID. Only the NACK message can indicate A-IoT Msg3 failure and AS ID invalidity to these devices. 
Proposal 12b: Device should consider the AS ID is invalid if it receives the NACK message echoed the same AS ID.
A-IoT Msg4:
Proposal 13: To shorten the time device monitoring PRDCH, the NACK message, or A-IoT Msg4, should be sent before next CBRA trigger message.
Proposal 14a: Similar to A-IoT msg2, the NACK message can also be multiplexed if A-IoT Msg3 is FDMed or TDMed with X=2.
Proposal 14b: For multiplexed A-IoT Msg3 transmission, two options for NACK feedback can be studied, both are only sent when NACK exists for Msg3,
Option 1: only NACK information is sent with AS ID to identify device
Option 2: bitmap is used with both NACK and ACK information.
CBRA failure detection:
Proposal 15a: RAN2 agree the WA that reader should consider the access attempt as failure and initiate re-access when:
A-IoT Msg1 collision, where reader detects the energy of the D2R message but cannot decode it.
A-IoT Msg2 reception failure at device side, where reader detects no energy on the D2R resource for A-IoT Msg3. Reader can resend the same A-IoT Msg2, but if it’s not improving, reader should initiate re-access and consider the AS ID as invalid.
A-IoT Msg3 failure caused by random ID collision, where reader detect energy on the D2R resource for A-IoT Msg3 but cannot decode it or CRC is wrong.
A-IoT Msg3 failure caused by reception and transmission failure, where reader detects no energy on the indicated resource or detects energy but fails to decode it.
Proposal 15b: RAN2 agree the WA that device should consider the access attempt as failure and wait for re-access when:
A-IoT Msg1 collision, or A-IoT Msg1 reception failure at reader side, or A-IoT Msg2 reception at device side, where device receives no A-IoT Msg2 or the received Msg2 is not reflecting its random ID.
A-IoT Msg3 failure caused by random ID collision, or reception failure, or transmission failure, where device receives the NACK message.

3GPP TSG-RAN WG2 Meeting #130                                    R2-2504454
St. Julien, Malta, 19th – 23rd May 2025

Agenda Item	: 8.2.3 (Ambient_IoT_solutions)
Source	: LG Electronics Inc.
Title	: Discussion on random access aspects for Ambient IoT
Document for	: Discussion and Decision

Conclusion
Based on the above discussion, we made following proposals and observations.
Proposal 1. A new timer for Msg2 reception is not introduced to determine the contention resolution failure
Proposal 2. If the access occasion trigger message is received after transmitting the Msg1, the A-IOT device considers the contention resolution as failed.
Proposal 3. The number of time/frequency domain resources for Msg1 is indicated in the A-IOT paging message in a static manner within the paging round.
Proposal 4. The time/frequency information should be contained in Msg2. 
Proposal 5. The index is pre-defined for each Msg1 resource within one access occasion.
Proposal 6. In Msg2, the bitmap field should be introduced to indicate the presence/absence of the random number. 
Proposal 7. The absence of the NACK feedback is considered as successful transmission of the Msg3.
Proposal 8. A new R2D MAC PDU format for NACK feedback should be defined.
Proposal 9. The NACK feedback should contain the information on at least one A-IOT device requiring the re-access procedure.
Proposal 10. Only time/frequency information should be contained in NACK feedback. 

3GPP TSG-RAN WG2 Meeting #130	R2-2504466
St.Julians, Malta, May 19th – 23rd, 2025

Agenda Item:	8.2.3
Source:	HONOR
Title: 	Discussion on A-IoT random access
Document for:	Discussion and decision
1	

Conclusions
In this contribution, we discussed the issues related to the random access procedure and failure handling aspects on Ambient IoT. Based on the  discussion, the following observation and proposals are concluded:
Observation 1: The device would regard the D2R transmission as failure if it has not received the corresponding mandatory R2D transmission, for example, the Msg2 is not received after sending the Msg1.
Observation 2: It is hard for the device to detect D2R data transmission failure if it has not received explicit R2D failure/success feedback indication since the subsequent R2D transmission is optional based on the reader implementation.
Observation 3: Failure could be detected from perspective of device based on the TD2R_max (maximum time between the D2R transmission and the corresponding R2D transmission following it) defined by RAN1.
Proposal 1: (Issue 2-4) Support the failure detection based on a timer which could be pre-configured time in the R2D trigger or the pre-defined time in RAN1. 
Proposal 2: (Issue 2-4) The subsequent R2D transmission for the device indicates that there is no failure handling for the last D2R message.
Proposal 3: (Issue 2-4) The absent of subsequent R2D transmission (e.g., Msg2 after Msg1 in CBRA) indicates the device should perform failure handling caused by D2R failure.
Proposal 4: (Issue 2-4) The present of the NACK indicates the device(s) to perform the failure handling.
Proposal 5: Device could perform re-access or D2R re-transmission upon failure detection by the device if allowed or when it is indicated by the reader.
Proposal 6: (Issue 2-11) One R2D message could be introduced to indicate the NACK for re-access or the scheduling of (re-) transmission of the last D2R message.
Proposal 7: NACK messages could be used by the reader to allocate resource(s) for re-transmission or indicate re-access before the subsequent R2D trigger.
Observation 4: Unless multi-reader scenario could be solved by implementation, more information (e.g., transaction ID) is needed to resolve the collision issue.
Proposal 8: (Issue 2-7) For CBRA, RAN2 to discuss at least the following information carried in Msg2 related to AS ID:
- the information about whether to reuse RN16.
- the information about whether to newly assign and the assigned AS ID.
Observation 5: Two devices would both transmit the Msg3 with the same frequency resource if the same RN is transmitted in the same slot.
Proposal 9: (Issue 2-5/ Issue 2-6) Information related to the resource could be used to indicate if RN16 is echoed the device using the resource to transmit its Msg1. 
Proposal 10: (Issue 2-7) Information related to the resource could be used to indication the absent/confirmation/assignment of AS ID to device using the resource to transmit its Msg1.
Proposal 11: (Issue 2-2) RAN2 to confirm that the paging message can be used to indicate the start of the first set of MSG1 resources. 
Proposal 12: (Issue 2-2) A paging message can be followed by one or multiple R2D trigger message(s) which indicates the start of a set of MSG1 resources.
Proposal 13: (Issue 2-1) For the resource selection for Msg1, the device:
randomly selects its time domain number based on the total number of time domain provided in the paging message,
finds its exact time domain based on the trigger and time domain after the previous R2D triggers,
 randomly selects among FDMA occasions in its time domain.
Proposal 14: Support NACK message could be applied to contention resolution (e.g., NACK for Msg1).
Proposal 15: NACK could also be applied to D2R data (e.g., NACK for command response).
4	

3GPP TSG RAN WG2 #130				R2-2504490
St. Julians, Malta, May. 19th – 23rd, 2025	

Agenda Item:	8.2.3
Source:		ASUSTeK
Title:				Discussion on Ambient IoT random access
Document for: Discussion and Decision

Conclusion
Proposal 1:  The information of time domain resources is included in the R2D trigger message.
Proposal 2:  For Msg1 resource selection, the device randomly selects an access round from the total number of access rounds included in the paging message, and randomly selects a time domain resource from the number of time domain resource within the access round included in the R2D trigger message for the access round.
Proposal 3:  The R2D trigger message could include NACK indication.

3GPP TSG-RAN WG2 Meeting #130	R2-2504536
St.Julians, Malta, May 19th – 23rd, 2025

Agenda item:		8.2.3
Source:				Samsung
Title:						Discussion on A-IoT random access
Document for:		Discussion 
1 

Conclusion
Based on above, RAN2 is requested to discuss and agree on the following proposals:
Proposal 1: Introduce 1 bit to indicate the value of X (X=1 or X=2) time domain resource(s) for Msg1 transmission(s) in R2D trigger message for CBRA. 
Proposal 2: R2D trigger message is byte-aligned.  
Proposal 3: R2D trigger message is NOT needed in CFRA. For CBRA, the device is allowed to transmit Msg1 without receiving R2D trigger message after paging message i.e., when initial counter value with 0 is selected at Msg1 resource selection.  
Proposal 4: Msg2 does not contain Msg1 resource identifier for CBRA. 
Proposal 5: RAN2 waits further RAN1 progress on the necessity of indicating the number of echoed random IDs in Msg2. 
Proposal 6: New R2D NACK feedback message is defined as one R2D MAC PDU including one or more AS IDs about failure of Msg3 reception from device(s).  
Proposal 7: Scheduling information is NOT included in the R2D NACK feedback message. 
4 

3GPP TSG RAN WG2 #130	                                           R2-2504581
St Julian’s, Malta, May 19th – 23th, 2025

Source:	CEWiT
Title:	A-IoT Random Access
Agenda Item:	8.2.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on random access for A-IoT. The proposals are summarized as follows.
Proposal 1: 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 2: R2D trigger used to determine the start of the RACH time window for transmission of MSG1 is supported.
Proposal 3: Support to generate the random number based on Q value configured in paging message by the A-IoT device for transmission of MSG1 in the predefine RACH time window.
Proposal 4. 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 5: Support to reuse the same resources of MSG1 transmission in absence of explicit indication in Msg 2 to determine the transmission resources for MSG3. 
Proposal 6: Support the timer based approach for monitoring the NACK feedback by the A-IoT device in case of MSG3 failure. 

Proposal 7: Support the following device behavior in case of failure of D2R (i.e., not receiving subsequent R2D or receiving NACK in subsequent R2D)
Retransmission of D2R
Declare procedure failure and start monitoring the service request

Proposal 8: Support the time based monitoring window for R2D to enable the device to detect D2R failure and respond accordingly.