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

Agenda item:		8.2.2
Source:		Futurewei
Title:		Open issues on A-IoT paging
Document for:		Discussion and Decision

Conclusions
Observation. Solution B is simpler and has less issues and hence is a better solution than Solution A for Rel-19 A-IoT.
Therefore, we propose the following:
Proposal 1. RAN2 adopts Solution B for parallel service requests for Rel-19 A-IoT.
Proposal 2. If Proposal 1 is not agreeable, RAN2 introduces some restriction on how the Transaction IDs from the same reader are generated, e.g., always increasing by 1 for new service request.
Proposal 3. If Transaction ID is always increased by 1 for a new service request from the same reader, a device finding that its stored Transaction ID does not match with the Transaction ID in a paging message received but matching with the Transaction ID value in the paging message minus 1, after possible adjustment by a modulo function for wrap-around, considers that the paging message is still received from the same reader except that the reader has terminated the old service request and is starting a new one. 
Proposal 4. Contents in a paging message that initiates a CFRA procedure is to be optimized by omitting all fields not needed for CFRA, e.g., value X, value Y, the Q-like value to begin with, without a need of a present bit for these fields in the paging message.
Proposal 5. A device uses the CBRA/CFRA indication bit in a paging message received to determine whether the presence bits associated with the fields carrying value X, value Y, and the Q-like value should be considered when parsing the paging message received.

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

Agenda Item		:	8.2.2 (Ambient_IoT_solutions)
Source		:	LG Electronics Inc.
Title		:	Discussion on A-IoT paging
Document for	:	Discussion and Decision
1.	

Conclusion
This contribution makes the following observations and proposals:
Proposal 1: A-IoT device should ignore all new requests and R2D messages addressed to itself that are not associated with the ongoing procedure, meaning that option (a) should be supported.
Proposal 2: RAN2 should introduce a method to indicate to the device the end of the procedure.
Proposal 3: Reader should indicate the end of the ongoing procedure to the A-IoT devices through an R2D message, and the A-IoT devices should adhere to this indication.
Proposal 4: A-IoT device should run a timer to determine the end of the procedure for the case of the indication of the end of the procedure is missed.
Proposal 5: A-IoT R2D messages (e.g., paging messages) should include transaction ID to specify which ongoing procedure the R2D message is associated with.
Proposal 6: RAN2 considers the multiple-reader scenario when determining how the reader generates the transaction ID.
Proposal 7: Considering the multiple-reader scenario, the transaction ID should have sufficient size (e.g., 8 bits) to accommodate information related to the reader.
Proposal 8: To ensure forward compatibility with scenarios where multiple paging identifiers can be contained in a single paging message, A-IoT paging message should include a reserved field to accommodate multiple paging identifiers.
Proposal 8a: If a reserved field for multiple paging identifiers is defined, the A-IoT paging message should include a ‘length information field’ for each identifier stored in the field.
Proposal 9: A-IoT paging message should include a list of frequency information for D2R transmission, e.g., Msg1 transmission.
Proposal 10: A-IoT paging message should directly indicate the first Msg1 resource (i.e., the start of the first access occasion) without requiring an additional R2D transmission.

4.	

3GPP TSG-RAN WG2 Meeting#130	R2-2503404
St Julian’s, Malta, 19th – 23rd May, 2025
                         
Source:	vivo
Title:	Discussion on A-IoT Paging
Agenda Item:	8.2.2
Document for:	Discussion and Decision

Conclusion
On a basis of above analysis, we make the following proposals regarding A-IoT paging:
Format
Issue 1-2
RAN2 to send LS to SA2 and RAN3 about the usage and requirement on transaction ID over the air interface in order to avoid duplicate responses for the same A-IoT service, with a suggested length of 4-bit. Let them decide on whether and how to specify the generation scheme.
Issue 1-4
X, Y and Z are respectively included in the paging message, where X/Y= the number of time/frequency domain resource(s) in each resource set for access occasions and Z= the number of resource sets within one paging procedure. The device obtains the number of access occasions N by X*Y*Z.
RAN2 to wait RAN1 decision on the value ranges of X and Y, and then to decide the reasonable length of field to indicate the number of resource sets, Z.
Issue 1-5
The fields of transaction ID, indication of paging ID presence and the number of access occasions can be omitted in the paging message when RA type indicates CFRA.
Access occasion trigger message rld.
The Access Occasion Trigger message is to indicate the start of the following set of access occasions (except the first set) in slotted-aloha CBRA scheme. RAN2 to capture the device behaviour upon reception of such Access Occasion Trigger message.
The start of the first set of access occasions is directly indicated by the A-IoT paging message. If not, RAN2 to send LS to RAN1 on feasibility evaluation for the device to receive two continuous R2D messages.
Access Occasion Trigger message should not be smaller than 6 bits according to RAN1 CRC-6 requirement.
Device cannot recognize the Access Occasion Trigger message associated with which Paging message if no transaction ID is not included in the Access Occasion Trigger message, which causes access collision issue when miss-detect of the latter paging message happens.
The MAC format of Access Occasion Trigger message contains:
Message type to indicate Accession Occasion Trigger;
Transaction ID.
Issue 1-6
The paging identifier can be in the form of filtering criteria to filter one or multiple devices, which cannot be associated to a specific AS ID assigned for one device for the further command service.
RAN3 introduces RAN NGAP device ID maintained per device by the reader, reported together with inventory report to AIOTF, where inventory report is based on MSG3 in the air associated to a specific AS ID.
RAN2 to confirm that the paging identifier is invisible at reader’s MAC layer, i.e., the reader maintains the mapping between RAN NGAP device ID used in the interface and AS ID assigned for the device in the air, to ensure that the command is toward which specific target device.

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

Agenda Item:	8.2.2
Source: 	CATT
Title: 	Discussion on Paging for Ambient IoT
Document for: 	Discussion and Decision

Conclusion on KI#3

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

Agenda Item:	8.2.2
Source: 	Xiaomi, Huawei, CMCC, Spreadtrum, CATT, Apple, China Telecom, Transsion Holdings, vivo, InterDigital, Philips International B.V., Qualcomm Incorporated, NTT DOCOMO, INC.
Title:  	Device behavior for parallel service requests (Joint paper: Option B - no further standard effort, issue 1-1)
Document for:	Discussion and decision

Conclusions
Based on the above discussion, we propose following proposals:
Observation 1: For the normal case, the reader should complete Inventory procedure for a device within the same access slot (rather than across R2D trigger messages).

Observation 2: During inventory procedure, the device is not required to receive R2D message other than the messages for this Inventory procedure if the reader follows the timing relationship of R2D and D2R message strictly.

Observation 3: The reader can trigger the command procedure for the same device in different access slot or even different paging round, but it should complete the command transmission of current session/service before triggering another session/service.

Observation 4: For overlapping among multiple readers scenario, the system does not work for both option a and b if there is no coordination between Readers on the timing of R2D transmission. However it can be left to reader’s implementation. 

Observation 5: For overlapping among multiple readers scenario, the system can work for both option a and b if readers follow the timing relationship among readers for R2D, D2R message transmission even if parallel session/service happens. However additional complexity is foreseen without significant benefit, e.g. on latency. 

Observation 6: Based on offline discussion in last meeting, option a is not a “complete” solution. Companies have different views on the details, e.g., “ongoing”, “deadlock”.  

Observation 7: To support Rel-20 A-IoT, message extensible based forward compatibility is sufficient in Rel-19. Backward compatibility issue shall be considered in Rel-20, e.g., not impact timing relationship requirements for Rel-19 R2D, D2R message transmission if a Rel-20 reader would like to support both device 1 and device 2b/c simultaneously.  

Observation 8: For coverage overlapping among multiple readers scenario, the resource utilization efficiency is really low for both option a and option b if interleaving service is allowed, especially when many devices are impacted. 

Observation 9: For coverage overlapping among multiple readers scenario, session loss issue does not exist if the sessions triggered by readers are same or the sessions are different but not for the same device even if the interleaving is allowed. 

Observation 10: For coverage overlapping among multiple readers scenario, the differences between option a and b are whether to define solution for “ongoing” and “deadlock” if the interleaving is allowed.

Observation 11: For deadlock issue of option a, it affects all devices (non-overlapping device and overlapping devices).

Proposal 1: RAN2 confirms that for CBRA, the parallel service requests by the same reader is not supported no matter to the same set of devices or different devices.
Proposal 2: For coverage overlapping among multiple readers scenario, the readers implementation still needs to follow the physical layer restrictions (e.g., timing relationship), i.e., readers coordination via implementation is inevitable in any case.
Proposal 3: The device always respond to the new service indicated by the received paging message, regardless whether there is any procedure ongoing, i.e., no specification impact, same as the description in the current section “Upon receiving the A-IoT Paging message” in the MAC running CR. 

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

Agenda Item:	8.2.2
Source: 	Xiaomi
Title:  	Remaining open issues on A-IOT paging procedure
Document for:	Discussion and Decision
1	

Conclusion		
In this contribution, we discussed the procedures and signalling for the initial access in A-IOT and have corresponding proposals.
Subgroup: Transaction ID:
Proposal 1 (Issue 1-2): RAN2 to agree the purpose of transaction ID is to avoid duplicated response from the same device for the same session/service. The size of transaction ID is 4. 
Proposal 1.1 (Issue 1-2): Send LS to RAN3, CC SA2, inform them of the need of transaction ID (avoid duplicated response from the same device for the same service) and the size (4bits), and ask them to decide how to generate the transaction ID.
Proposal 2: per session per device association between gNB and AIOTF has been concluded in RAN3. No RAN2 action is needed.

Subgroup: Paging message content:
Proposal 3 (Issue 1-3): Paging ID is byte aligned. The size of Paging ID length field is 6 bits to indicate the maximum 64 bytes Paging ID.
Proposal 3.1 (Issue 1-3): Send LS to SA2 and CT4 to inform them of RAN2 agreements “Paging ID is Byte aligned, and max size is 64bytes”.
Proposal 4 (Issue 1-4): MaxNoOfAO is 14 bits or 15 bits in order to address max 65535 devices, assuming Ymax is 4 or 6.
Proposal 5 (Issue 1-5): For paging message, “transaction ID”, “the number of access occasions”, “Indication of Paging ID present/absence” are not contained for CFRA.
Proposal 5.1 (Issue 1-5): For paging message, the message content for CBRA and CFRA is distinguished by RA Type.

Subgroup: Others:
Proposal 6 (Issue 1-6): Visibility means the reader cannot change the Paging ID, no spec impact. the Issue 1-6 can be closed.

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

Agenda item:	8.2.2
Source:	Nokia
Title:	AIoT paging aspects
WID/SID:	Ambient_IoT_solutions - Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations:
Observation 1: From efficiency perspective, it is undesirable to interrupt AIoT requests, especially those characterized by segmented transmissions, low-energy status, CFRA or inventory & command use-case.
Observation 2: Transaction ID clearly links together all messages associated with the same AIoT request. 
Observation 3: Multi-reader operation requires some degree of reader coordination, at least in the case of multiple readers handling the same CN request.
Observation 4: Device may prefer to respond to the best-connected reader to ensure successful response reception, rather than to the reader that paged it earlier.
Observation 5: Transaction ID is critical identifier used extensively throughout an AIoT session.
Observation 6: The transaction ID should be sufficiently long to uniquely identify multiple concurrent AIoT requests in parallel at multiple adjacent readers without collision.
Observation 7: A transaction ID at least partly encoded at PHY layer would help a device to efficiently decide whether to accept a message without the need to engage in processing/energy-demanding decoding of the MAC control information.
Observation 8: The WID states that the work should have forward compatibility in mind w.r.t communicating to a fixed group i.e. list of devices when designing the AIoT paging message.

And proposed the following:
Proposal 1: Device is considered to be in a “no interrupt” phase for a given AIoT request from the time it receives the associated R2D initial trigger (start time) until one of the following termination criteria is satisfied (end time):
the device responds to the reader,
the allocated response resources are exhausted,
medium access is not possible, 
a termination signal is received (eg, explicit signal from the reader or implicit timer / counter elapses).
Proposal 2: During the “no interrupt” phase, the device shall ignore any message with a different transaction ID. The response behaviour of the device outside of the engagement period is left to implementation. 
Proposal 3: All R2D messages including R2D initial trigger contain the transaction ID to unambiguously indicate their context.
Proposal 4: If multiple readers handle the same AIoT request from the CN,  they use the same transaction ID.
Proposal 5: RAN2 assumes that readers are able to coordinate transaction IDs and resource allocation purely based on their implementation without any impacts to RAN2. Send LS to RAN3/SA2 to confirm.
Proposal 6: RAN2 supports reader ID to permit reader selection and (e.g. based on signal strength) and reader-specific resource allocation / configuration.
Proposal 7: A MAC-layer transaction ID is determined as a subset of the CN correlation ID (including the case of entire CN correlation ID) whereby details are determined after SA2/RAN3 progress.
Proposal 8: RAN2 to send an LS to SA2 to enquire how many readers at most can be assumed to handle the same AIoT request.
Proposal 9: RAN2 to send an LS to RAN1 on whether at least partial PHY encoding of the transaction ID (e.g. via the choice of timing acquisition sequence) could be used for efficient message triage without the need for full MAC payload decoding. 
Proposal 10: RAN2 considers compression of device IDs involving at least common data like network/operator identification. FFS other portions and further details.

3GPP TSG RAN WG2 Meeting #130                                                            R2-2503518
St Julian's, Malta, May 19th - 23rd, 2025
Agenda item:	8.2.2
Source:	Ofinno
Title:	Discussion on issues 1-1 and 1-3 
Document for:	Discussion and decision

Conclusion
The observations captured are the following:  
Observation 1.	[Issue 1-1] [Parallel Service] It is unclear whether RAN2 agreement “Parallel service requests by the same reader is not supported” is from the readers PoV or the device PoV:
(a)	Reader PoV: the reader can only start one procedure with a device at any given time (which prevents parallel interleaved operation of two or more procedures by the same reader and different devices).
(b)	Device PoV: the reader may start different procedures in parallel with difference devices while the device does not expect to receive parallel service requests by one reader.
Observation 2.	[Issue 1-1] [Parallel Service] RAN2 agreement “The device is expected to only perform one procedure at a time” captures and is aligned to the interpretation from device PoV explained in Observation 1.
Observation 3.	[Issue 1-1] [Parallel Service] When handling parallel services, option A) of ignoring the new service request (and continuing with the ongoing one) is preferable as default/normal considering all the concerns identified for option B). However, there might be specific scenarios where option B) of starting the new service (and terminating ongoing one) might be sufficient or required, e.g., for very controlled or initial/early deployment of A-IoT or for services that network or if/when operators may require to prioritize in case-by-case basis.
Observation 4.	[Issue 1-1] [End of proc.] If the usage of immediately “sub-sequent” R2D trigger message by the device to determine the successful completion of an ongoing A-IoT procedure is restrictive from network point of view, other R2D messages and/or mechanisms could be considered.
Observation 5.	[Issue 1-1] [Transaction ID] It is helpful if a device can recognize R2D messages (including first and subsequent paging messages) associated to the same A-IoT service or procedure considering e.g., readers may send multiple paging messages for the same A-IoT procedure (up to implementation), one A-IoT procedure may require multiple R2D messages, or the device receives a new A-IoT service request while another A-IoT procedure is ongoing in the device.
Observation 6.	[Issue 1-3] [Paging] The A-IoT paging message needs to align with SA2/RAN3 design which enables triggering inventory request to a single, group, or all A-IoT devices within the requested service area, providing a message that allows this in Rel-19 (at least from specification PoV) and/or is forward compatible with Rel-20 and beyond.

The proposals captured are the following: 
Proposal 1.	[Issue 1-1] [Parallel Service] To clarify whether previous RAN2 agreement “Parallel service requests by the same reader is not supported” should be understood from device PoV (which means that the reader may start different procedures in parallel with difference devices while the device does not expect to receive parallel service requests by one reader) or from reader PoV (which means that the reader can only start one procedure with one device at any given time).
Proposal 2.	[Issue 1-1] [Parallel Service] When a device has an ongoing A-IoT procedure and receives a new service request, default/normal operation is to ignore the new service request (option A) but when required, network can indicate to the device to prioritize this new service request instead (option B).
Proposal 3.	[Issue 1-1] [End of proc.] If there are concerns with using the “subsequent” R2D trigger message for the device to determine the successful completion of an ongoing A-IoT procedure, to discuss whether to use the retransmitted Msg2 for the that purpose.
Proposal 4.	[Issue 1-1] [End of proc.] To discuss whether the device can determine the termination of the A-IoT procedure due to a “consistent failure” of the D2R (re)transmissions. If so, to discuss the meaning of “consistent failure” (e.g., by a maximum value/counter of D2R (re)transmissions, re-access/tries).
Proposal 5.	[Issue 1-1] [Transaction ID] A device needs to differentiate any R2D message(s) associated with the same A-IoT service (or procedure). This is done by including the same transaction ID in the corresponding R2D message(s), which would also apply to paging message and subsequent paging messages.
Proposal 6.	[Issue 1-3] [Paging] The design of A-IoT paging message should allow triggering paging to one or more devices, as well as groups of devices (i.e., paging IDs). FFS on the paging ID length (dependent to SA2/CT4 response).

3GPP TSG-RAN WG2 Meeting #130	R2-2503550
St.Julians, Malta, May 19th – 23rd, 2025
Agenda Item:	8.2.2
Source: 	Fujitsu
Title:	Discussions on AIoT Paging
Document for:	Discussion and Decision

Conclusion
In this contribution, we had some discussions on the Ambient IoT Paging and made the following observation and proposals:
Determination to skip the response
Proposal 1: To reduce the stored information, the A-IoT device releases the stored Transaction ID when the procedure fails. 
Proposal 1bis: The A-IoT device will skip subsequent paging with the same Transaction ID as its stored Transaction ID. 
Content and format for A-IoT paging
Proposal 2: Paging for CFRA can omit some of the CBRA related fields, including Indication of Paging ID presence, Number of access occasions.
Proposal 2bis: RA type field is present before the CBRA related fields, if present, including Indication of Paging ID presence and Number of Access Occasions.   
Proposal 3: RAN2 to discuss the length for Number of Access Occasions field is variable or not. The length needs to be indicated in the A-IoT Paging message if it is variable.
Proposal 4: RAN2 to confirm the current assumption that the paging identifier is transparent to the A-IoT MAC Layer and carried by upper layer.
Proposal 5: For forward compatibility, A-IoT Paging message contains a reserved field to indicate whether there is more information on paging ID length and corresponding paging identifier. 
Multi-reader scenario
Proposal 6: Support Option A: Ignore all new requests and R2D messages addressed to itself but not associated with the ongoing procedure.
Proposal 7: Transaction ID is included in every R2D Trigger message to avoid overhearing unintended R2D trigger messages in a multi-reader scenario.
Proposal 8: For CBRA, RAN2 to discuss the following options on Command procedure:
Option 1: all the message transmission for the command procedure targeting for one device will be finished in the same “slot” as the random access procedure, where the “slot” boundary is indicated by paging/R2D trigger message.
Option 2: the message transmission for the command procedure targeting for one device can be carried out in a different “slot” from the random access procedure.
Proposal 8bis: RAN2 to agree on option 1 in P8 (all the message transmission for the command procedure targeting for one device will be finished in the same “slot” as the random access procedure, where the “slot” boundary is indicated by paging/R2D trigger message). The next R2D trigger message after Msg1 transmission can be used as the end of procedure indication.
Proposal 9: Transaction ID is needed for CFRA in Paging message.
Proposal 10: For CFRA, R2D trigger message with Transaction ID is introduced as an end of procedure indication. Reader transmits an R2D trigger message when it determines the CFRA procedure completed, i.e., successful or failed.

3GPP TSG-RAN WG2#130											         R2-2503610
St Julian’s, Malta, May 19th – 23th, 2025
Agenda Item:	8.2.2 
Source: 	NEC
Title:	        Ambient-IoT Paging
Document for:	 Discussion

Conclusion
Observation 1:	The A-IoT RAN node might lack prior knowledge of “approximate number of AIoT devices”.

Proposal 1:	(MAC 2-4) For a service identified by a transaction ID, the device may store status information about whether the service has been successfully responded, or whether re-access is needed; If device considers it had successfully responded the received service before or re-access status of the service is “not needed”, device should avoid duplicated response:
Proposal 2:	(MAC 2-4) If device has transmitted msg3 and not receiving a following "NACK" indication, device considers the re-access status of the service is “not needed”;
Proposal 3:	(MAC 2-4) If device has not transmitted msg3 (this also includes cases that device selected resource but did not transmit msg1, or did not receive random ID response message echo its random ID), or device received "NACK" indication following the msg3 transmission, device considers the re-access status of the service is “needed”.
Proposal 4:	(MAC 2-8) Device always respond to a CFRA if it is identified by the CFRA without considering whether it has responded before or not.
Proposal 5:	(MAC 1-1) For device behavior if it gets a new service request, support option B: terminate the ongoing procedure and respond to the latest request.
Proposal 6:	(MAC 2-9) From RAN2 perspective, CFRA for multiple devices can be supported.
Proposal 7:	(MAC 2-9) For CFRA configuration when paging message contains multiple device identifiers, access occasions or AS IDs indicated in paging message are mapped to devices according to the ranking of the device identifier in the list.
Proposal 8:	Support lean inventory using CFRA configurations: reserves a single dedicated Msg1 resource with paging identifier set to "all" devices. The A-IoT RAN node can then estimate the number of in-coverage devices by analyzing the received signal strength from devices’ responses.

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

Summary and proposal
Proposal 1.	(Issue 1-1) The device receives the new paging unless other conditions meet (e.g. that of transaction ID).
Proposal 2.	(Issue 1-2) Part of correlation ID indicated by AIOTF is reused for transaction ID.
Proposal 3.	(Issue 1-2) Ask SA2 whether AIOTF can indicate different correlation IDs for different readers for the same paging request.
Proposal 4.	(Issue 1-2) The size of transaction ID is at least 8 bits.
Proposal 5.	(Issue 1-4) The field size of access occasion number is at least 14 bits.
Proposal 6.	(Issue 1-5) For CFRA, paging R2D message does not have fields for Indication of Paging ID presence, Transaction ID nor Number of Access Occasions.

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

Conclusion
In this contribution, we discuss the paging issue for Ambient IoT, and have the following proposals:
Proposal 1 	R2D trigger message includes the same “transaction ID” as the one in Paging message.
Proposal 2 	RAN2 discuss whether the slot# needs to be included in the R2D trigger message.
Proposal 3 	A device shall abort the current transaction and respond to the matching Paging request with new “Transaction ID”, regardless of whether this new paging transaction is initiated from the same reader or different reader.
Proposal 4 	At least for CFRA paging, Paging ID is visible to reader’s MAC layer.
Proposal 5 	Paging message for CFRA does not include transaction ID .
Proposal 6 	A transaction ID is not included in R2D data/command message.
Proposal 7 	4-6 bit “Transaction ID” is used for Paging message.
4 

3GPP TSG-RAN WG2 Meeting #129                                                                             R2-2503789
Malta, May 19th – 23rd , 2025
Agenda item:	8.2.2
Source:	China Telecom
Title:	Discussion on Paging Procedure for Ambient IoT
Document for:	Discussion

Conclusions
Based on the discussion in the previous sections, we propose the following:
Proposal 1: To define the device behavior for getting a new service request, as terminating the ongoing procedure and responding to the latest request.
Proposal 2:  	If the A-IoT paging message indicates that a device is not an intended device to participate in any access round in the current paging round, the device can make itself unavailable for communications with the reader to harvest energy until the end of the current paging round.
Proposal 3:  	The reader may further include information in the A-IoT paging message to indicate, or for unintended devices to estimate, how long the current paging round may be, e.g., the number of total access rounds to be scheduled in the current paging round or an estimated duration for the current paging round to be completed.
Proposal 4: To trigger A-IOT devices to find their correct access occasions in A-IOT CFRA procedure, three options can be discussed to be included in the A-IOT paging message:
One-to-one mapping of the device ID to the access occasion 
PF/PO-like access index allocation approach 
Mask ID 
Proposal 5: To support paging message containing multiple IDs of A-IoT devices. The multiple IDs can be used to indicate multiple devices with discontinuous device IDs.

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

Agenda Item:	8.2.2
Source:	Panasonic
Title:	Discussion on A-IoT paging  
Document for:	Discussion

Conclusion
In this paper, we have discussed some remaining issues on paging, including end of procedure, device behavior if multiple requests are received in parallel, reader ID and skip response due to energy constraint. The proposals are as follows:
Proposal 1. For CBRA, after sending Msg1 in response to an A-IoT paging, device assumes the procedure associated with this paging is ongoing (i.e. pending), until one of the following events occurs:
Msg2 is not received within a time window, in which case the procedure is concluded as failure
After sending Msg3 (i.e. inventory response),
Device receives NACK for re-access determination until next paging or trigger message, in which case the procedure is concluded as failure
No R2D is received until next paging or trigger message, in which case the procedure is concluded as successful
After sending command response (e.g. Msg5/Msg7/etc), in which case the procedure is concluded as successful
Proposal 2. For CFRA, after sending any D2R data , device assumes that the procedure associated with this paging ends successfully. 
Proposal 3. Paging message includes control information to indicate whether device should follow option-a or option-b.
Proposal 4. In additional to transaction ID, a reader ID can be optionally indicated in paging message. Device needs to maintain the reader ID (if indicated) and transaction ID in the memory after successful completion of the access procedure triggered by a paging. 
Proposal 5. On deciding whether or not to respond to a paging, device compares the stored IDs with the IDs in the paging as follows:
 
Proposal 6. Device is allowed to skip responding if device judges its remaining energy cannot sustain to complete whole access procedure triggered by this A-IoT paging.

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

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

Conclusion
A-IoT device behaviour in multi-reader scenario and A-IoT paging message content are discussed in this work in the context of one or multiple service request(s) received by the device from one or multiple base stations. We have made the following observations and proposals related to the above-mentioned topics:

Observation 1: Based on the deployment position, the A-IoT devices may get one or multiple service requests from one or multiple base stations.
Proposal 1: If the A-IoT device receives multiple service request in parallel, it will respond to the msg0 it receives first and start communicating with that reader. The parallelly received msg0 signals are discarded by the device until the ongoing process is completed successfully. Thus, Parallel service requests should have separate transaction ID to identify at the device side whether this is a different service request or same request from a different reader or same request from a same reader.  
Observation 2: The inventory process may involve multiple paging occasions. Once a device has completed the initial service request and goes to idle or listening mode, it can decide whether to respond to the next paging request based on transaction ID and/or Reader ID.     
Proposal 2: The reader should send an ACK signal if the Msg3 is successfully received at the reader. If the device doesn’t receive ACK and it receives next R2D trigger, it considers the transaction is failed.
Proposal 3: If the ongoing transaction is failed, it retransmits Msg1 after it receives the subsequent paging Msg0 for the same transaction. Until the ongoing transaction is successful, or reader specifically send a release message, the device will discard other Msg0 signals with different transaction ID.  
Proposal 4: If a device successfully sends the information at one slot it will not respond to the next slots for the same transaction or service request from the same reader to free up the resources for the other devices. 
Proposal 5: If a device successfully sends the information at one slot and goes to idle or listening mode, it may respond to the next slots for the same transaction or service request from a different reader.
Proposal 6: The R2D trigger message should contain the transaction ID so that the device can identify the trigger messages for that transaction.
Observation 3: As the service ID or the transaction ID plays an important role in order to decide the device behaviour when the device is in idle or listening mode, the device needs to differentiate among the different cases of multi-reader or multi-paging scenarios.  
Proposal 7: For the device to differentiate among the different cases of multi-reader or multi-paging scenarios, the transaction ID should be different for different reader for same service as well as it should be different for same reader for different services. The following options can be adopted to solve this problem:
Option 1: Concatenate reader ID and correlation ID received from the CN as transaction ID.
Option 2: Generate a new transaction ID from both the correlation ID received from the CN and the reader ID. FFS on operation to generate the Transaction ID from correlation ID and Reader ID. 
Proposal 8: If reader sends multiple msg2 signals, the msg2 signal can carry an indication to convey the device if it is the last msg2 signal in this communication slot.
Observation 4: The R2D transmission as a part of paging message can be a unique or unified message structure for all query/paging types for both CBRA and CFRA.
Proposal 9: 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 10: 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. 

TDoc file reading error

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

Agenda Item:	8.2.2
Source:	Spreadtrum, UNISOC
Title:	Discussion on A-IoT paging
Document for:	Discussion and Decision

Conclusions
In this contribution, we discuss the Rel-19 paging procedure and message content. And the proposals are given as follows:
Proposal 1: If a device receives a new service request while a procedure is still ongoing, the device will terminate the ongoing procedure and respond to the latest request.
Proposal 2: Specify a simple rule to generate the transaction ID.
Proposal 3: For the size of transaction ID, 3 bits can be reasonable size. 
Proposal 4: The number of bits required for paging ID length field can wait for SA2 progress. 
Proposal 5: RAN2 supports that A-IoT paging message includes a parameter N indicating the total number of access occasion set, such as 15 bits, value range as [1, 215].
Proposal 6: The transaction ID in AIoT paging message is not needed for CFRA procedure. 

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

Agenda Item:	8.2.2
Source:	Huawei, HiSilicon
Title:	A-IoT paging
Document for: Discussion and Decision 
1	

Conclusion
This contribution makes the following proposals:
Observation 1:	After two meetings’ discussion, the option (a) still:
has the diverse solutions to address the deadlock issue for end of procedure determination, each of which may have some concerns; and
suffers the overhead concern by including some ID in all R2D messages.
Observation 2:	The concern for forward compatibility that was raised for option (b) has been addressed. 
Observation 3a:	Network implementation for some coordination is anyway inevitable, to address the physical layer interference among neighbour readers.
Observation 3b:	Network implementation can avoid parallel services from the neighbour readers that belong to different BSs, e.g., OAM can allocate/configure non-overlapped time-domain resources.
Observation 3c:	Inter-BS coordination is not really critical for the indoor scenario of Rel-19.
Observation 4:	In Rel-19, without physical layer design to address interference issue in overlapped area, there is no point to introduce any RAN2 solution to address the overlapped area cases, which is not realistic either (i.e., most of the R2D messages cannot be correctly decoded at all due to interference). 
Observation 5:	Transaction ID is introduced in subsequent paging for re-access purpose. It will be unnecessary, since CFRA does not support re-access at all.
Observation 6:	Based on the above calculation, the maximum size of paging ID in case of mask/filter can be up to 300 bits. Then, 512 or 1024 can be the max value for paging ID length.
Observation 7:	No need to have different length filed for paging ID length, i.e., not to do further size reduction for CFRA. 
Observation 8a:	The linear representation, at the cost of 10 more bits overhead in paging message, can achieve optimized Slotted-ALOHA procedure by configuring the similar number of AO based on number of devices.
Observation 8b:	The exponential representation can save the overhead about 10bits, while it cannot configure relatively accurate number of AO according to number of devices.
Observation 9:	The difference between NR A-IoT design and RFID may be: A-IoT paging can tolerate more overhead, while the inventory procedure efficiency may be decreased due to many excessively allocated access occasions.
Observation 10:	Rel-19 device can ignore R bit and any other unknown fields in paging message.
Multi-reader paging (Issue 1-1)
Proposal 1:	(Issue 1-1) Agree option (b): If the “transaction ID” received in the paging message differs from the one currently maintained by the device, the device shall update its currently maintained “transaction ID” to the received value and act consequently.
Transaction ID (Issue 1-2, 1-5, 2-8)
Proposal 2:	(Issue 1-2) It is proposed to NOT specify how the reader generates the transaction ID, while some reader implementation manners can be the following:
The transaction ID is the right-most truncated part of CN Correlation Identifier; or
The reader tries to use different transaction IDs for different CN Correlation Identifiers; or
Reader generates the transaction ID without considering the CN Correlation Identifier at all (intentionally).
Proposal 3:	(Issue 1-2) 2-bit transaction ID in paging message seems enough, while 3-bit transaction ID in paging message seems a reasonable compromise.
Proposal 4:	(Issue 1-5, 2-8) For CFRA, the transaction ID is unnecessary in the paging message.
Paging message content (Issue 1-3, 1-4, 1-5)
Proposal 5:	(Issue 1-3) A 9-bit or 10-bit field for the “paging ID length” in the unit of bit is used.
Proposal 6:	(Issue 1-4) RAN2 to discuss the format and the size for the field of number of access occasions:
Option 1: linear way, 14 bits, value range as [1, 214-1] in the unit of 1; (suggested)
Option 2: exponential way, 4 bits, value range as [1, 215] with code points as {20, 21, 22, 23, 24, 25, ... 215}.
Proposal 7:	A single R bit is adequate for future extensions of the paging message.
Proposal 8:	(Issue 1-5) If the RA type indicates CFRA in paging message, the CBRA specific configurations/fields (e.g., access occasions number, transaction ID, paging ID presence indication) will be absent.
4	

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

Agenda Item:	8.2.2
Source: 	Transsion Holdings
Title:  	Discussion on Paging for A-IoT
Document for:	Discussion and Decision

Conclusions 
In this contribution we discussed issues related to A-IoT paging and made the following proposals:
Proposal 1: For all device paging, if the number of target devices is huge, the multi-round paging can be considered, the devices only respond to the paging belong to its own round.
Proposal 2:  RAN2 to make a assumption that if the device receives a service request(paging message) when there is an ongoing procedure, the service request is from a different reader.
Proposal 3: The device only response the service request if the transaction ID is different from the previous/current one no matter whether there is any ongoing procedure.
4 

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

Agenda Item: 	8.2.2
Source:		Sony
Title:			Considerations on paging for Ambient IoT
Document for:	Discussion & Decision

Summary
In this contribution, we have discussed our views on aspects related to subsequent paging, a new R2D trigger signal for D2R transmission and views on a number of the proposals from the email discussion

Proposal 1: The subsequent paging message for the same service includes information, on which devices that has either responded or which have not responded

Proposal 2: The msg 1 resources are provided in the initial paging message, and a new slot trigger is introduced only for timing purpose indicating the start of the uplink resources

Proposal 3: Presence of transaction ID is optional.

3GPP TSG-RAN WG2 Meeting #130						        											R2-2504112
St.Julians, Malta, May 19 – 23, 2025 			 
Source: 	ZTE Corporation, Sanechips, Continental Automotive, Tejas Networks, Nokia, Ofinno, Samsung, Fujitsu, Kyocera, Sony, ETRI, III, Ericsson, Nordic Semiconductor ASA

Title: 	Details of option A for overall A-IoT MAC procedure (Open Issue 1-1)
Agenda item:	8.2.2
Document for:	Discussion and Decision

Proposals and observations
The following observations and proposals (all related to open issue 1-1) are made: 

Option A overview
Proposal 1a: When a device has an ongoing A-IoT procedure, it ignores any paging request until the A-IoT procedure is considered completed (i.e. option A).
Proposal 1b: The R2D trigger message is used as an implicit end indicator for an ongoing procedure
Proposal 2: The R2D trigger message includes the transaction ID either explicitly as MAC payload or preferably, implicitly in physical layer signalling (e.g. mask the CRC with transaction ID or include it implicitly in the R2D preamble if feasible – details up to RAN1 – send an LS to RAN1 asking them to implement this) 

Inventory procedure
Proposal 3: In case of inventory procedure for CBRA: 
The device assumes that the inventory procedure is ongoing once MSG1 is transmitted and the procedure is considered complete upon receiving a subsequent R2D trigger with the same transaction ID as the one included in the paging message that triggered CBRA 
Upon receiving the subsequent R2D trigger message after transmitting MSG1: 
the inventory procedure is considered to be completed successfully if msg3 was transmitted and no NACK was received. In this case the device will not respond to the same transaction ID (i.e. no re-access)
The inventory procedure is considered to be completed unsuccessfully for all other cases (e.g. MSG1 failure, MSG2 failure, MSG3 failure). In this case the device will respond to paging for any transaction ID (including the same transaction ID – i.e. re-access)

Command procedure
Proposal 4: RAN2 to discuss and choose between the following for “Inventory + Command”: 
Option A-1: Inventory + Command procedure is completed between two consecutive R2D triggers (see Figure 2) – command indication is not needed in paging message for this option: or
Option A-2: Inventory step is completed first (between two consecutive R2D triggers) and command is transmitted afterwards (see Figure 3) – a command indication is needed in the paging message for this option: or
Support both options: Support both Option A-1 and Option A-2

Handling stuck devices
Observation 1:
In order to minimize the risk of the devices missing one or more R2D trigger messages and being “stuck”, the reader may adopt multiple strategies: 
Send one or more redundant R2D trigger messages with or without an a subsequent paging with the same transaction ID before moving to a new transaction ID
Turning the CW off to clear the device states before moving to a new transaction ID
Rely on the transaction ID wrap around 

Proposal 5: It is up to the reader implementation to handle the “stuck” devices (see observation 1). If none of the above options in observation 1 are deemed to be sufficient, RAN2 may discuss whether a device based solution (e.g. using a timer) may be used  

CFRA
Proposal 6. The procedure initiated for CFRA can be considered to be complete once inventory response/command response is transmitted by the device for inventory/inventory+command case respectively. 

Issues with option B
Observation 2: 
If the device is allowed to terminate the ongoing procedure upon receiving any new request from any reader, it results in the following issues: 
Race conditions where procedure initiated by one reader is terminated (repeatedly) by another
Issues with MSG3 collision and NACK collision which gets progressively worse towards the end of the paging round and may extend to next paging round if some of the devices miss the subsequent paging message
Prolong the overall service duration as essentially a single reader can perform the service in a given region at a given time
Interruption to command service is even more likely due to the extended duration between the inventory report and command with the 2-step command procedure agreed by SA2
Not forward compatible as the above multi reader issues are even more problematic with the typical use cases in topology 2 as well as outdoor deployments
System performance is degraded due to increased energy consumption (not only from network but also from device perspective), wasted radio resources, and increased implementation complexity

TDoc file reading error

3GPP TSG-RAN2 Meeting #130	R2-2504177 
Malta, 19th-23rd May, 2025		

Agenda item:	8.2.2
Title:	AIoT Paging: Handling a New Service Request
Source:	Philips International B.V.
Document for:	Discussion

	

Conclusion
In this paper, we make the following observations: 
Observation 1: There is no clear mechanism that allows a device to determine that a service request has terminated meaning that use of option (a) has the potential to cause device lock-up
Observation 2: Use of option (b) in environments with unco-ordinated readers operating simultaneously with areas of overlapping coverage, could lead to unexpected and generally sub-optimal device behaviour
Observation 3: In a controlled environment, there should only be one ongoing service request across all readers covering the same coverage zone
Observation 4: For coexistence in a controlled environment, there should be sone distance between active readers
Observation 5: In controlled environments, the first indication for a device that the current service request has indeed been terminated may be the arrival of a new service request from the same or a related reader belonging to a multi-reader group
Observation 6: A base station might send the same service request via a different reader is to solicit a response from devices that are part of the group but are inaccessible to the first reader
From these observations, we derive the following proposals:
Proposal 1: RAN2 agrees that parallel service requests by readers with overlapping coverage areas are not supported.
Proposal 2: When a device operating in a controlled environment receives a new service request from the same reader, it may abandon the current service request and respond as required to the new service request 
Proposal 3: When a device receives a new service request from a different reader belonging to the same base station, it may abandon the current service request and respond as required to the new service request
Proposal 4: A device receiving the same service request via a different reader shall treat it as an ongoing service request and respond as necessary.
Proposal 5: For this release, a device that receives a new service may assume that the current service request has terminated and may process the new service request. Thus, for Rel-19, RAN2 should adopt option (b).
Proposal 6: RAN2 should allow for future enhancements to the signalling and device handling defined in Rel-19  to allow for operational robustness in future, uncontrolled environments, including support of option (a)

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


Agenda Item:	8.2.2
Source: 	MediaTek Inc.
Title:  	Ambient IoT paging message format

Document for:	Discussion, decision
1	

Conclusion
This document promulgated the following proposals:
Proposal 1: A-IoT paging is designed in Rel-19 to be able to multiplex information for future-release devices in a single message together with Rel-19 devices.
Proposal 2: The paging message has a “header+paging records” format, with a Rel-19 reader constrained to have only one paging record in a message.
Proposal 3: The header portion of the paging message includes a field for the number of records, which is always set to 1 by a Rel-19 reader.
Proposal 4: A Rel-19 device is expected to read only the first paging record in the message, but required to behave gracefully in case the message contains multiple records.
Proposal 5: The paging record contains an indication of the record length to enable future-release devices to skip over a record.
Proposal 6: The paging message format contains the following fields (sizes FFS):
Header part
MSG_TYPE: R2D message type, constant value for paging
TRANSACTION_ID: Transaction ID, size and format to be determined (included in the header portion in accordance with the agreement to have no interleaved services; i.e., a paging message is always for one single service, even if in future multiple paging records are included)
NUM_REC: Number of records, always 1 for a Rel-19 reader, but included for forward compatibility
FFS need for padding to an octet boundary
Paging record part
E: Extension bit, 0 for a Rel-19 record, 1 for a record of an extended format for some later release
REC_LEN: Length of the paging record part (FFS bits or octets)
DEVICE_ID: Device identifier, with its own internal structure (including a length as agreed at RAN2#129bis), format to be determined with input from SA2
C: CBRA/CFRA bit, as agreed at RAN2#129bis
RSP_RSRC: Response resources, format to be determined with input from RAN1
FFS need for padding to an octet boundary
FFS need for padding to match the TB size
Proposal 7: Do not include an RSP_RSRC field in the header part of the paging message, and use a paging record with a reserved DEVICE_ID value to page all devices.
Proposal 8: RAN2 assume that the paging message describes the D2R radio resources for transmission of Msg1, and each subsequent trigger message for that paging round serves only to identify where the resources recur (i.e., there is no explicit description of Msg1 resources in the subsequent trigger message).  This assumption can be revisited if RAN1 require it.

3GPP TSG-RAN2 Meeting #130	R2-2504261
Malta, May 19-23, 2025	

Agenda Item:	8.2.2
Work Item:	Ambient_IoT_Solutions
Source: 	Qualcomm Incorporated
Title: 	Remaining aspects of Ambient IoT Paging
Document for:	Discussion/Decision

Summary 
Based on the discussion above, we have following observations: 
Observation 1.	If the A-IoT paging message indicates a single set of Msg1 resource(s), there is no need of R2D trigger message for that paging round.
Observation 2.	In some scenarios, the device ID may be absent in the D2R message in response to the A-IoT paging. When to include it should be indicated by Reader in the A-IoT paging message.

Based on these observations and discussion above, we have the following proposals:
Proposal 1:	Whether there is one or multiple set(s) of Msg1 resource(s) is indicated by the A-IoT paging message.
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:	If the A-IoT paging message indicates a single set of Msg1 resource(s), R2D trigger message is not used for that paging round.
Proposal 4:	Use A-IoT Msg1 and A-IoT Msg2 as message names in the A-IoT CBRA procedure.
Proposal 5:	RAN2 confirms that R2D trigger message does not include slot number/count down number.
Proposal 6:	The A-IoT paging message indicates the presence and information carried in the subsequent R2D message after D2R transmission (e.g. ACK/NACK feedback indication, follow-up command).
Proposal 7:	The A-IoT Paging Message indicates whether A-IoT Device ID needs to be included in D2R message.

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

Agenda Item:	8.2.2
Source:	Fraunhofer HHI, Fraunhofer IIS 
Title:	Discussion on A-IoT paging
Document for:	Discussion

Conclusion
In this contribution we discussed the A-IoT paging mechanism. Based on the discussion in the previous sections we made the following observations and proposals:

Observation 1: Session persistence under Option A may result in deadlocks if the procedure fails silently and there is no proactive session termination mechanism.
-----
Proposal 1: Introduce a lightweight session termination, such as a maximum inactivity threshold based on time or counter.
Proposal 2: Devices implementing Option B should notify the previous reader of the session termination using a lightweight signal (e.g., a short NACK or release message).
Proposal 3: An initial timer can be introduced to temporarily delay the response to new paging messages.
Proposal 4: Introduce end-of-procedure signal that marks the termination of a session. 
Proposal 5: The end-of procedure can also be used for slot termination if no device is detected.

3GPP TSG RAN WG2 Meeting #130	R2-2504396
Malta, May 19th – 23rd, 2025
Agenda Item:	8.2.2
Source:	CMCC	
Title:	Discussion on A-IoT paging
Document for:	Discussion 

Conclusion
Based on the discussions mentioned above, in this contribution we provide some discussions on A-IoT paging as following:
Observation 1: When different readers perform inventory procedures simultaneously, the interference of the signals received by the devices located in the overlapping coverage area may be extremely severe.
Observation 2: For the case where different readers perform inventory procedures interleavingly, it seems that there is no improvement in efficiency, but only an increase in the complexity of the protocol.
Observation 3: In R19 WID, only the case that multiple paging IDs are included in one A-IoT paging message is listed as a forward compatibility issue. For multi-reader scenario and/or parallel service case, neither of them has been agreed as the direction for forward compatibility yet.
Observation 4: There are several implementation methods to avoid the occurrence of multi-reader scenario or mitigate its impacts.
Observation 5: In terms of the device behavior when new service is received during an ongoing procedure, Option a has a greater specification impact than Option b, because RAN2 needs to discuss how the device determines whether the previous procedure is terminated. Leaving it to the device implementation will make it hard for the gNB-reader to predict the behavior of the devices.
Observation 6: In R19 WID, only the case that multiple paging IDs are included in one A-IoT paging message is listed.
Observation 7: The objectives and core part of R20 A-IoT WID are still undetermined in RAN.
Observation 8: Sub-grouping performed by the reader is an optimization scheme for the A-IoT procedure, which may be achieved by reader implementation, and is totally transparent to A-IoT device. 
Observation 9: Whether gNB-CN device ID is needed and the relationship between gNB-CN device ID and paging identifier have not determined by RAN3/SA2.
Observation 10: The method for gNB-reader generating transaction ID is not in RAN2 scope.
Observation 11: According to RAN1 agreement, it is clear that parameters for the D2R transmission resources should be included in A-IoT MAC layer message.
Observation 12: The indication of number of A-IoT MSG1 resources should also take RAN1’s agreement into consideration, because the number of time-domain resources and the frequency-domain information may need to be indicated separately.
Observation 13: There are six contents which may need to be included in an A-IoT paging message, that is, message type, CBRA or CFRA indication, transaction ID, paging identifier, reserved bit(s) for future features and resource indication.
Observation 14: With the consideration of the unavailability of A-IoT devices caused by their insufficient energy or fading in PRDCH, from the reader's perspective, the subsequent A-IoT paging message it sends may be treated as initial A-IoT paging messages by some A-IoT devices.

Proposal 1: In R19, reader ID is not included in A-IoT paging message for multi-reader scenario.
Proposal 2: In terms of the device behavior when it receives a new A-IoT paging during an ongoing procedure, terminating the ongoing procedure and responding to the latest request (i.e. Option b) is preferred. Leaving it to device implementation should be avoided.
Proposal 3: In terms of the forward compatibility of A-IoT paging message, RAN2 should only focus on reserved bit(s) and do not touch any details of future features and scenarios.
Proposal 4: From the perspective of specification impact, there is no clear necessity for the paging identifier to be visible to the A-IoT MAC layer at this stage, and may come back if necessary. 
Proposal 5: RAN2 is asked to wait for SA2 and CT4 reply on the paging identifier length before designing the detailed specifics of paging identifier field. 
Proposal 6: There is no need to include/reflect reader ID in the transaction ID.
Proposal 7: RAN2 is asked to agree to a 4-bit transaction ID.
Proposal 8: RAN2 is asked to wait for RAN1 agreement on detailed parameters of D2R transmission resources, and design the field of shared resources for A-IoT MSG1 transmission and the field of dedicated resources for first D2R response transmission in A-IoT paging message, accordingly.
Proposal 9: RAN2 is asked to agree that transaction ID can be absent in A-IoT paging message which triggers CFRA.
Proposal 10: At least for the design of A-IoT paging message, RAN2 is asked to agree to the following designing principles:
For each optional field in A-IoT paging message, one indication is needed to indicate whether it (maybe together with its length indication) exists in the A-IoT paging message.
For each field (whether optional or mandatory) with variable length, a length information indication is needed to indicate its length or the length option in the A-IoT paging message.
For the mandatory field(s) with fixed length, it(they) can be tightly arranged without any additional indication.
Proposal 11: For resource indication, RAN2 is asked to discuss whether we need to treat each parameter (such as: chip duration, number of FDMed occasions, etc.) agreed by RAN1 as a separate field, and discuss respectively whether it is mandatory or optional, after RAN1 provides the parameter list.
Proposal 12: The following fields may be included in the A-IoT paging message:
M: Message type (mandatory)
B/F: 1-bit CBRA or CFRA indication (mandatory)
T: Transaction ID (optional)
I: Indication which indicates whether paging identifier and its length information is present or absent (mandatory)
L&P: Length information of Paging identifier and Paging identifier field (optional)
RI: Resource indication of shared resources for A-IoT MSG1 transmission or dedicated resources for first D2R message transmission (details depend on RAN1)
R: Reserved bit(s) (mandatory)
Proposal 13: RAN2 is asked to take the overall format of A-IoT paging message shown in Figure 2 and specific format of A-IoT paging message shown in Figure 3 to Figure 5 as a start point.

Figure 2. Overall diagram of the format of A-IoT paging message

Figure 3. Schematic diagram of the format of A-IoT paging message which pages all devices

Figure 4. Schematic diagram of the format of A-IoT paging message which pages group of devices

Figure 5. Schematic diagram of the format of A-IoT paging message which pages one specific device
Proposal 14: There should be no difference between the subsequent A-IoT paging message and initial A-IoT paging message for at least the fields other than resource indication field.
Proposal 15: RAN2 is asked to discuss whether resource indication field can be different between subsequent paging message and initial paging message.

TDoc file reading error

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


Agenda Item:	8.2.2
Source:	Ericsson
Title:	Discussion on DL messages for Ambient IoT UEs
Document for:	Discussion/Decision
1	

Conclusion
In this contribution we discussed downlink/paging messages for A-IoT devices. Based on the discussion in the previous sections we made the following observations:

Observation 1	If the device abandons the ongoing procedure, radio and energy resources may be wasted since A-IoT device would switch procedures before completion assuming that readers are not coordinated.
Observation 2	Overall performance may be degraded as successful completion may be prolonged if ongoing procedure is abandoned when procedures from multiple readers are interleaved.
Observation 3	It should be clear for the device whether and when an ongoing procedure is completed.
Observation 4	The reader can utilize the end indication when it needs to terminate an ongoing procedure.
Observation 5	RAN3 agreed to introduce NGAP device ID which can be used to associate AS ID with upcoming command request at reader.
Observation 6	The reader needs to know whether there is a command request that follows the inventory.
Observation 7	RAN3 has agreed to introduce a follow-on command indication in Inventory Request Transfer IE.


Based on the discussion in the previous section, we propose the following:
Proposal 1	Device ignores any other paging service request received if it is performing a procedure associated with a paging service request received earlier, i.e., Option A.
Proposal 2	Access occasion trigger message includes the following:
- “end” indication that marks the last access occasion in a paging round
- a reader generated random number per paging round. FFS size, i.e., 5-8 bits.
Proposal 3	RAN2 assumes there is one to one mapping between CN correlation ID and transaction ID.
Proposal 4	Send an LS to SA2/RAN3 (cc: CT4) to inform those WGs about the assumptions in RAN2 and ask for the size of transaction ID.
Proposal 5	For CFRA, transaction ID is not included to the paging message.
Proposal 6	The paging identifier should be transparent to the reader, i.e., it should not be possible for the reader to, e.g., mask/regenerate the identifier provided by the CN
Proposal 7	R2D message types are reserved for future compatibility.
Proposal 8	RAN2 informs SA2 that the reader needs to know whether there is a command that follows the inventory and assumes that this can be achieved by follow-on command indication introduced in Inventory Request Transfer IE agreed in RAN3.


4      

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

Agenda Item:	8.2.2
Source:	HONOR
Title:	Discussion on A-IoT paging
Document for:	Discussion and Decision
1. 

Conclusions
 Proposal 1: (issue 1-1) The device needs to store the transaction ID in paging message and the corresponding response status.
Proposal 2: (issue 1-1) If the transaction ID is the same as the stored one and the device is selected by this paging message according to paging ID (no ID case and ID available case), the device will respond to the received paging message if pervious RA procedure was unsuccessful.
Proposal 3: (issue 1-1) RAN2 selects the option A for end-of procedure.
Proposal 4: (issue 1-1) The ongoing procedure can be as the following:
The device has initiated a RA procedure and the RA procedure is not completed;
The device has received a command request and the command procedure is not completed.
Proposal 5: (issue 1-1) The RA procedure is assumed completion as the following for CBRA:
Successful case: The device receives the following R2D message after Msg3 and no NACK is received;
Unsuccessful case: The device receives an explicit indication for end-of procedure when NACK message has been received.
Proposal 6: (issue 1-1) A indication to indicate whether there is a command request is introduced in paging message.
Proposal 7: (issue 1-1) The command procedure is assumed as completion if the device receives the following R2D message after command response.
Proposal 8: (issue 1-3) The paging message provides the information to indicate whether the paging ID is present.
Proposal 9a: (issue 1-3) If the paging ID length field is always present, the paging ID length filed can be used to indicate whether the paging ID is present.
Proposal 9b: (issue 1-3) If the paging ID length field is not always present, a separate bit is used for indicating the presence of paging ID as well as paging ID length field.
Proposal 10: (issue 1-4) The paging message includes the number of R2D trigger messages or the number of access occasions.
Proposal 11: (issue 1-5) The transaction ID in the paging message can be optional for the CFRA.
Proposal 12：RAN2 considers the following options to identify whether the multiple paging IDs are included in the paging message for the forward compatibility:
Option 1: an indication to inform whether a further paging ID is included; 
Option 2: introduce the number of paging IDs;
Option 3: the pair of information (i.e. paging ID length and paging ID) is included in the last part of the paging message.
4. 

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

Agenda Item:	8.2.2
Source:		ASUSTeK
Title:				Discussion on Ambient IoT paging message design
Document for: Discussion and Decision

Conclusion
Proposal 1:  To support multiple IDs in a paging message for forward compatibility, a paging message includes a field to indicate the number of IDs.
Proposal 2:  To support different device types for forward compatibility, a paging message includes a field to indicate device type information.
Proposal 3:  For Msg1 resource selection, a paging message includes a field to indicate the number of access rounds.

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

Agenda Item:	8.2.2
Source: 	ITL
Title: 	Discussion on A-IoT paging
Document for:	Discussion and decision

Conclusion
In this contribution, we discussed the A-IoT paging. According to discussion in section 2, we have the following proposals:
Proposal 1: Introduce Option A as the normative behavior in Rel-19 A-IoT.
Proposal 2: Introduce a timer-based release mechanism to enable the device to autonomously determine the end of an ongoing procedure
Proposal 3: Include Transaction ID in R2D messages to enable message relevance detection under Option A

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

Agenda item:		8.2.3
Source:		Samsung
Title:			Discussion on A-IoT paging
Document for:	Discussion & Decision
1 

Conclusion
Based on the discussion above, we have the following proposals:
Proposal 1: RAN2 is kindly asked to agree the Option 1: resource immediately following AIoT paging message, which indicates that AIoT paging message can omit the information on the number of access occasions.
Proposal 2: RAN2 is kindly asked to agree that the resource configuration in AIoT paging message for CBRA can include Q value, which is used to calculate the number of access occasions by 2^Q (same as RFID). 
Proposal 3: RAN2 is kindly asked to agree 4 bits for Q value. 
Proposal 4: RAN2 is kindly asked to discuss whether and how to include FDMA related resource allocation information in Paging message.

3GPP TSG RAN WG2#130   	R2-2504572                                                                            
St.Julians, Malta,  May 19th – 23rd , 2025
Agenda Item:	8.2.2
Source:	III
Title:	Discussion on paging procedure for Ambient-IoT 
Document for:	Discussion

Conclusion
We have the following proposal and observation:
Proposal 1: A new service request is received from different reader(s) while an ongoing procedure 
is still in progress. The following options can be considered as baseline:
Option 1: The device rejects new request(s).
Option 2: The device executes the new service request.
Option 3: The device will process higher priority request.

Proposal 2: The starting point of ongoing procedure is when the device receives a paging message from the reader in device point of view. 
Proposal 3: The ending point of ongoing procedure can be implicitly indicating by R2D message.
Observation 1: When the CN correlation ID was clarified by SA2, the reader can generate a transaction ID based on the CN correlation ID. We provides three options for further discussion.
Option 1: Use X bits (e.g. LSB),
Option 2: A mapping mechanism,
Option 3: The reader selects a transaction ID that has not been used recently to avoid ID duplication.

Observation 2: The single device ID in paging message can be based on IMSI / Instance Identifier for uniqueness in single/multiple readers.  
Reference:
[1] TR 38.769, “Study on solutions for ambient IoT (Internet of Things)”.
[2] TR 23.700-13,” Study on Architecture support of Ambient power-enabled Internet of Things”.
[3] TS 23.003,” Numbering, addressing and identification;”.

3GPP TSG-RAN WG2 Meeting #130	R2-2504573
St.Julians, Malta, May. 19th– 23rd, 2025
	
Agenda Item:	8.2.2
Source:	OPPO
Title:	Discussion on paging procedure for Ambient IoT
Document for:	Discussion, Decision

Conclusion
In this contribution, we focus on paging procedure and have the following observations and proposals:
Subsequent paging for the same service: Transaction ID
Proposal 1: RAN2 confirms that subsequent paging for the same service has the same transaction ID as the initial paging.
Subsequent paging for the same service: Message type
Observation 1: Using the same transaction ID for both initial and subsequent paging ensures that devices can effectively avoid duplicate responses. 
Proposal 2: Initial paging and subsequent paging share the same message type.
Subsequent paging for the same service: Missed NACK
Proposal 3: RAN2 to discuss which option is preferred for subsequent paging of devices that missed a NACK:
Option 1: The subsequent paging message can include AS ID/ device ID of devices that missed NACK.
Option 2: Reader can retransmit NACK to devices that failed to receive the initial NACK, followed by sending a second subsequent paging message for re-access.
Where is MSG1 resource
Proposal 4: RAN2 to clarify which understanding of the initial paging and R2D trigger messages is correct:
Understanding 1: The A-IoT device randomly selects the access occasion number from the initial paging message and use this information to find its detailed MSG1 resources in R2D trigger message 
Understanding 2: The initial paging message includes the detailed MSG1 resources and the R2D trigger message indicates the selected MSG1 resource is available.
Indication of paging ID existence
Proposal 5: Include 1 bit indicator in the header of A-IoT paging message to distinguish whether a paging ID is included.

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

Source:	CEWiT
Title:	A-IoT Paging 
Agenda Item:	8.2.2
Document for:	Discussion and Decision

Conclusion
In this contribution, we provide our views on aspects of paging message for Ambient IoT. The proposals are summarized as follows.

Proposal 1: Support the additional following contents for paging message :
Information related to random Number (Q) or random device ID Generation 
The total number of time domain resources and the number of the frequency domain resources for MSG1 transmission

Proposal 2: Support to define the device behavior if it gets a new service request while one procedure is still ongoing. 

Observation 1: Preferred Option A i.e. ignore all new requests and R2D messages addressed to itself but not associated with the ongoing procedure for the following reasons:
No reader coordination required
Simple device architecture

Proposal 3: Support option A i.e. device ignores all new service requests and R2D messages not associated with the ongoing procedure unless one of the following cases occurs:
Until receiving the NACK 
Not receiving a R2D message in the monitoring window

Proposal 4: Support to consider following device behavior if the parallel service request is associated with same procedure:
Respond to parallel service requests associated with same procedure if request is from same reader and contains a flag indicating the retransmission.
Neglect parallel service request associated with same procedure unless one of the following cases occurs
Until receiving NACK
Not receiving a R2D message in the monitoring window

Proposal 5: Include service request ID for the device to identify the procedure associated with the service request.

Proposal 6: Include service request ID in all R2D messages corresponding to a service request, enabling the device to associate all related R2D messages with the same service request.

Proposal 7: Include reader ID in service request for the device to identify the reader.

Proposal 8: For TDMA of multiple Msg1 transmissions in response to a R2D transmission triggering random access: 
Based on the slotted aloha in a predefined RACH time window.
Proposal 9: R2D trigger used to determine the start of the RACH time window for transmission of MSG1 is supported.
Proposal 10: 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. 

3GPP TSG-RAN WG2 Meeting #130						        			R2-2504638
St.Julians, Malta, May 19 – 23, 2025
Source: 		ZTE Corporation, Sanechips
Title:                  Further consideration on Paging procedure for A-IoT
Agenda item:   8.2.2
Document for: Discussion and Decision

Conclusion
The following observations and proposals are made in this contribution: 
Paging message contents
Proposal 1 (Issue 1-2): The exact reader behaviour for how transaction ID is generated need not be specified 
Proposal 2 (Issue 1-2): The size of the transaction ID should be 6 bits 
Proposal 3 (Issue 1-4): The paging message indicates the total number of MSG1 slots (Q) and the number of AOs in time domain per MSG1 slot (X: either 1 or 2) and number of AOs in frequency domain per MSG1 slot (Y)
Proposal 4 (Issue 1-4): The maximum value of Q is 15 – i.e. the total number of MSG1 slots is between 1 (i.e. 2^0) and 2^15. 
Proposal 5 (Issue 1-4): RAN2 should wait for RAN1 to decide the values for number of AOs in frequency domain per MSG1 slot (Y)

Paging ID visibility
Observation 1: Operating the system without group splitting (i.e. masking the paging identifier) will result in highly negative performance when the device density is high where the slotted-Aloha system operates in non-linear region
Observation 2: At low device densities, the optimal strategy is to not split the groups into sub-groups
Observation 3: The crossover point for the optimal operation for group splitting depends on device density, contention levels and other radio conditions such as coverage etc
Observation 4: The CN cannot control the contention based on the device density or the actual contention levels because these are not known at the CN. Furthermore, if a wrong group size/mask is selected by the CN, then the inventory procedure at the reader will suffer significantly and may never converge
Observation 5: Existing systems such as RFID employ reader based “select” procedure which enable sub-grouping of the contending devices on the radio side
Proposal 6 (Issue 1-6): The reader should be able to apply an AS layer “mask/filter” scheme on the Paging identifier information from a CN/AF service request to select a subset of devices.