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

Abstract

A method and device for handling end-to-end PC5 radio link failure are disclosed. A source remote user equipment also establishes at least one end-to-end PC5 radio resource control connection with at least one target remote user equipment via a 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 data packets to 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 indicating the PC5 relay radio link control channel to be released.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 548,103, filed November 10, 2023, and U.S. Provisional Patent Application No. 63 / 608,739, filed December 11, 2023, the entire disclosure of which is incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communication networks, and more specifically, to methods and apparatus for handling end-to-end PC5 radio link failures in wireless communication systems. Background Technology

[0004] With the rapid growth in 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. This type of IP packet communication can provide users of mobile communication devices with IP-bearing voice, multimedia, multicast, and video-on-demand communication services.

[0005] An exemplary network architecture is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). E-UTRAN systems can provide high data throughput to enable the aforementioned IP-based voice and multimedia services. Currently, the 3GPP standards organization is discussing new next-generation (e.g., 5G) radio technologies. Therefore, changes to the current core of the 3GPP standards are currently being submitted and considered to facilitate their evolution and completion. 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 data packets to at least one target remote UE. Additionally, the source remote UE detects an E2E PC5 Radio Link Failure (RLF) associated with one of the at least one target remote UEs. Furthermore, if at least one PC5 Relay RLC channel is used to transmit data packets to a target remote UE and is not shared by any other target remote UE, the source remote UE responds to the E2E PC5 RLF by transmitting an RRC reconfiguration sidelink message to the relay UE, wherein the RRC reconfiguration sidelink message contains information indicating the PC5 Relay RLC channel to be released. Attached Figure Description

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

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

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

[0010] Figure 4 This is based on 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 from 3GPP R2-2312029;

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

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

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

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

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

[0017] Figure 11 A PC5 RRC connection for inter-UE relay is illustrated according to an exemplary embodiment;

[0018] Figure 12 An example of disposing of an E2E PC5 RLF is shown according to an exemplary embodiment;

[0019] Figure 13 An example of handling a second-hop PC5 RLF notification is shown according to an exemplary embodiment;

[0020] Figure 14 This is a flowchart based on an exemplary embodiment. Detailed Implementation

[0021] The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication, 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 apparatus described below can be designed to support one or more standards, such as those provided by the alliance known herein as the 3GPP's "3rd Generation Partnership Project," which includes: TS38.331V17.6.0, "NR; Radio Resource Control (RRC) protocol specification (version 17)"; R2-2312029, "Introduction of NR sidelink relay enhancements (version 18)," LG Electronics; R2-2311857, "Introduction of NR sidelink U2U relay (version 18)," Vivo; R2-2312007, "Discussion on U2U relay," Fujitsu; and R2-2312696, "Control plane issues for L2 U2U relay." "Relaying", Samsung; and R2-2314014, "Introduction of Rel-18 SL relay enhancements", Huawei, HiSilicon, Vivo, and MediaTek. The standards and documents listed above are expressly incorporated herein by reference in their entirety.

[0023] Figure 1 A multiple access wireless communication system according to an embodiment of the present invention is illustrated. Access network 100 (AN) includes multiple antenna groups, one antenna group comprising 104 and 106, another antenna group comprising 108 and 110, and yet another antenna group comprising 112 and 114. Figure 1In this diagram, only two antennas are shown in 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 that used by reverse link 118.

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

[0025] In communications via forward links 120 and 126, the transmit antennas of access network 100 can utilize beamforming to improve the signal-to-noise ratio of the forward links used for different access terminals 116 and 122. Furthermore, compared to access networks that transmit to all their access terminals via a single antenna, access networks that use beamforming to transmit to access terminals randomly distributed within their coverage area cause less interference to access terminals in neighboring cells.

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

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

[0028] In one embodiment, each data stream is transmitted via a corresponding transmit antenna. The TX data processor 214 formats, encodes, and interleaves the service data for the data stream based on a specific encoding scheme selected for each data stream to provide encoded data.

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

[0030] The modulation symbols of all data streams are then provided to the TX MIMO processor 220, which can further process the modulation symbols (e.g., for OFDM). The TX MIMO processor 220 then... T A modulation symbol stream is provided to N T Transmitters (TMTRs) 222a to 222t. In some embodiments, the TX MIMO processor 220 applies beamforming weights to symbols of the data stream and to the antennas from which the symbols are being transmitted.

[0031] Each transmitter 222 receives and processes a corresponding symbol stream to provide one or more analog signals, and further modulates (e.g., amplifies, filters, and up-converts) the analog signals to provide modulated signals suitable for transmission over a MIMO channel. Subsequently, signals are received from N... T Antennas 224a to 224t transmit N from transmitters 222a to 222t. T A modulated signal.

[0032] At receiver system 250, by N R Each antenna 252a to 252r receives the transmitted modulated signal and provides the signal received from each antenna 252 to a corresponding receiver (RCVR) 254a to 254r. Each receiver 254 modulates (e.g., filters, amplifies, and down-converts) the corresponding received signal, digitizes the modulated signal to provide a sample, and further processes the sample to provide a corresponding "received" symbol stream.

[0033] The RX data processor 260 then utilizes specific receiver processing technology from N R 254 receivers receive and process N R Each received symbol stream provides NT Each detected symbol stream is then demodulated, deinterleaved, and decoded by the RX data processor 260 to recover the service data used for the data stream. The processing performed by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and 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 that includes the matrix index part and the rank part.

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

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

[0037] Turn Figure 3 This figure illustrates an alternative simplified functional block diagram of a communication device according to an embodiment of the present invention. Figure 3 As shown, this can be achieved using the communication device 300 in a wireless communication system. Figure 1 UE (or AT) 116 and 122 or Figure 1 The communication device 300 includes a base station (or AN) 100, and 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, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by a user via the input device 302 (e.g., a keyboard or keypad) and can output images and sounds via the output device 304 (e.g., a monitor or speaker). The transceiver 314 is used to receive and transmit wireless signals, deliver the received signals to the control circuit 306, and wirelessly output signals generated by the control circuit 306. The communication device 300 in a wireless communication system can also be used for this purpose. Figure 1AN100 in the middle.

[0038] Figure 4 This is according to an embodiment of the present invention. Figure 3 The diagram shows a simplified block diagram of program code 312. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a 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 connections.

[0039] 3GPP TS 38.331 specifies the following actions for sidelink radio bearer management and sidelink radio link failure related to version 17:

[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 Condition

[0043] For NR sidelink communication, initiate sidelink DRB release under the following conditions:

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

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

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

[0047] 1> For unicast, if there is no sidelink QoS stream mapped to a sidelink DRB for transmission with data indicated by the upper layer, the sidelink QoS stream is reconfigured by receiving SIB12 or SidelinkPreconfigNR; and if there is no sidelink QoS stream mapped to a sidelink DRB, the sidelink QoS stream is reconfigured by receiving RRCReconfigurationSidelink with data; or

[0048] 1> For unicast, if the SLRB-PC5-ConfigIndex of the sidelink DRB (if it exists) is included in slrb-ConfigToReleaseList in RRCReconfigurationSidelink, or if sl-ResetConfig is included in RRCReconfigurationSidelink; or

[0049] 1> For unicast, when the corresponding PC5-RRC connection is released due to the detection of a sidelink RLF in accordance with Clause 5.8.9.3; or

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

[0051] 5.8.9.1a.1.2 Sidelink DRB Release Operation

[0052] For each sidelink DRB that meets its sidelink DRB release condition as specified in Clause 5.8.9.1a.1.1, the UE configured by the upper layer to perform NR sidelink communication and capable of NR sidelink communication shall:

[0053] 1> For multicast and broadcast; or

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

[0055] 1> For unicast, after receiving the RRCReconfigurationCompleteSidelink message, if the sidelink DRB release is triggered due to configuration received in sl-ConfigDedicatedNR, SIB12, or SidelinkPreconfigNR, or indicated by the upper layer, 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 follows:

[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 SDAP entities (if present) for NR sidelink communication that do not have an associated sidelink DRB as specified in Clause 5.1.2 of TS 37.324

[24] ;

[0060] 1> For multicast and broadcast; or

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

[0062] 2> For each sl-RLC-BearerConfigIndex contained in the received sl-RLC-BearerToReleaseList, which is part of the current UE sidelink 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 is released due to receiving an RRCReconfigurationSidelink message; or

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

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

[0067] 2> Execute the sidelink UE information procedure for unicast in Clause 5.8.3 when necessary.

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

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

[0070] 5.8.9.1a.2 Adding / Modifying Side Link DRBs

[0071] 5.8.9.1a.2.1 Adding / Modifying Conditions for Side-Link DRB

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

[0073] 1> If any sidelink QoS flow is (re)configured by sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR and will be mapped to a sidelink DRB that has not been 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 communication, sidelink DRB modification is initiated only under the following conditions:

[0076] 1> For a sidelink DRB that is established, any of the parameters related to the sidelink DRB can be changed through sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR, or RRCReconfigurationSidelink.

[0077] 5.8.9.1a.2.2 Side Link DRB Addition / Modification Operations

[0078] For a sidelink DRB that meets the conditions for adding a sidelink DRB as specified in Clause 5.8.9.1a.2.1, the UE configured by the upper layer to perform NR sidelink communication and capable of NR sidelink communication should:

[0079] 1> For multicast and broadcast; or

[0080] 1> For unicast, if a sidelink DRB is added due to receiving an RRCReconfigurationSidelink message; or

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

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

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

[24] ;

[0084] 2> Reconfigure the SDAP entity based on sl-SDAP-ConfigPC5 received in RRCReconfigurationSidelink or sl-SDAP-Config received in sl-ConfigDedicatedNR, SIB12, or SidelinkPreconfigNR associated with the sidelink DRB;

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

[0086] 2> Establish an RLC entity for NR sidelink communication and configure the RLC entity according to sl-RLC-ConfigPC5 received in RRCReconfigurationSidelink or sl-RLC-Config received in sl-ConfigDedicatedNR, SIB12, or 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 execute the sidelink UE information procedure in Clause 5.8.3 for unicast when necessary;

[0089] 2> Otherwise, if this procedure is due to receiving the RRCReconfigurationCompleteSidelink message, then:

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

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

[0092] 3> Configure the MAC entity with the logical channel associated with the side link DRB based on the sl-MAC-LogicalChannelConfig received in sl-ConfigDedicatedNR, SIB12, and SidelinkPreconfigNR, and assign a new LCID to this logical channel.

[0093] Note 1: When a sidelink DRB is added due to the configuration of RRCReconfigurationSidelink, the sidelink DRB configuration is selected from the received sl-ConfigDedicatedNR (if under RRC_CONNECTED), SIB12 (if under RRC_IDLE / INACTIVE), and SidelinkPreconfigNR (if outside coverage) with the same RLC mode as configured in RRCReconfigurationSidelink, depending on the UE implementation scheme. The parameters of the sidelink DRB to be transmitted are selected as needed.

[0094] For a sidelink DRB that meets the modification conditions for its sidelink DRB as specified in Clause 5.8.9.1a.2.1, the UE configured by the upper layer to perform NR sidelink communication and capable of NR sidelink communication should:

[0095] 1> For multicast and broadcast; or

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

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

[0098] 2> The SDAP entity that reconfigures the sidelink DRB based on sl-SDAP-ConfigPC5 received in RRCReconfigurationSidelink or sl-SDAP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

[0099] 2> The PDCP entity that reconfigures the sidelink DRB based on sl-PDCP-ConfigPC5 received in RRCReconfigurationSidelink or sl-PDCP-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

[0100] 2> The RLC entity that reconfigures the sidelink DRB based on sl-RLC-ConfigPC5 received in RRCReconfigurationSidelink or sl-RLC-Config received in sl-ConfigDedicatedNR, SIB12, SidelinkPreconfigNR (if included);

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

[0102] [...]

[0103] 5.8.9.3 Actions related to sidelink radio link failure

[0104] UE should:

[0105] 1> After the side-link RLC entity indicates that the maximum number of retransmissions for a specific destination has been reached; or

[0106] 1> After the expiration of the T400 visa for a specific destination; or

[0107] 1> After the MAC entity indicates that the maximum number of consecutive HARQ DTXs for a specific destination has been reached, or

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

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

[0110] 2> Release the DRB for this destination in accordance with Clause 5.8.9.1a.1;

[0111] 2> Release the SRB for this destination in accordance with clause 5.8.9.1a.3;

[0112] 2> Release the PC5 trunk RLC channel for this destination (if configured) in accordance with Clause 5.8.9.7.1;

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

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

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

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

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

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

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

[0120] 3> Otherwise:

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

[0122] Note: Whether and how to instruct the upper layer to maintain keep-alive procedures depends on the UE implementation scheme

[55] . 3GPP Phase 2 Run CR (R2-2312029) version 18 specifies the sidelink relay as follows:

[0123] 16.12 Side Link 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 network connectivity for U2N remote UEs. Both L2 and L3 U2N relay architectures are supported. The L3 U2N relay architecture is transparent to the NG-RAN serving U2N relay UEs, except for controlling sidelink resources. Detailed architecture and procedures for L3 U2N relay can be found in TS23.304

[48] .

[0126] U2N relay UEs should be in RRC_CONNECTED state to perform unicast data relay.

[0127] For L2 U2N trunk operations, the following RRC state combinations are supported:

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

[0129] - An L2 U2N trunk UE can be in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED mode, as long as all L2 U2N remote UEs connected to the L2 U2N trunk UE are in RRC_INACTIVE or RRC_IDLE mode.

[0130] A single unicast link is established between an L2 U2N relay UE and an L2 U2N remote UE. NG-RAN services from a given L2 U2N relay UE to an L2 U2N remote UE and services of the L2 U2N relay UE should be separated in different Uu RLC channels.

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

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

[48] ), thereby 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. Detailed architecture and procedures for L3 U2U relay can be found in TS23.304

[48] .

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

[48] to provide coverage extension for sidelink transmission between two U2U remote UEs. For coverage extension, the U2U remote UE can communicate with a peer U2U remote UE that is not reachable within the sidelink coverage area. The U2U relay UE and the U2U remote UE can be in any RRC state. The U2U relay UE and the U2U remote UE can be within the coverage area of ​​different cells, partially within the coverage area, or outside the coverage area. 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, NR sidelinks are 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 is established 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 UE Inter-Relay

[0136] The protocol stacks for the user plane and control plane of the L2 U2U trunk architecture are shown in Figures 16.12.2.x-1 and 16.12.2.x-2. The SRAP sublayer is disposed on the two PC5 interfaces above the RLC sublayer used for both CP and UP. 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] The title of 3GPP R2-2312029 is "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 follows: Figure 5 ]

[0139] The 3GPP R2-2312029 document, 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 follows: Figure 6 ]

[0141] For L2 UE-to-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 trunk RLC channel between the L2 U2U remote UE and the L2 U2U trunk UE.

[0143] - For services transmitted from an L2 U2U remote UE to an L2 U2U relay UE, different end-to-end PC5 radio bearers (SL-SRB or SL-DRB) destined for the same peer L2 U2U remote UE and / or different peer L2 U2U remote UEs can be multiplexed onto the same PC5 relay RLC channel, which is located between the L2 U2U remote UE and the L2 U2U relay UE.

[0144] - For services received at an L2 U2U remote UE, the same PC5 relay RLC channel from an L2 U2U relay UE can be demultiplexed to different end-to-end PC5 radio bearers (SL-SRB or SL-DRB) of the same peer L2 U2U remote UE and / or 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. A local ID is assigned by the L2U2U relay UE to both L2 U2U remote UEs for identification. Of the two local IDs, one identifies the L2 U2U remote UE and the other identifies the peer L2 U2U remote UE. The peer L2 U2U remote UE's local ID and its own (i.e., the L2 U2U remote UE's) local ID, along with the corresponding L2 ID of the peer L2 U2U remote UE, are delivered to the L2 U2U remote UE. The L2 U2U remote UE's local ID and its own (i.e., the peer L2 U2U remote UE's) local ID are also 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 received packets used by the peer L2 U2U remote UE for a specific PDCP entity are associated with the correct end-to-end PC5 radio bearer of the L2 U2U remote UE.

[0146] For L2 UE-to-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 the mapping of the end-to-end PC5 radio bearers and egress PC5 relay RLC channels of a specific pair between the L2 U2U remote UE and its peer L2 U2U remote UE.

[0148] - For ingress traffic received at an L2 U2U relay UE from one or more L2 U2U remote UEs, if the local IDs identifying the peer L2 U2U remote UEs are 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 can 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 program for L2 U2U relay

[0151] L2 U2U remote UEs need to establish an end-to-end SL-SRB / DRB with their peer L2 U2U remote UEs before transmitting user plane data.

[0152] The following advanced connection establishment procedure in Figure 16.12.x-1 applies to L2 U2U relay UEs and L2 U2U remote UEs:

[0153] Figure 16.12.x-1 from 3GPP R2-2312029, titled "Procedure for L2 U2U Remote UE connection establishment," is reproduced as follows: Figure 7 ]

[0154] 1. L2 U2U remote UEs, L2 U2U relay UEs and peer L2 U2U remote UEs execute discovery procedures or integrated discovery procedures.

[0155] 2a. L2 U2U remote UE establishes / modifies PC5-RRC connection with the selected L2 U2U relay UE (i.e., as specified in TS23.304

[48] ).

[0156] 2b. L2 U2U relay UE establishes / modifies PC5-RRC connection with peer L2 U2U remote UE (i.e., as specified in TS23.304

[48] ).

[0157] 3. The L2 U2U relay UE is assigned two local IDs, which are delivered to each of the L2 U2U remote UEs via an 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 delivering the local IDs, the L2 ID of the peer L2U2U remote UE is also delivered to the U2U remote UE for association between the local IDs and the L2 ID of the peer U2U remote UE.

[0158] 4. The L2 U2U remote UE sends the set of all QoS attributes for the end-to-end QoS flow to the L2 U2U relay UE via PC5-RRC messages.

[0159] 5. L2 U2U relay UEs must perform QoS splitting at least for PDBs.

[0160] Note: The method of splitting the PDB depends on the L2 U2U relay UE implementation plan.

[0161] 6. The L2 U2U relay UE sends the split QoS value (i.e., at least PDB) to the L2 U2U remote UE via PC5-RRC message.

[0162] Editor's Note: Does FFS need to deliver the split QoS value to the peer L2 U2U remote UE?

[0163] 7. An L2 U2U remote UE establishes an end-to-end PC5-RRC connection with its peer L2 U2U remote UE via an L2 U2U relay UE. The L2 U2U remote UE exports the PDCP and SDAP configurations for the end-to-end SL-DRB and provides the reception-related portion of the configuration to the peer L2 U2U remote UE using an end-to-end PC5-RRC message. For 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 a specified PC5RLC channel configuration is used on each hop. The end-to-end bearer IDs used for SL-SRB and SL-DRB are used as inputs for L2 U2U relay encryption and decryption at the PDCP.

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

[0165] 8b. The L2 U2U relay UE exports the second-hop configuration (e.g., PC5 relay RLC channel configuration) for each SL-DRB, and provides the configuration related to the Rx received on the second hop (i.e., by the peer remote UE) to the peer L2 U2U remote UE using the per-hop RRCReconfigurationSidelink message.

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

[0167] Version 18 of the 3GPP RRC runs CR (R2-2311857), based on version 17 of 3GPP TS 38.331, specifies the sidelink RRC reconfiguration procedure using the underscore notation as follows:

[0168] 5.8.9.1 Sidelink RRC Reconfiguration

[0169] 5.8.9.1.1 Overview

[0170] The title of 3GPP R2-2311857 ​​is "Sidelink RRC reconfiguration successful".

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

[0172] The title of 3GPP R2-2311857 ​​is "Sidelink RRC reconfiguration failure".

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

[0174] The purpose of this procedure is to modify the PC5-RRC connection, such as to establish / modify / release the sidelink DRB or PC5 trunk RLC channel, to (re)configure NR sidelink measurement and reporting, to (re)configure sidelink CSI reference signal resources, to (re)configure CSI report delay limits, to (re)configure sidelink DRX and to (re)configure SL UE-to-UE coordination report delay limits.

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

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

[0177] - Establish a sidelink DRB associated with the peer UE, as specified in Clause 5.8.9.1a.2;

[0178] - Modify the parameters included 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 relay UEs and remote UEs, as specified in Clause 5.8.9.7.1;

[0180] - Establish for L2 U2N / U2U PC5 Relay RLC channels for relay UEs and remote UEs, as specified in Clause 5.8.9.7.2;

[0181] - Modify the contents included in L2 U2N / U2U The parameters in SL-RLC-ChannelConfigPC5 for the PC5 relay RLC channel of the relay UE and the remote UE are 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 report delay limits;

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

[0185] - (Re)configure the latency limits for SL inter-UE coordination reports ；

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

[0187] Under RRC_CONNECTED, the UE applies the NR sidelink communication parameters provided in RRCReconfiguration (if present). Under RRC_IDLE or RRC_INACTIVE, the UE applies the NR sidelink communication parameters provided in the 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: The two conclusions of FFS regarding the TX remote UE derivation of e2e SL-DRB do not exclude the possibility of information from gNB / pre-configuration / specified configuration.

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

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

[0191] The UE should configure the contents of the RRCReconfigurationSidelink message as follows:

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

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

[0194] 1> For each side link DRB to be established or modified, according to clause 5.8.9.1a.2.1, due to the receipt of sl-ConfigDedicatedNR, SIB12, or SidelinkPreconfigNR:

[0195] 2> To establish a sidelink DRB:

[0196] 3> Assign a new logical channel identifier to the logical channel as 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 based on the received sl-RadioBearerConfig and the sl-RLC-BearerConfig corresponding to the side link DRB;

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

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

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

[0201] 4> Configure sl-MeasConfig based on the NR sidelink measurement configuration information stored for this destination;

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

[0203] 4> Set sl-MeasConfig based on the stored NR side link measurement configuration received from SIB12;

[0204] 2> Otherwise:

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

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

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

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

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

[0210] 1> Configure 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 scheme.

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

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

[0214] 3> If the UE is under RRC_CONNECTED, and if sl-ScheduledConfig is included in sl-ConfigDedicatedNR within 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 under RRC_IDLE or RRC_INACTIVE or is outside the coverage area, or under RRC_CONNECTED, and sl-UE-SelectedConfig is included in sl-ConfigDedicatedNR within RRCReconfiguration, then the setting of sl-DRX-ConfigUC-PC5 depends on the UE implementation scheme.

[0217] 1> For each PC5 trunk 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 trunk RLC channel to be established or modified due to the receipt of sl-ConfigDedicatedNR:

[0220] 2> To establish a PC5 relay RLC channel, then:

[0221] 3> Assign a new logical channel identifier to the logical channel 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 successfully established, then:

[0225] 3> Assign a new local UEID to the L2U2U remote UE based on the association between the user information and the L2ID as specified in TS23.304

[65] . And set sl-RemoteUE-LocalIdentity-config in SL-SRAP-ConfigPC5 to include the new local UEID and L2ID of the L2 U2U remote UE when necessary;

[0226] 3> Assign a new local UE ID to the peer L2U2U remote UE according to the association between the user information and the L2 ID specified in TS23.304

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

[0227] 3> Confirm that the RRCReconfigurationSidelink message is submitted to the L2 U2U remote UE;

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

[0229] Editor's Note: WA: The RRCReconfigurationSidelink message carries the L2 ID and local ID, and assumes that the association between user information and L2 ID is done 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 contain 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 whether 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 the upper layer;

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

[0236] 2> Confirm that the RRCReconfigurationSidelink message is submitted to the L2U2U relay UE;

[0237] The UE should submit an RRCReconfigurationSidelink message to the lower layer for transmission.

[0238] 5.8.9.1.3 Receiving RRCReconfigurationSideline via UE

[0239] The UE should perform the following actions upon receiving the RRCReconfigurationSidelink:

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

[0241] 2> Execute 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 sidelink configuration;

[0244] 3> Perform the sidelink DRB release procedure in accordance with clause 5.8.9.1a.1;

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

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

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

[0248] 4> Apply SL-PQFI included 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 contained in slrb-ConfigToAddModList, which is part of the current UE sidelink configuration:

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

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

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

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

[0255] 3> If the sidelink DRB release condition as described in Clause 5.8.9.1a.1.1 is met, then:

[0256] 4. Perform the sidelink DRB release procedure in accordance with clause 5.8.9.1a.1.2;

[0257] 3> Otherwise, if the sidelink DRB modification conditions 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> Execute 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> Application configured with sidelink CSI report latency limits;

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

[0266] 2> For each SL-RLC-ChannelID value contained in sl-RLC-ChannelToReleaseListPC5, which is part of the current UE sidelink configuration;

[0267] 3> Perform the PC5 relay RLC channel release procedure in accordance with 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 sidelink configuration:

[0270] 3> Perform the PC5 trunk 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, which is part of the current UE sidelink 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 layer to perform sidelink DRX operations 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> Application configured sidelink IUC reporting latency limits;

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

[0279] 2> Configure the lower layer to perform NR side link U2U relay operations according to sl-RemoteUE-LocalIdentity-config for L2U2U remote UEs and sl-PeerRemoteUE-LocalIdentity-config for peer L2U2U remote UEs as defined in TS38.351

[65] ;

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

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

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

[0283] 2> Continue using 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 is not considered for application to the corresponding sidelink unicast communication;

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

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

[0293] 4> Confirm that the RRCReconfigurationCompleteSidelink message is submitted 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 will treat the situation as a side link RRC reconfiguration failure.

[0296] Note 2: Whether to indicate the rejection of the received side link DRX configuration to the peer UE depends on the UE implementation scheme.

[0297] [...]

[0298] 5.8.9.1.9 Receive RRCReconfigurationCompleteSidelink via UE

[0299] The UE should perform the following actions upon receiving RRCReconfigurationCompleteSidelink:

[0300] 1> Stop timer T400 at the destination (if it is 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 is not considered for application to the corresponding sidelink unicast communication;

[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 include 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 include the associated destination of the target L2 U2U remote UE;

[0308] 3> Determine whether 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-231-2007 discusses PC5 radio link failure (RLF) in UE-to-UE (U2U) relay as follows:

[0312] 2.1 RLF in U2U Repeater

[0313] E2E SL RLF

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

[0315] 1> After the side-link RLC entity indicates that the maximum number of retransmissions for a specific destination has been reached; or

[0316] 1> After the expiration of the T400 visa for a specific destination; or

[0317] 1> After the MAC entity indicates that the maximum number of consecutive HARQ DTXs for a specific destination has been reached, or

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

[0319] In U2U trunk scenarios, upon the expiration of the T400 for the peer remote UE, or upon a failure indication from the sidelink PDCP entity regarding the integrity check of SL-SRB2 or SL-SRB3 for the peer remote UE, the remote UE will consider the E2ESL RLF and thus trigger trunk reselection based on the previous RAN2 protocol. Similar to L2 UE-to-network trunking in Rel-17, the remote UE can choose to maintain or release its per-hop PC5 RRC connection with the trunk 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 scheme after detecting the E2E RLF.

[0321] If Proposal 1 is agreed upon and the remote UE chooses to maintain a per-hop PC5 RRC connection with the relay UE, then 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, then the remote UE sends an instruction 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) Handling sidelink radio link failures

[0325] [...]

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

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

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

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

[0330] Version 18 of the 3GPP RRC runs CR (R2-2314014) and updates the sidelink radio link failure related actions in Clause 5.8.9.3, specifying the notification message in Clause 5.8.9.10 as follows:

[0331] 5.8.9.3 Actions related to sidelink radio link failure

[0332] UE should:

[0333] 1> After the side-link RLC entity indicates that the maximum number of retransmissions for a specific destination has been reached; or

[0334] 1> After the expiration of the T400 visa for a specific destination; or

[0335] 1> After the MAC entity indicates that the maximum number of consecutive HARQ DTXs for a specific destination has been reached, or

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

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

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

[0339] 2> Release the DRB for this destination in accordance with Clause 5.8.9.1a.1;

[0340] 2> Release the SRB for this destination in accordance with clause 5.8.9.1a.3;

[0341] 2> Release the PC5 trunk RLC channel for this destination (if configured) in accordance with Clause 5.8.9.7.1;

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

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

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

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

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

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

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

[0349] 3> Otherwise:

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

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

[0352] Note: The decision on whether and how to instruct the upper layer to maintain the keep-alive procedure depends on the UE implementation scheme

[55] .

[0353] [...]

[0354] 5.8.9.10 Notification Message

[0355] 5.8.9.10.1 Overview

[0356] [3GPP R2-2314014, titled "Notification Messages in Side Links"] Figure 5 .8.9.8.1-1 reproduced as Figure 10 ]

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

[0358] 5.8.9.10.2 Initiated

[0359] A relay UE may initiate a procedure if 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 an RRCReconfiguration containing reconfigurationWithSync;

[0363] 2> After reselecting the community;

[0364] 2> After the RRC connection of an L2 U2N relay UE that includes RRC connection rejection as specified in 5.3.3.5 and 5.3.13.10 fails, and the T300 expires as specified in 5.3.3.7 and the 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 L2 U2U remote UE as specified in 5.8.9.3;

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

[0368] The relay UE should be configured with the following indication type:

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

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

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

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

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

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

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

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

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

[0378] 2> Submit NotificationMessageSidelink messages 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 a NotificationMessageSidelink message due to a PC5 RLF connection with an L2 U2U remote UE, then:

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

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

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

[0384] 5.8.9.10.4 Actions related to receiving NotificationMessageSidelink messages

[0385] Upon receiving NotificationMessageSidelink, the remote UE should:

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

[0387] 2> If indicationType is included:

[0388] 3> If the UE is an L2 U2N remote UE under RRC_CONNECTED:

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

[0390] 5> As specified in 5.7.3c, initiate an indirect path failure information procedure to report indirect path failures;

[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 (the UE is an L3 U2N remote UE or an L2 U2N remote UE under RRC_IDLE or RRC_INACTIVE):

[0394] 4> If it is determined that the PC5-RRC connection with the U2N relay UE should be released, then:

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

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

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

[0398] 6> Consider the possibility of cell reselection;

[0399] Note 1: For L3 U2N remote UEs or L2 U2N remote UEs under RRC_IDLE or RRC_INACTIVE, the decision to release or maintain the PC5 unicast link depends on the remote UE implementation scheme.

[0400] Note 2: If the L2 U2N remote UE is in an indirect-to-direct path handover, i.e., the source-side PC5 unicast link has not been released while T304 is running, then NotificationMessageSidelink can be ignored.

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

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

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

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

[0405] Note X1: After receiving the PC5 RLF indication from the U2U relay UE, it depends on the upper layer to decide whether to trigger U2U relay reselection and whether to maintain or release the PC5 link with the U2U relay UE.

[0406] U2U (User-to-User) relaying was introduced in 3GPP Release 18, where a relay UE is used to support communication between two remote UEs that cannot communicate directly with each other due to being outside radio coverage. The relay UE needs to establish a PC5RRC 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... Figure 11 The diagram illustrates a PC5 RRC connection for inter-UE relay according to an exemplary embodiment. Additionally, an end-to-end PC5 RRC connection can be established between these two remote UEs for 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 2 U2U relay UE, the end-to-end QoS requirements for relay services between peer Layer 2 remote UEs can be met by the corresponding QoS control for the PC5 RRC connection between the Layer 2 source remote UE and the Layer 2 relay UE (i.e., the first-hop PC5 QoS control) and the QoS control for the PC5 RRC connection between the Layer 2 relay UE and the Layer 2 target remote UE (i.e., the second-hop PC5 QoS control).

[0408] To achieve this, the source remote UE and the target remote UE can negotiate the end-to-end QoS requirements for the new PC5 QoS stream. The source remote UE can then provide the end-to-end QoS requirements to the relay UE, allowing the relay UE to break down the end-to-end QoS requirements into at least one QoS value for the first hop and at least another QoS value for the second hop. The relay UE can then provide the first-hop QoS value to the source remote UE, allowing the source remote UE to determine the end-to-end (E2E) SL DRB configuration and PC5 relay RLC channel configuration (for transmitting PC5 QoS stream packets to the target remote UE via the first hop) at least based on the QoS value received from the relay UE. The source remote UE then provides the relay UE (e.g., via an RRC reconfiguration sidelink message) with the receive (Rx)RLC parameters of the PC5 relay RLC channel configuration, enabling the relay UE to receive PC5 QoS stream packets from the source remote UE on the PC5 relay RLC channel. Additionally, the relay UE can 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 packets of the PC5 QoS stream to the target remote UE on the PC5 relay RLC channel via the second hop.

[0409] Essentially, different E2E SL-DRBs destined for the same or different remote UEs can be multiplexed onto the same PC5 Relay RLC channel for transmission. Therefore, the end-to-end PC5 radio bearer ID (E2E SL-DRB ID), the source remote UE's local UE ID, and the target remote UE's local UE ID are included in the header of the SRAP PDU (for transmitting data packets) so that the relay UE can determine the egress PC5 Relay RLC channel for forwarding data packets, and also so that received data packets used by the target remote UE for a specific PDCP entity can be associated 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 via the first hop between the source remote UE and the relay UE. Furthermore, 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 via the second hop between the relay UE and the target remote UE.

[0410] According to 3GPP R2-231-2007, a source remote UE may consider an E2E PC5 radio link failure (RLF) after the T400 for the target remote UE expires or after an integrity check failure indication from the sidelink PDCP entity regarding SL-SRB2 or SL-SRB3 for the target remote UE. In this case, the source remote UE may choose to maintain or release its PC5 RRC connection with the relay UE. For example, the source remote UE may maintain its PC5 RRC connection with the relay UE if it 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 its PC5 RRC connection with the relay UE after an E2E PC5 RLF, then 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 can inform the relay UE of the PC5-RLF, so that the relay UE can release the hop configuration for the corresponding destination.

[0411] Because 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 can release the second hop configuration for the corresponding destination when it receives an E2E PC5-RLF notification from the source remote UE. However, the identifier of the target remote UE associated with the E2E PC5-RLF should also be provided to the relay UE in the notification message (e.g., a notification message sidelink message or an RRC reconfiguration sidelink message). Additionally, the relay UE may not know which PC5 relay RLC channels above the first hop are used by the source remote UE to transmit data packets to the target remote UE of interest. The source remote UE should provide the relay UE with other or additional information (included in the same notification message or a different PC5 RRC message) to release the PC5 relay RLC channel through the first hop.

[0412] Basically, after an E2E PC5-RLF, if the established PC5 Relay RLC channel is only used to transmit data packets 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 can send a PC5RRC 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 an RLC entity is established to support the PC5 Relay RLC channel, the RLC entity associated with the PC5 Relay RLC channel can also be released.

[0413] In one embodiment, the PC5 trunk RLC channel configuration may include the identifier (ID) of the PC5 trunk RLC channel and the PC5 RLC configuration. Furthermore, an RLC entity is established based on the PC5 RLC configuration. In one embodiment, the ID of the PC5 trunk RLC channel is included in the list of sidelink RLC channels to be released in the RRC reconfiguration sidelink message, indicating the PC5 trunk RLC channel and / or RLC entity to be released.

[0414] An example of disposing of an E2E PC5 RLF is shown according to an exemplary embodiment. Figure 12 An example of the solution described above is shown.

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

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

[0417] This illustrates an example of handling a second-hop PC5 RLF notification according to an exemplary embodiment. Figure 13An example of the above solution is illustrated. UE1 communicates with UE2 and UE3 via a relay UE. A first PC5 relay RLC channel is established / configured solely for communication with UE2, and a second PC5 relay RLC channel is established / configured for communication with both UE2 and UE3. When UE1 receives a notification message sidelink message from the relay UE indicating a PC5 radio link failure (RLF) with UE2, UE1 transmits an RRC reconfiguration sidelink message to the relay UE indicating that the first PC5 relay RLC channel should be released.

[0418] Figure 14 This is flowchart 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 at least one target remote UE. In step 1420, the source remote UE detects an E2E PC5 radio link failure (RLF) associated with one of the target remote UEs. In step 1425, if at least one PC5 Relay RLC channel is used to transmit data packets to a target remote UE and is not shared by any other target remote UE, the source remote UE responds to the E2E PC5RLF by transmitting an RRC reconfiguration sidelink message to the relay UE, wherein the RRC reconfiguration sidelink message contains information indicating the PC5 Relay RLC channel to be released.

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

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

[0421] In one embodiment, after receiving an RRC reconfiguration complete sidelink message from the relay UE, the PC5 relay RLC channel can be released by the source remote UE.

[0422] Return to reference Figure 3 and Figure 4 In an exemplary embodiment from the perspective of the source remote UE, the source remote UE 300 includes program code 312 stored in memory 310. CPU 308 executes 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 at least one target remote UE, (iv) detect an E2E PC5 RLF associated with one of the target remote UEs, and (v) transmit an RRC reconfiguration sidelink message to the relay UE in response to an E2E PC5 RLF if 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, wherein the RRC reconfiguration sidelink message contains information indicating a PC5 relay RLC channel to be released. In addition, CPU 308 can execute program code 312 to perform all the actions and steps described above or other actions and steps described herein.

[0423] Various aspects of this disclosure have been described above. It should be understood that the teachings herein can be implemented in a wide variety of forms, and any particular structure, function, or both disclosed herein are merely representative. Based on the teachings herein, those skilled in the art will understand 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 an apparatus or practice. Furthermore, this apparatus or practice can be implemented or practiced using structures, functions, or structures and functions other than or different from one or more of the aspects set forth herein. As examples of some of the foregoing concepts, in some aspects, a parallel channel can be established based on a pulse repetition frequency. In some aspects, a parallel channel can be established based on a pulse position or offset. In some aspects, a parallel channel can be established based on a time-hopping sequence. In some aspects, a parallel channel can be established based on a pulse repetition frequency, a pulse position or offset, and a time-hopping sequence.

[0424] Those skilled in the art will understand that information and signals can 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 foregoing description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0425] Those skilled in the art will further understand that the various illustrative logic blocks, modules, processors, components, circuits, and algorithmic steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware (e.g., digital implementations, analog implementations, or combinations thereof, which may use source coding or some other technical design), incorporated with instructions in various forms of program or design code (which may be referred to herein as "software" or "software module" for convenience), or combinations thereof. To clearly illustrate this interchangeability between hardware and software, the functionality of the various illustrative components, blocks, modules, circuits, and steps has been generally described above. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a deviation from the scope of this disclosure.

[0426] Furthermore, the various illustrative logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within, or executed 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 alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration.

[0427] It should be understood that any particular order or hierarchy of steps in any disclosed process is an instance of a sample method. It should be understood that, based on design preferences, the particular order or hierarchy of steps in the process may be rearranged while remaining within the scope of this disclosure. The accompanying methodological solutions present elements of 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 methods or algorithms described in connection with the aspects disclosed herein can be implemented directly in hardware, with a software module executed by a processor, or a combination of both. The software module (e.g., containing executable instructions and associated data) and other data can reside in data memory, such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of computer-readable storage medium known in the art. The sample storage medium can be coupled to a machine such as a computer / processor (for convenience, the machine may be referred to herein as a "processor") such that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. The sample storage medium can be integrated with the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a user equipment. Alternatively, the processor and storage medium can reside as discrete components in a user equipment. Furthermore, in some aspects, any suitable computer program product may include a computer-readable medium comprising code associated with one or more aspects of this disclosure. In some respects, computer program products may include packaging materials.

[0429] While the invention has been described in conjunction with various aspects, it should be understood that further modifications are possible. This application is intended to cover any changes, uses, or adaptations to the invention that generally follow the principles of the invention and include such deviations from this disclosure that fall within the scope of known and customary practice in the art to which this invention pertains.

Claims

1. A method for a source remote user equipment (UE), comprising: The source remote UE and the relay UE establish a PC5 radio resource control (RRC) connection; The source remote UE establishes at least one end-to-end (E2E) PC5RRC connection with at least one target remote UE via the relay UE; The source remote UE 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, and wherein each configuration of the at least one PC5 relay RLC channel includes a PC5 RLC configuration and an identifier (ID) of the PC5 relay RLC channel. The source remote UE detects an E2E PC5 radio link failure (RLF) associated with the target remote UE in the at least one target remote UE, wherein the E2E PC5 RLF is detected due to T400 expiration or integrity check failure. 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 with any other target remote UE, the source remote UE responds to the E2E PC5 RLF by transmitting an RRC reconfiguration sidelink message to the relay UE, wherein the RRC reconfiguration sidelink message contains information indicating that the PC5 Relay RLC channel is to be released. as well as 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 shared with other target remote UEs, the source remote UE responds to the E2E PC5 RLF without transmitting the RRC reconfiguration sidelink message to the relay UE.

2. The method of claim 1, wherein the at least one configuration of the at least one PC5 relay RLC channel is transmitted in another RRC reconfiguration sidelink message.

3. The method of claim 1, wherein the information indicating the PC5 relay RLC channel to be released is the ID of the PC5 relay RLC channel.

4. The method according to claim 3, characterized in that, The ID of the PC5 relay RLC channel is included in the list of sidelink RLC channels to be released.

5. The method of claim 1, wherein after receiving the RRC reconfiguration complete sidelink message from the relay UE, the PC5 relay RLC channel is released by the source remote UE.

6. A source remote user equipment (UE), comprising: Control circuit; A processor, which is installed in the control circuit; as well as A memory, which is installed in the control circuit and operatively coupled to the processor; The processor is configured to execute program code stored in the memory to: Establish a PC5 radio resource control (RRC) connection with the relay UE; At least one end-to-end (E2E) PC5 RRC connection is established between the relay UE and at least one target remote UE; At least one configuration of at least one PC5 relay radio link control (RLC) channel is transmitted 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, and wherein each configuration of the at least one PC5 relay RLC channel includes a PC5 RLC configuration and an identifier (ID) of the PC5 relay RLC channel. Detect an E2E PC5 radio link failure (RLF) associated with the target remote UE in the at least one target remote UE, wherein the E2E PC5 RLF is detected due to T400 expiration or integrity check failure; 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 with any other target remote UE, an RRC reconfiguration sidelink message is transmitted to the relay UE in response to the E2E PC5 RLF, wherein the RRC reconfiguration sidelink message contains information indicating that the PC5 Relay RLC channel is to be released; as well as 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 shared with other target remote UEs, the RRC reconfiguration sidelink message is not transmitted to the relay UE in response to the E2E PC5 RLF.

7. The source remote UE of claim 6, wherein the at least one configuration of the at least one PC5 relay RLC channel is transmitted in another RRC reconfiguration sidelink message.

8. The source remote UE of claim 6, wherein the information indicating the PC5 Relay RLC channel to be released is the ID of the PC5 Relay RLC channel.

9. The source remote UE of claim 8, wherein the ID of the PC5 relay RLC channel is included in the list of sidelink RLC channels to be released.

10. The source remote UE according to claim 6, wherein the PC5 relay RLC channel is released by the source remote UE after receiving the RRC reconfiguration complete sidelink message from the relay UE.

Images