Method and apparatus for handling end-to-end pc5 radio link failure

Abstract

The invention discloses a method and a device for handling end-to-end PC5 radio link failure. The source remote user equipment also establishes at least one end-to-end PC5 radio resource control connection with the at least one target remote user equipment via the relay user equipment. The source remote user equipment detects an end-to-end PC5 radio link failure associated with a target remote user equipment of the at least one target remote user equipment. If a PC5 relay radio link control channel of the at least one PC5 relay radio link control channel is used to transmit a data packet for the target remote user equipment and is not shared by any other target remote user equipment, the source remote user equipment transmits a radio resource control reconfiguration sidelink message to the relay user equipment, and indicating the PC5 to be released to relay the radio link control channel.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 548,103 filed on November 10, 2023 and U.S. Provisional Patent Application No. 63 / 608,739 filed on December 11, 2023, the entire disclosures of the above U.S. Provisional Patent Applications are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates generally to wireless communication networks, and more particularly, to methods and apparatus for handling end-to-end PC5 radio link failures in wireless communication systems. Background Art

[0004] With the rapid growth of the demand for transmitting large amounts of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks that communicate using Internet Protocol (IP) packets. Such IP packet communications can provide IP-bearing voice, multimedia, multicast and on-demand communication services to users of mobile communication devices.

[0005] An exemplary network structure is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput to enable the above-mentioned IP-borne voice and multimedia services. Currently, the 3GPP standards organization is discussing new next-generation (e.g., 5G) radio technologies. Therefore, changes to the current body of 3GPP standards are currently being submitted and considered to evolve and complete the 3GPP standards. Summary of the invention

[0006] A method and apparatus for a source remote user equipment (UE). In one embodiment, the source remote UE establishes a PC5 radio resource control (RRC) connection with a relay UE. The source remote UE also establishes at least one end-to-end (E2E) PC5 RRC connection with at least one target remote UE via the relay UE. The source remote UE further transmits at least one configuration of at least one PC5 relay radio link control (RLC) channel to the relay UE, wherein the at least one PC5 relay RLC channel is used to transmit a data packet to at least one target remote UE. In addition, the source remote UE detects an E2E PC5 radio link failure (RLF) associated with a target remote UE in at least one target remote UE. In addition, if a PC5 relay RLC channel among at least one PC5 relay RLC channel is used to transmit data packets to the target remote UE and is not shared by any other target remote UE, the source remote UE transmits an RRC reconfiguration sidelink message to the relay UE in response to the E2E PC5 RLF, wherein the RRC reconfiguration sidelink message includes information indicating the PC5 relay RLC channel to be released. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A diagram illustrating a wireless communication system according to an exemplary embodiment;

[0008] Figure 2 is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an exemplary embodiment;

[0009] Figure 3 is a functional block diagram of a communication system according to an exemplary embodiment;

[0010] Figure 4 According to an exemplary embodiment Figure 3 Functional block diagram of the program code;

[0011] Figure 5 It is a reproduction of Figure 16.12.2.x-1 of 3GPP R2-2312029;

[0012] Figure 6 It is a reproduction of Figure 16.12.2.x-2 of 3GPP R2-2312029;

[0013] Figure 7 It is a reproduction of Figure 16.12.x-1 of 3GPP R2-2312029;

[0014] Figure 8 It is 3GPP R2-2311857 Figure 5 .8.9.1.1-1 reappearance;

[0015] Fig. 9 For 3GPP R2-2311857 Figure 5 .8.9.1.1-2 reappearance;

[0016] Fig.10 For 3GPP R2-2314014 Figure 5 .8.9.8.1-1 reappearance;

[0017] Fig.11 shows a PC5 RRC connection for inter-UE relay according to an exemplary embodiment;

[0018] Fig.12 An example for handling an E2E PC5 RLF is shown according to an exemplary embodiment;

[0019] Fig.13 An example for handling a second hop PC5 RLF notification according to an exemplary embodiment is shown;

[0020] Fig.14 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION

[0021] The exemplary wireless communication systems and devices described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communications, such as voice, data, etc. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP Long Term Evolution (LTE) radio access, 3GPP Long Term Evolution Advanced (LTE-A or LTE-Advanced), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation techniques.

[0022] Specifically, the exemplary wireless communication systems and devices described below may be designed to support one or more standards, such as those provided by an alliance named “3rd Generation Partnership Project” referred to herein as 3GPP, including: TS38.331V17.6.0, “NR; Radio Resource Control (RRC) protocol specification (Release 17)”; R2-2312029, “Introduction of NR sidelink relay enhancements (Release 18)”, LG Electronics; R2-2311857, “Introduction of NR sidelink U2U relay (Release 18)”, Vivo; R2-2312007, “Discussion on U2U relay”, Fujitsu; R2-2312696, “Control plane issues for L2 U2U relay”, LG Electronics; R2-2312697, “Control plane issues for L2 U2U relay”, LG Electronics; R2-2312698, “Control plane issues for L2 U2U relay”, LG Electronics; R2-2312699, “Control plane issues for L2 U2U relay”, LG Electronics; R2-2312697, “Control plane issues for L2 U2U relay”, LG Electronics; R2-231269 ... relaying”, Samsung; and R2-2314014, “Introduction of Rel-18 SL relayenhancements”, Huawei, HiSilicon, Vivo and MediaTek. The standards and documents listed above are hereby expressly incorporated herein by reference in their entirety.

[0023] Figure 1 1 shows a multiple access wireless communication system according to an embodiment of the present invention. An access network 100 (AN) includes multiple antenna groups, one of which includes antenna groups 104 and 106, another includes antenna groups 108 and 110, and another includes antenna groups 112 and 114. Figure 1In the figure, only two antennas are shown for each antenna group, however, each antenna group may utilize more or fewer antennas. Access terminal 116 (AT) communicates with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 via forward link 120 and receive information from access terminal 116 via reverse link 118. Access terminal (AT) 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to access terminal (AT) 122 via forward link 126 and receive information from access terminal (AT) 122 via reverse link 124. In an FDD system, communication links 118, 120, 124, and 126 may use different frequencies for communication. For example, forward link 120 may use a different frequency than the frequency used by reverse link 118.

[0024] Each antenna group and / or the area in which the antenna group is designed to communicate is often referred to as a sector of the access network. In an embodiment, the antenna groups are each designed to communicate with access terminals in a sector of the area covered by the access network 100.

[0025] In communicating over forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve the signal-to-noise ratio of the forward links for the different access terminals 116 and 122. Furthermore, an access network that transmits to access terminals randomly dispersed throughout its coverage area using beamforming may cause less interference to access terminals in neighboring cells than an access network that transmits to all of its access terminals over a single antenna.

[0026] An access network (AN) may be a fixed station or base station for communicating with a terminal, and may also be referred to as an access point, Node B, base station, enhanced base station, evolved Node B (evolved Node B, eNB), network node, network, or some other term. An access terminal (AT) may also be referred to as a user equipment (UE), a wireless communication device, a terminal, an access terminal, or some other term.

[0027] Figure 2 2 is a simplified block diagram of an embodiment of a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an access terminal (AT) or user equipment (UE)) in a MIMO system 200. At the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a transmit (TX) data processor 214.

[0028] In one embodiment, each data stream is transmitted through a respective transmit antenna.TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

[0029] The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream are then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. The data rate, coding, and modulation for each data stream may be determined by instructions executed by processor 230.

[0030] The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). T The modulation symbol streams are provided to N T transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

[0031] Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission over the MIMO channel. T The antennas 224a to 224t transmit N signals from the transmitters 222a to 222t. T a modulated signal.

[0032] At the receiver system 250, N R The transmitted modulated signals are received by each antenna 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the modulated signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.

[0033] RX data processor 260 then extracts the N R The receiver 254 receives and processes N R received symbol streams to provide NT The RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and the TX data processor 214 at the transmitter system 210.

[0034] Processor 270 periodically determines which precoding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.

[0035] The reverse link message may include various types of information about the communication link and / or the received data stream. The reverse link message is then processed by the TX data processor 238, which also receives traffic data for multiple data streams from the data source 236, modulated by the modulator 280, conditioned by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

[0036] At the transmitter system 210, the modulated signals from the receiver system 250 are received by the antenna 224, conditioned by the receiver 222, demodulated by the demodulator 240, and processed by the RX data processor 242 to extract the reverse link message transmitted by the receiver system 250. The processor 230 then determines which precoding matrix to use to determine the beamforming weights and then processes the extracted message.

[0037] Steering Figure 3 , this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the present invention. Figure 3 As shown in FIG. , the communication device 300 in the wireless communication system can be used to implement Figure 1 UE (or AT) 116 and 122 in or Figure 1 The base station (or AN) 100 in the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (CPU) 308, a memory 310, a program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 through the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by the user through the input device 302 (such as a keyboard or a keypad), and can output images and sounds through the output device 304 (such as a monitor or a speaker). The transceiver 314 is used to receive and transmit wireless signals, deliver the received signals to the control circuit 306, and wirelessly output the signals generated by the control circuit 306. The communication device 300 in the wireless communication system can also be implemented Figure 1AN100 in.

[0038] Figure 4 According to an embodiment of the present invention Figure 3 4. In this embodiment, program code 312 includes application layer 400, layer 3 portion 402, and layer 2 portion 404, and is coupled to layer 1 portion 406. Layer 3 portion 402 typically performs radio resource control. Layer 2 portion 404 typically performs link control. Layer 1 portion 406 typically performs physical connectivity.

[0039] 3GPP TS 38.331 specifies sidelink radio bearer management and sidelink radio link failure related actions for Release 17 as follows:

[0040] 5.8.9.1a Sidelink Radio Bearer Management

[0041] 5.8.9.1a.1 Sidelink DRB Release

[0042] 5.8.9.1a.1.1 Sidelink DRB Release Conditions

[0043] For NR sidelink communications, sidelink DRB release is initiated in the following cases:

[0044] 1> For multicast, broadcast, and unicast, if the slrb-Uu-ConfigIndex (if present) of the sidelink DRB is contained in the sl-RadioBearerToReleaseList in the sl-ConfigDedicatedNR; or

[0045] 1> For multicast and broadcast, if no sidelink QoS flow with data indicated by upper layers is mapped to the sidelink DRB for transmission, the sidelink QoS flow is (re)configured by receiving SIB12 or SidelinkPreconfigNR; or

[0046] 1> For multicast, broadcast, and unicast, if the SL-RLC-BearerConfigIndex (if present) for the sidelink DRB is contained in the sl-RLC-BearerToReleaseList in the sl-ConfigDedicatedNR; or

[0047] 1> For unicast, if no sidelink QoS flow with data indicated by upper layers is mapped to the sidelink DRB for transmission, the sidelink QoS flow is (re)configured by receiving SIB12 or SidelinkPreconfigNR, and if no sidelink QoS flow is mapped to the sidelink DRB, the sidelink QoS flow is (re)configured by receiving RRCReconfigurationSidelink with data; or

[0048] 1> for unicast, if the SLRB-PC5-ConfigIndex (if present) of the sidelink DRB is contained in the slrb-ConfigToReleaseList in RRCReconfigurationSidelink or if sl-ResetConfig is contained in RRCReconfigurationSidelink; or

[0049] 1> for unicast, when the corresponding PC5-RRC connection is released due to detection of sidelink RLF according to clause 5.8.9.3; or

[0050] 1> For unicast, when the corresponding PC5-RRC connection is released due to an upper layer request according to clause 5.8.9.5.

[0051] 5.8.9.1a.1.2 Sidelink DRB Release Operation

[0052] For each sidelink DRB for which the sidelink DRB release conditions are met as in clause 5.8.9.1a.1.1, a UE capable of NR sidelink communication that is configured by upper layers to perform NR sidelink communication shall:

[0053] 1> for multicast and broadcast; or

[0054] 1> For unicast, if the sidelink DRB release is triggered after receiving the RRCReconfigurationSidelink message; or

[0055] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB release is triggered due to a configuration received in sl-ConfigDedicatedNR, SIB12 or SidelinkPreconfigNR or indicated by upper layers, then:

[0056] 2> Release the PDCP entity used for NR sidelink communication associated with the sidelink DRB;

[0057] 2> If the SDAP entity used for NR sidelink communication associated with this sidelink DRB is configured as:

[0058] 3> Indicate the release of the sidelink DRB to the SDAP entity associated with this sidelink DRB (TS 37.324

[24] , clause 5.3.3);

[0059] 2> Release the SDAP entity (if any) that does not have an associated sidelink DRB as specified in TS 37.324

[24] clause 5.1.2 for NR sidelink communications;

[0060] 1> for multicast and broadcast; or

[0061] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB release is triggered due to the configuration received in sl-ConfigDedicatedNR, then:

[0062] 2> For each sl-RLC-BearerConfigIndex included in the received sl-RLC-BearerToReleaseList that is part of the current UE-side link configuration:

[0063] 3> Release the RLC entity and corresponding logical channel used for NR sidelink communication associated with sl-RLC-BearerConfigIndex.

[0064] 1> For unicast, if the sidelink DRB release is triggered by receiving an RRCReconfigurationSidelink message; or

[0065] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB release is triggered due to the configuration received in SIB12, SidelinkPreconfigNR or indicated by upper layers, then:

[0066] 2> Release the RLC entity and corresponding logical channel used for NR sidelink communication associated with the sidelink DRB;

[0067] 2> Perform the Sidelink UE Information procedure for unicast in clause 5.8.3 when required.

[0068] 1> If a sidelink radio link failure is detected for a particular destination, then:

[0069] 2> Release the PDCP entity, RLC entity and logical channels of the sidelink DRB for a specific destination.

[0070] 5.8.9.1a.2 Sidelink DRB Addition / Modification

[0071] 5.8.9.1a.2.1 Sidelink DRB Addition / Modification Conditions

[0072] For NR sidelink communication, sidelink DRB addition is initiated only in the following cases:

[0073] 1> if any sidelink QoS flow is (re)configured by sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR and will be mapped to a sidelink DRB that is not established; or

[0074] 1> If any sidelink QoS flow is (re)configured by RRCReconfigurationSidelink and will be mapped to an unestablished sidelink DRB;

[0075] For NR sidelink communications, sidelink DRB modification is initiated only in the following cases:

[0076] 1> If, for an established sidelink DRB, any of the sidelink DRB-related parameters are changed via sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR, or RRCReconfigurationSidelink;

[0077] 5.8.9.1a.2.2 Sidelink DRB Add / Modify Operation

[0078] For a sidelink DRB for which the sidelink DRB addition conditions are met as in clause 5.8.9.1a.2.1, an NR sidelink capable UE configured by upper layers to perform NR sidelink communication shall:

[0079] 1> for multicast and broadcast; or

[0080] 1> For unicast, if the sidelink DRB addition is triggered due to the reception of an RRCReconfigurationSidelink message; or

[0081] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB addition is triggered due to the configuration received in sl-ConfigDedicatedNR, SIB12 or SidelinkPreconfigNR or indicated by upper layers, then:

[0082] 2> If there is no SDAP entity for NR sidelink communication associated with the destination and broadcast type of the sidelink DRB:

[0083] 3> Establish an SDAP entity for NR sidelink communication as specified in TS 37.324

[24] clause 5.1.1;

[0084] 2> (Re)configure the SDAP entity according to the sl-SDAP-ConfigPC5 received in RRCReconfigurationSidelink or the sl-SDAP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR associated with the sidelink DRB;

[0085] 2> establish a PDCP entity for NR sidelink communication and configure the PDCP entity according to the sl-PDCP-ConfigPC5 received in RRCReconfigurationSidelink or the sl-PDCP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR associated with the sidelink DRB;

[0086] 2> Establish an RLC entity for NR sidelink communication and configure the RLC entity according to the sl-RLC-ConfigPC5 received in RRCReconfigurationSidelink or the sl-RLC-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR associated with the sidelink DRB;

[0087] 2> If this procedure is due to receiving an RRCReconfigurationSidelink message, then:

[0088] 3> configure the MAC entity with the logical channel according to the sl-MAC-LogicalChannelConfigPC5 received in RRCReconfigurationSidelink associated with the sidelink DRB and perform the Sidelink UE Information procedure in clause 5.8.3 for unicast if necessary;

[0089] 2> Otherwise, if this procedure is due to receipt of an RRCReconfigurationCompleteSidelink message, then:

[0090] 3> Configure the MAC entity with the logical channel associated with the sidelink DRB according to the sl-MAC-LogicalChannelConfig received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR;

[0091] 2> Otherwise (i.e., for multicast / broadcast):

[0092] 3> Configure the MAC entity with the logical channel associated with the sidelink DRB according to the sl-MAC-LogicalChannelConfig received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR, and allocate a new LCID to this logical channel.

[0093] NOTE 1: When the sidelink DRB addition is due to the configuration of RRCReconfigurationSidelink, it is up to the UE implementation to select the sidelink DRB configuration with the parameters of the sidelink DRB transmitted as needed from the received sl-ConfigDedicatedNR (if in RRC_CONNECTED), SIB12 (if in RRC_IDLE / INACTIVE), SidelinkPreconfigNR (if out of coverage) with the same RLC mode as configured in RRCReconfigurationSidelink.

[0094] For a sidelink DRB for which the sidelink DRB modification conditions are met as in clause 5.8.9.1a.2.1, an NR sidelink capable UE configured by upper layers to perform NR sidelink communication shall:

[0095] 1> for multicast and broadcast; or

[0096] 1> For unicast, if the sidelink DRB modification is triggered due to the reception of an RRCReconfigurationSidelink message; or

[0097] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB modification is triggered due to the configuration received in sl-ConfigDedicatedNR, SIB12 or SidelinkPreconfigNR, then:

[0098] 2> Reconfigure the SDAP entity of the sidelink DRB according to the sl-SDAP-ConfigPC5 received in RRCReconfigurationSidelink or the sl-SDAP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

[0099] 2> Reconfigure the PDCP entity of the sidelink DRB according to the sl-PDCP-ConfigPC5 received in RRCReconfigurationSidelink or the sl-PDCP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

[0100] 2> Reconfigure the RLC entity of the sidelink DRB according to the sl-RLC-ConfigPC5 received in RRCReconfigurationSidelink or the sl-RLC-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

[0101] 2> Reconfigure the logical channels of the sidelink DRB according to the sl-MAC-LogicalChannelConfigPC5 received in RRCReconfigurationSidelink or the sl-MAC-LogicalChannelConfig received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included).

[0102] […]

[0103] 5.8.9.3 Sidelink radio link failure related actions

[0104] The UE shall:

[0105] 1> after an indication from the sidelink RLC entity that the maximum number of retransmissions for a particular destination has been reached; or

[0106] 1> after the expiry of the T400 for a specific destination; or

[0107] 1> after an indication from the MAC entity that the maximum number of consecutive HARQ DTXs for a particular destination has been reached, or

[0108] 1> Following an integrity check failure indication from the sidelink PDCP entity regarding SL-SRB2 or SL-SRB3 for a specific destination:

[0109] 2> Consider a sidelink radio link failure detected for this destination;

[0110] 2> Release the DRB for this destination according to clause 5.8.9.1a.1;

[0111] 2> Release the SRB for this destination according to clause 5.8.9.1a.3;

[0112] 2> Release the PC5 relay RLC channel for this destination according to clause 5.8.9.7.1 (if configured);

[0113] 2>Discard the configuration related to NR sidelink communication of this destination;

[0114] 2> Reset the sidelink specific MAC for this destination;

[0115] 2> Consider releasing the PC5-RRC connection for the destination;

[0116] 2> Indicates the release of the PC5-RRC connection to the upper layer for this destination (i.e., PC5 is unavailable);

[0117] 2> If the UE is in RRC_CONNECTED:

[0118] 3> If the UE acts as a L2 U2N remote UE for the destination, then:

[0119] 4> Initiate the RRC connection re-establishment procedure as specified in clause 5.3.7.

[0120] 3> Otherwise:

[0121] 4> Perform sidelink UE information for NR sidelink communication procedures as specified in 5.8.3.3;

[0122] NOTE: It is up to the UE implementation to decide whether and how to indicate to upper layers the maintenance keep-alive procedure

[55] . The 3GPP Stage 2 Operation CR (R2-2312029) for Release 18 specifies the sidelink relay as follows:

[0123] 16.12 Sidelink Relay

[0124] 16.12.1 Overview

[0125] Sidelink relay is introduced to support 5G ProSe UE to Network Relay (U2N Relay) functionality (specified in TS23.304

[48] ) to provide connectivity to the network for U2N remote UEs. Both L2 and L3 U2N relay architectures are supported. Except for controlling the sidelink resources, the L3 U2N relay architecture is transparent to the serving NG-RAN of the U2N relay UE. The detailed architecture and procedures for L3 U2N relay can be found in TS23.304

[48] .

[0126] A U2N relay UE shall be in RRC_CONNECTED to perform relay of unicast data.

[0127] For L2 U2N relay operation, the following RRC state combinations are supported:

[0128] - Both the L2 U2N relay UE and the L2 U2N remote UE should be in RRC_CONNECTED to perform transmission / reception of relayed unicast data; and

[0129] - The L2 U2N relay UE may be in RRC_IDLE, RRC_INACTIVE or RRC_CONNECTED as long as all L2 U2N remote UEs connected to the L2 U2N relay UE are in RRC_INACTIVE or RRC_IDLE.

[0130] A single unicast link is established between one L2 U2N relay UE and one L2 U2N remote UE. Traffic from the NG-RAN to the L2 U2N remote UE via a given L2U2N relay UE and traffic from the L2 U2N relay UE shall be separated in different Uu RLC channels.

[0131] For L2 U2N relay, the L2 U2N remote UE may only be configured to relay data using resource allocation mode 2 (as specified in 5.7.2 and 16.9.3.1).

[0132] Sidelink relay is introduced to support 5G ProSe inter-UE relay (U2U relay) functionality (specified in TS23.304

[48] ), providing connectivity between U2U remote UEs. Both L2 and L3 U2U relay architectures are supported. The L3 U2U relay architecture is transparent to the AS layer of the U2U relay UE. The detailed architecture and procedures for L3 U2U relay can be found in TS23.304

[48] .

[0133] The U2U relay UE shall support the (U2U relay) functionality as specified in TS23.304

[48] to provide coverage extension of sidelink transmission between two U2U remote UEs. For coverage extension, the U2U remote UE may communicate with a peer U2U remote UE that is not reachable within the sidelink coverage. The U2U relay UE and the U2U remote UE may be in any RRC state. The U2U relay UE and the U2U remote UE may be within the coverage of different cells, partially within the coverage, or outside the coverage. Both sidelink resource allocation modes (i.e., mode 1 and mode 2) support the U2U relay UE and the U2U remote UE. For U2U relay, the NR sidelink is supported between the U2U relay UE and the U2U remote UE. After the NR sidelink is established between the U2U relay UE and the U2U remote UE, an end-to-end PC5 unicast link connection establishment is performed between the U2U remote UEs. Only unicast is supported between the U2U relay UE and the U2U remote UE.

[0134] […]

[0135] 16.12.2.x L2 Inter-UE Relay

[0136] The protocol stacks for the user plane and control plane of the L2 U2U relay architecture are shown in Figure 16.12.2.x-1 and Figure 16.12.2.x-2. The SRAP sublayer is disposed above the RLC sublayer for both CP and UP at the two PC5 interfaces. The sidelink SDAP, PDCP and RRC terminate between the two L2 U2U remote UEs (i.e., end-to-end), while SRAP, RLC, MAC and PHY terminate in each hop-by-hop PC5 link.

[0137] [3GPP R2-2312029 entitled "User plane protocol stack for L2 inter-UE relay

[0138] Figure 16.12.2.x-1 of the "protocol stack for L2 UE-to-UE Relay)" is reproduced as Figure 5 ]

[0139] [3GPP R2-2312029 titled "Control plane protocol stack for L2 inter-UE relay"

[0140] Figure 16.12.2.x-2 of the "protocol stack for L2 UE-to-UE Relay)" is reproduced as Figure 6 ]

[0141] For L2 inter-UE relay, the SRAP sublayer at the L2 U2U remote UE:

[0142] - The SRAP sublayer at the L2 U2U Remote UE performs bearer mapping between the end-to-end PC5 radio bearers (SL-SRB, SL-DRB) of the L2 U2U Remote UE and the hop-by-hop PC5 relay RLC channels between the L2 U2U Remote UE and the L2 U2U Relay UE.

[0143] - For traffic transmitted from a L2 U2U remote UE to a L2 U2U relay UE, different end-to-end PC5 radio bearers (SL-SRB or SL-DRB) destined to the same peer L2 U2U remote UE and / or different peer L2 U2U remote UEs may be multiplexed into the same PC5 relay RLC channel between the L2 U2U remote UE and the L2 U2U relay UE.

[0144] - For traffic received at a L2 U2U Remote UE, the same PC5 Relay RLC channel from one L2 U2U Relay UE may be demultiplexed to different end-to-end PC5 Radio Bearers (SL-SRB or SL-DRB) to the same peer L2 U2U Remote UE and / or to different peer L2 U2U Remote UEs.

[0145] -The SRAP sublayer at the L2 U2U remote UE supports identification of the peer L2 U2U remote UE and itself. Local IDs are allocated by the L2U2U relay UE to the two L2 U2U remote UEs for identification. For the two local IDs, one of the local IDs identifies the L2 U2U remote UE and the other local ID identifies the peer L2 U2U remote UE. The local ID of the peer L2 U2U remote UE and the local ID of itself (i.e., the L2 U2U remote UE) are delivered to the L2 U2U remote UE together with the corresponding L2 ID of the peer L2 U2U remote UE. The local ID of the L2 U2U remote UE and the local ID of itself (i.e., the peer L2 U2U remote UE) are delivered to the peer L2 U2U remote UE. The identification information of the end-to-end PC5 radio bearer and the two local IDs are included in the SRAP header so that the peer L2 U2U remote UE associates the received packets for a specific PDCP entity with the correct end-to-end PC5 radio bearer of the L2 U2U remote UE.

[0146] For L2 inter-UE relay, the SRAP sublayer at the L2 U2U relay UE:

[0147] - The SRAP sublayer at the L2 U2U Relay UE determines the egress PC5 Relay RLC channel based on a mapping of a specific pair of end-to-end PC5 radio bearers and egress PC5 Relay RLC channels between the L2 U2U Remote UE and the peer L2 U2U Remote UE.

[0148] - For ingress traffic received at a L2 U2U relay UE from one / multiple L2 U2U remote UEs, if the local ID identifying the peer L2 U2U remote UEs is the same, then different end-to-end PC5 radio bearers (SRBs or DRBs) of the same L2 U2U remote UE and / or different L2 U2U remote UEs may be multiplexed to the same egress PC5 relay RLC channel between the L2 U2U relay UE and the peer L2 U2U remote UE identified by the local ID.

[0149] […]

[0150] 16.12.x Control plane procedures for L2 U2U trunking

[0151] The L2 U2U remote UE needs to establish an end-to-end SL-SRB / DRB with the peer L2 U2U remote UE before user plane data transfer.

[0152] The following high-level connection establishment procedure in Figure 16.12.x-1 applies to L2 U2U Relay UE and L2 U2U Remote UE:

[0153] [Figure 16.12.x-1 of 3GPP R2-2312029 entitled "Procedure for L2 U2U Remote UE connection establishment" is reproduced as Figure 7 ]

[0154] 1. The L2 U2U remote UE, the L2 U2U relay UE and the peer L2 U2U remote UE perform a discovery procedure or an integrated discovery procedure.

[0155] 2a. The L2 U2U remote UE establishes / modifies a PC5-RRC connection with the selected L2 U2U relay UE (ie as specified in TS 23.304

[48] ).

[0156] 2b. The L2 U2U Relay UE establishes / modifies a PC5-RRC connection with the peer L2 U2U Remote UE (ie as specified in TS 23.304

[48] ).

[0157] 3. The L2 U2U relay UE allocates two local IDs and the two local IDs are delivered to each of the L2 U2U remote UEs via the RRCReconfigurationSidelink message: one local ID is used to identify the L2 U2U remote UE and the other local ID is used to identify the peer L2 U2U remote UE. When the local ID is delivered, the L2 ID of the peer L2U2U remote UE is also delivered to the U2U remote UE for association between the local ID and the L2 ID of the peer U2U remote UE.

[0158] 4. The L2 U2U Remote UE sends all QoS attribute sets for the end-to-end QoS flow to the L2 U2U Relay UE via PC5-RRC message.

[0159] 5. The L2 U2U relay UE performs QoS splitting at least for the PDB.

[0160] Note: It is up to the L2 U2U relay UE implementation to decide how to split the PDB.

[0161] 6. The L2 U2U Relay UE sends the split QoS values ​​(ie at least the PDB) to the L2 U2U Remote UE via PC5-RRC message.

[0162] Editor's Note: Whether FFS is required to deliver split QoS values ​​to peer L2 U2U remote UEs.

[0163] 7. The L2 U2U Remote UE establishes an end-to-end PC5-RRC connection with the peer L2 U2U Remote UE via the L2 U2U Relay UE. The L2 U2U Remote UE derives the PDCP and SDAP configuration for the end-to-end SL-DRB and provides the reception-related part of the configuration to the peer L2 U2U Remote UE using end-to-end PC5-RRC messages. For the end-to-end connection establishment, fixed indices (i.e., 0 / 1 / 2 / 3) are defined for end-to-end SL-SRB 0 / 1 / 2 / 3, respectively, and the specified PC5 RLC channel configuration is used on each hop. The end-to-end bearer ID for SL-SRB and SL-DRB is used as input for L2 U2U Relay encryption and decryption at PDCP.

[0164] 8a. The L2 U2U remote UE derives the first hop configuration for SL-DRB (e.g. PC5 relay RLC channel configuration) and provides the configuration related to reception on the first hop (i.e. Rx by the relay UE) to the L2 U2U relay UE using a per-hop RRCReconfigurationSidelink message.

[0165] 8b. The L2 U2U relay UE derives the second hop configuration (eg PC5 relay RLC channel configuration) for each SL-DRB and provides the configuration related to reception on the second hop (ie Rx by the peer remote UE) to the peer L2 U2U remote UE using a per-hop RRCReconfigurationSidelink message.

[0166] 9. The L2 U2U remote UE and the peer L2 U2U remote UE transmit or receive data via the L2 U2U relay UE.

[0167] 3GPP RRC Operation CR (R2-2311857) of Release 18 specifies the sidelink RRC reconfiguration procedure based on 3GPP TS 38.331 of Release 17 with the notation changed to underline as follows:

[0168] 5.8.9.1 Sidelink RRC Reconfiguration

[0169] 5.8.9.1.1 Overview

[0170] [3GPP R2-2311857 ​​titled "Sidelink RRC reconfiguration success (Sidelink RRCreconfiguration,

[0171] successful) Figure 5 .8.9.1.1-1 reproduced as Figure 8 ]

[0172] [3GPP R2-2311857 ​​entitled "Sidelink RRC reconfiguration failure

[0173] failure) Figure 5 .8.9.1.1-2 reproduced as Fig. 9 ]

[0174] The purpose of this procedure is to modify the PC5-RRC connection, for example to establish / modify / release sidelink DRB or PC5 relay RLC channel, to (re)configure NR sidelink measurement and reporting, to (re)configure sidelink CSI reference signal resources, to (re)configure CSI reporting delay bound, to (re)configure sidelink DRX and (re)configure delay bound for SL inter-UE coordinated reporting.

[0175] The UE may initiate the sidelink RRC reconfiguration procedure and perform the operations in clause 5.8.9.1.2 on the corresponding PC5-RRC connection in the following cases:

[0176] - Release the sidelink DRB associated with the peer UE as specified in clause 5.8.9.1a.1;

[0177] - Establishing a sidelink DRB associated with the peer UE as specified in clause 5.8.9.1a.2;

[0178] - modify the parameters contained in the SLRB-Config of the sidelink DRB associated with the peer UE, as specified in clause 5.8.9.1a.2;

[0179] - Release for L2 U2N / U2U PC5 relay RLC channels for the relay UE and remote UE as specified in clause 5.8.9.7.1;

[0180] - Built for L2 U2N / U2U PC5 relay RLC channels for the relay UE and remote UE as specified in clause 5.8.9.7.2;

[0181] - Modifications included in the L2 U2N / U2U the parameters in SL-RLC-ChannelConfigPC5 of the PC5 relay RLC channel of the relay UE and the remote UE, as specified in clause 5.8.9.7.2;

[0182] - (Re)configure the peer UE to perform NR sidelink measurements and reporting.

[0183] - (Re)configure sidelink CSI reference signal resources and CSI reporting delay bounds;

[0184] - (re)configure the peer UE to perform sidelink DRX;

[0185] - (Re)configure the delay bounds for SL inter-UE coordination reporting ；

[0186] - (re)configure the local UE ID and split QoS of the L2 U2U remote UE by the L2 U2U relay UE.

[0187] In RRC_CONNECTED, the UE applies the NR sidelink communication parameters provided in RRCReconfiguration (if present). In RRC_IDLE or RRC_INACTIVE, the UE applies the NR sidelink communication parameters provided in system information (if present). For other cases, the UE applies the NR sidelink communication parameters provided in SidelinkPreconfigNR (if present). When the UE performs a state transition between the above three cases, after obtaining the new configuration, the UE applies the NR sidelink communication parameters provided in the new state. Before obtaining the new configuration, the UE continues to apply the NR sidelink communication parameters provided in the old state.

[0188] Editor’s note: FFS’s two conclusions regarding TX remote UE derivation for e2e SL-DRB do not exclude the involvement of information from gNB / pre-configured / specified configuration.

[0189] Editor's Note: The relay UE derives the second-hop configuration for SL-DRB through FFS.

[0190] 5.8.9.1.2 Actions related to the transmission of the RRCReconfigurationSidelink message

[0191] The UE shall set the content of the RRCReconfigurationSidelink message as follows:

[0192] 1> For each sidelink DRB to be released, due to sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR or upper layer configuration according to clause 5.8.9.1a.1.1:

[0193] 2> Set the entries contained in slrb-ConfigToReleaseList corresponding to the sidelink DRB;

[0194] 1> For each sidelink DRB to be established or modified, as per clause 5.8.9.1a.2.1, due to reception of sl-ConfigDedicatedNR, SIB12, or SidelinkPreconfigNR:

[0195] 2> If you want to establish a side link DRB:

[0196] 3> Assign a new logical channel identifier for the logical channel to be associated with the sidelink DRB and set sl-MAC-LogicalChannelConfigPC5 in SLRB-Config to include the new logical channel identifier;

[0197] 2> Set the SLRB-Config contained in slrb-ConfigToAddModList according to the received sl-RadioBearerConfig and the sl-RLC-BearerConfig corresponding to the sidelink DRB;

[0198] 1>Set sl-MeasConfig as follows:

[0199] 2> If the frequency used for NR sidelink communication is contained in sl-FreqInfoToAddModList in sl-ConfigDedicatedNR in RRCReconfiguration message or in sl-ConfigCommonNR in SIB12:

[0200] 3> If the UE is in RRC_CONNECTED, then:

[0201] 4> Set sl-MeasConfig according to the NR sidelink measurement configuration information stored for this destination;

[0202] 3> If the UE is in RRC_IDLE or RRC_INACTIVE, then:

[0203] 4> Set sl-MeasConfig according to the stored NR sidelink measurement configuration received from SIB12;

[0204] 2> Otherwise:

[0205] 3> Set sl-MeasConfig according to sl-MeasPreconfig in SidelinkPreconfigNR;

[0206] 1>Set sl-LatencyBoundIUC-Report;

[0207] 1> Start timer T400 for the destination;

[0208] 1>Set sl-CSI-RS-Config;

[0209] 1>Set sl-LatencyBoundCSI-Report;

[0210] 1>Set sl-ResetConfig;

[0211] NOTE 1: Whether / how to set the parameters included in sl-LatencyBoundIUC-Report, sl-CSI-RS-Config, sl-LatencyBoundCSI-Report and sl-ResetConfig depends on the UE implementation.

[0212] 1>Set sl-DRX-ConfigUC-PC5 as follows:

[0213] 2> If the frequency used for NR sidelink communication is contained in sl-FreqInfoToAddModList in sl-ConfigDedicatedNR in RRCReconfiguration message or in sl-ConfigCommonNR in SIB12:

[0214] 3> If the UE is in RRC_CONNECTED and if the sl-ScheduledConfig is contained in the sl-ConfigDedicatedNR within the RRCReconfiguration, then:

[0215] 4> Set sl-DRX-ConfigUC-PC5 according to the NR sidelink DRX configuration information stored for this destination.

[0216] NOTE 2: If the UE is in RRC_IDLE or RRC_INACTIVE or out of coverage, or in RRC_CONNECTED, and sl-UE-SelectedConfig is contained in sl-ConfigDedicatedNR within RRCReconfiguration, then it is up to the UE implementation to decide to set sl-DRX-ConfigUC-PC5.

[0217] 1> For each PC5 relay RLC channel to be released due to the configuration of sl-ConfigDedicatedNR:

[0218] 2> Set the SL-RLC-ChannelID corresponding to the PC5 relay RLC channel in sl-RLC-ChannelToReleaseListPC5;

[0219] 1> For each PC5 relay RLC channel to be established or modified due to the reception of sl-ConfigDedicatedNR:

[0220] 2> If you want to establish a PC5 relay RLC channel, then:

[0221] 3> assign a new logical channel identifier for the logical channel to be associated with the PC5 relay RLC channel and set sl-MAC-LogicalChannelConfigPC5 in SL-RLC-ChannelConfigPC5 to include the new logical channel identifier;

[0222] 2> Set the SL-RLC-ChannelConfigPC5 contained in sl-RLC-ChannelToAddModListPC5 according to the received SL-RLC-ChannelConfig corresponding to the PC5 relay RLC channel, including setting sl-RLC-ChannelID-PC5 to the same value of sl-RLC-ChannelID received in SL-RLC-ChannelConfig;

[0223] 1> If the UE acts as an L2 U2U relay UE:

[0224] 2> If both the PC5-RRC connection with the L2 U2U remote UE and the PC5-RRC connection with the peer L2 U2U remote UE are established successfully, then:

[0225] 3> allocate a new local UE ID for the L2 U2U remote UE according to the association between user information and L2 ID as specified in TS23.304

[65] . And set the sl-RemoteUE-LocalIdentity-config in SL-SRAP-ConfigPC5 to contain the new local UE ID and L2 ID of the L2 U2U remote UE if necessary;

[0226] 3> allocate a new local UE ID for the peer L2 U2U remote UE according to the association between user information and L2 ID as specified in TS 23.304

[65] and, if necessary, set the sl-RemoteUE-LocalIdentity-config in SL-SRAP-ConfigPC5 to contain the new local UE ID and L2 ID of the peer L2 U2U remote UE;

[0227] 3> Determine to submit the RRCReconfigurationSidelink message to the L2 U2U remote UE;

[0228] 3> Determine to submit the RRCReconfigurationSidelink message to the peer L2 U2U remote UE;

[0229] Editor's Note: WA: The L2 ID and local ID are carried in the RRCReconfigurationSidelink message, and it is assumed that the association between user information and L2 ID is completed at the ProSe layer.

[0230] 2> If sl-QoS-InfoListPC5 is included in the RRCReconfigurationSidelink message received from the source L2U2U remote UE, then:

[0231] 3> Perform QoS splitting based on sl-QoS-InfoListPC5 for each QoS flow to determine the split QoS for each PC5 hop, and set sl-SplitQoS-InfoListPC5 to include the split QoS information on the second PC5 hop between the L2 U2U relay UE and the target L2 U2U remote UE;

[0232] 3> Determine to submit the RRCReconfigurationSidelink message to the target L2 U2U remote UE;

[0233] 1> If the UE acts as a source L2 U2U remote UE, then:

[0234] 2> Set sl-QoS-InfoListPC5 to the end-to-end QoS attribute set containing the sidelink QoS flow of the target L2U2U remote UE, if configured by upper layers;

[0235] 2> Set sl-DestinationIdentity to the associated destination containing the target L2 U2U remote UE, if configured by upper layers;

[0236] 2> Determine to submit the RRCReconfigurationSidelink message to the L2U2U relay UE;

[0237] The UE shall submit the RRCReconfigurationSidelink message to lower layers for transmission.

[0238] 5.8.9.1.3 Receiving RRCReconfigurationSidelink via UE

[0239] Upon receiving RRCReconfigurationSidelink, the UE shall perform the following actions:

[0240] 1> If RRCReconfigurationSidelink contains sl-ResetConfig, then:

[0241] 2>Perform the sidelink reset configuration procedure as specified in 5.8.9.1.10;

[0242] 1> If RRCReconfigurationSidelink contains slrb-ConfigToReleaseList:

[0243] 2> For each entry value contained in slrb-ConfigToReleaseList that is part of the current UE side link configuration;

[0244] 3> Perform the sidelink DRB release procedure according to clause 5.8.9.1a.1;

[0245] 1> If RRCReconfigurationSidelink contains slrb-ConfigToAddModList:

[0246] 2> For each slrb-PC5-ConfigIndex value included in slrb-ConfigToAddModList that is not part of the current UE side link configuration:

[0247] 3> If sl-MappedQoS-FlowsToAddList is included, then:

[0248] 4> Apply the SL-PQFI contained in sl-MappedQoS-FlowsToAddList;

[0249] 3> Perform the sidelink DRB addition procedure according to clause 5.8.9.1a.2;

[0250] 2> For each slrb-PC5-ConfigIndex value included in slrb-ConfigToAddModList that is part of the current UE side link configuration:

[0251] 3> If sl-MappedQoS-FlowsToAddList is included, then:

[0252] 4> Add the SL-PQFI contained in sl-MappedQoS-FlowsToAddList to the corresponding sidelink DRB;

[0253] 3> If sl-MappedQoS-FlowsToReleaseList is included, then:

[0254] 4> Remove the SL-PQFI contained in sl-MappedQoS-FlowsToReleaseList from the corresponding sidelink DRB;

[0255] 3> If the sidelink DRB release conditions as described in clause 5.8.9.1a.1.1 are met, then:

[0256] 4> Perform the sidelink DRB release procedure according to clause 5.8.9.1a.1.2;

[0257] 3> Otherwise if the sidelink DRB modification conditions as described in clause 5.8.9.1a.2.1 are met, then:

[0258] 4> Perform the sidelink DRB modification procedure according to clause 5.8.9.1a.2.2;

[0259] 1> If the RRCReconfigurationSidelink message contains sl-MeasConfig, then:

[0260] 2> Perform the sidelink measurement configuration procedure as specified in 5.8.10;

[0261] 1> If the RRCReconfigurationSidelink message contains sl-CSI-RS-Config, then:

[0262] 2> Application side link CSI-RS configuration;

[0263] 1> If the RRCReconfigurationSidelink message contains sl-LatencyBoundCSI-Report, then:

[0264] 2> Apply the configured sidelink CSI reporting latency bound;

[0265] 1> If RRCReconfigurationSidelink contains sl-RLC-ChannelToReleaseListPC5, then:

[0266] 2> for each SL-RLC-ChannelID value contained in sl-RLC-ChannelToReleaseListPC5 that is part of the current UE-side link configuration;

[0267] 3>Perform the PC5 relay RLC channel release procedure according to clause 5.8.9.7.1;

[0268] 1> If RRCReconfigurationSidelink contains sl-RLC-ChannelToAddModListPC5, then:

[0269] 2> For each sl-RLC-ChannelID-PC5 value contained in sl-RLC-ChannelToAddModListPC5 that is not part of the current UE side link configuration:

[0270] 3>Perform the PC5 relay RLC channel addition procedure according to clause 5.8.9.7.2;

[0271] 2> For each sl-RLC-ChannelID-PC5 value contained in sl-RLC-ChannelToAddModListPC5 that is part of the current UE side link configuration:

[0272] 3>Perform the PC5 relay RLC channel modification procedure according to clause 5.8.9.7.2;

[0273] 1> If the RRCReconfigurationSidelink message contains sl-DRX-ConfigUC-PC5, and

[0274] 1> If the UE accepts sl-DRX-ConfigUC-PC5, then:

[0275] 2> configure the lower layers to perform sidelink DRX operation according to sl-DRX-ConfigUC-PC5 for the associated destination as defined in TS 38.321 [3];

[0276] 1> If the RRCReconfigurationSidelink message contains sl-LatencyBoundIUC-Report, then:

[0277] 2> Apply the configured side link IUC reporting delay bound;

[0278] 1> If the RRCReconfigurationSidelink message contains sl-RemoteUE-LocalIdentity-config and sl-PeerRemoteUE-LocalIdentity-Config, then:

[0279] 2> configure the lower layers to perform NR sidelink U2U relay operation according to the sl-RemoteUE-LocalIdentity-config for L2U2U remote UE and the sl-PeerRemoteUE-LocalIdentity-config for peer L2U2U remote UE as defined in TS 38.351

[65] ;

[0280] 1> If RRCReconfigurationSidelink contains sl-QoS-InfoListPC5, then:

[0281] 2> Perform actions related to the transmission of RRCReconfigurationSidelink, as specified in 5.8.9.1.2;

[0282] 1> If the UE is unable to comply with the (partial) configuration contained in RRCReconfigurationSidelink (i.e., the sidelink RRC reconfiguration fails):

[0283] 2> Continue to use the configuration used before receiving the RRCReconfigurationSidelink message;

[0284] 2>Set the content of the RRCReconfigurationFailureSidelink message;

[0285] 3> Submit the RRCReconfigurationFailureSidelink message to the lower layer for transmission;

[0286] 1> Otherwise:

[0287] 2>Set the content of the RRCReconfigurationCompleteSidelink message;

[0288] 3> If the UE rejects the sidelink DRX configuration sl-DRX-ConfigUC-PC5 received from the peer UE, then:

[0289] 4> Include sl-DRX-ConfigReject in the RRCReconfigurationCompleteSidelink message;

[0290] 4> Sidelink DRX to be applied to the corresponding sidelink unicast communication is not considered;

[0291] 3> If sl-SplitQoS-InfoListPC5 is included in the RRCReconfigurationSidelink message received from the L2U2U relay UE, then:

[0292] 4> setting sl-AcceptQoS-InfoListPC5 to contain the accepted QoS information on the second PC5 hop between the L2 U2U relay UE and the target L2U2U remote UE, taking into account the received sl-SplitQoS-InfoListPC5;

[0293] 4> Determine to submit the RRCReconfigurationCompleteSidelink message to the L2U2U relay UE;

[0294] 3> Submit the RRCReconfigurationCompleteSidelink message to the lower layer for transmission;

[0295] NOTE 1: When the same logical channel is configured with a different RLC mode by another UE, the UE handles the situation as a sidelink RRC reconfiguration failure.

[0296] NOTE 2: It is up to the UE implementation to decide whether to indicate a rejection of the received sidelink DRX configuration to the peer UE.

[0297] […]

[0298] 5.8.9.1.9 Receiving RRCReconfigurationCompleteSidelink via UE

[0299] The UE shall perform the following actions after receiving RRCReconfigurationCompleteSidelink:

[0300] 1> Stop timer T400 for the destination (if running);

[0301] 1> Consider applying the configuration in the corresponding RRCReconfigurationSidelink message.

[0302] 2> If the RRCReconfigurationCompleteSidelink message contains sl-DRX-ConfigReject:

[0303] 3> Sidelink DRX to be applied to the corresponding sidelink unicast communication is not considered;

[0304] 2> If the RRCReconfigurationCompleteSidelink message received from the target L2U2U remote UE contains sl-AcceptQoS-InfoListPC5, then:

[0305] 3> Set the content of the RRCReconfigurationCompleteSidelink message:

[0306] 4> Taking into account the received sl-AcceptQoS-InfoListPC5, set sl-SplitQoS-InfoListPC5 to contain the split QoS information on the first PC5 hop between the source L2U2U remote UE and the L2U2U relay UE;

[0307] 4> Set sl-DestinationIdentity to the associated destination containing the target L2 U2U remote UE;

[0308] 3> Determine to submit the RRCReconfigurationCompleteSidelink message to the source L2 U2U remote UE;

[0309] 3> Submit the RRCReconfigurationCompleteSidelink message to the lower layer for transmission;

[0310] […]

[0311] 3GPP R2-2312007 discusses PC5 radio link failure (RLF) in UE-to-UE (U2U) relay as follows:

[0312] 2.1 RLF in U2U Relay

[0313] E2E SL RLF

[0314] In the current RRC specification, sidelink radio link failure related actions shall be performed by the UE under at least one of the following conditions:

[0315] 1> after an indication from the sidelink RLC entity that the maximum number of retransmissions for a particular destination has been reached; or

[0316] 1> after the expiry of the T400 for a specific destination; or

[0317] 1> after an indication from the MAC entity that the maximum number of consecutive HARQ DTXs for a particular destination has been reached, or

[0318] 1> Following an integrity check failure indication from the sidelink PDCP entity regarding SL-SRB2 or SL-SRB3 for a specific destination:

[0319] In the U2U relay scenario, after T400 expires for the peer remote UE, or upon an integrity check failure indication from the sidelink PDCP entity on SL-SRB2 or SL-SRB3 for the peer remote UE, the remote UE will consider E2ESL RLF and thus trigger relay reselection based on previous RAN2 protocols. Similar to L2 UE to network relay in Rel-17, the remote UE may choose to maintain or release the per-hop PC5 RRC connection with the relay UE based on its implementation. In our understanding, this applies to either the source remote UE or the destination remote UE.

[0320] Proposal 1: The source remote UE or the destination remote UE may choose to maintain or release the per-hop PC5 RRC connection with the relay UE based on its implementation upon detecting the E2E RLF.

[0321] If Proposal 1 is agreed and the remote UE chooses to maintain the per-hop PC5 RRC connection with the relay UE, the remote UE may need to inform the relay UE of the E2E RLF so that the relay UE can stop data transmission to the peer remote UE.

[0322] Proposal 2: If the remote UE chooses to maintain the per-hop PC5 RRC connection with the relay UE after the E2E RLF, the remote UE sends an indication to the relay UE to stop forwarding its data to the peer remote UE.

[0323] 3GPP R2-2312696 also discusses PC5 Radio Link Failure (RLF) in Inter-UE (U2U) relay as follows:

[0324] (3) Sidelink radio link failure handling

[0325] […]

[0326] A sidelink radio link failure for a specific destination may occur, for example, after T400 expiration or an integrity check failure indication of SL-SRB2 or SL-SRB3, and these failures may be detected at the RRC or PDCP. In the L2 U2U relay, the RRC or PDCP at each remote UE may detect a sidelink radio link failure due to, for example, T400 expiration or integrity check failure of SL-SRB2 / SL-SRB3. After a SL-RLF caused by, for example, T400 expiration or integrity check failure of SL-SRB2 / SL-SRB3, the remote UE follows the procedure for releasing the sidelink SRB and sidelink DRB of the corresponding destination as a traditional NR sidelink communication. The remote UE releases the associated hop configuration for the SL-DRB and SL-SRB and the PDCP / SDAP configuration for the SL-DRB and SL-SRB for the destination.

[0327] Observation 6. After SL-RLF for a specific destination due to T400 expiration or integrity check failure indication of SL-SRB2 / SL-SRB3, the remote UE releases the SL-SRB and SLB-DRB for the destination as traditional NR sidelink communication.

[0328] A remote UE that detects sidelink RLF for a specific destination due to T400 expiration or integrity check failure of SL-SRB2 / SL-SRB3 may inform its connected relay UE of PC5-RLF detection to release the hop configuration for the corresponding destination.

[0329] Proposal 5. When the remote UE detects PC5-RLF due to, for example, T400 expiration or integrity check failure indication of SL-SRB2 / SL-SRB3, the remote UE may inform the relay UE to which it is connected of the PC5-RLF.

[0330] 3GPP RRC Runtime CR (R2-2314014) of Release 18 updates the sidelink radio link failure related actions in clause 5.8.9.3 and specifies the notification message in clause 5.8.9.10 as follows:

[0331] 5.8.9.3 Sidelink radio link failure related actions

[0332] The UE shall:

[0333] 1> after an indication from the sidelink RLC entity that the maximum number of retransmissions for a particular destination has been reached; or

[0334] 1> after the expiry of the T400 for a specific destination; or

[0335] 1> after an indication from the MAC entity that the maximum number of consecutive HARQ DTXs for a particular destination has been reached, or

[0336] 1> after an integrity check failure indication from the sidelink PDCP entity on SL-SRB2 or SL-SRB3 for a specific destination; or

[0337] 1> Upon receiving a NotificationMessageSidelink indicating a PC5 RLF from the L2U2U relay UE for a specific destination based on the received sl-DestinationIdentity:

[0338] 2> Consider a sidelink radio link failure detected for this destination;

[0339] 2> Release the DRB for this destination according to clause 5.8.9.1a.1;

[0340] 2> Release the SRB for this destination according to clause 5.8.9.1a.3;

[0341] 2> Release the PC5 relay RLC channel for this destination according to clause 5.8.9.7.1 (if configured);

[0342] 2>Discard the configuration related to NR sidelink communication of this destination;

[0343] 2> Reset the sidelink specific MAC for this destination, except for L2 U2U relay operation;

[0344] 2> Consider releasing the PC5-RRC connection for the destination;

[0345] 2> Indicates the release of the PC5-RRC connection to the upper layer for this destination (i.e., PC5 is unavailable);

[0346] 2> If the UE is in RRC_CONNECTED:

[0347] 3> If the UE acts as a L2 U2N remote UE for the destination, then:

[0348] 4> Initiate the RRC connection re-establishment procedure as specified in clause 5.3.7.

[0349] 3> Otherwise:

[0350] 4> Perform sidelink UE information for NR sidelink communication procedures as specified in 5.8.3.3;

[0351] Editor's Note: FFS is an additional procedure for L2 U2U PC5 RLF initiation.

[0352] NOTE: It is up to the UE implementation to decide whether and how to indicate to upper layers the maintenance of the keep-alive procedure

[55] .

[0353] […]

[0354] 5.8.9.10 Notification Message

[0355] 5.8.9.10.1 Overview

[0356] [3GPP R2-2314014 entitled "Notification Messages in Sidelink" Figure 5 .8.9.8.1-1 reproduced as Fig.10 ]

[0357] This procedure is used by a U2N Relay UE to send notifications to a connected U2N Remote UE, or by a U2U Relay UE to send notifications to a peer connected U2U Remote UE when the connected U2U Remote UE meets the conditions as specified in 5.8.9.10.2.

[0358] 5.8.9.10.2 Initiation

[0359] The relay UE may initiate the procedure when one of the following conditions is met:

[0360] 1> If the UE acts as a U2N relay UE:

[0361] 2> after the Uu RLF as specified in 5.3.10;

[0362] 2>After receiving RRCReconfiguration containing reconfigurationWithSync;

[0363] 2>After the cell is reselected;

[0364] 2> after the RRC connection of the L2 U2N relay UE including RRC Connection Reject as specified in 5.3.3.5 and 5.3.13.10 fails, and T300 expires as specified in 5.3.3.7 and RRC recovery fails as specified in 5.3.13.5;

[0365] 1> If the UE acts as an L2 U2U relay UE:

[0366] 2> After the PC5 RLF is detected by the remote UE using L2 U2U as specified in 5.8.9.3;

[0367] 5.8.9.10.3 Actions related to the delivery of NotificationMessageSidelink messages

[0368] The relay UE shall set the indication type as follows:

[0369] 1> If the UE acts as a U2N relay UE:

[0370] 2> If the UE initiates the transmission of the NotificationMessageSidelink message due to Uu RLF, then:

[0371] 3>Set indicationType to relayUE-Uu-RLF;

[0372] 2> Otherwise, if the UE initiates the transmission of the NotificationMessageSidelink message due to reconfiguration using synchronization, then:

[0373] 3>Set indicationType to relayUE-HO;

[0374] 2> Otherwise, if the UE initiates the transmission of the NotificationMessageSidelink message due to cell reselection, then:

[0375] 3>Set indicationType to relayUE-CellReselection;

[0376] 2> If the UE initiates the transmission of the NotificationMessageSidelink message due to a failure in establishing / recovering the Uu RRC connection, then:

[0377] 3>Set indicationType to relayUE-Uu-RRC-Failure;

[0378] 2> Submit the NotificationMessageSidelink message to the lower layer for transmission;

[0379] 1> If the UE acts as an L2 U2U relay UE:

[0380] 2> If the UE initiates the transmission of the NotificationMessageSidelink message due to PC5 RLF with the L2 U2U remote UE, then:

[0381] 3>Set sl-IndicationType to relayUE-PC5-RLF.

[0382] 3> Set sl-DestinationIdentityRemoteUE to the associated destination of the L2 U2U remote UE;

[0383] 3> Submit the NotificationMessageSidelink message to the lower layer for transmission;

[0384] 5.8.9.10.4 Actions related to the reception of NotificationMessageSidelink message

[0385] After receiving the NotificationMessageSidelink, the remote UE shall:

[0386] 1> If the UE acts as a U2N remote UE:

[0387] 2> If indicationType is included:

[0388] 3> If the UE is a L2 U2N remote UE in RRC_CONNECTED:

[0389] 4> If MP is configured and MCG transmission is not suspended (i.e., direct path);

[0390] 5> initiate the indirect path failure information procedure as specified in 5.7.3c to report the indirect path failure;

[0391] 4> Otherwise, if T301 is not running:

[0392] 5> Initiate the RRC connection re-establishment procedure as specified in 5.3.7;

[0393] 3> Otherwise (UE is L3 U2N remote UE or L2 U2N remote UE in RRC_IDLE or RRC_INACTIVE):

[0394] 4> If you decide to release the PC5-RRC connection with the U2N relay UE, then:

[0395] 5> Instruct the upper layer to trigger the release of PC5 unicast link;

[0396] 4> Otherwise (i.e., maintain PC5 RRC connection):

[0397] 5> If the UE is a L2 U2N remote UE and indicationType is relayUE-HO or relayUE-CellReselection, then:

[0398] 6> Consider cell reselection;

[0399] NOTE 1: For a L3 U2N remote UE or L2 U2N remote UE in RRC_IDLE or RRC_INACTIVE, it is up to the remote UE implementation to decide whether to release or maintain the PC5 unicast link.

[0400] NOTE 2: If the L2 U2N remote UE has not released the PC5 unicast link on the source side during the indirect to direct path handover, i.e., T304 is running, it may ignore the NotificationMessageSidelink.

[0401] 1> If the UE acts as L2 U2U remote UE:

[0402] 2> If sl-IndicationType is relayUE-PC5-RLF, then:

[0403] 3> Indicate the PC5 RLF received from the L2 U2U relay UE to the upper layer of the indicated L2 U2U remote UE based on the received sl-DestinationIdentityRemoteUE;

[0404] 3> based on the received sl-DestinationIdentityRemoteUE, perform PC5 RLF related actions as specified in 5.8.9.3 on the indicated L2 U2U remote UE;

[0405] NOTE X1: Following a PC5 RLF indication received from a U2U relay UE, it is up to the upper layers to decide whether to trigger U2U relay reselection and whether to maintain or release the PC5 link with the U2U relay UE.

[0406] Inter-UE (U2U) relay is introduced into 3GPP Release 18, where a relay UE is used to support communication between two remote UEs when the two remote UEs cannot communicate directly with each other due to being out of radio coverage. The relay UE needs to establish a PC5 RRC connection (or PC5 unicast link) with each of the source remote UE (e.g., the first PC5 hop) and the target remote UE (e.g., the second PC5 hop), such as Fig.11 , which shows a PC5 RRC connection for inter-UE relay according to an exemplary embodiment. In addition, an end-to-end PC5 RRC connection can be established between the two remote UEs for layer 2 (Layer-2, L2) U2U relay. The source remote UE can communicate with multiple target remote UEs via the same relay UE.

[0407] For a Layer 2 remote UE connected to another Layer 2 remote UE via a Layer 2U2U relay UE, the end-to-end QoS requirements for relay services between peer Layer 2 remote UEs can be met by corresponding QoS control for the PC5 RRC connection between the Layer 2 source remote UE and the Layer 2 relay UE (i.e., first-hop PC5 QoS control) and QoS control for the PC5 RRC connection between the Layer 2 relay UE and the Layer 2 target remote UE (i.e., second-hop PC5 QoS control).

[0408] To achieve this, the source remote UE and the target remote UE may negotiate an end-to-end QoS requirement for the new PC5 QoS flow. The source remote UE may then provide the end-to-end QoS requirement to the relay UE so that the relay UE may split the end-to-end QoS requirement into at least one QoS value for the first hop and at least another QoS value for the second hop. The relay UE may then provide the QoS value for the first hop to the source remote UE so that the source remote UE may determine an end-to-end (E2E) SL DRB configuration and a PC5 relay RLC channel configuration (for transmitting packets of the PC5 QoS flow to the target remote UE via the first hop to the relay UE) based at least on the QoS value received from the relay UE, and then provide the receive (Rx) RLC parameters of the PC5 relay RLC channel configuration to the relay UE (e.g., via an RRC reconfiguration sidelink message) so that the relay UE may receive packets of the PC5 QoS flow from the source remote UE on the PC5 relay RLC channel. In addition, the relay UE may determine another PC5 relay LC channel configuration for the second hop based at least on another QoS value of the second hop, and then provide the Rx RLC parameters of the PC5 relay RLC channel configuration to the target remote UE (e.g., via another RRC reconfiguration sidelink message) so as to forward data packets of the PC5 QoS flow to the target remote UE on the PC5 relay RLC channel via the second hop.

[0409] Basically, different E2E SL-DRBs destined for the same target remote UE or different target remote UEs may be multiplexed to the same PC5 relay RLC channel for transmission. Therefore, the end-to-end PC5 radio bearer ID (E2E SL DRB ID), the local UE ID of the source remote UE, and the local UE ID of the target remote UE are included in the header of the SRAP PDU (for transmitting data packets) so that the relay UE determines the egress PC5 relay RLC channel for forwarding data packets, and also so that the target remote UE associates the received data packets for a specific PDCP entity with the correct E2E SL DRB of the target remote UE. To support this, for each target remote UE, the source remote UE needs to maintain the mapping between the E2E SL DRB and the egress PC5 relay RLC channel through the first hop between the source remote UE and the relay UE. In addition, for each source-target remote UE pair, the relay UE needs to maintain the mapping between the E2E SL DRB and the egress PC5 relay RLC channel through the second hop between the relay UE and the target remote UE.

[0410] According to 3GPP R2-2312007, after the T400 for the target remote UE expires or after an integrity check failure indication from the sidelink PDCP entity for the SL-SRB2 or SL-SRB3 for the target remote UE, the source remote UE may consider an E2E PC5 radio link failure (RLF). In this case, the source remote UE may choose to maintain or release the PC5 RRC connection with the relay UE. For example, the source remote UE may maintain the PC5 RRC connection with the relay UE if the source remote UE also communicates with other target remote UEs via the same PC5 RRC connection with the relay UE. If the source remote UE chooses to maintain the PC5 RRC connection with the relay UE after the E2E PC5 RLF, the source remote UE may send an indication to the relay UE to stop forwarding its data to the peer remote UE. Similarly, 3GPP R2-2312696 proposes that when an E2E PC5-RLF is detected, the source remote UE may inform the relay UE of the PC5-RLF so that the relay UE may release the hop configuration for the corresponding destination.

[0411] Since the relay UE needs to maintain the mapping between the E2E SL DRB and the egress PC5 relay RLC channel through the second hop for each source-target remote UE pair, the relay UE may release the second hop configuration for the corresponding destination upon receiving the E2E PC5-RLF notification from the source remote UE. However, the identity of the target remote UE associated with the E2E PC5-RLF should also be provided to the relay UE in a notification message (e.g., a notification message sidelink message or an RRC reconfiguration sidelink message). In addition, the relay UE may not know which PC5 relay RLC channels on the first hop are used by the source remote UE to transmit data packets to the target remote UE of interest. Other or additional information (contained in the same notification message or a different PC5 RRC message) should be provided by the source remote UE to the relay UE to release the PC5 relay RLC channel through the first hop.

[0412] Basically, after E2E PC5-RLF, if the PC5 relay RLC channel is established only for data packets transmitted to the target remote UE of interest (i.e., the PC5 relay RLC channel is not shared by any other target remote UE), then the PC5 relay RLC channel on the first hop between the source remote UE and the relay UE should also be released. The source remote UE may send a PC5 RRC message (e.g., an RRC reconfiguration sidelink message) to the relay UE to indicate the PC5 relay RLC channel to be released due to the E2E PC5 RLF. Since the RLC entity is established to support the PC5 relay RLC channel, the RLC entity associated with the PC5 relay RLC channel may also be released.

[0413] In one embodiment, the PC5 relay RLC channel configuration may include an identification (ID) of the PC5 relay RLC channel and the PC5 RLC configuration. And, the RLC entity is established according to the PC5 RLC configuration. In one embodiment, the ID of the PC5 relay RLC channel is included in the list of sidelink RLC channels to be released in the RRC reconfiguration sidelink message to indicate the PC5 relay RLC channel and / or RLC entity to be released.

[0414] An example of a method for handling an E2E PC5 RLF according to an exemplary embodiment is shown. Fig.12 An example of the above solution is shown.

[0415] Furthermore, according to section 5.8.9.3 of 3GPP 2314014, upon receiving a NotificationMessageSidelink message indicating a PC5 RLF from a L2 U2U relay UE for a specific destination (i.e., a target L2 U2U remote UE of interest), the source L2 U2U remote UE shall consider a sidelink radio link failure to be detected for the target L2 U2U remote UE of interest. Additionally, the source L2 U2U remote UE shall release the SRBs, DRBs, and PC5 relay RLC channels of the target L2 U2U remote UE of interest. Upon receiving the NotificationMessageSidelink message, the source L2 U2U remote UE shall be adapted to release the SRBs and DRBs of the target L2 U2U remote UE of interest. However, it is not appropriate for the source L2 U2U remote UE to release the PC5 relay RLC channel of the target L2 U2U remote UE of interest, because the PC5 relay RLC channel may be shared by multiple target L2 U2U remote UEs communicating with the source L2 U2U remote UE via the L2 U2U relay UE. In addition, if the PC5 relay RLC channel is configured / established only for transmitting data packets associated with the target L2 U2U remote UE of interest to the relay UE (i.e., not shared by any other target L2 U2U remote UE or associated with any end-to-end sidelink DRB), then the source L2 U2U remote UE preferably first transmits a PC5 RRC message (e.g., an RRC reconfiguration sidelink message) to the relay UE to indicate the PC5 relay RLC channel to be released. Subsequently, the source L2 U2U remote UE may release the PC5 relay RLC channel after receiving a response message (e.g., an RRC reconfiguration complete sidelink message) from the L2 U2U relay UE. Alternatively, the source L2 U2U remote UE may release the PC5 relay RLC channel after transmitting the RRC reconfiguration sidelink message and before receiving the response message.

[0416] In one embodiment, in RRC_IDLE or RRC_INACTIVE, the source remote UE is out of coverage (OOC). In the case where the source remote UE is in RRC_CONNECTED, the source remote UE may need to send a sidelink UE information message to inform its serving gNB that it is no longer interested in communicating with the target remote UE of interest due to PC5 RLF, so that the gNB can release the sidelink DRB and / or PC5 relay RLC channel configured / established for the target L2 U2U remote UE of interest.

[0417] FIG. 1 shows an example of handling a second hop PC5 RLF notification according to an exemplary embodiment. Fig.13An example of the above solution is shown. UE1 communicates with UE2 and UE3 via a relay UE. A first PC5 relay RLC channel is established / configured for communication with UE2 only, and a second PC5 relay RLC channel is established / configured for communication with both UE2 and UE3. When a notification message sidelink message indicating a PC5 radio link failure (RLF) with UE2 is received from the relay UE, UE1 transmits an RRC reconfiguration sidelink message indicating the first PC5 relay RLC channel to be released to the relay UE.

[0418] Fig.14 is a flow chart 1400 for a source remote user equipment (UE). In step 1405, the source remote UE establishes a PC5 radio resource control (RRC) connection with a relay UE. In step 1410, the source remote UE establishes at least one end-to-end (E2E) PC5 RRC connection with at least one target remote UE via the relay UE. In step 1415, the source remote UE further transmits at least one configuration of at least one PC5 relay radio link control (RLC) channel to the relay UE, wherein the at least one PC5 relay RLC channel is used to transmit data packets to the at least one target remote UE. In step 1420, the source remote UE detects an E2E PC5 radio link failure (RLF) associated with a target remote UE in the at least one target remote UE. In step 1425, if a PC5 relay RLC channel among at least one PC5 relay RLC channel is used to transmit data packets to the target remote UE and is not shared by any other target remote UE, the source remote UE transmits an RRC reconfiguration sidelink message to the relay UE in response to the E2E PC5RLF, wherein the RRC reconfiguration sidelink message includes information indicating the PC5 relay RLC channel to be released.

[0419] In one embodiment, at least one configuration of at least one PC5 relay RLC channel may be transmitted in another RRC reconfiguration sidelink message.Each configuration of at least one PC5 relay RLC channel may include a PC5 RLC configuration and an identification (ID) of the PC5 relay RLC channel.

[0420] In one embodiment, the E2E PC5 RLF may be detected due to T400 expiration or integrity check failure. The information indicating the PC5 relay RLC channel to be released may be the ID of the PC5 relay RLC channel. The ID of the PC5 relay RLC channel may be included in the list of sidelink RLC channels to be released.

[0421] In one embodiment, after receiving the RRC Reconfiguration Complete sidelink message from the relay UE, the PC5 relay RLC channel may be released by the source remote UE.

[0422] Return to reference Figure 3 and Figure 4 , in an exemplary embodiment from the perspective of a source remote UE. The source remote UE 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the source remote UE to: (i) establish a PC5 RRC connection with a relay UE, (ii) establish at least one E2E PC5 RRC connection with at least one target remote UE via the relay UE, (iii) transmit at least one configuration of at least one PC5 relay RLC channel to the relay UE, wherein the at least one PC5 relay RLC channel is used to transmit data packets to the at least one target remote UE, (iv) detect an E2E PC5 RLF associated with a target remote UE in the at least one target remote UE, and (v) if the PC5 relay RLC channel in the at least one PC5 relay RLC channel is used to transmit data packets to the target remote UE and is not shared by any other target remote UE, transmit an RRC reconfiguration sidelink message to the relay UE in response to the E2E PC5 RLF, wherein the RRC reconfiguration sidelink message includes information indicating the PC5 relay RLC channel to be released. Furthermore, CPU 308 may execute program code 312 to perform all of the actions and steps described above or other actions and steps described herein.

[0423] Various aspects of the present disclosure have been described above. It should be understood that the teachings herein can be implemented in a wide variety of forms, and any specific structure, function, or both disclosed herein are only representative. Based on the teachings herein, it should be understood by those skilled in the art that the aspects disclosed herein can be implemented independently of any other aspects, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement a device or practice method. In addition, other structures, functions, or structures and functions other than one or more of the aspects set forth herein or different from one or more of the aspects set forth herein can be used to implement this device or practice this method. As an example of some of the above concepts, in some aspects, parallel channels can be established based on pulse repetition frequencies. In some aspects, parallel channels can be established based on pulse positions or offsets. In some aspects, parallel channels can be established based on time hopping sequences. In some aspects, parallel channels can be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.

[0424] Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0425] It should be further understood by those skilled in the art that the various illustrative logical blocks, modules, processors, components, circuits, and algorithm steps described in conjunction with the aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two, which may be designed using source code or some other technique), various forms of program or design code incorporating instructions (which may be referred to herein for convenience as "software" or "software modules"), or a combination of the two. To clearly illustrate this interchangeability of hardware and software, the above has been generally described in terms of the functions of various illustrative components, blocks, modules, circuits, and steps. Whether such functions are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functions in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0426] In addition, the various illustrative logical blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. An IC may include a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within the IC, outside the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0427] It should be understood that any specific order or hierarchy of steps in any disclosed process is an example of a sample method. It should be understood that based on design preferences, the specific order or hierarchy of steps in a process can be rearranged while remaining within the scope of the present disclosure. The accompanying method solutions present elements of the various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented.

[0428] The steps of the method or algorithm described in conjunction with the aspects disclosed herein may be implemented directly with hardware, with a software module executed by a processor, or with a combination of the two. Software modules (e.g., including executable instructions and associated data) and other data may reside in a data memory, such as a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of a computer-readable storage medium known in the art. A sample storage medium may be coupled to a machine such as a computer / processor (for convenience, the machine may be referred to herein as a "processor") so that the processor may read information (e.g., code) from a storage medium and write information to the storage medium. An example storage medium may be integrated with a processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user device. In an alternative, the processor and storage medium may reside in a user device as discrete components. In addition, in some aspects, any suitable computer program product may include a computer-readable medium, which includes code related to one or more aspects of the present disclosure. In some aspects, a computer program product may include packaging materials.

[0429] Although the present invention has been described in conjunction with various aspects, it will be appreciated that the present invention is capable of further modification. This application is intended to cover any changes, uses or adaptations of the present invention that generally follow the principles of the present invention and include such deviations from the present disclosure that are within the scope of known and customary practice in the technical field to which the present invention belongs.

Claims

1. A method for handling end-to-end PC5 radio link failure, applicable to a source remote user equipment, characterized in that: include: The source remote user equipment establishes a PC5 radio resource control connection with the relay user equipment; The source remote user equipment establishes at least one end-to-end PC5 radio resource control connection with at least one target remote user equipment via the relay user equipment; The source remote user equipment transmits at least one configuration of at least one PC5 relay radio link control channel to the relay user equipment, wherein the at least one PC5 relay radio link control channel is used to transmit data packets to the at least one target remote user equipment; the source remote user equipment detecting a failure of an end-to-end PC5 radio link associated with a target remote user equipment of the at least one target remote user equipment; as well as If a PC5 relay radio link control channel among the at least one PC5 relay radio link control channel is used to transmit data packets to the target remote user equipment and is not shared with any other target remote user equipment, the source remote user equipment transmits a radio resource control reconfiguration side link message to the relay user equipment in response to the end-to-end PC5 radio link failure, wherein the radio resource control reconfiguration side link message includes information indicating the PC5 relay radio link control channel to be released.

2. The method according to claim 1, characterized in that Said at least one configuration of said at least one PC5 relay radio link control channel is transmitted in a further radio resource control reconfiguration sidelink message.

3. The method according to claim 1, characterized in that Each configuration of the at least one PC5 relay radio link control channel comprises a PC5 radio link control configuration and an identification of the PC5 relay radio link control channel.

4. The method according to claim 1, characterized in that: The end-to-end PC5 radio link failure is detected due to T400 expiration or integrity check failure.

5. The method according to claim 1, characterized in that The information indicating the PC5 relay radio link control channel to be released is an identifier of the PC5 relay radio link control channel.

6. The method according to claim 5, characterized in that The identification of the PC5 relay radio link control channel is contained in a list of sidelink radio link control channels to be released.

7. The method according to claim 1, characterized in that After receiving a Radio Resource Control Reconfiguration Complete sidelink message from the relay user equipment, the PC5 relay radio link control channel is released by the source remote user equipment.

8. A source remote user equipment for handling end-to-end PC5 radio link failure, characterized in that, include: Control circuit; a processor installed in the control circuit; as well as a memory installed in the control circuit and operably coupled to the processor; wherein the processor is configured to execute program code stored in the memory to: Establishing a PC5 radio resource control connection with the relay user equipment; establishing at least one end-to-end PC5 radio resource control connection with at least one target remote user equipment via the relay user equipment; transmitting at least one configuration of at least one PC5 relay radio link control channel to the relay user equipment, wherein the at least one PC5 relay radio link control channel is used to transmit data packets to the at least one target remote user equipment; detecting an end-to-end PC5 radio link failure associated with a target remote user equipment of the at least one target remote user equipment; as well as If a PC5 relay radio link control channel among the at least one PC5 relay radio link control channel is used to transmit data packets to the target remote user equipment and is not shared with any other target remote user equipment, a radio resource control reconfiguration side link message is transmitted to the relay user equipment in response to the end-to-end PC5 radio link failure, wherein the radio resource control reconfiguration side link message includes information indicating the PC5 relay radio link control channel to be released.

9. The source remote user device according to claim 8, characterized in that: Said at least one configuration of said at least one PC5 relay radio link control channel is transmitted in a further radio resource control reconfiguration sidelink message.

10. The source remote user device according to claim 8, characterized in that: Each configuration of the at least one PC5 relay radio link control channel comprises a PC5 radio link control configuration and an identification of the PC5 relay radio link control channel.

11. The source remote user device according to claim 8, characterized in that: The end-to-end PC5 radio link failure is detected due to T400 expiration or integrity check failure.

12. The source remote user device according to claim 8, characterized in that: The information indicating the PC5 relay radio link control channel to be released is an identifier of the PC5 relay radio link control channel.

13. The source remote user device according to claim 12, characterized in that: The identification of the PC5 relay radio link control channel is contained in a list of sidelink radio link control channels to be released.

14. The source remote user device according to claim 8, characterized in that: After receiving a Radio Resource Control Reconfiguration Complete sidelink message from the relay user equipment, the PC5 relay radio link control channel is released by the source remote user equipment.

Images