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

Agenda item:		8.2.4
Source:		Futurewei
Title:		Open issues on A-IoT data transmission and other aspects
Document for:		Discussion and Decision

Conclusions
Observation: the device’s earlier transmission of the first D2R segment can serve as an acknowledgement that the upper layer command has been received correctly.
Therefore, we propose the following:
Proposal 1. When D2R segmentation occurs, the D2R upper layer data SDU is segmented in the unit of bit. And for segment retransmission, the offset is indicated in the unit of bit.
Proposal 2. When D2R segmentation occurs, MAC padding bits may be used only for the last segment.
Proposal 3. The upper layer command does not need to be included in the R2D message scheduling for non-first segment.
Proposal 4. RAN2 consider using a presence bit or a Data SDU Length field set to value 0 to indicate the absence of the Data SDU field and hence the absence of the upper layer command.
Proposal 5. If the device had previously sent a D2R Upper Layer Data Transfer message with the More Data Indication set to True, receiving the R2D Upper Layer Data Transfer message with no Data SDU field serves as both an acknowledgement of receiving the previous segment and a prompt for the next segment.
Proposal 6. If the device had previously sent a D2R Upper Layer Data Transfer message with the More Data Indication set to False, the reader should not send an R2D Upper Layer Data Transfer message with no Data SDU field in response. However, if the reader has another command to send to the device, the reader can send another R2D Upper Layer Data Transfer message with the Data SDU field carrying the next command, which also implicitly acknowledges the reception of the previous D2R transmission, as RAN2 had agreed before.
Proposal 7. As a uniformed design, all R2D Upper Layer Data Transfer messages scheduling for the first segment or unsegmented message, whether for initial transmission or retransmission, should not include an Offset field, but should include the Data SDU field to carry the command, as RAN2 has agreed. 
Proposal 8. The device receiving the command will always respond by transmitting its upper layer response from the beginning, no matter whether the upper layer response is to be segmented or not and no matter whether it is the initial transmission or a retransmission, which is the intended behavior.

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

Source:	vivo
Title:	AIoT Data Transmission
Agenda Item:	8.2.4
Document for:	Discussion and Decision

Conclusion
In this contribution, remaining issues on AIoT data transmission and other general aspects are discussed, and we have the following observations:
For CBRA, the device can store the Random ID after transmitting MSG1.
For CBRA, the device can store the AS ID, which is promoted based on the value of the Random ID field or AS ID field after receiving MSG2.
For CBRA, it is beneficial that the device only stores Random ID or AS ID but not both, for the sake of saving device memory and reducing device cost.
Command in every R2D message for transmission of the segments after the first segment has the following concerns:
Whether the generated D2R messages in response to different receptions of the same CMD are completely the same;
R2D resource overhead increase for repeated transmissions of the same command;
The processing delay and additional energy consumption of the device.
Based the above discussions and observations, we have the following proposals:
AS ID
RAN2 to confirm that, for CFRA multi-device scenario is NOT supported in this Release, i.e., as to the AS ID assignment for CFRA, only consider the scenario that a single device is performing the procedure with the given reader.
Introduce an explicit release message that includes an AS ID field to indicate the AS ID release for a given device. This explicit release message also indicates the end of the current session/service for this given device.
A device performing a CBRA procedure is not required to store both Random ID and AS ID, i.e., the device can store the AS ID and release the stored Random ID immediately after successful contention resolution by MSG2. 
For CBRA, if the device has a stored Random ID only (i.e., no stored AS ID), only MSG2, wherein the value of the Random ID field included in MSG2 is matched with its stored random ID, is further processed, while other R2D messages are ignored.
For CBRA, if the device has a stored AS ID only (i.e., no stored Random ID), only MSG2, wherein the value of the AS ID field in MSG2 is matched with its stored AS ID, and R2D command MSG, wherein the value of the AS ID field in R2D command MSG is addressed to its stored AS ID, are further processed, while other R2D messages are ignored.
D2R Segmentation
The Command is not included in the R2D messages for transmission/retransmission of the segments after the first segment of a D2R message. If not agreeable, RAN2 should send an LS to ask SA2/SA3 to confirm whether the D2R messages generated by the same device in response to different CMD repetitions are completely the same.
For the transmission/retransmission of the first segment/unsegmented D2R message, offset zero is not included in the R2D message.
The offset indication for transmission/retransmission of the segments after the first segment of a D2R message is 8-bit length in bytes.
D2R MAC PDU format
SDU length field is used to indicate how many SDU bytes are present in D2R MAC PDU.
Message type field is not needed for D2R messages. 
The D2R MAC PDU for data transmission contains the following fields:
More Data Indication;
Length indication of a Data SDU;
Data SDU;
MAC Padding, if any.

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

Source:	CATT
Title:	Discussion on the A-IoT Data Transmission
Agenda Item:	8.2.4
Document for:	Discussion
1.	

Conclusion
Based on the analysis in the Section 2, the conclusions of this paper are summarized as follows:
Observation 1: The handling of non-initial segment retransmissions is implementation-dependent, with devices autonomously deciding whether to store or respond to received commands.
Observation 2: From the device perspective, it should release the AS ID as soon as possible controlled by the reader since the reader cannot predict when the new service request will come.

Further consideration on the segmentation for D2R
Proposal 1: (3-1) The upper layer command should be included in the R2D message for retransmission scheduling of non-first segments by the reader.
Proposal 2: (3-2) Offset zero is included in the R2D message along with the upper layer command for the retransmission of the first segment or unsegmented D2R message.
AS ID release
Proposal 3: (3-3) The service end indication (i.e., 1 bit) is included in the last subsequent paging associated with the same transaction ID. The device releases the AS ID upon receiving the service end indication.
D2R MAC PDU format
Proposal 4: (3-4) A fixed 10-bit SDU length field is included when the MAC PDU includes both MAC SDU and padding bits.
Proposal 5: (3-5) No need to introduce the field of D2R message type in Rel-19.
No available upper layer data for D2R scheduling
Proposal 6: (3-6) RAN2 assumes the device sends the “the operation result indication response” in NAS message to the reader upon finishing the write operation.
Proposal 7: (3-6) Send LS to RAN1/RAN4 to confirm whether there is an issue that D2R data is not available for the PDRCH transmission due to a long write time for the write operation by the device. 
Proposal 8a: (3-6) The device ignores the D2R scheduling if “the operation result indication response” in NAS message is not generated by the device.
Proposal 8b: (3-6) It’s up to reader to re-transmit the R2D Upper Layer Data Transfer message containing a new D2R Scheduling Info along with the write command to device.
Proposal 8c: (3-6) Device directly responds the write command re-transmitted by the reader with the “operation result indication” if the device had finished the same write operation by previous write command.
4. 

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

Agenda Item:	8.2.4
Source: 	Xiaomi
Title:  	Remaining open issues on Data transmission
Document for:	Discussion and decision

Conclusions
Based on the above discussion, we propose following proposals:
Segmentation
Proposal 1: (Issue 3-1) RAN2 to agree that for the retransmission of the non-first segment D2R message, the reader sends the R2D message by including the upper layer command again. 
Proposal 2: (Issue 3-2) RAN2 to agree that offset zero is always included for transmission/retransmission of first segment/unsegmented D2R response.

AS ID
Proposal 3: (Issue 3-3) RAN2 to agree that AS ID should be released upon receiving paging message with a new transaction ID, no matter whether the paging is for that device or not.

D2R message content
Proposal 4: (Issue 3-4) RAN2 to agree to define a SDU length field to indicate the length of MAC SDU. The size of the SDU length field is 7 bits. 
Proposal 5: (Issue 3-5) RAN2 to agree that D2R message type is not needed.

R2D message content
Proposal 6: (Issue 2-7) Introduce different R2D msg type for Msg2 used for inventory only procedure and Msg2 used for invenroty+command procedure. 

RN16 validity
Observation 1: For CBRA, RN16 should be stored separately and cannot be replaced directly by AS ID. 
Proposal 7: RAN2 to agree that for CBRA, RN16 should be stored separately as long as generated and released/replaced upon:
Successful transmission of Msg3, i.e., upon reception of subsequent R2D message triggering re-access with no NACK received 
Receiving the NACK for the device after the transmission of Msg3
Receiving the paging message with a new transaction ID, i.e., different session/service
Replacement by a new RN16, i.e., when it triggers new msg1 transmission as a result of receiving paging message (i.e., it has to generate a new RN16 for CBRA)

3GPP TSG RAN WG2 Meeting #130                                                            R2-2503520
St Julian's, Malta, May 19th - 23rd, 2025
Agenda item:	8.2.4
Source:	Ofinno
Title:	Discussion of new issue: success/failure of D2R message(s)
Document for:	Discussion and decision

Conclusion
The observations captured are the following: 
Observation 1.	After sending any D2R message, the A-IoT device is not aware whether or when to consider this message successful. This may impact negatively to the A-IoT device (e.g., if it keeps the previously transmitted D2R message until next applicable R2D message is received or the A-IoT procedure is terminated), or to the network (e.g., if the A-IoT device always considers a transmission of a D2R message as successful upon its transmission).
Observation 2.	RFID technology already defines multiple/different timers for the diverse scenarios and pairs of transmission/reception (as captured in §6.3.1.6.5 of RFID specification).

The proposals captured are the following: 
Proposal 1.	[New issue] To define a mechanism for the device to determine when the transmission of the D2R message is or can be considered successful or failure via a new short timer (TD2R_ACK) which works as follows:
Proposal 1.1.	Point (A) Upon transmission of the D2R message, 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 1.2.	Point (B) While TD2R_ACK is running, the device’s behaviour upon reception of the applicable R2D messages is defined case by case in A-IoT specification (including for both, failure and success).
Proposal 1.3.	Point (C) Upon expiry of TD2R_ACK, the device considers previously transmitted D2R message as successful or failed.

TDoc file reading error

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


Agenda Item:	8.2.4
Source:	Ericsson
Title:	A-IoT Data Transmission Aspects
Document for:	Discussion/Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	Msg3 D2R upper layer data transfer may need to carry security information in support of authentication procedure thus may require segmentation.
Observation 2	In case of segmentation, 1-bit indication from device is sufficient to manage resources except for allocation resources of last segment.
Observation 3	The device ID selection behavior in Msg3 is not settled in SA3. This may pose difficulty related to offset based mechanism for segmented transmission.
Observation 4	For segmented transmission, if re-access is triggered, the device begins transmission from the scratch (or with a first segment if segmentation needed) in a new occasion after passing contention.
Observation 5	Four R2D message types have been identified: A-IoT Paging message, Access Occasion Trigger message, Random ID Response message (Msg2), R2D Upper Layer Data Transfer message.
Observation 6	Aim is to restrict to fewer message types, and utilize a given message for multiple purposes. E.g., Random ID Response message Msg2 can be utilized to perform/indicate initial or re-transmission of Msg3 with or without segments, or NACK to trigger re-access.
Observation 7	A-IoT paging message may need to include security information to support device authentication, pending SA3 progress.

Based on the discussion in the previous sections we propose the following:
Proposal 1	No need of message type field in D2R message.
Proposal 2	Depending on progress from SA3, RAN2 may need to revisit the segmentation support for Msg3 D2R upper layer data transfer, i.e., in case additional security information is included.
Proposal 3	The length field indicates the size of the D2R MAC SDU with variable size
Proposal 4	Use 7 bits for the length field in MAC PDU for D2R.
Proposal 5	An unsegmented transmission can be retransmitted in similar manner as segmented transmission by indicating a zero offset.
Proposal 6	R2D message scheduling non-first segment (re)transmission does not include upper layer command.
Proposal 7	Multiplexing of information for multiple devices in R2D message after Msg2 is not supported.
Proposal 8	RAN2 should wait for SA3 progress on whether paging message needs to include security information for authentication.
Proposal 9	A-IoT paging message for CFRA can omit the paging ID presence/absence indicator, transaction ID, and number of access occasions.
Proposal 10	In case multi-device CFRA is supported, RAN2 to revisit if paging message format for CFRA and CBRA can be unified or not.
Proposal 11	Support 7-bit length field in MAC PDU of R2D message with NAS information of variable size.
Proposal 12	MAC PDU for the Random ID Response message (Msg2) includes:
	R2D message type
	One or multiple RN16s subject to message size limitation, for each of RN16 there are associated control information, including
o	RN16 value
o	Presence/absence indicator for AS ID (in case of AS ID assignment)
o	Scheduling information for Msg3
Proposal 13	For CBRA, from a device’s perspective, AS ID is valid until completion of the inventory + command procedure (Option 4b).
Proposal 14	Device considers procedure completed upon reception of an access occasion trigger message.

4      

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

Summary and proposal
Proposal 1.	(Issue 3-1) Upper layer command is not included in R2D message scheduling for non-first segment or for retransmission of segments.
Proposal 2.	(Issue 3-1) If Proposal 1 is not agreeable, send an LS to SA3 to ask feedback on whether/how to co-exist with replay protection of upper layer message.
Proposal 3.	(Issue 3-2) Offset is not included in R2D message to schedule first segment or unsegmented D2R message.
Proposal 4.	(Issue 3-3) The reader releases the AS ID when an R2D message is sent to the device.
Proposal 5.	(Issue 3-4) D2R message includes an SDU length field if a MAC PDU includes both MAC SDU and padding.
Proposal 6.	(Issue 3-5) Introduce D2R message type field.

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

Source:	China Telecom
Title:	A-IoT data transmission 
Agenda Item:	8.2.4
Document for:	Discussion and Decision

Conclusions in SA WG2.

3GPP TSG-RAN WG2 Meeting #1230												             R2-250xxxx
St Julian’s, Malta, 19-23 May 2025									  									  
Agenda item:	8.2.4
Source:	Apple
Title:	Remaining issues in data transmission
Document for:	Discussion and Decision

1	

Proposals
Observation 1: spare/reserved bits can be used for future extensions ; however we can’t rely on them exclusively for extensibility.
Observation 2: message type (with sufficiently large unused message type space) can be used for future extensions; this may be an additional motivation to introduce message type in D2R.
Proposal 1: to discuss which future extensibility mechanism to support in both D2R and R2D amongst: 
Protocol version 
Extension bit 
Message types (with sufficiently large “space”)
Proposal 2: to support message type in D2R direction.
Observation 4: there is no difference whether to indicate D2R SDU length or D2R padding length , in both cases the maximum length should be equal to the maximum SDU length.
Proposal 3: select one option between SDU length or padding length; the length size (regardless of the option chosen) is equal to the maximum SDU size.
Observation 5: A subsequent request for the same offset as the one previously signalled is in fact equivalent to NACK signalling.
Proposal 4: explicit NACK for D2R data is not needed.
Proposal 5: device ignores offset equal to 0.
Proposal 6: there is no needed to include a command when triggering retransmissions of segments other than the first one (i.e. offset>0).
Observation 6: as there is no RRC in Ambient IoT, optional features cannot be realized through capability signalling.
Proposal 7: optional features (e.g. segmentation and more data indication) are designed in a way that capability signaling is not required .
Proposal 8: for more data indication, 1 indicates device has more (beyond the current grant) data to transmit and 0 otherwise (or if the device doesn’t support the feature).
5	

3GPP TSG RAN WG2#130                                                                                  R2- 2503750
St.Julians, Malta, May. 19th– 23rd, 2025
Agenda Item:	8.2.4
Source:	OPPO
Title:	Discussion on AIoT data transmission related functionalities 
Document for:	Discussion, Agreement

Conclusion
We have the following proposals:
Consideration on segmentation retransmission:
Proposal 1: offset zero shall not be included in the R2D message triggering re-transmission of the first/unsegmented D2R message.
Proposal 2: the upper layer command is not needed to be carried in the R2D message to trigger the D2R message following segment re-transmission/transmission.
NACK based mechanism for subsequent D2R message:
Observation 1: the AIOT device needs to determine whether or not it shall perform re-access to the Reader when a subsequent A-IOT Paging message with the same transaction ID is received, or determine if it shall terminate the ongoing procedure to follow the new A-IOT paging message with another transaction ID.
Proposal 3: NACK feedback indication-based NACK mechanism applies to D2R message also.
Proposal 4: when receiving R2D trigger message, the A-IOT device who previously transmit the D2R message stops monitoring for the NACK message.
Proposal 5: the A-IOT device shall perform re-access to the Reader, when it receives a subsequent A-IOT Paging message with the same transaction ID as the previous one including the AS ID or device ID of it.
Proposal 6: the device shall maintain its AS ID until a subsequent A-IOT Paging message with new transaction ID is received.
How to end the current access procedure:
Observation 2: for option B, stringent coordination between Readers covering overlapping areas is necessary, in order to avoid terminating other Reader’s on-going procedure by triggering a new Paging message.
Observation 3: for Option A, the timer-based solution suffers from the bad clock synchronization performance.
Proposal 7: the R2D trigger message shall be employed to indicate the end of the access procedure for A-IOT device in the procedure.
Proposal 8: the validity of the AS ID shall not be terminated by the R2D trigger message.
Design of MAC PDU format:
Proposal 9: the number of TDM or the number of triggered Msg1 resources, i.e., TDM multiplied by FDM number, shall be provided by the R2D trigger message.
Observation 4:  in the CBRA scenario, if R2D message is needed to be sent to each A-IOT device individually, then messages should be sent one-by-one in time domain. Correspondingly, each A-IOT device shall parse these messages one-by-one to see if one of the messages is destined to itself, which causes heavy burden to these A-IOT devices.
Proposal 10: allow packaging contents for different A-IOT devices in the same R2D message, besides A-IOT Msg2.
Observation 5: setting a common header field could let A-IOT devices not involved in the current access procedure skip parsing the message content part.
Proposal 11: place a common header field, consisting of the message type to indicate the purpose of the message, in the beginning of the 5G A-IOT R2D MAC PDU. 
Proposal 12: MAC subPDUs destined to targeted A-IOT devices consisting of the sub-header and payload are put in sequential order in the 5G A-IOT R2D MAC PDU.
Observation 6: the number of variable part(s) included in the R2D message MAC PDU should be reduced as much as possible. In such way, the need of length fields can be alleviated, which also reduces the decoding complexity for A-IOT devices.
Proposal 13: employing fixed number of bitstream to represent variable parts, e.g., number of total access occasions, number of FDM for D2R transmission, AS ID, etc, for all kinds of R2D message, as much as possible.
Proposal 14: following fields are considered to be included in the sub-header fields for the R2D message in A-IOT system:
the Length field for SDU:  set to 1 byte
the ACK/NACK to the previous transmitted D2R message for triggering re-access (optional): wherein the 1-bit flag being setting to 1 is to indicate NACK and setting to 0 means ACK/NACK feedback is disabled. 
AS IDs for the targeted A-IOT devices are included in the R2D message except the A-IOT paging message.
the Reserved field could be included in the sub-header field, if any blank is left, for future-proof purpose.
Segment retransmission enabling indicator 
Proposal 15: confirm that concatenation of MAC subPDUs including the response for different commands is not needed for the D2R message.
Proposal 16: following fields are considered to be included in the sub-header fields for the D2R message in A-IOT system:
length field: this field indicates the length of the padding field in bytes. If the length field is set 0, it means that padding field is absent in the D2R message.
AS ID

3GPP TSG-RAN WG2 Meeting #130	R2-2503779
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:	8.2.4
Source:	NEC
Title:	Ambient-IoT Data transmission
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following observations and proposals:

Observation 1	The reader is able to know whether there is follow on command upon reception of the “Follow on Command Indication” included in the Inventory Request transfer.
Observation 2	Assigning AS ID in CFRA A-IoT paging message is feasible since the reader knows whether there is follow on command upon reception of the “Follow on Command Indication” included in the Inventory Request transfer.
Observation 3	To simplify processing for the A-IoT device, only one type of MAC PDU that always includes the offset is sufficient.
Observation 4	To keep the A-IoT device simple and cost-effective, only one type of MAC PDU that always includes the upper layer command is sufficient.
Observation 5	The D2R message including both the MAC SDU and the padding comprises only one field of length, indicating the length of the padding.
Observation 6	To keep the A-IoT device simple, the D2R message including MAC SDU always comprises one field of length of the padding.

Proposal 1	Revise RAN2#129bis agreement “For CFRA, command message is used for AS ID assignment.” to “For CFRA, the CFRA A-IoT paging message is used for AS ID assignment.”
Proposal 2	(Issue 3-3) Support an explicit message to release the AS ID to avoid devices keeping AS ID indefinitely.
Proposal 3	(Issue 3-1 and 3-2) Only one type of MAC PDU for the upper layer command that always includes the field of upper layer command and the field of offset is supported.
Proposal 4	(Issue 2-3) The R2D trigger message comprises only the field of R2D Message Type and does not require byte-aligned.
Proposal 5	(Issue 3-4) The D2R message including MAC SDU always comprises one and only one field of length, which indicates the length of the padding.
Proposal 6	(Issue 3-4) The size of the length field is 7 bits.

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

Agenda Item:	8.2.4
Source:	Panasonic
Title:	Discussion on addressing issue for AS ID assignment and segment retransmission 
Document for:	Discussion

Conclusion
In this paper, we have discussed addressing issues for AS ID assignment and upper layer command for segment retransmission . We have the following proposals.
Proposal 1. For CBRA, both RN16 and AS ID in Msg2 are used for addressing purpose. 
Proposal 2. For CBRA, if Msg2 contains responses for multiple devices who have sent Msg1, RN16 or AS ID in the received Msg2 can be used for the identifier of the transmitted Msg1s.
Proposal 3. AS ID field in Msg2 for CBRA is optional. 
Proposal 4. (revert RAN2 previous agreement) RN16 is included in the first D2R message in the CFRA procedure and both RN16 and AS ID are used for addressing the device in the R2D command message of AS ID assignment.
Proposal 5. Upper layer command and offset are always present regardless of whether the R2D message is to trigger (re)transmission of first segment/unsegmented D2R or retransmission of segments. In case of first segment/unsegmented data, offset is indicated as zero.

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

Agenda item:	8.2.4
Source:	Nokia
Title:	AIoT data transmission and other aspects
WID/SID:	Ambient_IoT_solutions - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This Tdoc has provided the following observations and proposals.
Observation 1: Energy-intensive procedures such as segmented transmissions or write commands are likely to fail in devices with low / unreliable energy sources (eg, energy-harvesting devices).
Observation 2: Reporting of energy status allows the reader to determine whether a device is capable to complete its response procedures successfully.
Proposal 1: RAN2 to support energy status reporting by devices:
either reactively upon reader request (e.g. in “inventory and command” scenarios), and/or
proactively by device during transmissions of segmented / repetitive / large payload.
Proposal 2: At least Msg 1 contains the energy status bit for all device types. FFS other messages.
Observation 3: Energy status reports allow the reader to take precautionary measures (eg permitting the device to harvest more energy) by delaying ongoing transmissions and coordinating new requests from other readers.
Observation 2: The definition of AIoT MAC CEs may become complex due to the multifold functionality.
Observation 3: ASN.1 is primarily a markup language and encoding/decoding complexity based on encoding rules.
Observation 4: ASN.1 specifies in human-readable format a set of components to be transmitted over a digital interface.
Observation 5: There are ASN.1 rules for fast, low-complexity encoding/decoding (e.g. OER).
Observation 6: The overhead of simple encoding rules depends on the data to encode (e.g. byte-aligned encoding suffers from large overhead for single Boolean values).
Observation 7: Current MAC specification has many flags indicating different usage of the MAC CE which can be efficient replaced by using enumerations.
Proposal 3: RAN2 to agree that byte-aligned MAC PDUs are sufficient for most MAC CEs. FFS on MAC PDUs having only a few bits.
Proposal 4: RAN2 to model MAC PDUs by using OER ASN.1
Proposal 6: ACK/NACK is needed for a device to acknowledge a write command.
Proposal 7: In case of NACK, RAN2 to discuss whether the energy bit should be sent as well such that the reader can determine whether retransmissions were useful.
Observation 4: RAN1 can implement ACK/NACK by using L1 preambles which allows for efficient ACK/NACK detection at L1 without the need for energy-intensive L2 decoding.
Proposal 8: RAN2 to consult RAN1 whether they can design efficient L1 ACK/NACK implementation.

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

Agenda item:	8.2.4
Source:	Spreadtrum, UNISOC
Title:	Discussion on A-IoT data transmission
Document for:	Discussion and Decision
1 

Conclusion
In this contribution we discuss the functionalities required for A-IoT, with the following proposals:
Proposal 1: Apply message type to D2R MAC header as in R2D direction for forward compatibility.  
Proposal 2: A length field is supported for D2R MAC SDU in MAC header, in case where MAC PDU includes both MAC SDU and padding.
Proposal 3: The size of length field is at least 7 bits.
Proposal 4: Offset zero is always included in the retransmission scheduling R2D message for the first segment/unsegmented D2R message.
Proposal 5: Reader always includes the upper layer command each time in the R2D message triggering the A-IoT device to (re)transmit the segment.
Proposal 6: The command type (e.g., read, write, disable) can be indicated to reader by AIOTF, if D2R message size is not provided by AIOTF.

3GPP TSG-RAN WG2 Meeting #130						        R2-2503970
St.Julians, Malta, May 19 – 23, 2025		         
Source: 	ZTE Corporation, Sanechips 
Title: 	Open issues for data transmission and MAC PDU design
Agenda item:	8.2.4
Document for: 	Discussion and Decision

Conclusion and proposals
The following proposals are made in this contribution: 
Proposal 1 (Issue 1-1): When the device has sufficient energy, the device shall:  
If there is no stored transaction ID: 
Monitor PRDCH for paging messages and store the received transaction ID once a paging message addressed to the device is received
If there is a stored transaction ID: 
Monitor PRDCH for broadcast (e.g. MSG2 and MSG1 trigger messages) and unicast messages (addressed to the device’s ASID) that include the stored transaction ID until the AS procedure (Inventory/Command) is completed (either successfully or unsuccessfully)
Proposal 2 (Issue 1-2): The transaction ID length should be 6 bits
Proposal 3 (Issue 1-1): All R2D messages include a transaction ID either explicitly (e.g. paging message) or implicitly (by masking the CRC with the transaction ID)
Proposal 4 (Issue 3-5): Message type field is included for all messages (including the Random ID message)
Proposal 5 (Issue 2-6, 2-7): The message structures proposed in the figure below should be taken as baseline 

Proposal 6 (Issue 3-1, 3-2): For the retransmission of the first segment/unsegmented D2R message, only the R2D command message is included without the offset
Proposal 7(Issue 3-1, 3-2): For the retransmission of subsequent segments (i.e. after the first segment), only the offset is included (i.e. R2D command is not included).  
Proposal 8(Issue 3-1, 3-2): The granularity of the offset should be designed such that it covers 1 or more D2R TB sizes (including the max D2R TB size) 

TDoc file reading error

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

Agenda Item:	8.2.4
Source:	Huawei, HiSilicon
Title:	A-IoT data transmission
Document for: Discussion and Decision 
1	

Conclusion
This contribution makes the following proposals:
Observation 1:	The reader is not aware which devices will be selected by the paging message of new service. Then, AS ID management per service is not feasible.
Observation 2a:	There are different understandings or reader implementation as to the end of the procedure:
Manner 1: reader should complete the device procedure before next paging, if possible. 
AS ID can be released upon receiving paging with same transaction ID for those successful device.
This is beneficial when one paging round handles thousands of device.
Manner 2: reader may continue the data transmission after/across the subsequent paging.
AS ID should not be release autonomously by device upon paging with same transaction ID.
Then, in this case, many AS ID are occupied before new service, which requires a separate R2D message to release AS ID before the new service.
Observation 2b:	Paging message with 1-bit indication control can allow both reader implementation manners above (i.e. release AS ID either by subsequent paging or by new paging).
Observation 3:	For CFRA, the device should release the AS ID upon receiving paging for new service; otherwise, it may not work since reader cannot associate the “device ID” across two service requests from CN.
Observation 4:	RAN3 agreed to use RAN NGAP Device ID: “Introduce per-session per-device Device Association (“RAN NGAP Device ID”, and “(FFS) CN NGAP Device ID” pair) between gNB and AIOTF, in case of Command after inventory.”
Observation 5:	For command case, it is reader implementation to maintain the association between AS ID and RAN NGAP Device ID for one specific device.
Observation 6:	To further reduce device complexity, some device should be able to not implement segmentation. 
Observation 7a:	For Alt.1, the overhead of R2D upper-layer command or offset field can be saved in different cases.
Observation 7b:	For Alt.2, for each segmentation, device implementation just picks the “segment part” from the upper layer data. It does not matter whether upper layers always provide upper layer response each time.
Observation 8:	The typical size for one R2D command is not large, e.g. below 100bits.
Observation 9a:	Different write command size and different device write speed (depending on the power consumption used for write operation) may cause unpredictable time when the upper layer delivers the “successful write” response to A-IoT MAC.
Observation 9b:	When the reader schedules the D2R transmission for write command response, the D2R upper layer data may not be available/ready yet. In this case, device can just send MAC padding, i.e., no other enhancement is needed.

AS ID release (Issue 3-3)
Proposal 1:	(Issue 3-3) The RAN2 agreement needs to be revised/clarified, since reader has no idea on which devices will be selected by the paging and the corresponding occupied AS IDs: 
“The device releases the AS ID at least: upon receiving Paging with new transaction id for that device, i.e. different session/service”
Proposal 2:	(Issue 3-3) RAN2 to discuss the need of one broadcast R2D message to release all devices’ AS ID (e.g., the paging message includes 1-bit indication).
Proposal 3:	(Issue 3-3) In CFRA, RAN2 confirms that device releases its AS ID, if any, upon receiving paging message. 
Segmentation (Issue 3-1, 3-2)
Proposal 5:	RAN2 agrees that devices should be allowed to skip the D2R transmission/segmentation, when the allocated TBS is not sufficient to accommodate the entire D2R message.
Proposal 6:	(Issue 3-1, 3-2) RAN2 to discuss two alternatives and decide between them:
Alt.1: Two formats of R2D messages are used to trigger the D2R (re-)transmission: 
For the scheduling of non-segmented message or first segment, “R2D upper-layer command” is included and “received size/offset=0” is NOT included;
For the scheduling of non-first segment, “received size/offset” is included and “R2D upper-layer command” is NOT included.
Alt.2:	Single format of R2D message is used to trigger the D2R (re-)transmission: “R2D upper-layer command” and “received size/offset” are always included. 
Proposal 7:	Inform CT1 about the RAN2 conclusion on not supporting R2D segmentation for their considerations, e.g., as to the maximum value of R2D command message size. 
Proposal 8:	RAN2 suggests to RAN3 that the CN should indicate the command type (e.g., read, write, disable) to the reader.
MAC PDU format and others (Issue 2-3, 3-4, 3-6, 4-1)
Proposal 9:	(Issue 2-3) The R2D trigger message need not be byte-aligned.
Proposal 10:	(Issue 3-4) The length field inside MAC for SDU is not needed for R2D messages, assuming R2D MAC padding is not needed.
Proposal 11:	(Issue 3-4) The length field in MAC indicates the size of D2R MAC padding, in the unit of byte, using 7 bits. This (7 bits in the unit of byte) also applies to the “Received Data Size” field used for segmentation.
Proposal 12a:	(Issue 3-6) The D2R response of write operation may cause the case of “the upper layer data is NOT available” upon D2R scheduling.
Proposal 12b:	(Issue 3-6) Allow device to send MAC padding without SDU, in case “the upper layer data is NOT available” upon D2R scheduling.
Proposal 13:	(Issue 4-1) RAN1 will provide the D2R scheduling information parameter list, based on which RAN2 can further determine the information to put into paging message, Msg2 and R2D upper layer data message.
4	

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

Agenda Item: 	8.2.4
Source:		Sony
Title:			Considerations on segmentation and remaining bits
Document for:	Discussion & Decision

Summary
In this contribution, we have discussed our views on aspects related to segmentation and remaining bits, offset and energy level.

Proposal 1: Further discuss whether additional bits would be needed for different use cases.

Proposal 2: The device indicating how many bits are present in the SDU, can be used for indicating total remaining bits if not being the last segment.

Proposal 3: Clarify the definition of offset, and if there is a need to clearly relate the offset to a specific MAC PDU.

Proposal 4: RAN2 to discuss which layer in the device handles information about energy level. Opt1. Upper layer, Opt2. MAC layer, Opt3. PHY layer.

TDoc file reading error

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


Agenda Item:	8.2.4
Source: 	MediaTek Inc.
Title:  	Ambient IoT MAC PDU formats

Document for:	Discussion, decision
1	

Conclusions in SA WG2”, LS from SA2 to RAN2 et al., RAN2#129

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

Agenda item:	8.2.4
Source:	Qualcomm Incorporated
Title:	Data Transmission and Other General Aspects of Ambient IoT 
WID/SID:	Ambient_IoT_solutions – Release 19
Document for:	Discussion and Decision

Conclusion
Based on the discussion above, we’d recommend RAN2 to discuss and adopt the following proposals:
Proposal 1:	A-IoT device segments and transmits the A-IoT upper layer data based on the scheduled TB size from the Reader.
Proposal 2:	The upper layer command (Data SDU) and Received Data Size field are always present in R2D data message (i.e. R2D Upper Layer Data Transfer message in MAC running CR).
Proposal 3:	A length field directly indicates the length of D2R data MAC SDU to support varying lengths of D2R data. The size of length field is FFS.
Proposal 4:	For R2D and D2R data message, a single MAC header is associated with multiple MAC subPDUs in an A-IoT MAC PDU.
Proposal 5:	The concept of logical channels (similar to NR MAC) is also supported for A-IoT MAC.
Proposal 6:	At least two transport channels, i.e., RD-SCH and DR-SCH are supported for A-IoT.
Proposal 7:	From RAN2 perspective, legacy NR UE registration-like procedure is not supported by A-IoT device.
Proposal 8:	From RAN2 perspective, legacy NR NAS functions are not supported by A-IoT device.
Proposal 9:	Update Figure 16.x.3-1 in the current MAC running CR to include the AOTF as well as A-IoT NAS layer (take Figure 3 from R2-2504222 as baseline).

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

Source: 			CMCC
Title:  		    Discussion on data transmission for A-IoT
Agenda item:	8.2.4
Document for: 	Discussion

Conclusion 
According to the above discussion, the following proposals are given:
Segmentation 
Length of offset
Proposal 1: The length of offset indicator can be 7 bits.

Command message in R2D for retransmission of segment
Proposal 2: The start address in command message needs to be stored in the VM of device.
Proposal 3: In case subsequent segment retransmission, the command message does not need to be re-contained in the R2D message.

Offset zero for first segment and Unsegment packet
Proposal 4: For the first segment and unsegmented packet retransmission, the “offset” indicator in R2D is not needed.
Offset in D2R

Proposal 5: The “offset” indicator is not needed in D2R message.

AS ID
Proposal 6: the AS ID should be released in the following cases:
Power off (no change)
Upon receiving paging message with new transaction ID (no change)
Upon CBRA failure (update)
Upon receiving paging message of CFRA (new add)

Write operation response
Proposal 7: From the perspective of RAN2, the reader can obtain the “write” results from the devices with longer processing times through multiple D2R scheduling. 
Proposal 8: If the device has not finished the “write” operation, it feedbacks padding and informs reader about the remaining data.
Proposal 9: The reader shall read the padding length field, no matter if there is remaining data.

PDU format
General 
Proposal 10: NACK message for multiple devices can be multiplexed in one Msg4.
Proposal 11: RAN2 is asked not to consider multiplex command message of different devices within one R2D message.
D2R format
Proposal 12: The MAC header is not required for Msg1 of CBRA and first D2R message of CFRA.
Proposal 13: Message type is not needed for Msg3 and D2R data.

Padding
Proposal 14: Suggest introducing length field of the padding in D2R message. 
Proposal 15: Suggest considering 7 bits length field of the padding.
Proposal 16: RAN2 is suggested to agree the following cases for D2R MAC PDU format:
The remaining data indicator is set valid, and if the padding length field is zero, it is addressed to data segmentation, the PDU may not include the padding. 
The remaining data indicator is set valid, and if the padding length field is not zero, it is addressed to response to unfinished “write” operation, the PDU may include the padding only.
The remaining data indicator is set invalid, and the padding length field is not zero, it is addressed to unsegment or last segment packet.

3GPP RAN WG2 Meeting #130                                                     	R2-2504467 
St.Julian, Malta, May. 19th – 23rd, 2025
	      
Agenda Item:	8.2.4
Source:	HONOR
Title:	Discussion on Data Transmission for Ambient IoT
Document for:	Discussion and Decision
1. 

Conclusions
In this contribution, we analyze the data transmission procedure for A-IoT device and made the following observations and proposals:
Observations
Observation 1: If considering to segment the application layer packet, it is useful to transmit the upper layer command in every R2D message to avoid recoding starting point. However, this needs to coordinate with application layer which is not in the scope of 3GPP and SA2 should be involved to evaluate whether this solution could work. 
Observation 2: If considering to segment the NAS PDU, it is not natural to record the starting point which is also the position to store the NAS PDU, because there would be only one NAS PDU in the buffer waiting for transmission. There is no additional requirement introduced by segmentation.
Observation 3: There is no case for the reader to schedule the device with the assigned AS ID again if the device has already completed current procedure successfully. Therefore, there is no need to store the AS ID after the procedure completed successfully.
Observation 4: Considering energy consumption of A-IoT device, the R2D message with upper layer command should be transmitted to the device as soon as possible, e.g. in the same slot or round with sending MSG3. 
Observation 5: Length field is necessary to indicate how may SDU bits are present when there is no more data and there is padding in the MAC SDU.
Observation 6: 1-bit indication (More Data indication) is introduced to indicate whether there is more data in the device side.
Proposals
Issue 3-1/Issue 3-2: Segmentation
Proposal 1: (Issue 3-1) RAN2 to discuss not include the upper layer command for subsequent segments (re-)transmission. 
Proposal 2: (Issue 3-1) The R2D message could also be used for scheduling subsequent segment and the “upper layer command” should be not present for segment (re-)transmission.
Proposal 3: (Issue 3-2) The offset (i.e. Received Data Size) should be included in the R2D message scheduling for the first segment and unsegmented message.
Issue 3-3: AS ID Release
Proposal 4: (Issue 3-3) The device will release the AS ID upon completing the service request procedure successfully.
Proposal 5: (Issue 3-3) The device will release the AS ID upon receiving the page message with the stored transaction ID.
Proposal 6: (Issue 3-3) The device will release the AS ID upon receiving NACK for re-access.
Issue 3-4/Issue 3-5: D2R Message Content
Proposal 7: (Issue 3-4) Length field indicates the number of bytes in Data SDU field.
Proposal 8: (Issue 3-4) The size of the Length field is 7bits.
Proposal 9: (Issue 3-4) Length field is optionally present. The Length field will be present in the D2R MAC PDU if more data indication indicates there is “No” more data stored in the device side.
Proposal 10: (Issue 3-5) Message Type should be included in the D2R MAC PDU for further extensible.
Others
Proposal 11: The R2D message should be able to multiplex information for multiple devices.
4. 

3GPP TSG-RAN WG2 Meeting #130	R2-2504491
St. Julian’s, Malta, 19th-23rd May, 2025 	Revision of R2-2502821

Agenda Item:	8.2.4
Source:			ASUSTeK
Title:	Discussion on the assistance information from device
Document for: 	Discussion and Decision

Conclusion
We have the following proposals for assistance information in D2R message for upper layer data transmission:
Proposal 1: Confirm that the 1-bit segmentation indication is always included in the D2R message for upper layer data transmission, with value 1 or 0 to indicate whether there is more data or not.
Proposal 2: The energy status indication could be always included in the D2R message for upper layer data transmission, with value 1 or 0 to indicate whether the remaining energy of the device is insufficient.
Proposal 3: The device stops the ongoing procedure after providing the energy information indicating the remaining energy of the device being insufficient.
Proposal 4: For forward compatibility, reserved bits could be included along with the indications in the D2R message for upper layer data transmission.

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

Agenda item:		8.2.4 (Ambient_IoT_solutions)
Source:	LG Electronics Inc.
Title: 	Discussion on A-IoT data transmission
Document for:	Discussion and Decision
1.	

Conclusion
This document discusses segmentation, AS ID, and segmentation and message content for data transmission.
Proposal 1. The reader does not include the command for retransmission of segments except the first segment/unsegmented D2R message.
Proposal 2. The reader does not include offset zero in the first segment/unsegmented D2R message.
Proposal 3. The device releases the AS ID upon receiving paging with new transaction id for other devices.
Proposal 4. SDU length field is used to indicate how many SDU bytes are present.
Proposal 5. From RAN2 perspective, the device may send padding only MAC PDU if there is no available upper layer data at a D2R transmission resource. The reader considers it as the successful D2R transmission if successfully received. This assumes that upper layer message exchanges are managed by the upper layers. 

TDoc file reading error

3GPP TSG RAN WG2#130 	R2-2504577                                                                            St.Julians, Malta, May 19th – 23rd , 2025
Agenda Item:	8.2.4
Source:	III
Title:	Discussion on A-IoT data segmentation and transmission 
Document for:	Discussion

Conclusion
We have the following proposals:
Observation 1: For CFRA case, option 2 / option 4 is sufficient.
Proposal 1: Two segmentation-based transmission processes are proposed:
Unified response after full segment transmission,
Send instant responses segment by segment.