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

Agenda Item:	8.13.3
Source:	NEC
Title:	Remaining Issues of Control Plane aspects
Document for:	Discussion, Decision

Conclusion and Proposal
We have the following proposals:

Proposal 1: Fast/parallel SRB0 message forwarding is supported for both UL SRB0 message and DL SRB0 message.
Proposal 2:	The source of on demand SIB request message (i.e., Remote UE ID) is included in the on demand SIB request message over PC5 RRC (i.e., within the RemoteUEInformationSidelink) along the relay path until the last Relay UE.
Proposal 3:	The destination of requested SIB message (i.e., Remote UE ID) is included in the on forwarded SIB message over PC5 RRC (i.e., within the UuMessageTransferSidelink) along the relay path until the first Relay UE.
Proposal 4:	The intermediate Relay UE is allowed to provide the request SIBs to the Remote UE if there is a valid version of the request SIBs.
Proposal 5:	The intermediate Relay UE continues to further forward the SIB request message to its parent Relay UE if the intermediate Relay UE only holds a subset of the SIBs requested by the Remote UE.

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

Source:	CATT 
Title:	Discussion on the Control Plane Procedures
Agenda Item:	8.13.3
Document for:	Discussion and Decision

Conclusion
According to the analysis in section 2, for Approach 1, it is proposed:
RLF handling
Proposal 1: In approach 1, when Remote UE detects PC5 RLF, its behaviors are same as Rel-17 U2N Remote UE.
Proposal 2: In approach 1, when the first Relay UE detects PC5 RLF between the Remote UE and the first Relay UE, its behaviors are same as Rel-17 U2N Relay.
Proposal 3: In approach 1, when the first Relay UE detects PC5 RLF between the first Relay UE and Intermediate Relay/last Relay UE, it can send NotificationMessageSidelink to the Remote UE to indicate the failure between first Relay UE and Intermediate Relay/last Relay UE.
Proposal 4: In approach 1, when the last Relay UE detects PC5 RLF, its behaviors are same as Rel-17 U2N Relay UE.
QoS split
Proposal 5:  In approach 1, UE assistance information is not needed for QoS split.

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

Agenda Item:	8.13.3
Source:	OPPO
Title:	Control plane procedures of multi-hop U2N relay  
Document for:	Discussion, Agreement

Conclusion
We have the following observations:
Observation 1	The baseline mechanism works well and is implemented in the running CR with very minor specification impact.
Observation 2	In R17, at the U2N Relay UE, the SRAP configuration for each remote UE is configured based on the L2 ID of the remote UE, the L2 ID is mandatory present and can uniquely identify a link and SRAP configuration for the remote UE.
Observation 3	In legacy, radio bearer is identified by UE ID and BEARER ID, it is not clear how to identify the radio bearer without local ID or bearer ID configuration.
Observation 4	In legacy, egress RLC channel is configured by the network based on the BEARER ID for each remote UE, it is not clear how to know the RLC channel without RLC channel configuration.
Observation 5	In legacy, Relay UE checks whether the received SRAP PDU is unknown, unforeseen, and erroneous by matching the UE ID and BEARER ID with the SRAP configuration, without local ID configuration, the handling of unknown, unforeseen, and erroneous protocol data cannot work.
Observation 6	As shown in the above table, it is not clear what signaling can be saved by reflective bearer mapping.
Observation 7	The necessary SIB(s) for Intermediate U2N relay UE includes the SIB(s) requested by the Child UE already.
Observation 8	Upon reception of paging request from the Child UE, the intermediate U2N Relay UE should either send the paging request to the parent UE or acquire paging directly from the network.
Observation 9	Similar to SIB request, legacy condition “if the UE has paging related information to provide” is sufficient to let the intermediate U2N Relay UE forward paging request for the child UE when necessary (i.e., no direct acquisition from the network).
Observation 10	The RRC_CONNECTED relay UE on an active BWP without pagingSearchSpace configured acquires paging message of the RRC_CONNECTED remote UE via dedicatedPagingDelivery.

We have the following proposals:
Proposal 1	(SRAP-1) RAN2 not pursue reflective bearer mapping enhancement and confirm the current running CR (i.e., child UE’s SRAP configuration includes entries for indirect child UE) as it is.
Proposal 2	For any SIB(s) requested by child UE, the Intermediate U2N Relay UE is allowed to acquire them over Uu interface as necessary SIB(s) without any further specification impact.
Proposal 3	Rely on legacy condition “if the UE has paging related information to provide” to allow intermediate U2N Relay UE to either forward paging request for the child UE when necessary or to directly acquire from the network (but not both) without additional spec impact.
Proposal 4	Similar to SIB request, a paging information list should be introduced for the intermediate relay UE to carry the paging information from the downstream remote UEs as above TP.
Proposal 5	As in R17, the RRC_CONNECTED L2 intermediate relay UE reports paging-related information of the connected child UE via SUI and acquires paging messages for its child UEs via dedicatedPagingDelivery.
Proposal 6	The intermediate relay UE in RRC_CONNECTED releases the paging-related information for the child UEs in the parent UE.

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

Agenda item:	8.13.3
Source: 	China Telecom
Title:	Discussion on control plane aspects for NR sidelink multi-hop relay
WID/SID:	NR_SL_relay_multihop
Document for:	Discussion and Decision

Conclusion
In this contribution, we discuss control plane remaining issues for multi-hop U2N relay. We kindly ask RAN2 to consider the corresponding proposals listed as below.
Proposal 1: RAN2 confirms that the child UE’s SRAP configuration can include entries for indirect child UE with associated local ID for next-hop determination.
Proposal 2: No need to introduce reflective bearer mapping for SRAP configuration at the relay UE.
Proposal 3: For the SIB requested by child UE, if it is NOT the concerned SIB of intermediate relay UE, regarding in-coverage intermediate relay UE in IDLE/INACTIVE is allowed to acquire such SIB broadcast by the last relay UE’s serving cell via Uu interface directly, which is up to UE implementation. No spec impact is needed.
Proposal 4: Regarding the sending of SI request by an intermediate relay UE to the parent relay, RAN2 confirms not to support sending SI request when there is a change in the ability of the intermediate UE to receive SIB broadcast on Uu.
Proposal 5: RAN2 confirms that the intermediate relay UE can respond directly if it has the requested SI. For the requested SI that the intermediate relay UE doesn’t have, it forwards the requested SI list to the parent relay or last relay.

3GPP TSG-RAN WG2 Meeting #130	R2-2503726
St. Julians, Malta, 19-23 May 2025
                            
Agenda item:	8.13.3
Source:	Apple, FirstNet, Ericsson, AT&T, Kyocera, Philips, NEC 
Title:	Fast & Parallel RRC Establishment for Multi-hop U2N relaying and TP
WID/SID:	NR_SL_relay_multihop – Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss the design of fast forwarding of SRB0 for Multi-hop SL relay, and have the following observations:
Observation 1	Remote UE get to know its Local ID allocation from DL RRC message (SRB0). UE ID indication need not to be set in the new SRAP header with L2 ID.
Observation 2	With Uu SRAP header unchanged, there is no RAN3 impact in regards of support fast forwarding.
Observation 3	gNB awareness of full path information is not needed when handling SRB0 message.
Observation 4 	A relay UE in RRC_CONNECTED forwards SRB0 message(s) received in SL-RLC0/SL-RLCx as same as baseline procedure.
Observation 5	A relay UE can detect whether its next hop relay supports fast-forwarding or not via PC5-RRC Capability Exchange procedure.
Based on the discussion, we propose:
Proposal 1 	Fast forwarding is applicable to Both UL and DL SRB0 message.
Proposal 2	L2 ID is included in the SRAP header between relay UEs when forwarding SRB0 message in both directions.
Proposal 3	Relay UE remember which PC5 link is received the first UL RRC message from the downstream nodes and use it for egress PC5 link determination for DL SRB0 message. 
Proposal 4	The SRAP operation in the first PC5 hop (Remote-FirstRelay) and last hop (Uu hop) remain as same as Rel-17 legacy.
Proposal 5	A new default SL-RLCx is introduced between relay UEs to carry fast-forwarded SRB0 traffic.
Proposal 6	SRAP configurations in DL SRB0 message for each Relay UE for SRB1 message forwarding can be signaled by the gNB reusing the legacy Rel-17 SRAP configuration structure without knowing the path information. The relay UE determines the egress link based on reflective mapping.

Proposal 7	Support SUI signalling to report the L2 ID(s) of the indirectly connected downstream nodes to solicit local ID allocation.
Proposal 8 	Assume fast forwarding is optional for U2N relay UEs to support. A Relay UE which does not support SRB0 fast-forward or has detected its parent relay does not support fast-forward should enter RRC_CONNECTED first and then forward the SRB0 message(s) to gNB as same as baseline procedure. 
4 

3GPP TSG-RAN WG2 Meeting #130	R2-2503727
St. Julians, Malta, 19-23 May 2025
                                
Agenda item:	8.13.3
Source:	Apple
Title:	Discussion on SRAP and Control Plane for Multi-hop Layer-2 U2N Relay
WID/SID:	NR_SL_relay_multihop – Release 19
Document for:	Discussion and Decision
1 

Conclusion
In this contribution, we discuss some SRAP and RRC remaining issues and have the following proposals:
Proposal 1 	Reflective mapping is used for SRAP entity to derive DL egress PC5 link as it does not require the change of legacy SRAP configuration .
Proposal 2 	RAN2 discuss whether SL-RLC Channel configuration for Intermediate relay UE is per direction or for both directions. And if the configuration is direction-agnostic, what is the correct UE behaviour.
Proposal 3 	Both UL PDB and DL PDB can be provided in SL-RLC-ChannelConfig together in dedicated RRC configuration for intermediate relay UE to use in UL direction or DL direction respectively .
Proposal 4	When the SRAP mapping configuration (RB to Relay RLC channel) is not provided for a “local ID”, the default PC5 relay RLC channel(s) are used by the relay UE to forward the SRAP PDU for this “local ID” .
Proposal 5 	Support to label a certain SL-RLC-ChannelConfig or SL-RLC-Channel-ID to be the default egress RLC channel for a certain kind of end-to-end traffic ( SRB or DRB, upstream or downstream ).
Proposal 6 	Allow Intermediate Relay UE to send/forward PC5-RLF notifications to upstream nodes via PC5-RRC .
Proposal 7 	Extend RemoteUEInformationSidelink message to allow aggregation of multiple paging/SI requests together.
Proposal 8 	Allow UuMessageTransferSidleink to contain a list of PagingRecord.
4 

TDoc file reading error

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

Agenda Item	: 8.13.3
Source	: LG Electronics Inc.
Title	: Discussion on Control Plane Procedure for multi-hop U2N relay
Document for	: Discussion and Decision
1.	

Conclusion
Observation 1: In the legacy, gNB naturally knows that which Remote UE has a connection with which Relay UE.
Observation 2: The gNB has to know the configured SL RLC channel configuration for SRB1 is used for which PC5 link to manage the PC5 RLC channel configuration.  
Observation 3: In the multi-hop with fast/parallel setup procedure, gNB cannot know which PC5 link is associated with which Remote UE or intermediate Relay UE. 
Observation 4: Considering RAN3 operation, the gNB configures SRB1 for the Remote UE upon receiving the initial SRB0 message of the Remote UE. To do this, gNB has to know that the SRB1 configuration is for the PC5 link between the Remote UE and the first Relay UE.
Proposal 1: Considering RAN3 operation, gNB has to know which PC5 link is used for the SRB1 when configuring SRB1. 
Proposal 2: If the last Relay UE reports path information, gNB can configure SRB1 parallelly for each intermediate Relay UEs and Remote UEs.
Proposal 3: The SRB1 of the Remote UEs can be multiplexed over the egress PC5 RLC channel of the parent UE as the SRB1 of the Remote UE can be multiplexed at the Uu link of the U2N relay UE in the legacy.
Proposal 4: For the initial UL SRB0 message delivery, the following new SRAP header structure can be used for the CONNECTED intermediate or last Relay UE to infer the path information. 
-  The L2 ID (A) is the source L2 ID of the Remote UE (the source means the uplink direction).
- The L2 ID (B) is the source L2 ID of the first Relay UE (the source means the uplink direction).

Figure 3. SRAP header structure for delivering the initial UL SRB0 message when the first Relay UE is in RRC_IDLE/INACTIVE

Proposal 5: The new SRAP header can be attached when the first Relay UE is in RRC_IDLE/INACTIVE.
Proposal 6: If the IDLE/INACTIVE intermediate Relay UE receives the new SRAP header, the intermediate Relay UE forwards it transparently.
Proposal 7: If the CONNECTED intermediate Relay UE or last Relay UE receives the initial UL SRB0 message with the new SRAP header, the intermediate Relay UE or last Relay UE reports the path information and request local ID allocation to the gNB.
Proposal 8: The gNB sends SRB0 message with the legacy SRAP header.
Proposal 9: The last Relay UE modifies the SRAP header to add L2 ID, which is matched with the local ID. The modified SRAP header structure is as follows:
- The UE L2 ID (A) is the L2 ID that the SRB0 (/RRCSetup) message should be arrived.

Proposal 10: If the received SRAP header is belonging to its child UE, the intermediate Relay UE or last Relay UE removes the SRAP header and delivers it to the child UE as the legacy.
Proposal 11: If the received SRAP header is not belonging to its child UE, the intermediate Relay UE forwards it to the proper child UE. The way to find a proper child UE is based on the matching between stored L2 ID information when receiving the initial UL SRB0 message and the L2 ID in the received SRAP header.
Proposal 12: When the Remote UE in RRC_INACTIVE uses the pre-allocated local ID to become RRC_CONNECTED, if its parent Relay UE doesn’t have the related configuration of the local ID, the parent Relay UE will discard the received packet. In this case, RAN2 has to discuss how the Remote UE or the parent Relay UE in RRC_INACTIVE performs.
Proposal 13: When the RRC_INACTIVE Remote UE having the pre-allocated local ID moves to the other cell/gNB, the original gNB should recall the pre-allocated local ID from the Remote UE. RAN2 has to discuss how the gNB can recall the pre-allocated local ID.
Proposal 14: The timer (e.g., T300, T301 or T319) value for RRC connection establishment has a dependency on the hop count.
Proposal 15:  The gNB and Remote UE has to be set the same timer value for RRC connection establishment.
Proposal 16: If the path information is reported to the gNB, the gNB can know implicitly the hop count to reach the Remote UE in the fast/parallel setup procedure.
Proposal 17: If the intermediate Relay UE receives a notification message while the timer (e.g., T300, T301 or T319) for connection establishment is running, the intermediate Relay UE stops the behaviour and forwards the received notification message to the child UE. 
4.	

3GPP TSG-RAN WG2 Meeting #130	R2-2503929
Saint Julian’s, Malta, 19 – 23 May 2025	R2-2502194	

Agenda item:	8.13.3
Source:	Nokia
Title:	Control plane and SRAP procedures for Multi-hop relay
WID/SID:	NR_SL_relay_multihop – Release 19
Document for:	Discussion and Decision
1	

Conclusion
This document has made the following observations and proposals:
Observation 1: Some UEs may be able to distinguish whether the stored SI is applicable to the remote UE.
Observation 2: Allowing the parent UE to acquire SI from the serving cell can reduce overhead and latency significantly within the system.
Proposal 1: An intermediate relay UE can acquire SI from both the last relay UEs serving cell, if applicable, as well as through PC5-RRC from the parent relay UE.
Proposal 2: The intermediate relay UE can respond directly instead of forwarding the request to the parent node if it has the requested SI.

TDoc file reading error

TDoc file reading error

TDoc file reading error

3GPP TSG-RAN WG2 #130	R2-2504160
St Julian’s, Malta, 19-23 May 2025
Agenda Item:	8.13.3
Source:	Ericsson
Title:	Discussion on control plane procedures
Document for:	Discussion, Decision
1	

Conclusion
In the previous sections we made the following observations: 
Observation 1	For the baseline approach, upon reception of a SRAP data PDU, the relay UE needs to first locate the matching SRAP configuration entry according to the local ID contained in the SRAP header, then to find the L2 ID of the directly connected child. The searching procedure is two-step wise, which is not efficient.
Observation 2	For the baseline approach, it is not feasible for the gNB to provide delta configuration for one indirectly connected child based on its L2 ID.
Observation 3	By adopting a flatten structure for the SRAP configuration of each relay UE, it is easier to find matching SRAP entity upon reception of an SRAP data PDU since the searching procedure is 1 step wise.
Observation 4	By adopting a flatten structure for the SRAP configuration of each relay UE, it is feasible for the gNB to provide delta configuration for each indirectly connected child UE.
Observation 5	Reflective mapping for determining the egress link can be always applied (if the relay UE supports it), since each child UE will always start with SRB transmission.
Observation 6	Reflective mapping for determining the egress RLC channel may be not always feasible (even if the relay UE supports it), since each child UE may not always start with UL transmission for an RB (e.g., SRB2 and/or DRBs).
Based on the discussion in the previous sections we propose the following:
Proposal 1	For the SRAP configuration at the relay UE (both last relay and intermediate relay UE), rely on network to provide SRAP configuration for both directly connected child UEs and indirectly connected child UEs, based on their L2 IDs, i.e., the flatten structure for SRAP configuration is adopted.
Proposal 2	In the flatten SRAP structure at the relay UE (both last relay and intermediate relay UE), include a field sl-DLNextHop-L2Identity-r19 for configuring the next hop L2 ID for downlink mapping.
Proposal 3	In the flatten SRAP structure at the relay UE (both last relay and intermediate relay UE), for each received SRAP data PDU, the relay UE determines the egress link based on sl-DLNextHop-L2Identity-r19 if it is present, otherwise, based on sl-L2IdentityRemote.
Proposal 4	Reflective mapping is optional to be supported at relay UE for DL mapping.
Proposal 5	Reflective mapping is only supported for egress link determination.
Proposal 6	When Reflective mapping is applied, the field sl-DLNextHop-L2Identity-r19 for the flatten structure is absent, while the field sl-LocalIdentity-r17 is still needed to be included in the SRAP configuration for each child for indexing the corresponding SRAP configuration.

4	

3GPP TSG-RAN WG2 Meeting #130	R2-2504274
St Julian’s, Malta, May. 19th – 23rd, 2025
Agenda Item:	 8.13.3
Source:	 Huawei, HiSilicon
Title:	 Control Plane Procedures for Multi-hop Relay
Document for:  Discussion and Decision
1	

Conclusion 
Alternative Solutions for Reducing Connection Establishment Latency
Observation 1: The scenario where all the relay UEs involved in the multi hop connection establishment are in the RRC IDLE/INACTIVE state when the remote UE triggers the connection establishment is unlikely to occur frequently in reality. A more common scenario is that the last and intermediate relay UEs (including the first relay UE) are already in connected state and have established the connection to the network for their own traffic before they start serving the remote UEs.
Proposal 1: Considering the benefits and minimal specification impact of the three candidate solutions, one of the following candidate solutions can be adopted to reduce the latency associated with the connection establishment procedure of a remote UE:
Solution 1 - The Relay UE includes its RRC state in the discovery message, allowing the remote UE to prioritize selection of an RRC_CONNECTED Relay UE when its service requirements are stringent otherwise it can choose the path through RRC_IDLE or RRC_INACTIVE Relay UEs.
Solution 2 - An RRC_IDLE or RRC_INACTIVE Relay UE performs the discovery procedure only until the hop count between the relay UE and the network reaches (maximum supported hop count − 1).
Solution 3 - Certain Relay UE(s) can be authorised to remain in RRC Connected State for longer duration after establishing the connection with the network thereby improving their availability for low-latency relay service
Open issue RRC-4: Extending T300, T301 and T319
Proposal 2: Extend the T300, T301 and T319 timer for multi-hop U2N relay operation in accordance with the hop count for connection establishment/ re-establishment and resume procedure.
QoS split
Proposal 3. RAN2 confirm that the QoS split is determined by gNB and guaranteed by gNB by implementation.

SRAP configuration
Proposal 4: The SRAP configuration contains the mapping configuration between the remote UE’s SRB/DRB and the egress Uu/PC5 Relay RLC channel.
For the first relay UE, the SRAP configuration includes the remote UE ID (L2 ID and local ID), SRB/DRB ID, the egress PC5 relay RLC channel between the first relay UE and remote UE, the egress PC5 relay RLC channel between the first relay UE and its parent relay UE.
For intermediate relay UE, the SRAP configuration includes the remote UE ID (L2 ID and local ID), SRB/DRB ID, the identity (L2 ID) of its child relay UE, the egress PC5 relay RLC channel between the intermediate relay UE and its child relay UE, the egress PC5 relay RLC channel between the intermediate relay UE and its parent relay UE.
For the last relay UE, the SRAP configuration includes the remote UE ID (L2 ID and local ID), SRB/DRB ID, the identity (L2 ID) of its child relay UE, the egress Uu relay RLC channel on Uu, the egress PC5 relay RLC channel between the last relay UE and its child relay UE.

Proposal 5: For handling the Multi hop relay path information there are two options that can be considered 
Option 1 - The path information can be implicitly delivered by last or the intermediate relay UE by mapping local ID of the remote UE (carried in the SRAP header) to the L2 ID of the child relay UE during the uplink transmission of RRCSetupRequest message 
Option 2 - The path information can be explicitly provided through the identity (L2 ID) of the child relay UE in the SRAP configuration for the intermediate and last relay UE.
Paging forwarding
Proposal 6: Paging monitoring by the last relay UE for the remote UE(s)/child UEs should be considered as the baseline approach. An intermediate relay UE, when within cell coverage, may optionally monitor paging for the connected remote/child UEs based on its implementation.

4	

3GPP TSG-RAN-WG2 Meeting #130	R2-2504359
St.Julians, Malta, 19th– 23rd May, 2025
Agenda item	:		8.13.3
Source	: 	Sharp
Title	: 	Remaining issues for C-plane procedure
Document for	:	Discussion and Decision

Conclusion
In this paper, we made following observations and proposals:
Proposal 1. When intermediate relay UE enters RRC_CONNECTED, paging information at a parent relay UE is not released. 
Observation 1. Paging information at R17/18 U2N relay UE is associated with a PC5-RRC connection.
Proposal 2. Information indicating paging information to be released should be included in RemoteUEInformaionSidelink.
Proposal 3. Changes in PO monitoring availability on Uu should not trigger requests/cancellations of PO monitoring.
Proposal 4. An intermediate relay UE will forward a received paging record only if a paging record containing the corresponding paging UE ID has not already been forwarded to the child UE.
Proposal 5. Support SIB receiving on Uu by an intermediate relay UE.
Proposal 6. The intermediate relay UE doesn’t send SI requests/cancelations in PC5-RRC to the parent relay when there is a change in the ability of the intermediate UE to receive SIB broadcast on Uu.
Observation 2. Relay UEs can forward SIBs based on the internal routing table as shown in figure 2.
Proposal 7. UE ID is not required in SIB request message and SIB delivery message.
Proposal 8. Responding requested SI directly by an intermediate relay UE is supported.
Proposal 9. An intermediate relay UE should check whether the received SIB is updated to avoid duplicated SIB forwarding.
Proposal 10. The value of BEARER ID 0,1,2 should be used for E2E SRB 0,1,2 as with U2U relay.
Proposal 11. QoS related optimization should be considered since very low E2E latency is required for some use cases.
Proposal 12. The principles of resource allocation follow the legacy mechanism, i.e., last relay can be configured with mode 1 resource allocation, and remote UE and other relay UEs are configured with mode 2 resource allocation.
Observation 3. gNB can guarantee at least one hop (i.e., last relay hop) QoS using mode 1 resource allocation or UL grant allocation.
Observation 4. If gNB knows quality of each hop, gNB can configure appropriate QoS for each hop and also select appropriate indirect path with good quality. 
Proposal 13. UE reports hop-by-hop link quality to gNB for path selection and split QoS configuration.
Proposal 14. RAN2 discusses whether the UE received NotificationMessageSidelink sets the same indicationType with the received notification or multi-hop specific indicationType.
Proposal 15. New UE type in SUI is introduced for an intermediate relay UE.
Proposal 16. intermediate relay UE specific information reporting is introduced in SUI to avoid duplicated information reporting by multiple relay UEs.
Observation 5. In Rel-17, RAN2 decided not to support resource allocation mode 1 for remote UE because HARQ using gNB is disabled, RAN1 hasn’t discussed mode 1 for remote UE, and CG type 1 is introduced for URLLC.
Proposal 17. RAN2 confirms that resource allocation mode 1 can only be supported by a last relay UE. Remote UE and intermediate relay UE only support resource allocation mode 2 regardless it is IC or OOC.
Proposal 18. Discuss whether RAN2 assumes or specifies NW ensures that an intermediate relay UE is not configured with dataInactivityTimer.
Proposal 19: Discuss UE behavior in RRC re-establishment procedure to perform relay selection or cell selection considering the UE’s role in the multi-hop.

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130		R2-2504523
St.Julians, Malta, 19th – 23rd May 2025		
Source:	vivo
Title:	Discussion on remaining issues on paging
Agenda Item:		8.13.3
Document for:	Discussion and Decision

Conclusion
In this contribution, we discussed potential spec impact on paging request forwarding on the link between intermediate relay UE and its parent relay UE. We have the following Observations and Proposals:
Observation 1: In post email discussion about SIB request on parent link, the legacy condition is preferred by companies to adopt to determine SIB request in parent link is needed or not.

Proposal 1: To minimize the spec impact to support intermediate relay UEs in coverage monitoring paging for a child UE on Uu interface, adopt legacy condition (‘if the UE has paging related information to provide’) to determine paging request in parent link is needed or not.
Proposal 2: Legacy condition (“if the UE has paging related information to provide”) is enough and no additional specification change is needed to support FFS ‘upon change in the ability of the intermediate UE to monitor paging on Uu (e.g., moving in/out of coverage) to initiate/cancel paging monitoring by the parent relay)’.

TDoc file reading error

3GPP TSG-RAN WG2 Meeting #130                                                                  R2-2504561
St.Julians, Malta,  May 19th – 23rd , 2025
Source:	Qualcomm Incorporated 
Title:	Open issue for control plane
Agenda Item:	8.13.3
Document for:	Discussion and Decision
Introduction & 

Conclusion
Paing forwarding
The intermediate does not monitor paging for the child UE over Uu interface.
The intermediate Relay UE always forwards paging request to the parent UE if receiving from the child UE.
The intermediate Relay UE does not release paging information for the child UEs in the parent relay UE when the intermediate relay UE is in RRC_CONNECTED.
When an intermediate relay UE is in RRC_IDLE/RRC_INACTIVE acting as Remote UE functionality, it can obtain paging for itself directly on Uu by implementation when the intermediate relay UE is in coverage, like today’s Remote UE.
When an intermediate relay UE moves in or out of coverage, it does not initiate or cancel paging monitoring by parent relay UE.
Fast SRB0 forwarding
The Remote UE can store the assigned Local ID in CONNECTED state when entering Inactive state.
The Remote UE includes the stored local ID as UE ID in the SRAP header for RRCResumeRequest message.
The gNB includes the stored local ID as UE ID in the SRAP header for RRCResume message.
Scenario restriction 
If the intermediate Relay UE has established PC5 connection for one RSC associated with one last Relay UE, the intermediate Relay UE does not transmit other RSC(s) in any discovery message.
Sends LS to SA2.
If a UE in CONNECTED state via direct path receives relay establishment request from the Remote UE or downstream intermediate Relay UE, the UE can perform direct path to indirect path switch to act as an intermediate Relay UE for the relay traffic and Remote UE for its own traffic
 gNB can configures the UE whether to perform direct path to indirect path switch.

3GPP TSG-RAN WG2 Meeting #130	R2-2504642
St Julian’s, Malta, 19 – 23 May 2025	
Agenda item:	8.13.3
Source:	Samsung
Title:	SRAP design for R19 multi-hop SL relaying and remaining Control Plane issues
Document for:	Discussion & Decision

Conclusion
RAN2 is kindly asked to discuss and agree the following proposals:
Proposal 1a. RAN2 to clarify whether intermediate Relay UE acting as a U2N Remote UE, is only applicable to the connection establishment and set-up procedure, or whether simultaneous operation is foreseen more permanently i.e. if a UE can act simultaneously as a Relay UE for a MH network, and a legacy Remote UE.
Proposal 1b. RAN2 to clarify whether such simultaneous operation has any impact on specifications e.g. whether intermediate Relay UE acting as a U2N Remote UE impacts UE protocol stack, or whether these roles can be described separately and assumed applied in parallel.
Proposal 1c. RAN2 to clarify whether the simultaneous operation (if supported/relevant) of R19 MH “intermediate” and “first” relays as Remote UE is to be based on procedures for R17/18 (legacy) U2N Remote UEs (which is what the 38.300 running CR draft seems to hint at), or on procedures for legacy U2N Relay UE (which is the approach adopted by 38.351 running CR draft, but without discussing possible simultaneous operation).
Proposal 2. To cover the operation of a R19 intermediate Relay UE, the receiving SRAP operation of legacy U2N Remote UE in the downstream needs to be modified so that – based on the UE ID field of the received SRAP packet – the UE either delivers the packet to higher layers, or passes it on to the transmitting part of the SRAP entity.
Proposal 3. To cover the operation of a R19 intermediate Relay UE, the transmitting SRAP operation of legacy U2N Remote UE in the downstream needs to be introduced so that it can receive an SRAP packet from the receiving part of the SRAP entity, and so that it can – based on the next hop configured for this Relay UE per destination UE – determine the next Relay UE (or destination Remote UE, if the Relay in question is a first Relay UE) to deliver the packet to.
Proposal 4. To cover the operation of a R19 intermediate Relay UE, the receiving SRAP operation of legacy U2N Remote UE in the upstream needs to be introduced so that the UE can receive and process SRAP packets from other UEs.
Proposal 5. To cover the operation of the R19 last Relay UE, the legacy U2N Relay UE handling of SRB0 can be modified to apply the special SRB0 handling only for SL UEs attaching directly to this last Relay UE.
Proposal 6. The egress link on PC5 interface towards the next hop is determined based on the L2 ID of the next-hop UE (e.g. sl-L2IdentityNextHop) configured for the concerned destination UE ID.
Proposal 7: RAN2 is kindly asked to discuss how to avoid the connection establishment failure caused by the connection setup of first/intermediate/last relay UE (e.g., hop number based T300/T301/T319 setting). 
Proposal 8: RAN2 is kindly asked to discuss how to handle the remote UE’s packets undertaking forwarding in the routing path before releasing the configuration for the remote UE at the intermediate relay UE.

TDoc file unavailable