Managing link problems in sidelink relay systems

Abstract

In a wireless communication system including a relay UE node for relaying data between at least one node of a plurality of nodes and at least one other node of the plurality of nodes, a method in the relay UE node includes: identifying a relay capability for data relay by the relay UE node, determining whether relaying by the relay UE to one or more remote UE nodes is supportable based on the identified relay capability, and in response to determining that relaying by the relay UE node is supportable, transmitting a sidelink management message for indicating that relaying by the relay UE node is supportable, and in response to determining that relaying by the UE node is not supportable, transmitting a sidelink management message for indicating that relaying by the relay UE node is not supportable or not transmitting one or more sidelink management messages. A method in a relay UE is also disclosed. A method of signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes is also described. The relay UE node is configured to relay data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes. The method at a relay UE node includes detecting a link problem in the wireless communication system, and in response to detecting a link problem, generating link problem feedback information for the detected link problem, the link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem, and transmitting the link problem feedback information. A method for processing link problem feedback information at a node of a wireless communication system is also disclosed.

Description

[Technical field]

[0001] The present invention relates generally to managing link problems in a sidelink relay system and / or signaling link problems in a wireless communication system, and in particular to a method performed in different nodes in a sidelink relay system, a method and an apparatus for signaling link problems in a sidelink relay system, and a method and an apparatus for processing link problem feedback information for signaling link problems in a sidelink relay system. [Background technology]

[0002] The present invention relates to Vehicle-to-Everything (V2X) communications, and more precisely to New Radio (NR) sidelink relaying for coverage extension and power efficiency.

[0003] Recent Cellular-vehicle-to-everything (C-V2X) technologies are expected to support Intelligent Transportation Systems (ITS) where all road users, including vehicles and pedestrians, cooperate with each other via wireless communication, enhancing traffic efficiency (e.g., reducing congestion) and improving road safety while avoiding road accidents. The wireless communication aims to increase the visibility of vehicles, especially in Non-Line-Of-Sight (NLOS) conditions, in adverse weather conditions or high traffic density, by exchanging messages between road users such as vehicles, Vulnerable Road Users (VRUs) (e.g., pedestrians, cyclists) and Road Side Units (RSUs). C-V2X is studied in the 4G LTE and 5G NR (New Radio) releases of the specifications defined by 3GPP. The term V2X means "Vehicle to Everything" and vehicles may establish communication with "everything", meaning different network entities and / or User Equipments (UEs). The following communications are considered: - V2V or Vehicle-to-Vehicle communication for the exchange of safety and advanced service information, - V2P or Vehicle-to-Pedestrian for sending warnings to pedestrians, - V2I or Vehicle-to-Infrastructure, such as Road Side Units providing road safety services; - Vehicle-to-Network or V2N, which connects vehicles to cellular base stations for real-time traffic.

[0004] 3GPP has been developing standards for UE-to-UE direct communication, called Sidelink (SL) communication or PC5 communication (e.g., direct communication between UEs over a Sidelink or PC5 interface). Sidelink (or PC5) communication was first introduced in 3GPP Release 12 for LTE technology as part of the Proximity Service (ProSe) framework. Later versions of Sidelink for LTE are primarily focused on Vehicle-to-Vehicle (V2V) related use cases and introduce Basic Safety Messaging (BSM). Note that the term UE in UE-to-UE direct communication can mean a UE of a VRU (e.g., a pedestrian's UE) or a UE inside or part of a vehicle or RSU.

[0005] The first version of sidelink for 5G or New Radio (NR) will be developed as part of the 5G V2X Work Item in Release 16 and will support advanced V2X scenarios and commercial applications and services in addition to complementing traditional basic safety services.

[0006] NR V2X addresses advanced driving use cases where vehicles exchange large amounts of data while respecting low latency requirements. Advanced V2X scenarios therefore demand ultra-high reliability and low latency to cover high speed and high density scenarios along with extending the network coverage, which may require some data relaying.

[0007] The NR sidelink is designed to provide three basic transmission scenarios: broadcast, groupcast, and unicast, while considering both out-of-coverage and in-network deployment scenarios.

[0008] In this regard, sidelink relaying is being studied in 3GPP with the aim to provide sidelink / network coverage extension along with improved power efficiency, enabling a wider range of applications and services.

[0009] 3GPP has approved a study item for Release 17 (Rel-17) titled "Study on NR Sidelink Relay" that covers the enhancements and solutions required to support both UE-to-Network (U2N) and UE-to-UE (U2U) sidelink relaying as described in 3GPP TR 38.836. The study covers discovery procedures, both Layer 2 and Layer 3 UE-to-Network relaying and UE-to-UE relaying, including details on relay (re)selection, authentication, QoS management, service continuity, security, protocol stack design, and control plane (CP) procedures.

[0010] A new adaptation layer is being considered by 3GPP to manage Layer 2 (L2) sidelink relay. This Sidelink Relay Adaptation Layer (SRAP) sits on top of the RLC sublayer. SRAP is described in 3GPP TS 38.351.

[0011] Further enhancements are planned for Release 18, including support for UE-to-UE network relaying for extending sidelink coverage, service continuity, and multipath communications.

[0012] NR sidelink relaying has the particularity of relaying data from a source node to a destination or target node between two hops (e.g., two links). For UE-to-Network (U2N) relaying, the source node is either a network node or a base station (for 5G NR, the base station is called gNB) for the downlink and a remote UE for the uplink, and the destination or target node is either a remote UE or a gNB, respectively. For UE-to-UE (U2U) relaying, the source node is called the source UE and the destination or target node is called the target UE. The hop between two UEs (e.g., a remote UE and a relay UE) is a sidelink PC5 hop, and the hop between a gNB and a UE is a Uu hop. Thus, for UE-to-Network (U2N) relaying, the hop between remote UE and relay UE (in uplink) or between relay UE and remote UE (in downlink) is a sidelink PC5 hop, and the other hop between relay UE and gNB (in uplink) or between gNB and relay UE (in downlink) is a Uu hop, and for UE-to-UE (U2U) relaying, the hop between source UE and relay UE and between relay UE and target UE is a sidelink PC5 hop.

[0013] Due to the presence of an intermediate UE between the two aforementioned hops, this partial visibility between the transmitting Tx (source) device (remote UE or gNB or source UE) and the receiving Rx (destination) device (remote UE or gNB or target UE) may hide possible issues at the other hop from one hop.

[0014] In wireless communication, different types of problems can occur. The first problem is congestion, when the amount of data to transmit on a hop exceeds the current capacity of the network, i.e. the resources / bandwidth available for transmission. To allow for quality of service differentiation in the Radio Access Network (RAN), the system uses different logical channels for the transmission of data of different priorities. This allows for a differentiation of resource allocation for each logical channel depending on the priority level of the channel. As a result, congestion can occur on one or more specific channels depending on the current capacity of the network and the QoS required for the data to be transmitted. According to Fig. 2A and Fig. 2B, which represent the protocol stacks of the user plane of UE-to-Network (U2N) relay and UE-to-UE (U2U) relay, respectively, congestion can be detected at different levels in the protocol stack, and congestion on a specific channel can be detected on a single Radio Bearer (RB) of a QoS flow or on the ingress / egress Radio Link Control (RLC) channel of the corresponding hop. In more severe cases, global congestion can occur, affecting all Radio Bearers and RLC channels.

[0015] Other problems related to the propagation environment, such as RF signal attenuation due to objects or bad weather, or user equipment mobility, can occur on the link, which can significantly reduce the signal strength, especially when using high-throughput mmWave signals, causing link degradation or radio link failure (RLF) on the corresponding hop.

[0016] As mentioned above, RAN links can suffer from various problems. These problems can cause continuous loss of data or increased latency leading to poor quality of service (QoS). Link problems derived from these problems can be congestion, link degradation, or radio link failure detected at the relay UE. Congestion can occur on a radio bearer or an RLC channel, or it can affect a group of RLC channels.

[0017] A link problem detected on the first hop is detected by the affected node and the relay UE (e.g. the affected node is connected to the relay UE by the first hop). However, a second node on the second hop (e.g. another remote UE or a gNB connected to the relay UE) is not informed of the link problem, so that the link problem affects the transmission or reception of traffic at the second node. And vice versa, if a link problem is detected on the second hop, the affected node on the first hop is not informed. This partial visibility of relay traffic can result in continuous retransmission requests with degraded QoS, and the link problem can be amplified and affect other bearers and channels.

[0018] Therefore, a solution to at least one of the above problems is desired. Summary of the Invention

[0019] According to a first aspect of the present invention, there is provided a method for signaling a link problem in a wireless communication system, the wireless communication system including a relay user equipment (UE) node and a plurality of nodes, the relay UE node for relaying data between at least one of the plurality of nodes and at least one other of the plurality of nodes, the method in the relay UE node including: Detecting a link problem in a wireless communication system; in response to detecting the link problem, generating link problem feedback information for the detected link problem, the link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem; Sending link problem feedback information.

[0020] The link problem feedback information may be transmitted to at least one of a plurality of nodes associated with one or more communication flows affected by the detected link problem. For example, the link problem feedback information may be transmitted to at least one of a plurality of nodes affected by the detected link problem. The link problem feedback information may be transmitted to at least one of a source node and a destination node.

[0021] In one example, the link problem feedback information may be transmitted to all of a plurality of nodes connected to the relay UE.

[0022] The plurality of nodes may include at least two remote UEs. The plurality of nodes may include at least two remote UEs and a network node, such as a gNB.

[0023] According to a second aspect, there is provided a method for processing link problem feedback information in a node in a wireless communication system, the link problem feedback information signaling a link problem in the wireless communication system, the wireless communication system including a node, a relay UE node, and at least one other node, the method including: receiving link problem feedback information from the relay UE node, the link problem feedback information including flow information for identifying one or more communication flows affected by a detected link problem; processing the link problem feedback information to determine, based on the flow information, one or more communication flows that are affected by the detected link problem, and evaluating, on the one or more determined communication flows, a level of impact of the detected link problem on data communication at the node; Performing an action at the node based on the assessed impact level of the detected link problem.

[0024] In one example, the flow information includes a flow identifier for identifying one or more communication flows affected by the detected link problem. The identifier may be one of the following (e.g., based on the type of link problem): DRB ID, SRB ID, SL DRB ID, SL SRB ID, RLC bearer ID, RLC channel ID, link ID (e.g., PC5 ID or Uu ID) for identifying a link associated with the detected link problem.

[0025] The link problem feedback information may further include information for identifying a type of the detected link problem (e.g., whether the link problem is a handover, congestion, link degradation, RLF, temporary / short-term or long-term / permanent type of link problem). The information for identifying the type of the detected link problem may include a reason identifier (ID) or another identifier for identifying the type of the detected link problem. The information may also include reason / context information for indicating a reason or context of the detected link problem. In addition to identifying the type of the detected link problem, the reason ID may represent a reason or context of the detected link problem, as described above.

[0026] In one example, the link problem feedback information is included in a link problem signaling message transmitted by the relay UE node. The link problem feedback information may further include information for indicating a type of the link problem signaling message. For example, the type may be either a link problem feedback type, a (re)selection feedback type, or a link status change feedback type, and the information may be included in an Information Element (e.g., PDU type) of the message.

[0027] By generating link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem and transmitting the link problem feedback information to at least one of a plurality of nodes (e.g., the affected node may be at least a source node or a transmitter configured for data transmission, and may be a remote UE or a network node) associated with the one or more communication flows affected by the detected link problem, the affected node (e.g., including a "hidden" node) in the sidelink relay connection or path can be informed of the detected link problem and the affected node can take appropriate action. The action at the affected node can include, for example, releasing and performing (re)selection of the link associated with the affected one or more communication flows, waiting for new link problem feedback information, resuming transmission of data on the affected one or more communication flows, etc. This means that continuous retransmission requests with QoS degradation when a link problem occurs, which may amplify the link problem and affect other bearers or channels, can be avoided.

[0028] By including a flow identifier for identifying one or more communication flows affected by the detected link problem, and possibly information for identifying the type of link problem detected (which may also include the reason for the link problem), the relay UE node may provide feedback information identifying the granularity of the link problem that may help the affected node take optimal action in response to the detected link problem (e.g., the affected node may take prompt action and intelligently adapt its behavior depending on the details of the link problem).

[0029] The information indicating the type of the link problem signaling message (e.g., PDU type) serves to indicate one or more actions to be taken by a node receiving the link problem signaling message. By including the information indicating the type of the link problem signaling message in the link problem feedback information (flow identifier, information for identifying the type of the detected link problem), the link problem signaling message may have the same format for different link problems. In other words, the link problem signaling message may have the same format whether the link problem signaling message signals link problem feedback, (re)selection feedback, or link status change feedback. The PDU type information and the link problem feedback information may be used by a node receiving the link problem signaling message to determine what action to take.

[0030] According to a third aspect, there is provided a method for signaling link problems in a wireless communication system, as set forth in appended claim 44. By transmitting link problem information by a relay UE node in a discovery message (e.g. a message for identifying relay UEs to remote UE nodes in the vicinity or coverage area of ​​the relay UE node), the remote UE node can avoid selecting as relay UE node a node that cannot actually provide relay services to the remote UE node due to some link problem.

[0031] The information for identifying the type of link problem detected (e.g., whether the link problem is one of the following types of link problem: handover, congestion, link degradation, RLF, temporary / short-term, or long-term / permanent link problem) may include a reason identifier (ID) or another identifier for identifying the type of link problem detected. The information may also include reason / context information for indicating a reason or context of the detected link problem. In addition to identifying the type of link problem detected, the reason ID may represent a reason or context of the detected link problem, as described above.

[0032] According to a fourth aspect, there is provided a method for signalling a link problem in a wireless communication system, as set out in appended claim 53. Having knowledge about the link problem that caused the relay UE node to send a reselection message, the remote UE node can make a more efficient decision on whether to maintain a connection to the relay UE node anyway, to attempt to reconnect after a short time (taking into account that the congestion may be transient and may be alleviated quickly), or to actually perform a relay reselection.

[0033] According to a fifth aspect, there is provided a method performed by a relay user equipment (UE) node of a wireless communication system, as claimed in claim 1.

[0034] The sidelink management message includes relay capability information indicating the relay capability of the relay UE node for relaying data by the relay UE node.

[0035] The sidelink management message may be a discovery message or a link management message (such as a direct link message or a direct communication message). A discovery message may be an announcement message or a response message sent in response to a received discovery solicitation message. A link management message may be a direct link establishment accept / reject message, a direct link modification accept / reject, a direct link modification / release request message, or a direct communication accept / reject message.

[0036] According to a sixth aspect, there is provided a method performed by a remote User Equipment (UE) node of a wireless communication system, as claimed in claim 13.

[0037] The sidelink management message includes relay capability information indicating the relay capability (Capacity) of the relay UE node for relaying data by the relay UE node.

[0038] The sidelink management message may be either a discovery message or a link management message (such as a direct link message or a direct communication message).

[0039] The relay capability information included in the sidelink management message may include one or more of the following: new connection information for indicating whether the relay UE node can accept a new connection to a new remote UE node, relay load information for indicating the current load of the relay UE node, Quality Of Service (QoS) information for indicating the QoS level of each of the one or more communication flows currently being provided by the relay UE node, sidelink measurement report information for indicating the radio quality of one or more communication links between the relay UE node and at least one remote UE node, network link measurement report information for indicating the radio quality of a communication link between the relay UE node and a network node of the wireless communication system, bit rate information for indicating the maximum bit rate currently supported by the relay UE node, network load information for indicating the current channel occupancy and the remaining bandwidth for new communications.

[0040] By identifying the relaying capabilities of the relay UE node and determining whether relaying by the relay UE to one or more remote UE nodes is supportable, the relay UE node can ascertain whether there is a risk of link problems and act proactively to prevent or allow new connections to one or more new remote UEs and / or prevent or allow modification of existing connections and / or modify or release existing connections so as to avoid or minimize the risk of link problems occurring in the future. The relay UE node can act proactively by transmitting a sidelink management message (such as a discovery message) that indicates whether relaying by the relay UE is supported (e.g., whether new connections are supported / allowed) and can additionally or alternatively provide information indicating the actual or current relaying capabilities of the relay UE node. Alternatively, if the relay UE node cannot support relaying to new or existing remote UEs due to a high risk of link problems occurring in the future, the relay UE node can act proactively by stopping a sidelink management process (e.g., a discovery process or a link management process such as a direct link process or a direct communication process) to not transmit or stop transmitting one or more sidelink management messages (discovery messages). By not transmitting or stopping transmission of one or more sidelink management messages, UEs in the vicinity of the relay UE node will not receive any information from the relay UE node. For example, in case of a discovery process, UEs in the vicinity of the relay UE node will not consider the relay UE node when performing relay (re)selection. Upon receiving a sidelink management message containing relay capability information, the remote UE node may decide what action to take (e.g. whether to request connection establishment with the relay UE node) based on the relay capability information. If information indicating the actual or current relay capability of the relay UE node is included in the sidelink management message, the remote UE node has additional information on which to base its decision on what action to take.This allows the remote UE node to select the optimal (eg based on required QoS, bit rate, link quality, load requirements) action (eg the best relay UE node to connect to in case of a discovery process).

[0041] According to a seventh aspect, there is provided a method performed by a remote User Equipment (UE) node in a wireless communication system, as claimed in claim 19.

[0042] If the relay UE node does not send a sidelink management message or stops sending or stops forwarding the sidelink management process, if no sidelink management message is received after sending a request message, it informs the new or remote UE node that the relay UE is overloaded or experiencing other limitations that affect the relay UE node's ability to support new and existing connections. For example, in case of a discovery process, if no discovery response message is received after sending a discovery request message), if there is no available relay UE node (for example, if the discovery request message is broadcast), or if the target relay UE (in case of unicast) is overloaded or experiencing other limitations that affect the relay UE node's ability to support new connections to the remote UE node. From the information obtained by the remote UE, the remote UE may decide what action to take.

[0043] In summary, a method is proposed for a sidelink relay system to reduce the perturbation of link problems while ensuring the QoS of the relay traffic.

[0044] According to an eighth aspect of the present invention, there is provided a relay UE node for a wireless communication system (e.g. for a sidelink relay system of a wireless communication system) as claimed in claim 60.

[0045] According to a ninth aspect of the present invention, there is provided a node for a wireless communication system (e.g. for a sidelink relay system in a wireless communication system) as claimed in claim 61.

[0046] Further example features of the invention are set out in the other independent and dependent claims.

[0047] Any feature in one aspect of the invention may be applied to other aspects of the invention in any appropriate combination, in particular method aspects may be applied to apparatus / device / unit aspects and vice versa.

[0048] Furthermore, hardware implemented functionality may be implemented in software and vice versa. Any references herein to software and hardware features should be construed accordingly. For example, according to another aspect of the invention, there is provided a computer program comprising instructions which, when the program is executed by a processing unit, cause the processing unit to perform the method of any aspect or embodiment described above, and a computer readable storage medium carrying the computer program. [Brief description of the drawings]

[0049] Different aspects of the invention will now be described, by way of example only, with reference to the following drawings: [Figure 1] 1 is a schematic diagram illustrating a deployment of sidelink relaying with UE-to-network based relaying and UE-to-UE based relaying; [Figure 2A] FIG. 1 is a schematic diagram illustrating a UE-to-network user plane sidelink (SL) relay architecture with adaptation layer according to 3GPP TR 38.836; [Figure 2B] FIG. 1 is a schematic diagram illustrating a UE-to-UE user plane sidelink (SL) relay architecture with adaptation layer according to 3GPP TR 38.836; [Diagram 3]FIG. 2 is a schematic diagram showing 1:1 mapping between radio bearers (RBs) and PC5 RLC channels, and N:1 mapping to Uu RLC channels in Uu SRAP for UE-to-network sidelink relay; [Figure 4] FIG. 2 is a schematic diagram illustrating N:1 mapping and 1:1 mapping between radio bearers (RBs) and PC5 RLC channels, and N:1 mapping between RBs and PC5 RLC channels in a PC5 SRAP for UE-to-UE sidelink relay; [Diagram 5] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 6A] 1 is a flow diagram of an exemplary method for detecting link problems and generating link problem feedback information at a relay node, according to an embodiment of the present invention; [Figure 6B] 1 is a flow diagram of an exemplary method for processing link problem feedback information at an affected node, according to an embodiment of the present invention; [Figure 7A] FIG. 2 is a flow diagram of an exemplary method in a relay node for generating a link problem signaling message including information for indicating relay (re)selection feedback, according to an embodiment of the present invention; [Figure 7B] FIG. 7B is a flow diagram of an exemplary method, in an affected node, for processing information contained in a link problem signaling message generated by the method described with respect to FIG. 7A, in accordance with an embodiment of the present invention; [Figure 8A] FIG. 2 is a flow diagram of an exemplary method in a relay node for generating a link problem signaling message including information for indicating link status change feedback, according to an embodiment of the present invention; [Figure 8B] FIG. 8B is a flow diagram of an exemplary method, in an affected node, for processing information contained in a link problem signaling message generated by the method described with respect to FIG. 8A, in accordance with an embodiment of the present invention; [Figure 9]1 is a flow diagram of an exemplary method for signaling link problems in a sidelink relay system according to an embodiment of the present invention; [Figure 10] FIG. 2 is a flow diagram of an exemplary method for processing link problem feedback information at an affected node in a sidelink relay system after receiving feedback from a relay UE according to an embodiment of the present invention; [Figure 11A] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 11B] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 11C] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 11D] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 11E] FIG. 2 is a schematic diagram illustrating an example format of a link problem signaling message according to an embodiment of the present invention; [Figure 12] 1 is a block schematic diagram of an exemplary wireless communication device, in accordance with an embodiment of the present invention; [Figure 13] 1 is a flow diagram of an exemplary method performed at a relay UE node, according to an embodiment of the present invention; [Figure 14A] 1 is a flow diagram of an example of a method performed at a remote UE node according to an embodiment of the present invention; [Figure 14B] 4 is a flow diagram of an example method performed at a remote UE node according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0050] FIG. 1 illustrates an example of a wireless communication system capable of supporting sidelink relay, showing a sidelink relay arrangement or system including a relay user equipment (UE) node and a plurality of nodes. The relay UE node relays data between at least one of the plurality of nodes and at least one other of the plurality of nodes. For example, in FIG. 1, the UE node 100 may act as a relay UE node to relay data between one of the UE nodes 101, 102, 103 (referred to as a remote UE node) and the network node 107 in the case of UE-to-network relay, and / or may act as a relay UE node to relay data between one of the UE nodes 101, 102, 103 (referred to as a remote UE node) and another one of the UE nodes 101, 102, 103 in the case of UE-to-UE relay. The UE node 102 may also act as a relay node (e.g., relaying data between the UE 100 (in this case a remote UE node) and the network node 107, and between the UEs 100, 101, 103 over PC5 connections (some of which are not shown in FIG. 1)). Thus, as shown in FIG. 1, a relay UE node (100 or 102) may be a UE-to-Network Relay, a UE-to-UE Relay, or both at the same time.

[0051] The plurality of nodes may include at least two remote UE nodes (in FIG. 1, UE node 100 is a relay node and three remote UE nodes 101, 102, 103 are shown) and may include a network node 107. The network node 107 may be a base station of a wireless network, such as a fifth generation (5G) New Radio (NR) network or a Long Term Evolution (LTE) network. FIG. 1 shows only a base station of the wireless network for clarity. In the case of a 5G NR network, the network node 107 is called a gNB. Although FIG. 1 (and some of the other figures) shows UE nodes represented by vehicles, it is not intended that the present invention be limited to UE nodes that are in or part of a vehicle. Each of the UE nodes (relay or remote) may be a wireless communication device located in or part of a vehicle, or a Road Side Unit (RSU), or a wireless communication device of a Vulnerable Road User (VRU) (e.g., a mobile or portable communication device of a pedestrian or cyclist, such as a smartphone, PDA, laptop, or similar device). In the following, the relay UE node is also referred to as relay UE, the remote UE node is also referred to as remote UE, and the network node is also referred to as gNB. In the following description, embodiments and examples of the present invention are described with respect to a 5G NR network, however, it will be understood that the present invention is not intended to be limited to 5G NR systems, but may be used in any wireless communication system supporting sidelink (or peer-to-peer) relay communication.

[0052] In the example shown in FIG. 1, in a UE-to-Network (or U2N) scenario where the UE 100 acts as a UE-to-Network relay UE, the UE-to-Network relay UE 100 connects UEs 101, 102, and 103 acting as remote UEs to a gNB 107. Remote UE1 101 is connected to the relay UE 100 via a PC5 hop or link or connection or interface 101a. Similarly, remote UE2 102 and remote UE3 103 have PC5 hops or links or connections or interfaces 102a and 103a with the relay UE 100, respectively. Uu hop or link or connection or interface 105a connects the relay UE 100 to the gNB 107. The PC5 connection is used for relay traffic of the remote UEs (101, 102, 103) and non-relay traffic specific to the relay UE 100, i.e., direct communication between the relay UE 100 and other remote UEs (101, 102, 103). Thus, remote UE1 101 is connected to gNB 107 via relay UE 100 by PC5 hop 101a and Uu hop 105a: for uplink communication, remote UE1 101 is the source node (or transmitting node that transmits data) and gNB 107 is the destination or target node (or receiving node that receives data) for a sidelink relay connection established between remote UE1 101 and gNB 107 by PC5 hop 101a and a second Uu hop 105a, and for downlink communication, remote UE1 101 is the destination or target node (or receiving node) and gNB 107 is the source node (or transmitting node). Similarly, remote UE3 103 is connected to gNB 107 via relay UE 100 by PC5 hop 103a and Uu hop 105a. Uu link 105b directly connects remote UE2 102 to gNB 107. Thus, this remote UE2 102 has two different communication paths between UE2 102 and the gNB 107: the first is a direct Uu link 105b and the other is an indirect path via the relay UE 100.

[0053] A connection between a remote UE (such as Remote UE1 101) and the gNB 107 may be established by establishment of a PC5 connection between Remote UE1 101 and Relay UE 100, with Remote UE1 101 being the initiator of the connection. A Uu connection between Relay UE 100 and the gNB 107 is established via RRC setup (before or after the PC5 connection is established), with Relay UE 100 being the initiator of the connection. Remote UE1 101 then initiates an RRC setup with the gNB 107 via Relay UE 100, which forwards RRC messages from Remote UE1 101 to the gNB 107 for "RRC Setup Request" and from the gNB to Remote UE1 101 for "RRC Setup Response".

[0054] In the example shown in FIG. 1, UE 100 may also be a UE-to-UE relay by connecting remote UEs 101, 102, and 103 together in a UE-to-UE (or U2U) scenario. Thus, for example, a communication path may be set up between remote UE1 101 and remote UE2 102 via relay UE 100 connecting PC5 hops 101a and 102a together. In a UE-to-UE relay, when a sidelink relay connection is established between two remote UEs, the remote UE that transmits data (e.g., packets) is identified as a source remote UE or source UE and is connected to the relay UE by a first PC5 hop or link, and the other remote UE that receives data (e.g., packets) is identified as a destination or target remote UE or destination or target UE (or receiving node) and is connected to the relay UE by a second PC5 hop or link. The source UE may be a transmitting node or transmitter that transmits packets to the destination or target UE via the relay UE and the two PC5 hops. The two direct connections (PC5 hops) between the relay UE and two other UEs (source UE and target UE) in the U2U scenario are established in the same way as the PC5 connections are established as described above for the U2N scenario. The two PC5 direct connections are established to provide a "tunneled" connection between the source UE and the target UE via the relay UE.

[0055] To set up relay traffic between a first node (remote UE) and a second node (gNB or remote UE), a sidelink relay architecture according to 3GPP TR 38.836 may be used. The user plane architecture or protocol stack is shown in Figures 2A and 2B, depicting a sidelink relay adaptation layer called SRAP. The SRAP layer is introduced between the PDCP layer and the RLC layer in extreme nodes and above the RLC layer in relay UEs. This architecture was first documented in TR 38.836 and was finally refined in 3GPP TS 38.351.

[0056] The architecture shown in Figure 2A illustrates a sidelink relay architecture for a UE-to-Network relay scenario. The architecture shown in Figure 2B illustrates a sidelink relay architecture for a UE-to-UE relay scenario. As shown in Figure 2B, the architecture is similar to that shown in Figure 2A. However, the relay UE in the case of UE-to-UE relay has two PC5 SRAP entities or layers 221 and 222.

[0057] As shown in FIG. 2A for the UE-to-Network Relay scenario, a remote UE, such as Remote UE1 101, has a PC5 SRAP layer 201 between the Uu PDCP layer and the PC5 RLC layer. In a relay UE (such as Relay UE 100), there are two SRAP layers to interface the PC5 hop 101a and the Uu hop 105a, where the PC5 SRAP layer 202 is connected to the PC5 SRAP 201 of the remote UE 101 via the PC5 hop 101a, and the Uu SRAP layer or entity 203 is connected to the Uu SRAP layer 204 on the gNB side 107 via the Uu link 105a. The remote UE 101 establishes an End-to-End Radio Bearer 205 with the gNB 107. These Radio Bearers can be Signaling Radio Bearers (SRB) or Data Radio Bearers (DRB). FIG. 2A shows, as an example, an E2E Uu DRB between a remote UE 101 and a gNB 107.

[0058] The PC5 SRAP layer 202 of the UE-to-Network relay UE 100 receives data or packets (traffic data or signaling) from the remote UE 101 in the uplink direction via or over an ingress PC5 RLC channel 206 and transmits the packets to a Uu SRAP entity 203 of the same relay 100. The Uu SRAP 203 entity maps the corresponding ingress PC5 RLC channel 206 to the egress Uu RLC channels 100b and / or 100c of the Uu link 105a. Therefore, a mapping table is required for the uplink, which is configured by the gNB 107 in the Uu SRAP entity 203 of the relay UE 100.

[0059] The mapping table takes as input the identifier of the remote UE 101 (e.g., L2-ID), the identifier of the E2E radio bearer 205 (e.g., E2E Uu DRB 205 ID), and the identifier of the ingress PC5 RLC channel (or bearer) 206, and identifies the egress Uu RLC bearer ID to which the E2E radio bearer is mapped. For example, the UE E2E bearer ID and the remote UE ID may be obtained from the header of the data packet received at the Uu SRAP entity 203. An example of an entry in the uplink mapping table with one entry configured with the Uu SRAP entity 203 is shown in Table 1 below. It will be appreciated that the mapping table is configured to have an entry for each remote UE connected to the relay UE. Table 1 TIFF2025513671000002.tif21140

[0060] On the Uu side or link 105a, different radio bearers of the same or different remote UEs may be subject to N:1 mapping and data multiplexing on Uu RLC channels 100b and 100c, as will be described in more detail below.

[0061] In the downlink direction, data or packets transmitted from the gNB 107 arrive at the relay UE 100 via the Uu link 105a. The ingress Uu RLC channels 100b and 100c in the Uu SRAP entity 203 of the relay UE 100 are mapped to the egress PC5 RLC channel 206 in the PC5 hop 101a. The corresponding packets in the downlink are sent from the Uu SRAP entity 203 to the PC5 SRAP entity 202 and transmitted to the remote UE 101 via the PC5 RLC channel 206. Therefore, a mapping table is required for the downlink and is configured in the Uu SRAP entity 203 of the relay UE 100 by the gNB 107. The mapping table requires the L2-ID, End-to-End Radio Bearer 205 ID, and ingress Uu RLC channel (or bearer) 100b and 100c ID of the remote UE 101 as input, and sends the egress PC5 RLC channel (or bearer) 206 ID to the PC5 SRAP entity 202 of the same relay UE 100. The End-to-End Radio Bearer 205 is then mapped to the egress PC5 RLC channel 206 at the PC5 hop 101a. For example, the UE E2E Bearer ID and the remote UE ID can be obtained from the header of the packet received at the Uu SRAP entity 203. An example of a downlink mapping table with one entry configured at the Uu SRAP entity 203 is shown in Table 2 below. It will be understood that the mapping table is configured to have an entry for each remote UE connected to the relay UE. Table 2 TIFF2025513671000003.tif21140

[0062] As described in 3GPP TS 38.351, each SRAP entity has a transmitter and a receiver. Via the PC5 interface 101a, the transmitter of the PC5 SRAP entity 201 in the remote UE 101 has a corresponding receiver of the PC5 SRAP entity 202 in the UE-to-Network Relay UE 100, and vice versa. Via the Uu interface 105a, the transmitter of the Uu SRAP entity 203 in the UE-to-Network Relay UE 100 has a corresponding receiver of the Uu SRAP entity 204 in the gNB 107, and vice versa.

[0063] 3 illustrates N:1 mapping between radio bearers of multiple remote UEs and Uu RLC channels 100b, 100c in a Uu link 105a of a UE-to-network sidelink relay. Remote UE1 101 connected to a gNB 107 via a relay UE 100 has two End-to-End radio bearers 101b and 101c that are mapped to different PC5 RLC channels 206 (206a and 206b, respectively) at the PC5 hop 101a and to different Uu RLC channels 100b and 100c at the Uu hop 105a according to the gNB configuration of the Uu SRAP entity 203 of the relay UE 100 (e.g., according to a mapping table configured in the Uu SRAP entity 203 of the relay UE 100 by the gNB 107). Similarly, remote UE3 103 has an End-to-End radio bearer 103b established between remote UE3 103 and the gNB 107. This E2E RB 103b is mapped to a PC5 RLC channel (206d) at PC5 hop 103a and to a Uu RLC channel 100c at Uu hop 105a according to a mapping table configured by the gNB 107 in the Uu SRAP entity 203 of the relay UE 100. The remote UE2 102 has one end-to-end radio bearer 102 that is mapped to a PC5 RLC channel (206c) at PC5 hop 102a and to a Uu RLC channel 100b at Uu hop 105a. As shown in FIG. 1, the remote UE2 has two different paths, a first Uu path 105b is a direct path with the gNB 107 and a second path is a path via the relay UE 100 with two hops 102a and 105a corresponding to PC5 and Uu hops respectively.

[0064] As mentioned above, the mapping table of the Uu SRAP entity 203 maps these E2E RBs to corresponding PC5 RLC channels 206a to 206d and Uu RLC channels 100b, 100c.

[0065] 3 also illustrates a 1:1 mapping between the UE-to-Network Relay Radio Bearers 101b, 101c, 102b, 103b and the PC5 RLC channels 206a-d. The E2E RBs 101b, 101c, 102b, 103b are mapped to the PC5 RLC channels 206a, 206b, 206c, 206d at the PC5 interfaces 101a, 102a, 103a, respectively. Since N:1 bearer mapping is supported in the Uu SRAP 203 of the relay UE 100, the PC5 RLC channels 206a and 206c are mapped to the same Uu RLC channel 100b, and the remaining PC5 RLC channels 206b and 206d are mapped to the second Uu RLC channel 100c of the Uu link 105a, as shown in FIG. 3. An N:1 mapping may exist for upstream (uplink) and downstream (downlink) packets or traffic.

[0066] In the case of UE-to-UE relay as shown in FIG. 4, the mapping is performed in two PC5 hops. In other words, in an example scenario where Remote UE1 101 communicates with Remote UE2 102 via Relay UE 100, the mapping is performed in PC5 hop 101a between Remote UE1 101 and Relay UE 100, and in PC5 hop 102a between Relay UE 100 and Remote UE2 102. N:1 mapping is supported by the PC5 SRAP entity of the source UE (e.g., SRAP entity 201 of Remote UE1 101) for mapping between Remote UE SL Radio Bearers and PC5 RLC channels for relay (e.g., first PC5 hop 101a) as agreed in the Rel-17 Work item. For example, a source UE (e.g., Remote UE1 101) may have one connection to two different destination or target UEs (e.g., Remote UEs 102 and 103). In this case, if the bearers of the two destinations are mapped to the same RLC channel, N:1 mapping may be applied. The PC5 SRAP entity (e.g., SRAP entity 222 of relay 100) of the second PC5 hop 102a supports N:1 bearer mapping between multiple ingress PC5 RLC channels on the first PC5 hop and one egress PC5 RLC channel on the second PC5 hop. For example, if two source UEs (remote UEs 101 and 103) have connections to the same destination or target UE (e.g., remote UE 102), the relay UE may apply N:1 mapping by mixing the bearers of each source UE to the same RLC channel to reach the same destination or target UE. The second PC5 SRAP entity 222 operates similarly to the Uu SRAP entity 203 in the UE-to-Network relay case.

[0067] In the case of UE-to-UE relay as shown in FIG. 4 and in the example scenario where remote UE1 101 communicates with remote UE2 102 via relay UE 100, multiple SL radio bearers may be mapped to the same PC5 RLC channel in the first PC5 hop 101a, since SL radio bearers 101b, 101c are mapped to PC5 RLC channel 206a. The second PC5 SRAP entity 222 of relay UE 100 may map multiple ingress PC5 RLC channels onto one egress PC5 RLC channel 102c in the second PC5 hop 102a. Thus, corresponding SL radio bearers are mapped in the PC5 SRAP entities 201 and 222 of the two hops. The mapping may be performed using a mapping table in a similar manner as described above for U2N. For example, a mapping table such as Table 3 may be used, as described below. Table 3 TIFF2025513671000004.tif21143

[0068] As explained in the introduction, various factors such as interference, and / or high QoS traffic, and / or propagation environment, and / or UE mobility may cause link problems in links of a sidelink relaying deployment or system (such as that shown and described above with reference to FIG. 1 and related figures). The link problems may be congestion, link degradation, or link failure and may occur at one or more of the PC5 hops 101a, 102a, 103a, or the Uu hop 105a. Congestion is detected by monitoring the buffer status of the relaying UE 100. For example, the status of the Tx RLC buffer of the relaying UE 100 may be monitored and congestion may be detected when the amount of data in the buffer reaches a certain threshold (similar to the process of generating a Buffer Status Report (BSR) as described in TS 38.322-5.5). Link degradation is detected when the quality of the link becomes weak (e.g., when the signal strength reaches a certain threshold) and the relaying UE should notify the affected nodes of the possible link failure. A link failure (e.g., Radio Link Failure (RLF)) is detected when the link becomes unresponsive after a threshold number of retransmissions or timer expiration.

[0069] Since various types of link problems may occur, such as congestion, link degradation, link failure, transient or long-term link problems, etc., an objective of an embodiment of the present invention is to provide a mechanism for a relay UE node to detect a link problem and transmit link problem feedback information based on the detected link problem. The relay UE node may transmit the link problem feedback information to one or more nodes affected by the detected link problem, and / or to all nodes currently connected to the relay UE node, and / or to one or more nodes within the coverage area of ​​the relay UE node (e.g., in the vicinity of the relay UE node). For example, one or more communication flows affected by the detected link problem may be identified, and the type of link problem and the cause of the link problem may be identified so that nodes related to the one or more communication flows affected by the detected link problem (e.g., affected nodes performing packet transmission and / or reception) can be notified. The communication flows may be data or control flows of relay data or packets corresponding to one or more radio bearers and / or links (one or more E2E radio bearers, one or more RLC bearers, one or more RLC channels, one or more PC5 links, one or more Uu links, etc.). Thus, a communication flow affected by a detected link problem may include a communication flow having a corresponding E2E radio bearer, or one or more RLC bearers, or one or more RLC channels, or one or more PC5 links, or one or more Uu links, that are affected by the link problem. The relay UE node determines the affected nodes and notifies at least one of the affected nodes. For example, the relay UE node notifies (e.g., transmits link problem feedback information) the affected node determined to be a source node (e.g., configured to transmit data) and / or notifies the affected node determined to be a destination node or target node (e.g., configured to receive data).If a sidelink relay connection is established between a source node, a relay node, and a destination node, the node associated with the affected communication flow may be the source node (e.g., source UE) and / or the destination (or target) node (e.g., destination or target UE) associated with the affected communication flow (e.g., the detected link problem is associated with at least one of a first link between the source node and the relay node, and a second link between the destination node and the relay node).

[0070] Consider three example scenarios where nodes affected by a detected link problem are notified of the link problem: 1. Link problem feedback is provided as notification to affected nodes 2. In relay (re)selection feedback, the relay UE informs the remote UE of the type of link problem and triggers relay (re)selection, and optionally the relay UE releases its PC5 link with the remote UE 3. Link status change feedback to inform affected nodes that the status of the corresponding link has changed (failed or recovered).

[0071] (Link Problem Feedback) As explained above, the relay UE 100 monitors its internal buffers to detect congestion. As explained in the architecture diagrams (FIGS. 2A and 2B), the SRAP entity sits just above the RLC layer, allowing the relay UE 100 to identify congestion on a particular RLC channel. Once congestion is detected by the relay UE in one or more RLC channels, the relay UE 100 analyzes the mapping table to obtain correspondence to the affected E2E bearers, ingress RLC channels, and affected nodes, and creates link problem feedback (e.g., identifying one or more communication flows that are affected by the detected link problem).

[0072] In the case of downlink communication (UE-to-Network (U2N) relaying scenario), i.e., an example of congestion occurring when the sender or source node is a gNB 107 as shown in FIG. 3, the relaying UE 100 detects congestion in the PC5 RLC channel 206a. Based on the mapping table of the Uu SRAP layer 202 (see Table 2 for downlink, as described above), the relaying UE 100 determines that the ID of the corresponding ingress Uu RLC channel 100b mapped to the egress PC5 RLC channel 206a and the ID of the E2E radio bearer corresponding to Remote UE 1 DRB1 101b of Remote UE1 101 are affected by a congested link problem (e.g., Remote UE 1 DRB1 101b and Uu RLC channel 100b are communication flows or paths affected by a link problem related to the congestion of the PC5 RLC channel 206a). The relay UE 100 creates or generates a congested link problem feedback (e.g., link problem feedback information) including a Uu RLC channel ID and an E2E Radio Bearer ID (e.g., to identify one or more communication flows or paths affected by the link problem). The link problem feedback is sent from the relay UE 100 to the gNB when the sender (gNB 107) is affected by the congested link problem. In this example, due to the 1:1 mapping between E2E radio bearers and the congested PC5 RLC channel 206a, the congestion occurs only on a single E2E Radio Bearer (DRB1 of remote UE1) 101b, and therefore the QoS flows reserved on this Radio Bearer are congested.

[0073] 3, in an example where congestion occurs in uplink communication (UE-to-Network relaying scenario), i.e., when remote UEs 101, 102, and 103 are senders (e.g., source or transmitting nodes sending packets to relay UE 100 for relay to gNB 107), relay UE 100 detects congestion on Uu RLC channel 100b. In that example, multiple E2E Radio Bearers (e.g., 101b and 102b) and corresponding ingress PC5 RLC channels (e.g., PC5 RLC channels 206a and 206c) are mapped to the same congested egress Uu RLC channel 100b (e.g., remote UE 1 DRB1 101b and remote UE 2 DRB1 and PC5 RLC channels 206a and 206c are communication flows or paths affected by link issues related to congestion on Uu RLC channel 100b). Then, based on the mapping table (see Table 1 for uplink above) of the Uu SRAP layer 203, the relay UE 100 determines that the IDs of the corresponding ingress PC5 RLC channels 206a and 206c that are mapped to the egress Uu RLC channel 100b and the E2E Radio Bearer IDs corresponding to Remote UE1 DRB1 101b (encapsulated in PC5 RLC channel 1 206a) of Remote UE1 101 and Remote UE2 DRB1 102b (encapsulated in PC5 RLC channel 3 206c) of Remote UE2 102 are affected by the congestion link problem. The relay UE 100 generates congestion link problem feedback (e.g., link problem feedback information) including the PC5 RLC channel IDs and the E2E Radio Bearer IDs (e.g., to identify one or more communication flows or paths that are affected by the link problem). When the relay UE 100 determines that multiple nodes (UE1 101 and UE2 102) are affected by the congested link problem, link problem feedback is sent from the relay UE 100 to these affected nodes.To reach the affected nodes, the relaying UE 100 may transmit the congested link problem feedback in a broadcast, multicast, or groupcast manner if there is a group address that includes these affected nodes (the creation of a group is outside the scope of this specification). Alternatively, the relaying UE 100 may transmit the congested link problem feedback individually (unicast) to each affected node. In another alternative, the relaying UE 100 may create one congested link problem feedback dedicated to each affected node, i.e., containing only information related to the affected node instead of information related to all affected nodes, and transmit this dedicated congested link problem feedback in a unicast manner to the affected nodes.

[0074] As shown in FIG. 4, in an example where congestion occurs in a UE-to-UE (U2U) relay case of communication from UE1 101 to UE2 102 and communication from UE3 103 to UE2 102, each relayed by a relay UE 100, the relay UE 100 detects congestion in the PC5 RLC channel 102c. The relay UE 100 determines based on the mapping table of the PC5 SRAP layer 222 (see Table 3 for U2U case above) that the IDs of the corresponding ingress PC5 RLC channels 206a and 206d mapped to the egress PC5 RLC channel 102c and the IDs of the E2E Radio Bearers corresponding to Sidelink Data Radio Bearer 1 (SL DRB1) and SL DRB2 of Remote UE1 (101b and 101c, respectively) encapsulated in PC5 RLC channel 1 206a and SL DRB1 103b of Remote UE3 103 encapsulated in PC5 RLC channel 4 206d are affected by the congested link problem (Remote UE1 SL DRB1 101b, Remote UE1 SL DRB2 101c, and Remote UE3 SL DRB1 103b, and PC5 RLC channels 206a and 206d are affected by the congested link problem). The relay UE 100 generates a congestion link problem feedback (e.g., link problem feedback information) including the PC5 RLC channel ID and the E2E Radio Bearer ID (e.g., to identify one or more communication flows or paths affected by the link problem). When the relay UE 100 determines that multiple nodes (UE1 101 and UE3 103 - the source nodes in this case) are affected by the congestion link problem, the link problem feedback is transmitted by the relay UE 100 to these affected nodes. To reach the affected nodes, the relay UE 100 may transmit the congestion link problem feedback in a broadcast manner or in a groupcast manner if an address of a group exists that includes these affected nodes (the creation of the group is outside the scope of this specification).Alternatively, the relay UE 100 may send (unicast) the congested link problem feedback to each affected node individually. In another alternative, the relay UE 100 may create one congested link problem feedback dedicated to each affected node (i.e., containing only information relevant to the affected node instead of information relevant to all affected nodes) and send this dedicated congested link problem feedback to the affected nodes in a unicast manner.

[0075] As shown in FIG. 4, in an example where congestion occurs in a UE-to-UE relay case of communication from UE2 102 to UE1 101 and communication from UE2 102 to UE3 103, each relayed by the relay UE 100, the relay UE 100 detects congestion in the PC5 RLC channel 206d. Based on the mapping table of the PC5 SRAP layer 222 (see Table 3 for U2U case above), the relay UE 100 determines that the ID of the corresponding ingress PC5 RLC channel 102c mapped to the egress PC5 RLC channel 206d and the ID of the E2E Radio Bearer corresponding to the SL DRB1 103b of the remote UE3 103 encapsulated in the PC5 RLC channel 4 206d are affected by the congestion link problem (e.g., the remote UE3 SL DRB1 103b and the PC5 RLC channel 102c are the communication flow or path affected by the link problem related to the congestion at the PC5 RLC channel 206d). The relay UE 100 creates the congestion link problem feedback (e.g., link problem feedback information) including the PC5 RLC channel ID and the E2E Radio Bearer ID (e.g., for identifying one or more communication flows or paths affected by the link problem). When the relay UE 100 determines that UE2 102 is affected by the congested link problem, it sends link problem feedback to the affected node, which in this case is the source node. To reach the affected node, the relay UE 100 may send the congested link problem feedback in a broadcast, groupcast, or unicast manner, as described above.

[0076] If the relay UE 100 broadcasts the congested link problem feedback, it may be received by all UEs in the vicinity of the relay UE 100, and may inform all UEs that the relay UE has some problem to reach a certain UE. This information may be useful as a criterion for relay selection.

[0077] In one example, when a relay UE node detects a link problem in a wireless communication system (e.g., as shown in FIG. 1), in response to the detection of the link problem, the relay UE node generates link problem feedback information for the detected link problem, including information for identifying a type of the detected link problem, and transmits the link problem feedback information in a discovery message. In another example, when a relay UE node detects a link problem in a wireless communication system (e.g., as shown in FIG. 1), in response to the detection of the link problem, the relay UE node may stop transmitting one or more discovery messages. That is, the relay UE node may modify (e.g., stop) a discovery process performed at the relay UE node to stop transmitting announcement messages (for discovery model A defined in 3GPP TS 23.303 for LTE or TS 23.304 for 5G systems, V17.1.1) or any response messages (for discovery model B defined in 3GPP TS 23.303 for LTE or TS 23.304 for 5G systems, V17.1.1). Due to the stop of sending discovery messages, UEs in the vicinity of the relay UE node (e.g., relay UE 100) will not receive information from the relay UE node and will not consider the relay UE when performing relay (re)selection. For example, if a remote UE acting as a discoverer UE sends a discovery request message to discover a relay UE node (e.g., in response to a trigger event), the remote UE will not receive a response message if the relay UE node stops sending discovery messages. In response to not receiving a message in response to the discovery request message, the remote UE performs an action. The remote UE may start a timer upon sending the discovery request message and perform an action if no response message is received within a certain time period determined by the timer. The discovery request message may be sent by broadcast, unicast, or groupcast.The actions may include performing a (re)selection or discovery process for another relay UE node, or determining that there is (e.g., currently) no available relay in the vicinity of the remote UE node. Different types of link problems may include congestion, link degradation, Radio Link Failure (RLF), short / transient or long-term link problems. The discovery message may be autonomously broadcast by the relay UE in the usual manner of discovery model A, or it may be a discovery message sent back by the relay UE in response to a request from a discoverer UE intending to associate with the relay UE (as defined in TS 23.303 or / and TS 23.304). In the latter case, the discoverer UE may indicate in the discovery request message its interest in the status of the requested relay UE, e.g., link and connectivity with other UEs. The discovery message may be received by UEs in the vicinity or coverage area of ​​the relay UE. The information for identifying the type of link problem may include an identifier for identifying the type of link problem. The information may also include reason / context information to indicate the reason or context of the detected link problem. The identifier may be a reason ID that only indicates the type of link problem, as described below, or may be a reason ID that indicates both the type of link problem and the reason or context of the link problem, as described below (see also Tables 4 and 5 for examples of reason IDs).

[0078] The above example assumes that congestion is detected at the egress RLC channel, for example by monitoring the amount of data in the Tx RLC buffer. In an alternative embodiment, monitoring may be performed at the RX RLC buffer of the relay UE, and then congestion is detected at the ingress RLC channel, and the relay UE skips the step of mapping from the egress RLC channel to the ingress RLC channel as described in the above example. As another alternative, the relay UE may use Channel Busy Ratio (CBR) and / or Channel occupancy Ratio (CR) metrics (as defined in TS38.215) to infer congestion and create the congestion link problem feedback. In such a case, the link problem feedback information may be transmitted by broadcast (in this case the relay UE does not need to identify the affected node). Alternatively, CBR / CR reports may be provided from different nodes to the relay UE, and from the CBR / CR reports the relay may identify the affected node to which the link problem feedback information should be transmitted. In another example, the relay UE itself may perform CBR / CR measurements and from the measurements identify the resource pool (e.g., frequency band) where the link problem is occurring. Since the relay UE knows the frequency on which the PC5 link is established to each remote UE, it may infer the identity of the affected node based on the resource pool or frequency where the problem is occurring. If excessive CBR or CR is detected on a given link, this link may be considered to be experiencing link problems. In that case, it is treated in the same way as RLF is treated.

[0079] In an additional embodiment, the relay UE may detect congestion on a particular E2E Radio Bearer by inspecting the SRAP header of each packet at the SRAP layer to obtain the packet's Bearer ID and monitoring the amount of data associated with each E2E Radio Bearer by determining the amount of data rate of each E2E Radio Bearer on the RLC channel. The relay UE may detect congestion on an E2E Radio Bearer if it determines that the data rate of the E2E Radio Bearer on the RLC channel is too high.

[0080] In the case of a downlink in U2N relay between a gNB and a remote UE, the remote UE may be notified of a link problem occurring at a PC5 hop or a Uu hop or an E2E radio bearer by a relay UE that is not a source node (e.g., a transmitting node that transmits packets to the relay UE 100 for relay to another node) but transmits link problem feedback information to the remote UE (as a receiving node) to identify the link problem and the communication flow affected by the detected link problem. In other words, the relay UE may transmit link problem feedback information of the detected link problem to the source node and / or destination node. The remote UE configured as a destination node does not wait for packets from the gNB and does not request retransmission until the link is restored.

[0081] In case of U2U relaying, link problem feedback may be sent to the source UE and / or destination remote UE to inform them of link problems in reception.

[0082] In other words, in case of U2N and / or U2U relaying, the relay UE may send link problem feedback information to the source node and / or destination node of the sidelink relay connection affected by the link problem. The relay UE may send the link problem feedback information to one or more other nodes connected to the relay UE. In another example, the relay UE may send the link problem feedback information via broadcast to all UEs in the vicinity or coverage area of ​​the relay UE 100 (e.g., UEs not yet connected to the relay or UEs connected to another relay).

[0083] Congestion can occur at the link level, either at the PC5 hop or at the Uu hop, and therefore the source node or sender (which may also be the destination node or receiver, as mentioned above) can be informed of link problems by the relaying UE according to different example scenarios: -If congestion occurs at PC5 hop 101a, The sender or source node is the remote UE1 101: the link problem feedback information is sent from the relay UE 100 to the remote UE1 101 and includes the L2-ID of the remote UE1 101 (e.g. in its information element, as described below with reference to FIG. 5). Based on the link problem feedback information, the remote UE1 101 therefore understands that congestion is occurring across the PC5 hop 101a. In order to identify which radio bearer is affected in case there are multiple PC5 links between the remote UE1 101 and the relay UE 100, the E2E Radio Bearer 101b and 101c IDs are included in the link problem feedback information The sender or source node is the gNB 107 in case of U2N relay (or the remote UE, e.g. UE2 102, in case of U2U relay). Link problem feedback information is sent by the relay UE 100 to the source node (optionally to the destination node or receiver) with the L2-ID of the remote UE1 101 connected to the PC5 hop 101a. The E2E Radio Bearer 101b and 101c IDs are also identified by the Uu SRAP entity 203 to the gNB 107 to identify the affected radio bearers at the PC5 hop 101a in case of U2N relay. In case of U2U relay, the link problem feedback is sent to the source node (e.g. source remote UE2 102) (which can also be optionally sent to the destination node or receiver, e.g. destination remote UE UE1 101)) with the L2-ID of the source remote UE and the affected SL Radio bearers IDs. The PC5 SRAP entity in the relaying UE provides the SL Radio bearers ID which is mapped to the PC5 RLC channel as described above. - In other words, if a problem occurs on a PC5 link, the link affected by the problem is identified by the L2-ID of the remote UE connected to this relay UE - In the case of U2N relay, congestion occurs at Uu hop 105a The sender or source node is the remote UE1 101. The link problem feedback information is sent from the relay UE 100 to the source node, for example, identifying the L2-ID of the relay UE 100 as the identification of the Uu link. In another embodiment, a link problem without any L2-ID value or default value indicates a problem on the Uu link. The remote UE1 101 understands that congestion occurs on the Uu link 105a (U2N relay). The overall E2E Radio Bearer is congested on the Uu hop 105a (U2N relay). Thus, in case of U2N relay, the Uu SRAP entity 203 identifies the E2E Radio Bearer IDs 101b and 101c of the affected remote UE1 101 in the link problem feedback. The sender or source node is the U2N relay gNB 107. The link problem feedback information sent to the source node (and optionally to the destination node or receiver) identifies, for example, the L2-ID of the relay UE 100 (as the identity of the Uu link) and a list of Radio bearers (101b, 101c, 102b, 103b) affected by the link congestion.

[0084] In the above example, the identification of the link experiencing the problem is replaced in a more compact way by the use of the L2-ID (usually used to identify the UE) to inform of the affected RLC channels in the congested link problem feedback. The node receiving the congested link problem feedback then determines the affected RLC channels. For example, if a problem occurs on a Uu link, the link affected by the problem can be identified by the L2-ID of the relay UE, and in another example, a link problem without a L2-ID value or a default value indicates a problem on the Uu link. In another example, if a problem occurs on a PC5 link, the link affected by the problem can be identified by the L2-ID of the remote UE connected to this link. In another example, the identification of the link experiencing the problem (i.e., the use of a link identifier, ID, information element) can be replaced by a list of affected radio bearers and / or a list of affected RLC channels.

[0085] Link degradation is a precursor to link failure and informs the affected node of a possible link failure. The link failure may occur at the PC5 hop or the Uu hop and may affect a large amount of data traffic at this hop. In other words, in this particular scenario, the link problem feedback sent by the relay UE indicates to the affected node a link degradation with a possible link failure.

[0086] Link failure occurs following link degradation. In one embodiment of the present invention, link failure is detected when the link quality (e.g., SNR or RSRP) falls below a critical threshold level. In another embodiment, link failure is detected when the link degradation fails to recover (e.g., link degradation is detected for a predetermined period of time on a given link). In another embodiment, link failure is detected by timer expiry and / or counter thresholds. For example, as defined in TS38.331, the use of timer T310 plus counter N310 indicating the number of "out of sync" received from the physical layer may trigger a radio link failure. Information to be included in link problem feedback for signaling link failure or link degradation (e.g., information for identifying one or more communication flows or paths affected by the link problem) is described below with reference to FIG. 5.

[0087] On the other hand, link problem feedback for link degradation (including link failure) in U2N relaying is only sent by relay UE to uplink remote UE (e.g. source or sender node) when Uu link degradation occurs. In case of U2U relaying, link problem feedback is sent by relay UE to remote UE when other remote UE suffers link quality degradation. For example, if link degradation occurs on the second PC5 hop between relay UE and other remote UE acting / functioning as destination or target UE, the second hop between relay and destination UE is hidden from remote UE acting / functioning as source remote UE (connected to relay UE on the first PC5 hop), and source UE is notified with link problem feedback reporting link quality degradation of the second PC5 hop. With reference to FIG. 1, as an example, remote UE1 101 is designated as source remote UE (or source UE) connected to relay UE 100 by the first PC5 hop 101a and communicates with remote UE2 102 designated as destination or target remote UE (or target UE). Target UE2 102 is connected to relay UE 100 by a second PC5 hop 102a. When source UE1 101 is sending packets to target UE2 102, the second PC5 hop 102a is "hidden" from source UE1 101, and then when there is link quality degradation on the second PC5 hop 102a, source UE1 101 is sent link problem feedback information by relay UE 100.

[0088] In order to distinguish between different link problems, in one example and as described with reference to FIG. 5, the link problem feedback information may further include information for identifying the type of the detected link problem (e.g., whether the link problem is of any type: congestion, or link degradation, or RLF, or transient / short-term, or long-term link problem). The information may include a reason identifier (ID) for identifying the type of the detected link problem. In one example, the reason ID may represent a reason or context of the detected link problem in addition to identifying the type of the detected link problem. For example, the reason ID may identify that the link problem is of any type: congestion on PC5 hop, congestion on Uu hop, congestion on E2E Uu RB, congestion on remote UE E2E RB, congestion on Uu RLC channel / bearer, congestion on PC5 RLC channel / bearer, link degradation, link level congestion (on PC5 hop or Uu hop), RLF. In an example arrangement, the reason ID is included in the link problem signaling message that identifies the type of the announced link problem at the corresponding hop. The reason identifier may be a number or other identifier to distinguish between different types and / or reasons of link problems. For example, a reason ID equal to 1 indicates congestion of the radio bearer, and a reason ID equal to 5 indicates congestion of the RLC channel at the PC5 hop. To provide more information about the link problem, a reason ID equal to 1 may indicate congestion of the radio bearer due to a new QoS being added to the E2E DRB. For other examples of reason IDs, see Tables 4 and 5 below. In another example, the information for identifying the type of the detected link problem may include a link problem type identifier (e.g., a PDU type identifier) ​​that identifies the type of the detected link problem (e.g., whether the link problem is a congestion, or link degradation, or RLF, or a transient, or long-term (e.g., permanent), or event link problem). In this case, the link problem feedback information may also include a reason identifier (ID) indicating the reason or context of the detected link problem, as described above.Additional information may be included to provide better visibility into the status of the relay UE and affected nodes and to properly inform the affected nodes of link issues (e.g., see the discussion below with reference to FIG. 5 regarding additional information elements).

[0089] The link problem feedback information may be transmitted in a link problem signaling message for signaling or indicating a link problem.

[0090] (Relay (re)selection feedback) After detecting the link problem, the relay UE (100) may decide to send a relay (re)selection trigger or relay (re)selection signaling to the remote UEs (101, 102, 103) connected to the relay UE (one or more or all of the remote UEs connected to the relay UE, if there is more than one remote UE connected to the relay UE). The purpose of sending the relay (re)selection signaling is to instruct the remote UE to switch to another relay UE. For example, if the relay UE detects congestion on an RLC channel with low priority QoS due to a large amount of data transmitting with high priority QoS, the relay UE may consider that the remote UE affected by the congestion should move to another relay UE. In this example, the relay (re)selection signaling message includes information (such as a reason ID) corresponding to the congestion or congestion of a low priority flow. In another example, if the relay UE detects a link failure on a Uu hop (between the relay UE 100 and the gNB 107), the relay UE may send a relay (re)selection signaling message including a reason ID related to the link failure. Thus, the reason ID may identify the type of link problem (e.g., whether the link problem is one of the link problem types: congestion, link degradation, or RLF) and / or the context or reason of the link problem. The reason ID information may be split into two parts: a main part containing the type of link problem or, more generally, the event that triggers the relay (re)selection (radio link failure, Uu radio link failure, PC5 radio link failure, congestion, relay handover, internal problem (low battery, CPU utilization, user change, relay capability disabled, etc.), or other event) and an optional part for additional context information. This additional information may indicate whether the problem is permanent (long-term) or transient (short-term). In case the reason ID indicates a radio link failure, this additional information may indicate the nature of the affected link, i.e., the Uu link or the PC5 link. Splitting the reason ID allows the relay (re)selection signaling message to be more compact and allows the relay UE to add additional information if necessary. Examples of reason IDs are shown in the table below: Table 4 TIFF2025513671000005.tif44140Table 5 TIFF2025513671000006.tif76140

[0091] The reason IDs in the above table are provided for illustrative purposes. As explained above, the reason IDs may be grouped into a single range of IDs instead of two ranges of reason IDs.

[0092] In the above example, the remote UE receiving the relay (re)selection signaling is responsible for releasing the connection with the relay UE to perform relay (re)selection. In some cases, the remote UE prefers to maintain the connection with the current relay UE because there are no other relay UE candidates available in the vicinity or because the relay UE maintains the connection with the relay as a backup path and reroutes data on another path (such as a direct connection with the gNB).

[0093] In another example, the relay UE may determine to release the remote UEs connected to the relay UE (one or more or all of the remote UEs connected to the relay UE, if there is one or more remote UEs connected to the relay UE) after detecting a link problem. Thus, when the relay UE determines to release the remote UE, the relay UE transmits link problem feedback information to the remote UE, the link problem feedback information including flow information for identifying one or more communication flows and information indicating link problem feedback information related to the relay (re)selection feedback. The link problem feedback information may be transmitted in a link problem signaling message configured to indicate relay (re)selection. The link problem signaling message for indicating relay (re)selection identifies a link problem type in a reason ID, requests or requests release of the PC5 link with the remote UE, and triggers relay (re)selection. As an example, if link congestion occurs at Uu hop 105a of the sidelink relay connection between remote UE1 101 and gNB 107, whether for uplink or downlink traffic, the relay UE 100 may deduce that it is better to release that remote UE (remote UE1 101) so that the released remote UE can (re)select another relay UE that does not have link issues. This step may help to mitigate the link issues on the relay UE's side.

[0094] A link problem signaling message or a relay (re)selection message for signaling a relay (re)selection may include all or some of the information elements described in FIG. 5. For example, a link problem signaling message for indicating a relay (re)selection may include link problem feedback information including information for identifying a type of a detected link problem (e.g., different types of link problems including handover, congestion, link degradation, and Radio Link Failure (RLF)). The information for identifying a type of a detected link problem may include a reason identifier or another identifier for identifying a type of a detected link problem. The information may also include reason / context information for indicating a reason or context of the detected link problem. In addition to identifying a type of link problem, the reason ID may indicate a reason or context of the detected link problem as described above.

[0095] In one example, when a relay UE node detects a congested link problem in a wireless communication system (e.g., as shown in FIG. 1), in response to the detection of the congested link problem, the relay UE node generates link problem feedback information including information for indicating that a congested link problem has been detected, and transmits the link problem feedback information in a relay (re)selection signaling or a relay (re)selection message. The relay (re)selection signaling may be transmitted to a remote UE affected by the congested link problem, and may be transmitted to all remote UEs connected to the relay UE. The information for indicating the congested link problem may include an identifier that identifies a congestion type of the link problem, and may also include reason / context information for indicating a reason or context of the congestion. The identifier may be a reason ID that only indicates a congestion type, as described above, or may be a reason ID that indicates both a congestion type and a reason or context of the congestion, as described above (see also Tables 4 and 5 for examples of congestion reason IDs).

[0096] In another example, the link problem signaling message for indicating relay (re)selection may include link problem feedback information including link problem flow information (e.g., flow identifiers of the affected radio bearers and radio links) for identifying one or more communication flows affected by the detected link problem, as described above with respect to link problem feedback.

[0097] (Link Status Change Feedback) Upon detecting the link problem, the relay UE 100 may determine whether the link problem is a transient / short-term link problem (e.g., the link has recovered or will recover soon) or a long-term link problem (e.g., the link problem worsens, resulting in the link problem being unable to be recovered (i.e., a permanent link problem)). For example, the relay UE may set a timer or start a counter to determine whether the link will recover (e.g., respond). If the link does not respond after multiple retransmissions beyond the timer expiration or counter threshold, a link failure (e.g., Radio Link Failure (RLF)) is detected. If the relay UE determines that the link has recovered or cannot be recovered, the relay UE may transmit (e.g., to the affected node) link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem, further including information for identifying the type of the detected link problem (e.g., link degradation, RLF...), and may include information indicating that the link problem feedback information is associated with the link status modification feedback information. The link status change feedback information may announce the link recovery or the worsening link problem.

[0098] The link status modification feedback message may include all or some of the information elements described in Figure 5. For example, a link problem signaling message for indicating link status change feedback includes link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem (e.g., flow identifiers of the affected radio bearers and radio links, as described above with respect to the link problem feedback scenario).

[0099] FIG. 5 illustrates an example format of a link problem signaling message according to an embodiment of the present invention.

[0100] As mentioned above, the link problem signaling message (which may be for signaling any one of link problem feedback, relay (re)selection feedback, or link status correction feedback) sent to at least one of the affected nodes includes link problem feedback information of the detected link problem. In one example, the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. Thus, the link problem signaling message sent to the affected nodes may include an information element for providing link problem feedback information for identifying one or more communication flows affected by the detected link problem. Additional information elements are optionally added to provide better visibility (e.g., more details) of the link problem. Some of the additional information elements may depend on information provided in other information elements.

[0101] The link problem signaling message may consist of six information elements (IEs), as shown in Figure 5. The order of the IEs shown in Figure 5 is for illustrative purposes only. For example, the positions of IE 503 and IE 504 may be swapped, as shown in Figures 11A, 11B, 11C, and 11D.

[0102] Information element 501 is a PDU type information element, and the information provided in this information element 501 identifies or indicates the type of feedback to be sent to the affected node in the link problem signaling message. The PDU type of feedback may be link problem feedback, relay (re)selection feedback, or link status correction feedback, as described above. The type of link problem signaling message serves to indicate to the node receiving the link problem signaling message one or more actions to take. In another example, PDU type information element 501 may include information to identify the type of event or detected link problem (e.g., whether the link problem is of the type congestion, link degradation, RLF, or any of the temporary or long-term link problems). For example, PDU type IE 501 may include a number as shown in Table 4 above, representing one of the different types of link problems or events.

[0103] The link problem feedback type of the link problem signaling message provides notification to the affected node about the link problem, identifies the affected communication flow (e.g., affected bearer or link or channel) and may also provide notification about the type of link problem (e.g., congestion, link degradation, RLF). The link problem feedback type may also provide notification of the reason or context of the detected link problem. The link problem signaling message of the relay (re)selection feedback type provides notification of relay (re)selection feedback to the affected node to trigger the remote UE to (re)select another UE as the relay UE after the release of the PC5 link with the relay UE. The link problem signaling message for relay (re)selection may indicate the type of the detected link problem (e.g., congestion if a congestion link problem is detected) and may provide notification of the reason or context of the detected link problem. In this case, flow information identifying the affected communication flow may be optionally provided in the signaling message. In another example, a link problem signaling message of a relay (re)selection feedback type may identify the affected communication flow (e.g., the affected bearer or link) and identify the link problem type (e.g., congestion, link degradation, RLF) causing the relay (re)selection. A link problem signaling message of a link status change feedback type may provide a notification to the affected node signaling a link status change feedback to inform the affected node of the change that occurred in the link problem. For example, in addition to identifying the affected communication flow, the link problem signaling message may provide information indicating that the link problem has been alleviated (or recovered) or intensified (or worsened). The link status modification feedback may be transmitted by the relay UE after the relay UE has previously transmitted a link problem feedback type of link problem signaling message to the affected node.

[0104] The information element 502 specifies the destination ID of the link problem signaling message. Thus, the information element 502 includes the identifier (e.g., L2 ID) of the affected node. For example, considering a link failure in Uu hop 105a of the uplink traffic, the destination of the link problem signaling message is the sending remote UE1 101, whose ID is included in the information element 502. If there are multiple affected nodes and one link problem signaling message is sent for each affected node (e.g., unicast communication), the IE 502 includes a single node identifier for each affected node. If there are multiple affected nodes and one link problem signaling message is sent to all affected nodes, the IE 502 carries a list of node identifiers of all affected nodes (e.g., in case of broadcast communication) or a group identifier (e.g., in case of groupcast communication). This information in the IE 502 may be optional if it is added by another layer during the encapsulation process. For example, as described in Chapter 6.2.4 of TS38.321, the destination L2_ID is present in the MAC subheader of the SideLink Shared CHannel (SL-SCH) in the DST field.

[0105] If IE 501 indicates the type of feedback to be sent to the affected node in the link problem signaling message, information element 503 may identify the type of link problem detected and may include an identifier for identifying the type of link problem. Information element 503 may indicate the reason or context of the detected link problem. The identifier may be a reason ID that only indicates the type of link problem, as described above, or may indicate both the type of link problem and the reason or context of the link problem, as described above (see also Tables 4 and 5 for examples of reason IDs). The reason ID may be a number or other identifier to distinguish different types of link problems and / or reasons for the link problem. For example, the reason ID may identify that the link problem is one of the following types: congestion on PC5 hop, congestion on Uu hop, congestion on E2E Uu RB, congestion on remote UE E2E RB, congestion on Uu RLC channel / bearer, congestion on PC5 RLC channel / bearer, link degradation, link level congestion (on PC5 hop or Uu hop), RLF. The Reason ID may provide additional information regarding the reason for the link problem as described above. The Reason ID may also embed information related to the nature of the link problem as short-term or long-term (i.e., a link problem that lasts longer than a predefined timing threshold).

[0106] Alternatively, as described above, the PDU type information element 501 may indicate the type of problem (congestion, link failure...), and the information element 503 in this case further indicates the reason for the detected link problem (new QoS flow, low priority of the offered QoS, SNR degradation, etc.). For example, the information element 503 includes a reason ID to indicate the reason or context of the link problem, as described above (see also Tables 4 and 5 for examples of reason IDs).

[0107] The presence and meaning of the information element 504 depends on the content of the PDU type information element 501 and / or the content of the reason ID information element 503. The information element 504 may include information of the result of the link problem detection, such as the available buffer size when the link problem type is congestion, detected based on the available buffer status, and may include link quality parameters (RSRP, RSRQ, SINR, etc.) when the link problem type is link degradation, detected based on the link quality parameters. For example, if the reason ID listed in the information element 503 is related to radio bearer congestion, the information element 504 specifies the available buffer size. For example, see Figures 11A to 11E: Figures 11A and 11B show information elements of an example link problem signaling message for a congestion type link problem, Figures 11C and 11D show information elements of an example link problem signaling message for a link degradation type link problem, and Figure 11E shows information elements of an example link problem signaling message for link level congestion and RLF type link problems.

[0108] The available buffer size or link quality parameters optionally provided in the information element 504 may be replaced by other information providing an indication on the magnitude or level of the link problem, such as a criticality level. For example, the other information may inform the affected node of a criticality level that explicitly indicates the buffer status of the relay UE. For example, the criticality of the buffer size may be categorized as low, medium, and critical according to the buffer size threshold. The link quality parameters may be classified as medium, weak, and critical according to the link quality parameters evaluated. One or more of three parameters such as Reference Signal Receive Power (RSRP), Reference Signal Receive Quality (RSRQ), and Signal Interference and Noise Ratio (SINR) may be used to evaluate the link quality parameters.

[0109] Information indicating the QoS or priority reserved for the affected bearer / channel compared to the QoS or priority of other bearers / channels provided by the relay UE may be introduced in the link problem signaling message to help the affected node to make a decision depending on the service reserved for the bearer / channel. For example, if a higher QoS is provided by the relay UE than that of the affected bearer or channel, the affected node may intelligently release the established connection or attempt to reconfigure the bearer affected by the link problem. This information element may include, for example, a list of QoS / priority levels of the RLC channels provided by the relay. This information may be carried by information element 505 and may indicate the quality of service (QoS) or priority level reserved for one or more communication flows affected by the detected link problem.

[0110] The last information element 506 provides exclusively flow information for identifying one or more communication flows (e.g., bearers or links) affected by the detected link problem. For example, the flow information includes a flow identifier (ID) for identifying one or more communication flows in the information element 506, and may include one or more of a radio bearer ID (e.g., DRB / SRB ID), a Sidelink (SL) radio bearer ID (e.g., SL DRB ID / SL SRB ID), an RLC channel or bearer ID, or a link ID for identifying a link associated with the detected link problem, or a path ID (e.g., in case of a multiple relay connection of a remote UE), or a hop ID (e.g., in case of a remote UE using multiple chained relay UEs to reach a destination node). The link ID may be based on the L2_ID of the source node, and each link ID / path ID / hop ID list is shared between nodes during the connection process.

[0111] The link problem signaling messages for providing link problem feedback, relay (re)selection feedback, and link status correction feedback share the same format as in FIG. 5, with different PDU types indicated in information element 501 to indicate whether the link problem signaling message indicates link problem feedback, relay (re)selection feedback, or link status correction feedback.

[0112] The link problem signaling message has a flexible size depending on the optional information elements included and the list of bearer or link IDs inserted in information element 506 and the L2 ID inserted in information element 502 .

[0113] All or part of the above mentioned information elements may be included in different types of containers, such as MAC-CE as specified in TS 38.321, SRAP control PDU as specified in TS 38.351, PC5-RRC message as specified in TS 38.331 or PC5-S message as specified in TS 24.334. All or part of the above described information elements may be embedded in new signaling or may be additionally embedded in existing signaling.

[0114] The MAC-CE defined in TS 38.321 may be used as a container for the above link problem signaling messages. It may accommodate messages of flexible size. The link problem signaling messages are placed in the payload of the MAC-CE structure. In an alternative embodiment, the PDU type information 501 may be supported by an LCID indicating the type of MAC-CE being conveyed. As a result, new LCID values ​​may be defined for each of the above PDU types.

[0115] An SRAP (Adaptation Layer) control PDU may be used as a container for a link problem signaling message. The D / C bit, as specified in TS 38.351, indicates whether the corresponding SRAP PDU is a SRAP Data PDU or a SRAP Control PDU. The feedback may be transmitted using RRC signaling (such as PC5-RRC). The signaling message may be transmitted as an information element, which may be referred to as a link problem feedback information element.

[0116] FIG. 6A illustrates steps of a method 600 for signaling a link problem in a sidelink relay system of a wireless communication system (such as the wireless communication system illustrated in FIG. 1 and related figures) according to an embodiment of the present invention. The method 600 is performed in a relay UE node. The wireless communication system includes a relay UE node (e.g., relay UE 100 as illustrated) and a plurality of nodes (e.g., two or more remote UE nodes such as remote UEs 101, 102, 103 as illustrated, and a network node 107). The relay UE node is configured to relay data (e.g., packets) between at least one of the plurality of nodes and at least one other of the plurality of nodes. The relay UE node may be implemented in a communication device 1200 as illustrated in and described with reference to FIG. 12 below, with the method as illustrated in FIG. 6A being executed by a processing unit 1211.

[0117] As mentioned in step 601, a link problem is detected at the relay UE 100. In step 602, the relay UE generates or prepares link problem feedback information for the detected link problem. The link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. In step 603, the relay UE 100 transmits the link problem feedback information. In one example, the relay UE 100 transmits the link problem feedback information to at least one of a plurality of nodes associated with the one or more communication flows affected by the detected link problem. The relay UE 100 may identify at least one or more communication flows or paths (e.g., radio bearers or links) affected by the detected link problem so as to identify or determine at least one of a plurality of nodes associated with the one or more communication flows affected by the detected link problem (i.e., at least one affected node). For example, once a link problem is detected and an affected communication flow is identified (e.g., an affected E2E radio bearer, an RLC bearer / channel, a PC5 and / or a Uu link is identified), a mapping table may be used to identify an affected node (e.g., one or more remote UEs or gNBs), as described above with respect to the description of the link problem feedback scenario and different types of link problems. The affected node may include at least one of a source node and a destination node. For example, in a sidelink relay system, when a sidelink relay connection is established between a source node, a relay UE node, and a destination node, detecting a link problem may include detecting a link problem associated with at least one of a first link between the source node and the relay node and a second link between the destination node and the relay node, and transmitting link problem feedback information to at least one of the source node and the destination node. In one example, the relay UE 100 may transmit link problem feedback information to all nodes connected to the relay UE 100.

[0118] In one example, the flow information includes a flow identifier for identifying one or more communication flows affected by the detected link problem, which may be one of the following (e.g., based on the type of link problem): DRB ID, SRB ID, SL DRB ID, SL SRB ID, RLC bearer ID, RLC channel ID, a link ID (such as PC5 ID or Uu ID) for identifying a link associated with the detected link problem.

[0119] The link problem feedback information may further include information for identifying a type of the detected link problem (e.g., whether the link problem is one of the following types of link problems: congestion, link degradation, RLF, temporary / short-term or long-term / permanent). The information for identifying a type of the detected link problem may include a reason identifier (ID) or another identifier (e.g., PDU type) for identifying a type of the detected link problem, as described above. The information may also include reason / context information for indicating a reason or context of the detected link problem. In addition to identifying a type of the detected link problem, the reason ID may represent a reason or context of the detected link problem, as described above. For example, the reason ID may identify that the link problem is any of the following types of link problems: congestion on PC5 hop, congestion on Uu hop, congestion on E2E Uu RB, congestion on remote UE E2E RB, congestion on Uu RLC channel / bearer, congestion on PC5 RLC channel / bearer, link degradation, link level congestion (on PC5 hop or Uu hop), RLF.

[0120] The link problem feedback information may further include at least one identifier, such as an L2 ID of a remote UE or an identifier of a network node gNB, for identifying at least one node of the multiple nodes to which the link problem feedback information is to be sent, which is also called a destination ID (destination of the link problem signaling message).

[0121] The link problem feedback information may be included in a link problem signaling message transmitted by the relay UE 100. The link problem signaling message may have an exemplary format as described above with respect to FIG. 5 and FIG. 11A-FIG. 11E. In this format, flow information (e.g., a flow identifier) ​​is provided in information element 506, information for identifying the type of the detected link problem is provided in information element 503, and at least one identifier for identifying at least one of a plurality of nodes to which the link problem feedback information is to be sent is provided in information element 502 (i.e., a destination ID information element). The link problem signaling message may further include a PDU type information element 501 for indicating the type of the link problem signaling message (i.e., for example, whether the link problem signaling message is a link problem feedback type, a (re)selection feedback type, or a link status change feedback type). Optionally, the link problem signaling message also includes information indicating the QoS or priority level ensured by the relay node in information element 505. Optionally, the link problem signaling message also includes information providing notification regarding the magnitude or level of the link problem in information element 504, such as available buffer size, provided link quality parameters, or a criticality level that provides the affected node with an explicit view regarding the buffer status or link quality determined by the relaying UE 100.

[0122] The link problem signaling message may be transmitted by unicast, multicast, or broadcast communication. If the relay UE determines (using a mapping table, etc.) that only one node is affected by the detected link problem, the relay UE may use unicast to transmit the link problem feedback information directly to this node. In this case, when the link problem feedback information is transmitted in a link problem signaling message having a format as shown in FIG. 5, IE 502 contains only one identifier to identify one node. If multiple nodes are affected, multicast or groupcast may be used for the set of affected nodes if a group (with a specific address) has already been defined / created. In all cases, the link problem feedback information may be transmitted in a broadcast message, in which case the affected node may filter according to the RLC ID, bearer ID, or link ID (checking whether the ID in the message corresponds to the ID used by the node) instead of using the destination address of the message. The type of communication used (unicast, multicast, or broadcast) may also depend on the type of message (MAC CE, RRC, SRAP).

[0123] In the link problem feedback scenario described above and the example where the link problem signaling message has the format as shown in Figure 5 and Figure 11A-11E and the PDU type IE 501 indicates the link problem feedback type, the relay UE 100 sets the PDU type in the PDU type information element 501 to indicate the link problem feedback type. Then, the reason ID in the information element 503 is identified based on the link problem type (congestion, link degradation or link failure) and the corresponding bearer or link (e.g. flow ID) that is affected. The table of reason IDs described above is used to map the problem detected on the bearer or RLC channel or link to a reason. The bearer ID or RLC channel ID or link ID (e.g. flow ID) is identified according to the link problem type and added to the information element 506 of the link problem signaling message.

[0124] Available buffer size or link quality parameters (or other information indicating the magnitude of the link problem) may also be added (e.g., in information element 504) in case of congestion or link degradation problems on the bearer. Optional information elements are added as available features.

[0125] The generated link problem feedback information and additional information are then transmitted to the affected nodes in a link problem signaling message (e.g., as in step 603). The container type of the link problem signaling message is selected by the relaying UE 100 as a function of the size, the criticality of the link problem, and the type of communication (unicast, multicast, or broadcast). The container type may be one of a MAC CE container, a SRAP control PDU, RRC signaling, or PC5 signaling, as described above. The link problem signaling message may be transmitted by unicast, multicast, or broadcast based on the type of link problem detected.

[0126] Reference is now also made to Fig. 6B, which illustrates steps of a method 604 for processing link problem feedback information at an affected node in a sidelink relay system of a wireless communication system (such as the wireless communication system illustrated in Fig. 1 and related figures) according to an embodiment of the present invention. The affected node may be at least one of a plurality of nodes (e.g., remote UE or network node) affected by a link problem detected by a relay node (e.g., relay UE 100). The affected node may be implemented in a communication device 1200 as illustrated in and described with reference to Fig. 12 below, together with the method as illustrated in Fig. 6B executed by a processing unit 1211.

[0127] The link problem feedback information transmitted by the relay UE 100 is received by an affected node (e.g., a remote UE (such as remote UEs 101, 102 and / or 103) and / or a gNB 107) in step 605. The link problem feedback information received from the relay UE 100 includes flow information for identifying one or more communication flows affected by the detected link problem.

[0128] In step 606, the affected node processes the link problem feedback information to determine one or more communication flows affected by the detected link problem based on the flow information and evaluate a level of impact of the detected link problem on data communication at the node on the one or more determined communication flows. For example, the impact may extend to data transmission by the node or data reception at the node. In one example, the link problem is at least one of a plurality of different types of link problems, the plurality of link problem types including handover, congestion, link degradation, RLF, temporary / short-term or long-term / permanent link problems. The link problem feedback information may further include information for identifying a type of link problem (such as a reason ID or PDU type as described above) that may be used by the node to evaluate an impact level of the detected link problem. In addition to identifying a type of the detected link problem, the reason ID may represent a reason or context of the detected link problem as described above. The flow information may include a flow identifier for identifying one or more communication flows affected by the detected link problem as described above. The affected node may then assess the level of impact of the detected link problem by determining one or more affected communication flows from the flow information, and may perform the assessment based on the type of link problem.

[0129] In step 607, based on the assessed impact level of the detected link problem, the affected node takes an action or performs an operation at the affected node. The action or operation is performed to mitigate the impact of the detected link problem when the assessment determines that the assessed impact level reaches a certain threshold. The action or operation may include releasing links associated with one or more affected communication flows and (re)selecting relay nodes, waiting for new link problem feedback information, and adapting (e.g., restarting or resuming) transmission of data (packets) by nodes on one or more affected communication flows. It should be noted that although steps 607 and 606 are shown as separate steps, step 607 may be performed as part of the processing of step 606.

[0130] As described above, the link problem feedback information received at the node may be included in a link problem signaling message and may further include PDU type information to indicate a type of the link problem signaling message. The link problem signaling message may be one of a link problem feedback type, a (re)selection feedback type, or a link status change feedback type. The operation performed in step 607 may include performing an operation or taking an action at the node based on the type of the link problem signaling message determined based on the PDU type information and the assessed impact level of the detected link problem.

[0131] As described above with respect to step 605, the link problem signaling message is received by the affected node. After receiving the link problem signaling message, processing the link problem feedback information (e.g., as in step 606) may include identifying the PDU type from information element 501 and knowing what action to take. If it is a link problem feedback, the affected node checks about the link problem without any action being requested from the affected node. The affected node then reads the remaining information elements to know the type of link problem (whether it is bearer level, RLC channel level, or link level as specified by the reason ID). It also checks the related information element (e.g., IE 506) that corresponds to the ID of the problematic bearer or link. After collecting the information from the signaling message, the affected node starts the feedback process, which includes evaluating the extent of the link problem and its impact on transmission and the decision to take or not based on the information received in the link problem signaling message.

[0132] FIG. 7A illustrates steps of a method 700 for generating a link problem signaling message including information for indicating relay (re)selection feedback in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. FIG. 7B illustrates steps of a method 704 for processing information included in a link problem signaling message at an affected node in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. The method 700 is performed at a relay UE node, such as the relay UE 100 of FIG. 1 and related figures, and the method 704 is performed at a remote UE node affected by a link problem detected by the relay node (such as the relay UE 100). Each of the relay UE node and the affected node may be implemented in a communication device 1200 as shown in and described with reference to FIG. 12 below.

[0133] 7A, in this example, after detecting a link problem at the relay UE in step 701, the relay UE 100 evaluates the situation from its side and decides to trigger the remote UE for relay (re)selection. In other words, the relay UE may consider a high level of criticality that requires prompt action to mitigate the link problem. This case applies when the remote UE is the affected node.

[0134] The relay prepares or generates, in step 702, information for a link problem signaling message for indicating relay (re)selection feedback, similar to generating information for a link problem signaling message for indicating link problem feedback (e.g., as generally discussed with respect to step 602). For example, the link problem signaling message generated in step 702 may include link problem feedback information including flow information as described above, and may further include a different PDU type indicating a relay (re)selection trigger from the relay UE.

[0135] In another example, the link problem signaling message for indicating relay (re)selection generated by the UE relay 100 in step 702 may include link problem feedback information including information for identifying a type of detected link problem (e.g., different types of link problems including congestion, link degradation, Radio Link Failure (RLF)). The information for identifying the type of detected link problem may include a reason identifier or another identifier for identifying the type of detected link problem. The information may also include reason / context information for indicating a reason or context of the detected link problem. The reason ID, in addition to identifying the type of link problem, may indicate a reason or context of the detected link problem as described above. In this example, the link problem signaling message for indicating relay (re)selection may not include flow information.

[0136] Then, in step 703, a link problem signaling message or feedback is sent to the affected remote UE.

[0137] As mentioned above, the container of the link problem signaling message depends on its size, the criticality of the link problem requiring low delay.

[0138] Referring now also to Figure 7B, in step 705, the remote UE receiving the link problem signaling message for indicating relay (re)selection feedback from its relay UE identifies the PDU type (e.g. in information element 501 of the message shown in Figures 5 and 11A-11E) that in this case requests relay (re)selection or is related to relay (re)selection. The remote UE reads the next information element of the link problem signaling message to identify the reason for the link problem and the corresponding bearer or link problem. In feedback processing step 706, the remote UE releases the PC5 link with the relay UE, which may be the link affected by the detected link problem in case of a link failure or may include one or more communication flows (such as RLC channels) affected by the detected link problem, and proceeds to relay (re)selection. In an implementation example in which the link problem signaling message for indicating relay (re)selection does not include flow information but includes a reason ID identifying the type of link problem and indicating the reason or context of the detected link problem (as described above), in response to receiving the link problem signaling message, the remote UE may release the PC5 link and initiate a (re)selection procedure based on the reason ID included in the message.

[0139] FIG. 8A illustrates steps of a method 800 for generating a link problem signaling message including information for indicating a link status correction feedback in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. FIG. 8B illustrates steps of a method 804 for processing information included in the link problem signaling message at an affected node in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. The method 800 is performed at a relay UE node, such as the relay UE 100 of FIG. 1 and related figures, and the method 804 is performed at a node (at least one of a plurality of nodes (e.g., a remote UE or a network node, etc.)) affected by a link problem detected by the relay node (e.g., the relay UE 100). Each of the relay UE node and the affected node may be implemented in a communication device 1200 as illustrated in and described with reference to FIG. 12 below.

[0140] Upon detecting the link problem, the relay UE 100 may determine (e.g., using a timer or counter as described above) whether the link problem is a transient or short-term link problem (e.g., the link has recovered or will recover shortly) or a long-term link problem (e.g., the link problem worsens, resulting in the link problem not being able to be recovered (i.e., a permanent link problem)). Upon determining that the link has recovered or cannot be recovered, the relay UE 100 may send a link status correction feedback (e.g., to the affected node). In this case, detecting the link problem includes, in step 801, detecting a change in the link status at the relay UE 100. Then, in step 802, information for a link problem signaling message is generated or prepared to indicate the link status correction feedback. For example, the link problem signaling message generated in step 802 includes link problem feedback information including flow information as described above, but the PDU type in this case corresponds to the link status correction feedback. The following information elements (e.g., information elements 502-506 of the link problem signaling message in FIG. 5 and FIG. 11A-FIG. 11E) may be updated as a function of the link status modification. In other words, the information provided in the information elements of the link problem signaling message (e.g., IEs 502-506 of FIG. 5) is updated based on the current status of the detected link problem.

[0141] In case of congestion or link degradation, the information elements related to the available buffer size and the link quality parameters may change as a function of updating the criticality of the link problem. For example, in case of a link degradation problem, when the evaluated link quality parameter goes from weak to medium, the link status change feedback sends the same information elements as in the case of the link problem feedback with an update of the link quality parameter information element (IE 504).

[0142] Congestion detected for a particular bearer or RLC channel may worsen and affect all RLC channels carried on the link (link level congestion), therefore, as an optimization method, link status modification feedback may be sent with an identifier of the link experiencing the problem instead of a list of IDs of all affected channels. Furthermore, link status change feedback may be sent without notification of available buffer size, thereby informing the affected node that the link problem has intensified and resulted in link level congestion.

[0143] Then, in step 803, a link problem signaling message is sent to the affected node to indicate link status change feedback.

[0144] Referring now also to FIG. 8B, the affected node receives in step 804 a link problem signaling message for indicating link status modification feedback and specifies in its PDU type (e.g., in information element 501 of the message, as shown in FIG. 5 and FIG. 11A-FIG. 11E) that the feedback is about link status modification. If the available buffer size or link quality parameters are not indicated or included in the feedback, it may still indicate or have become a link level congestion or link failure. The reason ID in information element 503 identifies the type of link problem and the associated bearer / channel or link that is affected. For example, congestion that occurred in the uplink Uu RLC channel may degenerate and the number of affected PC5 RLC channels may increase. The flow information in information element 506 identifies the communication flow that is affected. Thus, a link status change may be sent from the relay UE side to the remote UE to indicate that the Uu RLC channel is still congested, but the number of affected PC5 RLC channels has increased.

[0145] A feedback process is performed by the affected nodes in step 805 to re-evaluate the link problem status. Link status correction feedback indicating that the link problem has ended may cause relay nodes to reset timers or counters used to determine whether the congestion is short-term or long-term congestion (congestion is considered long-term congestion if the time reaches a predefined threshold).

[0146] FIG. 9 illustrates steps of a method 900 for signaling a link problem in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. The method 900 is performed in a relay UE node. The wireless communication system comprises a relay UE node (e.g., relay UE 100 as shown) and a plurality of nodes (e.g., two or more remote UE nodes such as remote UEs 101, 102, 103 and network node 107 as shown). The relay UE node may be implemented in a communication device 1200 as shown in and described with reference to FIG. 12 below, with the method as shown in FIG. 9 being executed by a processing unit 1211. According to the example method 900 of FIG. 9, the relay UE 100 generates a link problem signaling message (e.g., having a format as shown in FIG. 5 and FIG. 11A-11E and described with reference to FIG. 11A-11E) including information for signaling link problem / relay (re)selection / link status change feedback to the affected node (e.g., according to general steps 601-603 of FIG. 6A).

[0147] The relay UE 100 detects a link problem or link status change (e.g., in other words, a change in the link status of a previously detected link problem) in step 901. Steps 903-904 relate to desired information (e.g., information in information elements 502, 503, 504, 506 in the format shown in FIG. 5) identified by the relay UE 100 to generate a link problem signaling message according to the example format shown in FIG. 5.

[0148] The relay UE 100, in step 902, identifies one or more flows or communication flows affected by the link problem, whether one or more radio bearers, RLC channels, or links. By identifying the affected flows, the relay UE 100 may define or determine the affected nodes. For example, it may define or identify a source node (or transmitter) and / or a destination node (or receiver) to which the link problem feedback information included in the link problem signaling message should be transmitted. The relay UE 100 also determines flow information (also called flow ID or flow data ID) that identifies one or more communication flows (e.g., radio bearers or links) identified as affected by the detected link problem. For example, the flow data ID considers the radio bearer ID or RLC bearer ID in case of RB level or RLC channel level congestion. Link level congestion and link failure require identifying the source of the link problem. For example, for this type of link problem, the flow information includes a link identifier (PC5 link ID or Uu link ID). A link failure at Uu is identified by the L2-ID of the relay UE. Additionally, the radio bearer IDs affected by the link level problem are reported in the flow information or flow data ID feedback (e.g., in information element 506). If multiple RLC channels or bearers are affected, a list of the affected RLC channels / bearers (e.g., list of RLC channel / bearer IDs) may be reported in the flow information (e.g., IE 506).

[0149] The link problem feedback information included in the link problem signaling message further includes an identifier (e.g., in information element 502) for identifying the determined affected node to which the link problem feedback information is sent. If the affected node is a remote UE, the L2-ID of the remote UE is determined by the Uu SRAP layer 203 in case of U2N relay (the second PC5 SRAP layer in case of U2U relay). For uplink traffic, this L2-ID is the destination ID identified in step 903 and is included in information element 502. For downlink, a gNB is determined as the destination of the feedback and the gNB ID is included in information element 502. For U2U relay, the ID information or identifiers of the source UE and destination or target UE are candidate information included in the adaptation layer, so that when the link problem signaling message is sent to the source UE, the corresponding destination ID in information element 502 is the L2-ID of the source UE. If the link problem signaling message is sent to a destination UE, the corresponding destination ID in information element 502 is the L2-ID of the destination UE.

[0150] Link level congestion or link failure refers to a global link problem affecting a set of RLC channels, radio bearers, and destination nodes as determined by the Uu SRAP layer 203 for U2N relay (or the second PC5 SRAP layer in case of U2U relay) and the mapping tables configured in these SRAP entities as described above. Thus, a list of destination IDs of all affected nodes may be provided as described above.

[0151] A reason ID for identifying the type of link problem is identified or determined and specified in the information element 503, as in step 904. After detecting the affected flow, the reason for the link problem or link status change can be known by the relay UE 100, which can determine an ID (e.g., a number or other identifier) ​​indicating the type of link problem or associated with the type of link problem, and can also indicate a congestion reason for such link problem type (bearer, RLC channel, or link level). For example, as described above, a reason ID table listing different reason IDs for each type of link problem can be provided to the relay UE 100 (see, for example, examples shown in Tables 4 and 5). If the relay UE 100 cannot recognize the reason for the link problem or link status change, a specific code can be used as the reason ID. For example, the assigned reason ID can correspond to a type of link problem for which no reason is specified. For example, if a link failure occurs on a PC5 link and there is no reason to explain the link failure, the relay UE 100 transmits a reason ID that matches or corresponds to the reason "no recognized reason for PC5 link failure".

[0152] The information in information elements 502, 503 and 506 is identified by the relay UE 100 in steps 903-904 and incorporated into the link problem signaling message along with additional information elements that are optional and known by the relay UE 100, such as buffer status or link quality parameters (in the case of information element 504) and / or QoS / priority level in the case of information element (505).

[0153] FIG. 10 illustrates steps of a method 1000 for processing link problem feedback information at an affected node in a sidelink relay system of a wireless communication system (such as the wireless communication system illustrated in FIG. 1 and related figures) according to an embodiment of the present invention. For example, FIG. 10 illustrates how an affected node makes a decision and performs an operation (e.g., according to steps 606-607 of FIG. 6B) after receiving feedback from a relay UE 100 in a link problem signaling message. The affected node may be at least one of a plurality of nodes (e.g., remote UEs or network nodes) affected by a link problem detected by a relay node (e.g., relay UE 100). The affected node may be implemented in a communication device 1200 as shown and described with reference to FIG. 12 below, with the method as shown in FIG. 10 executed by a processing unit 1211.

[0154] The affected node receives a link problem signaling message including feedback information in step 1001. As mentioned above, the link problem signaling message may be one of three different types based on the type of feedback it signals. The link problem signaling message may be either a link problem feedback type, a (re)selection feedback type, or a link status change feedback type. In one example, the link problem signaling message includes (in addition to the link problem feedback information) PDU type information to indicate the type of the link problem signaling message. The affected node identifies or determines the type of the link problem signaling message based on the PDU type information in step 1002.

[0155] The PDU type may be link problem feedback to inform the affected node of the current situation. In response to receiving a link problem signaling message of link problem feedback type (i.e., for signaling link problem feedback), the affected node does not need to take any action and may therefore wait before taking any action (step 1003 following the "Link Problem" branch from step 1002). However, as indicated in step 1003, it may trigger relay (re)selection after release.

[0156] In case of relay (re)selection feedback, the remote UE, which is the destination of the link problem signaling message containing the feedback, is requested or required to release the link corresponding to the communication flow affected by the detected link problem and (following the "Relay release RQ" branch from step 1002) perform relay (re)selection as in step 1005. Thus, upon receiving the link problem signaling message, the affected remote UE releases the affected link and performs relay (re)selection.

[0157] As a third option, link status modification feedback may be transmitted by the relay UE 100. In this case, a link problem signaling message including the link status modification feedback announces the recovery of the link and the affected node may resume its transmission in step 1004 (following the "Link Recovery" branch from step 1002). For example, the affected node may resume transmitting data (e.g., packets) on one or more affected communication flows. If the link status modification feedback reports a worsening of the link problem, relay (re)selection may be considered in step 1004, as in step 1005.

[0158] According to some aspects described in the above description, the link problem feedback signal may be used by the relay UE to inform the remote UE that all or a portion of its communication is affected by an ongoing link problem (e.g., RLF, congestion). The affected remote UE may use this feedback information for relay (re)selection, for example, as described above (e.g., with respect to FIGS. 6B, 7B, and 10).

[0159] According to another aspect, a relay UE may experience some shortcomings that limit its current relaying capability, e.g., the actual relaying capability may be affected by radio conditions (e.g., RSRP, SINR...) or the actual load of the relay UE. Such relaying capability limitations may cause further linking problems (e.g., congestion) if remote UE candidates attempting to connect to the relay UE do not take such limitations into account and still request to connect to the relay UE and / or if links with already connected remote UEs are not modified or released.

[0160] Therefore, it may be valuable for a relay UE to take into account the capacity limitations that may result in link problems when a new connection to one or more remote UEs is permitted or accepted, or when a link change with an already connected remote UE is permitted or accepted, or when a link with an already connected remote UE is not changed or released, and share such actual relay capabilities with the remote UEs in a proactive manner (e.g., during the discovery phase or during a link management process such as a direct link process or a direct communication process) to prevent such link problems from occurring, e.g., by ensuring that candidate remote UEs do not create link problems by connecting to the relay UE or by changing or releasing a link with an already connected remote UE.

[0161] FIG. 13 illustrates steps of a method 1300 performed by a relay user equipment (UE) node of a wireless communication system (such as the wireless communication system shown in FIG. 1 and related figures) according to an embodiment of the present invention. The method 1300 is performed in the relay UE node. The wireless communication system comprises a relay UE node (e.g., a relay UE 100 as shown in FIG. 1 and related figures) and a plurality of nodes (e.g., one or more remote UE nodes such as remote UEs 101, 102, 103 as shown in FIG. 1 and related figures, and a network node 107). The relay UE node is configured to relay data (e.g., packets) between at least one node of the plurality of nodes and at least one other node of the plurality of nodes. The relay UE node may be implemented in a communication device 1200 as shown in and described with reference to FIG. 12 below, with a method as shown in FIG. 13 performed by a processing unit 1211.

[0162] The method illustrated in Figure 13 enables a relay UE node to manage new and existing remote UE connections according to the actual relay capabilities of the relay UE node during a sidelink management process such as a discovery process or a link management process (such as a direct link process or a direct communication process), which may also include sharing such relay capabilities between the relay UE node and the remote UE node.

[0163] 5G Proximity-based Services (ProSe) U2N / U2U relay UEs support two discovery models, such as Model A and Model B, as defined in 3GPP TS 23.304, V17.1.1. Model A uses one discovery protocol message (Announcement message sent by relay UE acting as announcing UE) and Model B uses two discovery protocol messages (Solicitation message sent by remote UE acting as discovering UE and Response message from relay UE acting as discovering UE). In the latter case of Model B, the discoverer UE may indicate interest in the status of the requested relay UE (e.g., link or actual load of relay UE, or connectivity with other UEs, etc.) in its discovery solicitation or request message. Discovery solicitation messages may be sent in broadcast, unicast, or groupcast.

[0164] A relay UE may also support link management processes, such as a direct link process or procedure for establishing a direct link between a UE node and another UE node (such as the direct link process defined in 3GPP TS 24.587, V17.5.0), and / or a direct communication process or procedure for direct communication between two or more UEs (such as the direct communication process defined in 3GPP TS 23.304, V17.1.1).

[0165] In the direct link process, the remote UE node sends a direct link establishment request message. If the relay UE node receives the direct link establishment request message and accepts the request to establish a direct link (e.g., over a PC5 link) with the remote UE node, the relay UE node responds by sending a direct link establishment accept message. In the case of UE-to-UE relay or multi-hop UE-to-Network (i.e., the remote UE uses multiple consecutive relay UEs to reach the gNB), upon receiving the direct link establishment request message, if the relay UE node accepts the request to establish a direct link (e.g., over a PC5 link) with the remote UE node, the relay UE forwards the direct link establishment request message or sends a new direct link establishment request message of its own device to establish a direct link connection (e.g., via another PC5 link) with the target UE or another relay UE. When the relay UE's direct link establishment request is accepted by the target UE or other relay UE, or to save the time of the establishment process, the relay UE sends a direct link establishment accept message in response to the remote UE, but if the direct link establishment with the target UE or other relay UE is rejected, the relay UE may accept the direct link establishment request of the remote UE based only on the criteria of the relay UE, even if it needs to release the direct link connection with the remote UE later. When receiving the direct link establishment request message, if the relay UE node does not accept the request to establish a direct link (such as a PC5 link) with the remote UE node, the relay UE node sends a direct link establishment reject message in response. The direct link process also provides that a direct link change request is sent from a UE (e.g., a relay UE) to another pair UE (e.g., a UE already connected to the relay UE) to initiate a direct link change procedure (e.g., change the PC5 link between the relay UE node and the remote UE node). The direct link process also provides for a direct link release request to be sent from a UE (e.g., a relay UE) to another paired UE (e.g., a UE already connected to the relay UE) to initiate a direct link release procedure (e.g., to release the PC5 link between the relay UE node and the remote UE node).

[0166] In the direct communication process, the remote UE node sends a direct communication request message. When receiving the direct communication request message, if the relay UE node accepts the request to establish direct communication with the remote UE node (e.g., on a PC5 link), the relay UE node sends a direct communication accept message in response. In the case of UE-to-UE relay or multi-hop UE-to-Network, when receiving the direct communication request message, if the relay UE node accepts the request to establish direct communication with the remote UE node (e.g., on a PC5 link), the relay UE forwards the direct communication request message or sends a new direct communication request message of its own device to establish direct communication with the target UE or another relay UE (e.g., via another PC5 link). The relay UE sends a direct communication accept message in response to the remote UE when its direct communication request is accepted by the target UE or other relay UE, or to save time in the establishment process, but the relay UE may accept the direct communication request of the remote UE based only on its own device's criteria, even if it needs to release the direct communication with the remote UE later if the direct communication with the target UE or other relay UE is rejected. If the relay UE node does not accept the request to establish a direct link (eg, over a PC5 link) with the remote UE node when the direct communication request message is sent, the relay UE node sends a direct communication rejection message in response.

[0167] The relay UE node of FIG. 13 identifies or confirms its relay capability for relaying data in step 1301. For example, the relay UE node identifies its current or actual relay capability. The relay UE node may check its relay capability periodically or in response to a triggering event. The triggering event may include at least one of receiving a discovery solicitation message, or receiving a direct link establishment / modification request, or receiving a direct communication request, or based on a measurement result (e.g., the measurement result indicates a significant change in the relay UE node's capability (e.g., a decrease in capability beyond a certain level or a decrease in capability beyond a certain level) such that it is merited for the relay UE node to proactively notify remote UE nodes in the relay UE node of the change). The relay UE node may identify its relay capability by determining or checking one or more relay parameters associated with the current data relay by the relay UE node. The one or more different relay parameters may include one or more of the following: the current load of the relay UE node, the number of remote UE nodes currently connected, the radio conditions (or link quality) on each communication link (such as a PC5 link or a Uu link) between the relay UE node and one or more nodes to which the relay UE node is relaying data (which may be based on measurements such as RSRP, SINR, RSSI, RSRQ, etc. of PC5 and Uu links), the QoS level, the bit rate of each of the one or more communication flows currently served by the relay UE node, and / or the network load (which may be based on the Channel Busy Ratio (CBR) and / or Channel Occupancy Ratio (CR) of each band / pool currently being used by the relay UE node for data relaying).

[0168] In step 1302, the relay UE node determines whether relaying by the relay UE node to one or more remote UE nodes (e.g., one or more remote UE nodes that are new or added to those already served by the relay UE node and / or one or more remote UE nodes that may already be connected to the relay UE node) can be supported without risk of link problems. For example, the relay UE checks whether a potential risk of link problems may arise from the connection of one or more new or additional remote UEs and checks whether it can accept a connection with the new remote UE node. In another example, the relay UE checks whether a potential risk of link problems may arise from an existing connection with one or more remote UEs and checks whether the existing connection needs to be modified or released or checks whether it can accept a modification request from the remote UE for the existing connection.

[0169] If, in step 1302, the relay UE node determines that relaying by the relay UE node to one or more remote UE nodes cannot be supported without risk of link problems, the relay UE node may decide whether to prevent new remote UE connections, prevent modification of existing remote UE connections, or modify or release existing remote UE connections to avoid the risk of future link problems.

[0170] In one example, in step 1304, in response to determining that relaying by the relay UE node cannot be supported for the one or more remote UE nodes, the relay UE node transmits a sidelink management message to indicate that relaying by the relay UE node cannot be supported for the one or more remote UE nodes (e.g., to prevent a remote UE connection as indicated by box 1306). The sidelink management message may include relay capability information indicating a relay capability (e.g., current relay capability) of the relay UE node for data relaying by the relay UE node. In an alternative example at step 1304, in response to determining that relaying by the relay UE node cannot be supported for the one or more remote UE nodes, the relay UE node does not transmit the one or more sidelink management messages. For example, the relay UE node may modify (e.g., stop) a sidelink management process executed at the relay UE node to stop transmission of the one or more sidelink management messages.

[0171] In an example where the relay UE node supports (e.g., is performing) a discovery process, the sidelink management message is a discovery message and the relay UE node may transmit the discovery message indicating an inability to support relaying by the relay UE node to one or more new remote UE nodes (e.g., to prevent a remote UE connection, as indicated by box 1306). The discovery message may include relay capability information indicating the relay capability (e.g., current relay capability) of the relay UE node for data relay by the relay UE node. In an alternative example, the relay UE node may not transmit or stop forwarding one or more discovery messages (e.g., to remote UEs or target UEs or subsequent relay UEs). That is, the relay UE node may modify (e.g., stop) the discovery process performed by the relay UE node such that it stops sending announcement messages (for discovery model A as defined in 3GPP TS 23.304, V17.1.1) or response messages (for discovery model B as defined in 3GPP TS 23.304, V17.1.1) to received discovery request messages. By stopping the sending of discovery messages, the UE relay node may prevent new remote UE connections by not considering relay UEs when performing relay selection since UEs (e.g. relay UE 100) in the vicinity of the relay UE node will no longer receive information from the relay UE node.

[0172] In an example where the relay UE node supports (e.g., is running) a link management process such as a direct link process or a direct communication process, the sidelink management message is a link management message (e.g., a direct link message or a direct communication message, respectively), and in response to determining that relaying by the relay UE node cannot be supported for one or more remote UE nodes, the relay UE node may transmit a link management message indicating that relaying by the relay UE node for one or more remote UE nodes is not supported (e.g., to prevent a remote UE connection, as indicated by box 1306), such as, for example, a direct link establishment reject message for a direct link process or a direct communication reject message for a direct communication process. The link management message may include relay capability information indicating the relay capability (e.g., current relay capability) of the relay UE node for data relaying by the relay UE node. The link management message may be transmitted in response to a link management request message. For example, a direct link establishment reject message for a direct link process may be transmitted in response to a direct link establishment request message. A direct communication reject message for a direct communication process may be transmitted in response to a direct communication request message. The relay capability information may, for example, inform the remote UE under what conditions a new connection can be accepted by the relay UE.

[0173] In the alternative, if the relay UE node supports a direct link process, in response to determining that relaying by the relay UE node cannot be supported, the relay UE node may send a link management message to the already connected remote UE node indicating that relaying by the relay UE node for one or more remote UE nodes can no longer be supported, such as, for example, a direct link modification request message to request modification of a link (PC5 link) between the relay UE node and the connected remote UE node or a direct link release request message to request release of a link (PC5 link) between the relay UE node and the connected remote UE node. The direct link modification request message and / or the direct link release request message may include relay capability information indicating a relay capability (e.g., current relay capability) of the relay UE node to relay data by the relay UE node.

[0174] Alternatively, similar to the discovery process, the relay UE node may not transmit or forward (e.g., to the relay UE or the target UE or subsequent relay UEs) one or more link management messages, such as link establishment messages. That is, the relay UE node may modify (e.g., stop) the link management or establishment process performed at the relay UE node to stop transmitting response messages to received direct link establishment requests (defined in 3GPP TS 24.587 V17.5.0) or to received direct communication request messages (defined in 3GPP TS 23.304, V17.1.1). By stopping the transmission of link establishment messages, the UE relay node may prevent new remote UE connections to UEs in the vicinity of the relay UE node (e.g., relay UE 100).

[0175] The relay capability information included in a sidelink management message (e.g. in a discovery message or a link management message) sent by the relay UE node if the relay UE node determines in step 1302 that relaying by the relay UE node to one or more remote UE nodes is not supported may include one or more pieces of information included in a relaying capacity information element, as described below.

[0176] Thus, there are two possible options for step 1304: - the relay UE no longer executes a sidelink management process such as a direct link process, a direct communication process or a discovery process, e.g. the relay UE does not send an announce message (in the case of model A) or a response message (in the case of model B); A relay UE may indicate in a sidelink management message that it cannot support one or more remote UE nodes, and may share its relaying capabilities with remote UEs by adding a relaying capacity information element (described below) to sidelink management messages (e.g., discovery messages or link management messages) sent to the remote UEs.

[0177] If, in step 1302, the relay UE node determines that relaying by the relay UE node for one or more remote UE nodes can be supported without risk of link problems, the relay UE node may, in step 1303, send a sidelink management message to indicate that relaying by the relay UE node for one or more remote UE nodes can be supported (e.g., to allow or enable a remote UE connection as indicated by box 1305). The sidelink management message may include relay capability information indicating the relay capability (e.g., current relay capability) of the relay UE node for data relaying by the relay UE node.

[0178] In an example where the relay UE node supports (e.g., is performing) a discovery process, the sidelink management message is a discovery message and the relay UE node may transmit the discovery message indicating that relaying by the relay UE node to one or more remote UE nodes is supportable (e.g., to permit or enable a remote UE connection, as indicated by box 1305). Thus, in this case, the relay UE node may perform the discovery process in the normal manner at step 1303. The discovery message transmitted by the relay UE node may be transmitted as a broadcast or announcement message (in the case of discovery model A defined in 3GPP TS 23.304, V17.1.1) or as a response message in response to a discovery solicitation message received from a remote UE node (in the case of discovery model B defined in 3GPP TS 23.304, V17.1.1). The discovery message may include relay capability information indicating the relay capability (e.g., current relay capability) of the relay UE node for data relaying by the relay UE node.

[0179] In an example where the relay UE node supports (e.g., is performing) a link management process such as a direct link process or a direct communication process, the sidelink management message is a link management message (e.g., a direct link message or a direct communication message, respectively), and if the relay UE node determines in step 1302 that relaying by the relay UE node to one or more remote UE nodes is feasible without risk of link problems, the relay UE node may send a link management message in step 1303 indicating that relaying by the relay UE node to one or more remote UE nodes is supportable (e.g., to permit or enable remote UE connectivity, as indicated by box 1305). Thus, in this case, the relay UE node may perform a link establishment process in the usual manner in step 1303. The link management message may be sent in response to the link management request message. In other words, the link management message sent by the relay UE node may be sent as a response message (e.g., a direct link establishment accept message) in response to a received direct link establishment request (defined in 3GPP TS 24.587, V17.5.0), or may be sent as a response message (e.g., a direct link modification accept message) in response to a received direct link modification request (defined in 3GPP TS 24.587, V17.5.0), or may be sent as a response message (such as a direct communication accept message) in response to a direct communication request message (defined in 3GPP TS 23.304, V17.1.1) received from a remote UE node. In the case of a UE-to-UE relay or multi-hop UE-to-Network, upon receiving a link management request message (e.g., a direct link establishment request message or a direct communication request message), if the relay UE node accepts the request to establish a direct link or direct communication with the remote UE node, the relay UE may either forward the link management request message or send a new link management request message of its own (e.g., a direct link establishment request message or a direct communication request message) to establish a direct link or direct communication (e.g., via another PC5 link) with the target UE or another relay UE.The link management message may include relay capability information indicating the relay capability (eg, current relay capability) of the relay UE node for data relay by the relay UE node.

[0180] In cases where the relay UE node determines in step 1302 that it can support relaying by the relay UE node for one or more remote UE nodes (and in cases where the relay UE node determines in step 1302 that it cannot support relaying by the relay UE node for one or more remote UE nodes), the relay capability information that may be included in the sidelink management message (e.g. in a discovery message or a link management message sent by the relay UE node) may include one or more of the information included in a relaying capacity information element, as described below. Thus, the relay UE may share its relaying capabilities with the remote UE by adding a relaying capacity information element to a sidelink management message (e.g. a discovery message or a link management message) sent to the remote UE. The relaying capacity information element shared by the relay UE with the remote UE may include all or part of the following information: - New connection accepted information: This information indicates the ability of the relay UE to accept a new remote UE connection. For example, this information indicates whether the relay UE node is able to accept a new connection to a new remote UE node. For example, this information can be a Boolean parameter. In one example, "True" indicates yes and "False" indicates no. Alternatively, a single bit with value "1" or "0" can indicate whether the UE node is able to accept a new connection or not. - Relay Load Information: This information reflects the load of the relay UE (e.g. the current load of the relay UE node). The load of the relay UE may be expressed in terms of connected remote UEs. For example, this information may relate to the actual number of remote UEs connected to the relay UE or any information reflecting this number, e.g. the load level (Low / medium / High). In one example, this relay load information may reflect the number of new connected remote UEs that the relay UE can accept. In another example, this relay load information may indicate the number of remote UEs currently connected to the relay UE and the maximum number of remote UEs that the relay UE can accept. - Served QoS information: This information relates to the QoS level of one or more flows currently accommodated by a relay UE, which may serve multiple QoS flows with a particular priority level. For example, this QoS information indicates the respective QoS level of one or more communication flows currently provided or supported by the relay UE node. The served QoS information may include a list of all or a part of the QoS levels provided by the relay UE, or a list of all or a part of the QoS levels that the relay UE does not provide. For example, if a given remote UE discovers two relay UEs, and the first relay UE (UE1) provides the QoS requested by the remote UE, while the second relay UE (UE2) provides a higher QoS level, the remote UE is more likely to be served properly if it chooses to join relay UE1, which has dedicated E2E Uu DRB and Uu RLC channels for the QoS level it is requesting. - PC5 measurement report information: This PC5 or sidelink measurement report information indicates the radio quality of one or more communication links (e.g. PC5 links) between a relay node and at least one remote UE node. A relay UE may perform sidelink measurements such as SL-RSRP (Reference Signal Receive Power), SL-RSSI (Received Signal Strength Indicator), SL-CR (Channel Occupancy Ratio), SL-CBR (Channel Busy Ratio) on the PC5 links as defined in TS 38.215. These measurements may indicate poor radio conditions (busy channel, interference, etc.) on one or more of the PC5 links. For example, in case of UE-to-UE relaying, the relay UE may include information of PC5 links involved in future communication between the remote UE and a potential target UE (e.g. identified by the dest L2 id in the PC5 measurement report information or discovery model B solicitation message or identified by the target UE information). Thus, the remote UE may choose to ignore candidate relay UEs with poor radio conditions on a PC5 link (eg, the PC5 link to the remote UE's target UE). -Uu measurement report information: This Uu or network link measurement report information indicates the radio quality of the communication link (e.g., Uu link) between the relay node and the network node (e.g., gNB) of the wireless communication system. Various types of measurements on the Uu link may be requested by the gNB and periodically reported by the relay UE. Some of these measurements may be relevant for remote UE candidates. For example, a relay UE showing a low Uu-RSRP may suffer reduced bandwidth that may affect the Uu RLC channel and cannot guarantee uplink / downlink data rates. This information may be optional for UE-to-UE relays. - Acceptable bitrate information: Based on local measurements performed on the Uu link and / or on its PC5 link between the relay UE and a network node (e.g. gNB) of the wireless communication system, the relay UE may indicate to the remote UE a target or maximum bitrate that can be handled on the Uu link and / or on its PC5 link. For example, this information indicates the maximum bitrate currently supported by the relay UE node. - Network load information: This information indicates the current channel occupancy rate and indicates the remaining bandwidth for new communications.

[0181] The relaying capacity information element may be announced by a relaying UE (discovery model A) or requested by a remote UE (discovery model B), encompassing L2 and L3 relaying. In this regard, the relaying capacity information element may be added to the announcement message (model A) or the response message (model B) when performing L2 relaying. An additional announcement used for L3 relaying support (model A) may be used to share this information.

[0182] The relaying capacity information element may be transmitted in some dedicated discovery messages using a new "relaying discovery additional information" message type that may rely on the PC5-D protocol stack defined in 3GPP TS 23.304.

[0183] Reference is now also made to Fig. 14A and Fig. 14B, which illustrate steps of a method 1400 and 1403 performed at a remote UE node of a sidelink relay system of a wireless communication system (such as the wireless communication system illustrated in Fig. 1 and related figures) according to an embodiment of the present invention. For example, Fig. 14A illustrates steps performed at the remote UE node in response to receiving a sidelink management message from a relay UE node, and Fig. 14B illustrates steps performed at the remote UE node in response to not receiving a response message in response to a request message sent by the remote UE node. The remote UE node may be one of the remote UEs 101, 102, 103 illustrated and described with respect to the figures, and the relay UE node may be the relay UE 100 illustrated and described with respect to the figures. The remote UE node may be implemented in a communication device 1200 as illustrated and described with reference to Fig. 12 below, with the method as illustrated in Fig. 14A and Fig. 14B executed by a processing unit 1211.

[0184] Referring initially to FIG. 14A, in step 1401, the remote UE node receives a sidelink management message from a relay UE node indicating whether relaying by the relay UE node for one or more remote UE nodes is supportable. The sidelink management message may be a discovery message or a link management message (e.g., a direct link message or a direct communication message) as described above with respect to FIG. 13. The link management message may include relay capability information indicating a relay capability (e.g., a current relay capability) of the relay UE node for data relaying by the relay UE node. The relay capability information included in the sidelink management message received from the relay UE node may include one or more of the information included in the relaying capacity information element, as described above. In step 1402, the remote UE node performs an action based on the received sidelink management message. Performing the action may include performing a (re)selection or a discovery process or a direct link establishment process or a direct communication process to another relay UE node in response to determining based on the received sidelink management message that relaying by the relay UE node for one or more remote UE nodes is not supportable. Performing the action may include initiating establishment of a connection with the relay UE node (e.g., performing link establishment) in response to determining that relaying by the relay UE node for one or more remote UE nodes is supportable based on the received relay capability information. As described above, when relay capability information is included in the sidelink management message along with one or more of the information included in the relaying capacity information element, the remote UE node has additional information to enable it to determine whether to request a connection with the relay UE node.For example, if a remote UE node receives relay capability information from two relay UE nodes, where a first relay UE (UE1) indicates in the relay capability information that it provides a QoS level corresponding to a QoS level requested by the remote UE node, and a second relay UE (UE2) indicates in the relay capability information that it provides a QoS level corresponding to a higher QoS level compared to the QoS level requested by the remote UE node, the remote UE is more likely to be properly served when it selects to join relay UE1, which has dedicated E2E Uu DRB and Uu RLC channels corresponding to the QoS level it is requesting. Thus, in this case, the remote UE node may decide to initiate the establishment of a connection with the first relay UE (UE1).

[0185] Referring now also to FIG. 14B, in step 1404, the remote UE node acting as a discoverer UE transmits a request message to initiate communication with the relay UE node. For example, the request message may be a discovery request message to discover the relay UE node as defined for discovery model B in 3GPP TS 23.304, V17.1.1. The discovery request message may be transmitted by broadcast or unicast or groupcast. In another example, the request message may be a direct link establishment request message (e.g., as defined in 3GPP TS 24.587, V17.5.0) or a direct communication request (e.g., as defined in 3GPP TS 23.304, V17.1.1). In response to not receiving a message in response to the request message, the remote UE node performs an action (step 1405). For example, the remote UE node may start a timer upon transmission of the request message, and if it does not receive a response message within a certain time determined by the timer, the remote UE node may perform an action. This action may include performing a (re)selection, or performing a discovery process or a direct link establishment process or a direct communication process with another relay UE node, or determining that there are no available relays (e.g. currently) in the vicinity of the remote UE node.

[0186] Thus, by identifying the relaying capabilities of the relay UE node and determining whether relaying by the relay UE to one or more remote UE nodes is supportable, the relay UE node may ascertain whether there is a risk of link problems and act proactively to prevent or allow new connections to one or more new remote UEs and / or modify or release existing connections to avoid or minimize the risk of link problems occurring in the future. The relay UE node may act proactively by sending a sidelink management message (such as a discovery message) indicating whether relaying by the relay UE is supportable (e.g., whether new connections are supported / allowed), and possibly with some restrictions. The sidelink management message may include relay capability information that provides information indicative of the actual or current relaying capabilities of the relay UE node. Alternatively, if the relay UE node cannot support relaying to new or existing remote UEs due to a high risk of link problems occurring in the future, the relay UE node may act proactively by not sending or stopping sidelink management messages (e.g., discovery messages) and by stopping the sidelink management process (e.g., discovery process). By not transmitting or stopping the transmission of discovery messages, UEs in the vicinity of the relay UE node will not receive any information from the relay UE node. Thus, in case of a discovery process, UEs in the vicinity of the relay UE node will not consider the relay UE when making a relay (re)selection. Upon receiving a sidelink management message including the relay capability information, the remote UE node may decide what action to take (e.g. whether to request a connection establishment with the relay UE node) based on the relay capability information. If information indicating the actual or current relaying capabilities of the relay UE node is included in the discovery message (e.g. one or more of the information included in the relaying capacity information element mentioned above is included in the message), the remote UE node has additional information on which to base its decision on whether to initiate a connection establishment with the relay UE node.This helps the remote UE node to select the most appropriate (e.g., based on the required QoS, bit rate, link quality, or load requirements) relay UE node to connect to. If a relay UE node does not send or has stopped sending sidelink management messages, then no response received after sending a link management request message (e.g., no discovery response message received after sending a discovery solicitation message) indicates to the remote UE node that there are no relay UE nodes available (e.g., the discovery solicitation message is broadcast) or that the target relay UE (in the unicast case) is overloaded or suffers from other limitations that affect the relay UE's ability to support new connections to the remote UE node as described above.

[0187] FIG. 12 is a schematic diagram of an example wireless communication device in accordance with one or more exemplary embodiments of the present disclosure.

[0188] The wireless communication device 1200 may preferably be any communication device capable of wireless communication such as a microcomputer or a workstation or a mobile device or a lightweight portable device or a fixed device. The communication apparatus 1200 preferably includes a communication bus 1213 to which the following are connected: - A processing unit 1211, such as a microprocessor, denoted CPU in FIG. 12. The processing unit 1211 may be a single processing unit or processor, or may include two or more processing units or processors that perform the processing necessary for the operation of the communication device 1200. The number of processors and the allocation of processing functions to the central processing unit 1211 is a matter of design choice for those skilled in the art. - memory for storing data and computer programs containing instructions for operation of the communication device 1200. The computer programs may include a number of different program elements (modules) or subroutines containing instructions for various operations and for implementing methods according to one or more embodiments of the present invention; and - at least one communication interface 1202 for communicating with other devices or nodes in a wireless communication system, such as the wireless communication system of Figure 1. The at least one communication interface 1202 may be connected to a communication network 1203, such as a radio access network of the wireless communication system, over which digital data packets or frames or control frames are transmitted.

[0189] Each of the relay node and multiple nodes (e.g., remote UEs and network nodes) of a sidelink relay arrangement or system may constitute such a communications device 1200.

[0190] The memory may include: - a read-only memory 1207, represented by ROM, for storing computer programs for implementing the methods according to one or more embodiments of the invention, - a random access memory 1212, represented by RAM, for storing executable code of the methods according to one or more embodiments of the invention, and registers adapted for recording variables and parameters necessary for implementing the methods according to one or more embodiments of the invention.

[0191] Optionally, the communications device 1200 may include one or more of the following components: - a data storage means 1204, such as a hard disk, for storing a computer program for implementing the method according to one or more embodiments of the invention, a disk drive 1205 for a disk 1206, the disk drive being adapted to read data from the disk 1206 or to write data to said disk, A screen 1209 for displaying the decoded data and / or for serving as a graphical interface with the user, via a keyboard 1210 or other user input means.

[0192] Preferably, a communication bus provides communication and interoperability between various elements included in or connected to the communications device 1200. The representation of a bus is not limiting, in particular a processing unit is operable to communicate instructions to any element of the communications device 1200 directly or by way of another element of the communications device 1200.

[0193] The disk 1206 may optionally be replaced by any information carrier, such as, for example, a compact disk (CD-ROM), rewritable or not, a ZIP disk, a USB key or a memory card, and in general by an information storage means readable by a microcomputer or microprocessor, possibly removable, whether integrated in the communication device or not, and adapted to store one or more programs, the execution of which can implement the methods according to the embodiments of the present invention.

[0194] The executable code may optionally be stored either in a read-only memory 1207, on the hard disk 1204 or on a removable digital medium as previously described, such as for example the disk 1206. According to an optional variant, the executable code of the program may be received by the communication network 1203, via the interface 1202, to be stored in one of the storage means of the communication device 1200, such as the hard disk 1204, before being executed.

[0195] The processing unit 1211 is preferably adapted to control and direct the execution of instructions of a program or parts of software code according to the invention, which instructions are stored in one of the aforementioned storage means. The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the term "processor" as used herein may refer to the aforementioned structures, or other structures suitable for implementing the techniques described herein. Also, the techniques may be implemented entirely in one or more circuit or logic elements.

[0196] Although the present invention has been described with reference to the embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. Those skilled in the art will appreciate that various changes and modifications may be made without departing from the scope of the present invention as defined in the appended claims. All features disclosed in this specification (including the appended claims, abstract and drawings) and / or all steps of any method or process so disclosed may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including the appended claims, abstract and drawings) may be replaced with an alternative feature serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is only one example of a generic series of equivalent or similar features.

[0197] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

[0198] In the above-described embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit.

[0199] Computer-readable media may include computer-readable storage media, which correspond to tangible media such as data storage media, or communication media, which include any medium that facilitates transfer of a computer program from one place to another, for example according to a communication protocol. Thus, computer-readable media may generally correspond to (1) non-transitory tangible computer-readable storage media, or (2) communication media, such as signals or carrier waves. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, code and / or data structures for implementing the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0200] By way of example and not limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly referred to as a computer-readable medium. For example, if the instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, microwave, etc., the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, microwave, etc., are included in the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but are instead directed to non-transitory tangible storage media. As used herein, disk and disc include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and Blu-ray discs, where disks typically reproduce data magnetically and disks reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer readable media.

Claims

1. 1. A method performed by a relay user equipment (UE) node of a wireless communication system including a relay UE node and a plurality of nodes, the relay UE node relaying data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes, the method in the relay UE node comprising: determining, by the relay UE node, a relay capability for relaying data; determining whether relaying by the relay UE node to one or more remote UE nodes can be supported based on the identified relay capabilities; and in response to determining that relaying by the relay UE node is capable of being supported to one or more remote UE nodes, transmitting a sidelink management message to indicate that relaying by the relay UE node is capable of being supported to one or more remote UE nodes. in response to determining that relaying by the relay UE node is not supportable for one or more remote UE nodes, transmitting a sidelink management message to indicate that relaying by the relay UE node is not supportable for the one or more remote UE nodes, or not transmitting the one or more sidelink management messages. method.

2. the sidelink management message includes relay capability information indicating a relay capability of the relay UE node for relaying data by the relay UE node. The method of claim 1.

3. Identifying relay capabilities includes determining one or more relay parameters associated with relaying current data by the relay UE node. The method according to claim 1 or claim 2.

4. the one or more relay parameters include one or more of: a current load of the relay UE node; a network load; a number of currently connected remote UE nodes; radio conditions in each communication link between the relay UE node and one or more nodes to which the relay UE node is relaying data; a level of QoS for each of one or more communication flows currently being provided by the relay UE node; and a bit rate for each of one or more communication flows currently being provided by the relay UE node. The method according to claim 3.

5. the sidelink management message is either a discovery message or a link management message.

5. The method according to any one of claims 1 to 4.

6. the sidelink management message is a discovery message, and transmitting the sidelink management message comprises broadcasting a discovery message.

5. The method according to any one of claims 1 to 4.

7. the sidelink management message is a discovery message, and transmitting the sidelink management message comprises transmitting the discovery message as an announcement message.

5. The method according to any one of claims 1 to 4.

8. the sidelink management message is a discovery message, and the method further comprises: receiving a discovery request message from a remote UE node; and transmitting a sidelink management message includes transmitting a discovery response message in response to the received discovery request message.

5. The method according to any one of claims 1 to 4.

9. The method further comprising: receiving a discovery request message from a remote UE node; and in response to determining that relaying by the relay UE node is not supported, not transmitting one or more sidelink management messages comprises not transmitting a discovery response message in response to the received discovery request message.

5. The method according to any one of claims 1 to 4.

10. the sidelink management message is a link management message, receiving a link management request message from the remote UE node; and transmitting a sidelink management message includes transmitting a link management message in response to the received link management request message.

5. The method according to any one of claims 1 to 4.

11. The method comprises: receiving a link management request message from the remote UE node; and not transmitting one or more sidelink management messages in response to determining that relaying by the relay UE node is not supported comprises not transmitting a link management response message in response to the received link management request message.

5. The method according to any one of claims 1 to 4.

12. the sidelink management message is a direct link message, and transmitting a sidelink management message in response to determining that relaying by the relay UE node is not supported further comprises: transmitting a direct link modification request message or a release request message in response to determining that relaying by the relay UE node is not supported.

5. The method according to any one of claims 1 to 4.

13. 1. A method performed in a remote user equipment (UE) node in a wireless communication system, the wireless communication system including the remote UE node, a relay UE node, and a plurality of other nodes, the relay UE node relaying data between at least one of the plurality of nodes and at least one other node of the plurality of nodes, the method in the remote UE node comprising: receiving, from the relay UE node, a sidelink management message indicating whether relaying by the relay UE node to one or more remote UE nodes is supportable; and and performing an action based on the received sidelink management message. method.

14. the sidelink management message includes relay capability information indicating a relay capability of the relay UE node for data relay by the relay UE node. The method of claim 13.

15. performing an action in response to determining, based on the received sidelink management message, that relaying by the relay UE node to one or more remote UE nodes cannot be supported comprises at least one of performing a (re)selection, or performing a discovery process, or a direct link establishment process, or a direct communication process, to a different relay UE node. The method according to claim 13 or claim 14.

16. and performing an action in response to determining, based on the received sidelink management message, that relaying by the relay UE node to one or more remote UE nodes is supportable, comprising initiating establishment of a connection with the relay UE node.

16. The method according to any one of claims 13 to 15.

17. The sidelink management message is a discovery message or a link management message.

17. The method according to any one of claims 13 to 16.

18. The sidelink management message includes relay capability information indicating a relay capability of the relay UE node for data relay by the relay UE node, the relay capability information comprising: new connection information to indicate whether the relay UE node can accept a new connection to a new remote UE node; relay load information for indicating a current load of the relay UE node; QoS (Quality of Service), which is information for indicating the QoS level of each of one or more communication flows currently provided by the relay UE node; and - sidelink measurement report information for indicating radio quality of one or more communication links between the relay UE node and at least one remote UE node; network link measurement report information for indicating a radio quality of a communication link between said relay UE node and a network node of said wireless communication system; bit rate information for indicating a maximum bit rate currently supported by the relay UE node; network load information to indicate current channel occupancy; 18. The method according to any one of claims 1 to 17.

19. 1. A method performed in a remote user equipment (UE) node in a wireless communication system, the wireless communication system including the remote UE node, a relay UE node, and a plurality of other nodes, the relay UE node relaying data between at least one of the plurality of nodes and at least one other of the plurality of nodes, the method in the remote UE node comprising: sending a request message to initiate communication with the relay UE node; in response to not receiving a message in response to the request message, performing actions including at least one of: performing a (re)selection, or performing a discovery process or a direct link establishment process or a direct communication process for a different relay UE node, or determining that there are no available relay UE nodes for the remote UE node. method.

20. A method for signaling a link problem in a wireless communication system, the wireless communication system including a relay user equipment (UE) node and a plurality of nodes, the relay UE node relaying data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes, the method in the relay UE node comprising: detecting a link problem in the wireless communication system; generating link problem feedback information for the detected link problem in response to detecting the link problem, the link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem; and transmitting the link problem feedback information. method.

21. Transmitting the link problem feedback information includes transmitting the link problem feedback information to at least one of the plurality of nodes associated with one or more of the communication flows affected by the detected link problem.

21. The method of claim 20.

22. determining at least one of the plurality of nodes associated with one or more of the communication flows affected by the detected link problem, and transmitting the link problem feedback information includes transmitting the link problem feedback information to at least one of the determined plurality of nodes.

21. The method of claim 20.

23. At least one of the determined plurality of nodes includes at least one of a source node and a destination node.

23. The method of claim 22.

24. Determining at least one of the plurality of nodes associated with one or more of the communication flows affected by the detected link problem includes mapping the affected one or more of the communication flows to at least one of the plurality of nodes using a mapping table.

24. The method of claim 22 or claim 23.

25. The link problem feedback information further includes an identifier for identifying the at least one of the plurality of nodes to which the link problem feedback information is to be transmitted.

25. The method of any one of claims 21 to 24.

26. a sidelink relay connection is established between a source node, the relay UE node, and a destination node; Detecting a link problem includes detecting a link problem associated with at least one of a first link between the source node and the relay UE node and a second link between the destination node and the relay UE node; Transmitting the link problem feedback information includes transmitting the link problem feedback information to at least one of the source node and the destination node.

26. The method according to any one of claims 20 to 25.

27. Transmitting the link problem feedback information includes transmitting the link problem feedback information to all of the plurality of nodes connected to the relay UE node.

27. The method of any one of claims 20 to 26.

28. The link problem feedback information further includes information for identifying a type of the link problem detected.

28. The method according to any one of claims 20 to 27.

29. The detected link problem is at least one of a plurality of different types of link problems, the plurality of different types of link problems including handover, congestion, link degradation, and Radio Link Failure (RLF).

29. The method of claim 28.

30. The congestion type link problem includes at least one of Radio Bearer (RB) congestion, RLC channel congestion, link level congestion, or higher layer congestion.

30. The method of claim 29.

31. The link problem detected is either a short-term problem or a long-term problem.

31. The method of any one of claims 28 to 30.

32. The flow information includes a flow identifier for identifying one or more of the communication flows that are affected by the detected link problem.

32. The method of any one of claims 20 to 31.

33. determining one or more communication flows affected by the detected link problem using a mapping table that maps the detected link problem to one or more affected communication flows identified by respective flow identifiers.

33. The method of any one of claims 20 to 32.

34. the flow identifier (ID) is one of a Data Radio Bearer (DRB) identifier (ID), a Signalling Radio Bearer (SRB) ID, a Sidelink (SL) DRB ID, a SL SRB ID, an RLC bearer ID, an RLC channel ID, a link ID for identifying a link associated with the detected link problem; A method according to claim 32 or claim 33.

35. Transmitting the link problem feedback information includes transmitting a link problem signaling message including the link problem feedback information.

35. The method of any one of claims 20 to 34.

36. The link problem signaling message is transmitted in a container, the container including one of a MAC CE container, a Sidelink Relay Adaptation Protocol (SRAP) control packet data unit (PDU), or an RRC signaling.

36. The method of claim 35.

37. Transmitting the link problem feedback information includes transmitting the link problem signaling message by one of a unicast communication, a multicast communication, or a broadcast communication. A method according to claim 35 or claim 36.

38. The link problem signaling message includes a flow identifier information element of the flow information, and further includes at least one of an information element for indicating a type of the link problem signaling message, an information element for identifying at least one of the plurality of nodes to which the link problem feedback information is to be sent, an information element for identifying a type of the detected link problem, an information element for indicating a reason for the detected link problem, an information element for indicating a Quality of Service (QoS) or priority level to be ensured by the relay UE node, and an information element for indicating a magnitude or level of the detected link problem.

38. The method of any one of claims 35 to 37.

39. The type of the link problem signaling message includes one of a link problem feedback type, a (re)selection feedback type, or a link status change feedback type.

39. The method of claim 38.

40. A method for processing link problem feedback information in a node of a wireless communication system, the link problem feedback information signaling a link problem in the wireless communication system, the wireless communication system including the node, a relay UE node and at least one other node, the method comprising: receiving link problem feedback information from the relay UE node, the link problem feedback information including flow information for identifying one or more communication flows affected by a detected link problem; processing the link problem feedback information to determine one or more of the communication flows that are affected by the detected link problem based on the flow information, and assessing a level of impact of the detected link problem on data communication at the node on one or more of the determined communication flows; and performing an action at the node based on the assessed level of impact of the detected link problem. A method comprising:

41. The link problem is at least one of a plurality of different types of link problems, the plurality of types of link problems including handover, congestion, link degradation, RLF, short-term or long-term link problems, and the link problem feedback information further includes information for identifying the type of link problem.

41. The method of claim 40.

42. The flow information includes a flow identifier for identifying one or more of the communication flows that are affected by the detected link problem.

42. The method of any one of claims 40 to 41.

43. The flow identifier (ID) is any one of a Data Radio Bearer (DRB) identifier (ID), a Signalling Radio Bearer (SRB) ID, a Sidelink (SL) DRB ID, a SL SRB ID, an RLC bearer ID, an RLC channel ID, and a link ID for identifying a link related to the detected link problem.

43. The method of claim 42.

44. Receiving link problem feedback information includes receiving a link problem signaling message including the link problem feedback information.

44. The method of any one of claims 40 to 43.

45. The received link problem signaling message is included in a container, the container including either a MAC CE container, a Sidelink Relay Adaptation Protocol (SRAP) control Packet Data Unit (PDU), or an RRC signaling.

45. The method of claim 44.

46. The link problem signaling message includes a flow identifier information element of the flow information, and further includes at least one of an information element for indicating a type of the link problem signaling message, an information element for identifying at least one of the plurality of nodes to which the link problem feedback information is to be sent, an information element for identifying a type of the detected link problem, an information element for indicating a reason for the detected link problem, an information element for indicating a Quality of Service (QoS) or priority level to be ensured by the relay UE node, and an information element for indicating a magnitude or level of the detected link problem. A method according to claim 44 or claim 45.

47. and determining a type of the link problem signaling message based on the information element for indicating a type of the link problem signaling message, the type of the link problem signaling message being one of a link problem feedback type, a (re)selection feedback type, or a link status change feedback type.

47. The method of claim 46.

48. Determining whether to take action includes determining whether to take action at the node based on the determined type of link problem signaling message and the assessed level of impact of the detected link problem.

48. The method of claim 47.

49. Taking action at the node includes any of releasing links associated with one or more of the affected communication flows, performing a (re)selection, waiting for new link problem feedback information, and adapting the transmission of data on one or more of the affected communication flows.

49. The method of any one of claims 40 to 48.

50. 1. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, the relay UE node relaying data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes, the method in the relay UE node comprising: detecting a link problem in the wireless communication system; generating link problem feedback information for the detected link problem, the link problem feedback information including information for identifying a type of the detected link problem; transmitting a discovery message including the link problem feedback information. method.

51. The link problem feedback information includes context information to indicate a context of the detected link problem.

51. The method of claim 50.

52. Transmitting the discovery message includes broadcasting the discovery message.

52. The method of claim 50 or claim 51.

53. Transmitting the discovery message includes transmitting the discovery message as an announcement message.

52. The method of any one of claims 50 to 51.

54. receiving a discovery request message from a remote UE node; Transmitting a discovery message includes transmitting the discovery message in response to a received discovery request message.

52. The method of any one of claims 50 to 51.

55. 1. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, the relay UE node relaying data between at least one of the plurality of nodes and at least one other of the plurality of nodes, the method in the relay UE node comprising: detecting a link problem in the wireless communication system; and in response to detecting the link problem, ceasing transmission of one or more discovery messages. method.

56. The detected link problem is at least one of a plurality of different types of link problems, the plurality of different types of link problems including handover, congestion, link degradation, Radio Link Failure (RLF), short-term or long-term link problems.

56. The method of any one of claims 50 to 55.

57. 1. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, the relay UE node relaying data between at least one of the plurality of nodes and at least one other of the plurality of nodes, the method in the relay UE node comprising: Detecting a congested link problem in a wireless communication system; generating link problem feedback information in response to detecting the congested link problem, the link problem feedback information including information indicating that a congested link problem has been detected; transmitting said link problem feedback information in a relay (re)selection signaling. method.

58. 58. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out a control method according to any one of claims 1 to 57.

59. 60. A computer readable medium carrying a computer program according to claim 58.

60. 1. An apparatus for a relay user equipment (UE) node of a wireless communication system, the relay UE node relaying data between at least one of a plurality of nodes of the wireless communication system and at least one other node of the plurality of nodes, the apparatus comprising: Identifying a relay capability for relaying data by the relay UE node; determining whether relaying by the relay UE node to one or more remote UE nodes is supportable based on the determined relay capabilities; and in response to determining that relaying by the relay UE node to one or more remote UE nodes is supportable, transmitting a sidelink management message to indicate that relaying by the relay UE node to one or more remote UE nodes is supportable. and one or more processing units configured to, in response to determining that relaying by the relay UE node to one or more remote UE nodes cannot be supported, transmit a sidelink management message to indicate that relaying by the relay UE node to one or more remote UE nodes cannot be supported, or not transmit the one or more sidelink management messages. Device.

61. One or more of the processing units are further configured to perform the method according to any one of claims 2 to 12.

61. The apparatus of claim 60.

62. 1. An apparatus for a remote user equipment (UE) node for a wireless communication system, the apparatus comprising: receiving a sidelink management message from a relay UE node indicating whether relaying of data by the relay UE node to one or more remote UE nodes is supportable; and one or more processing units configured to perform an action based on the received sidelink management message. Device.

63. One or more of the processing units are further configured to perform the method according to any one of claims 14 to 18.

63. The apparatus of claim 62.

64. 1. An apparatus for a remote user equipment (UE) node of a wireless communication system, the apparatus comprising: Sending a request message to initiate communication with the relay UE node; and one or more processing units configured to perform actions including at least one of: performing (re)selection, or performing a discovery process, or a direct link establishment process, or a direct communication process, for a different relay UE node, in response to not receiving a message in response to the request message; or determining that there are no available relay UE nodes for the remote UE node. Device.

65. 1. An apparatus for a relay user equipment (UE) node of a wireless communication system, the relay UE node relaying data between at least one of a plurality of nodes of the wireless communication system and at least one other node of the plurality of nodes, the apparatus comprising: Detecting a link problem in the wireless communication system; generating link problem feedback information of the detected link problem in response to detecting the link problem, the link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem; and one or more processing units configured to transmit the link problem feedback information. Device.

66. One or more of the processing units are further configured to carry out a method according to any one of claims 21 to 39.

66. The apparatus of claim 65.

67. An apparatus for a node of a wireless communication system, the apparatus comprising: receiving link problem feedback information from a relay UE node signaling a link problem in the wireless communication system, the link problem feedback information including flow information for identifying one or more communication flows affected by a detected link problem; determining, based on the flow information, one or more of the communication flows that are affected by the detected link problem, and processing the link problem feedback information to assess a level of impact of the detected link problem on data communication of the node on the one or more determined communication flows; and one or more processing units configured to perform an action at the node based on the assessed level of impact of the detected link problem. Device.

68. One or more of the processing units are further configured to perform a method according to any one of claims 41 to 49.

68. The apparatus of claim 67.

69. 1. An apparatus for a relay user equipment (UE) node of a wireless communication system, the relay UE node relaying data between at least one of a plurality of nodes of the wireless communication system and at least one other node of the plurality of nodes, the apparatus comprising: Detecting a link problem in the wireless communication system; generating link problem feedback information for the detected link problem, the link problem feedback information including information for identifying a type of the detected link problem; and one or more processing units configured to transmit a discovery message including the link problem feedback information. Device.

70. 1. An apparatus for a relay user equipment (UE) node of a wireless communication system, the relay UE node relaying data between at least one of a plurality of nodes of the wireless communication system and at least one other node of the plurality of nodes, the apparatus comprising: Detecting a link problem in the wireless communication system; and one or more processing units configured to stop transmitting one or more discovery messages in response to detecting the link problem. Device.

71. 1. An apparatus for a relay user equipment (UE) node of a wireless communication system, the relay UE node relaying data between at least one of a plurality of nodes of the wireless communication system and at least one other node of the plurality of nodes, the apparatus comprising: Detecting a congested link problem in the wireless communication system; generating link problem feedback information in response to detecting the congested link problem, the link problem feedback information including information indicating that a congested link problem has been detected; and one or more processing units configured to transmit said link problem feedback information in a relay (re)selection signaling. Device.

72. A relay UE node of a wireless communication system including a plurality of nodes, the relay UE node comprising: at least one communication interface for relaying data between at least one of the plurality of nodes and at least one other of the plurality of nodes; a processing unit connected to at least one of said communication interfaces and configured to perform a method according to any one of claims 1 to 12, 18, 20 to 39, 50 to 57. Relay UE node.

73. A node of a wireless communication system including a relay UE node and at least one other node, said node comprising: at least one communication interface for communicating data between said node and at least said relay UE node; a processing unit connected to at least one of said communication interfaces and configured to perform the method according to any one of claims 13 to 19 and 40 to 49. node.

Images