Managing link problems in sidelink relay systems

Abstract

The present invention provides a method and apparatus for a sidelink relay system that reduces link problem perturbations while ensuring QoS of relay traffic. [Solution] In a wireless communication system including a relay UE node, the relay UE node identifies its relay capability for data relay, determines whether it can support relaying by the relay UE to one or more remote UE nodes based on the identified relay capability, and sends a sidelink management message to indicate that relaying by the relay UE node is supported. Alternatively, in response to determining that relaying by the UE node is not supported, the relay UE node sends a sidelink management message to indicate that relaying by the relay UE node is not supported, or does not send one or more sidelink management messages.

Description

Technical Field

[0001] The present invention generally relates to the management of link problems in a sidelink relay system and / or the signaling of link problems in a wireless communication system, and more particularly to methods executed at different nodes in a sidelink relay system, methods and apparatuses for signaling link problems in a sidelink relay system, and methods and apparatuses for processing link problem feedback information for signaling link problems in a sidelink relay system.

Background Art

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

[0003] Recent Cellular-vehicle-to-everything (C-V2X) technologies are expected to support an intelligent transportation system (ITS) in which all road users, including vehicles and pedestrians, cooperate with each other via wireless communication, improve traffic efficiency (such as alleviating traffic jams), and improve traffic safety while avoiding traffic accidents. Wireless communication aims to enhance the visibility of vehicles, especially in Non-Line-Of-Sight (NLOS) conditions, bad weather, or high traffic density, by exchanging messages among road users such as vehicles, Vulnerable Road Users (VRUs) (pedestrians, bicycles, etc.), 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 a vehicle can establish communication with "everything", which means different network entities and user equipment (UE). The following communications are considered: - V2V or Vehicle-to-Vehicle communication for exchanging 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 that provide traffic safety services. - Vehicle-to-Network (V2N) or V2N, which connects vehicles to cellular base stations for real-time traffic.

[0004] 3GPP has developed standards for UE-to-UE direct communication, known as Sidelink (SL) communication or PC5 communication (such as 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. Subsequent versions of Sidelink for LTE have focused primarily on vehicle-to-vehicle (V2V) related use cases and have introduced Basic Safety Messaging (BSM). Note that the term UE in UE-to-UE direct communication can refer to a UE in a VRU (such as a pedestrian UE) or to an UE inside or within a vehicle or RSU.

[0005] The initial version of Sidelink for 5G or New Radio (NR) was developed in Release 16 as part of the 5G V2X Work Item, and in addition to complementing the existing basic security services, it supports advanced V2X scenarios and commercial applications and services.

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

[0007] NR Sidelink is designed to provide three basic transmission scenarios: broadcast, groupcast, and unicast, while also considering deployment scenarios both outside of coverage and within the network.

[0008] In this regard, sidelink relay is being studied by 3GPP with the aim of providing improved power efficiency along with extended sidelink / network coverage, enabling a wider range of applications and services.

[0009] 3GPP has approved the Release 17 (Rel-17) study item, "Study on NR Sidelink Relay," which covers the extensions and solutions necessary to support both UE-to-Network (U2N) and UE-to-UE (U2U) sidelink relay as described in 3GPP TR 38.836. This study covers discovery procedures, both Layer 2 and Layer 3 UE-to-Network and UE-to-UE relay, and includes 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 relaying. This Sidelink Relay Adaptation Layer (SRAP) will be placed 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 relay to expand sidelink coverage, as well as service continuity and multipath communication.

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

[0013] The presence of a relay UE between the two aforementioned hops means that 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) can mask potential problems occurring at the other hop from one hop.

[0014] In wireless communication, various types of problems can occur. The first problem is congestion, which occurs when the amount of data transmitted over a hop exceeds the network's current capacity, i.e., the resources / bandwidth available for transmission. To enable quality of service differentiation in a Radio Access Network (RAN), systems use different logical channels for transmitting data of different priorities. This allows for differentiation of resource allocation for each logical channel depending on the channel's priority level. As a result, congestion can occur on one or more specific channels, depending on the network's current capacity and the QoS required for the data being transmitted. As shown in Figures 2A and 2B, which represent the protocol stacks of the user planes for UE-to-Network (U2N) and UE-to-UE (U2U) relays, congestion can be detected at different levels within the protocol stack, and congestion on a particular channel can be detected at a single radio bearer (RB) of the QoS flow or at the corresponding hop's ingress / outgress radio link control (RLC) channels. In more severe cases, global congestion can occur, affecting all radio bearers and RLC channels.

[0015] Other issues related to the propagation environment, such as RF signal attenuation due to objects or adverse weather conditions, and the mobility of user equipment, can occur on the link, potentially leading to a significant decrease in signal strength, especially when using high-throughput millimeter-wave signals. This can cause link degradation or radio link faults (RLF) at the corresponding hops.

[0016] As mentioned above, RAN links can suffer from a variety of problems. These problems can lead to continuous data loss and increased latency, resulting in a decline in quality of service (QoS). Link problems stemming from these issues can include congestion detected by the relay UE, link degradation, or radio link failure. Congestion may occur on a radio bearer or RLC channel, or it may affect a group of RLC channels.

[0017] A link problem detected at the first hop is detected by the affected node and the relay UE (the affected node is connected to the relay UE via the first hop, for example). However, the link problem is not notified to the second node at the second hop (e.g., another remote UE or gNB connected to the relay UE), so the link problem affects the transmission or reception of traffic at the second node. The reverse is also true; if a link problem is detected at the second hop, it is not notified to the affected node at the first hop. This partial visibility of relay traffic can lead to a series of retransmission requests with degraded QoS, amplifying the link problem and potentially affecting other bearers and channels.

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

[0019] According to a first aspect of the present invention, a method is provided for signaling a link problem in a wireless communication system, the wireless communication system comprising a relay user equipment (UE) node and a plurality of nodes, the relay UE node being for relaying data between at least one of the plurality of nodes and at least one other node of the plurality of nodes, and the method in the relay UE node includes: To detect link problems in wireless communication systems; In response to the detection of the link problem, link problem feedback information is generated for the detected link problem, and the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem; Please submit feedback information regarding the link issue.

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

[0021] For example, link problem feedback information may be sent to all of the multiple nodes connected to the relay UE.

[0022] Multiple nodes may include at least two remote UEs. Multiple nodes may include at least two remote UEs and network nodes such as gNBs.

[0023] According to a second aspect, a method is provided for processing link problem feedback information at a node in a wireless communication system, the link problem feedback information signals a link problem in the wireless communication system, the wireless communication system includes a node, a relay UE node, and at least one other node, and the method includes: Receiving link problem feedback information from the relay UE node, wherein the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem, The link problem feedback information is processed to determine one or more communication flows affected by the detected link problem based on the flow information, and the level of impact the detected link problem has on data communication at the node on the one or more determined communication flows is evaluated. To take 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, a link ID (such as a PC5 ID or Uu ID) for identifying the link associated with the detected link problem.

[0025] 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 the type of handover, congestion, link degradation, RLF, temporary / short-term or long-term / permanent 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 the reason or context of the detected link problem. The reason ID may represent the reason or context of the detected link problem in addition to identifying the type 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 a relay UE node. The link problem feedback information may further include information for indicating the type of the link problem signaling message. For example, the type may be any of 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] Generate link problem feedback information including flow information for identifying one or more communication flows affected by the detected link problem, and transmit 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 affected node may be at least a source node or transmitter configured for data transmission, and may also be a remote UE or network node). Thus, the nodes affected in the sidelink relay connection or path (including, for example, "hidden" nodes) can be notified of the detected link problem, and the affected nodes can take appropriate actions. Actions at the affected nodes may include, for example, releasing (re)selecting the links associated with one or more affected communication flows, waiting for feedback information on new link problems, resuming data transmission on one or more affected communication flows, etc. This means that when a link problem occurs, retransmission requests accompanied by QoS degradation can be avoided from occurring continuously, and the link problem can be prevented from being amplified and affecting other bearers and channels.

[0028] By including a flow identifier for identifying one or more communication flows affected by the detected link problem, and optionally information for identifying the type of the detected link problem (which may also include the reason for the link problem), the relay UE node can provide feedback information for identifying the granularity of the link problem that can help the affected node take optimal actions for the detected link problem (for example, the affected node can quickly take actions based on the details of the link problem and can adapt its operation smartly).

[0029] Information indicating the type of link problem signaling message (such as the PDU type) helps a node receiving the link problem signaling message to indicate one or more actions it should take. By including information indicating the type of link problem signaling message in the link problem feedback information (flow identifier, information for identifying the type of link problem detected), link problem signaling messages can have the same format for different link problems. In other words, link problem signaling messages can have the same format whether the link problem signaling message signals link problem feedback, (re)selection feedback, or link status change feedback. PDU type information and link problem feedback information can be used to determine what action a node receiving a link problem signaling message should take.

[0030] According to a third aspect, a method for signaling a link problem in a wireless communication system is provided, as described in claim 44 of the appended claims. By having a relay UE node transmit link problem information in a discovery message (for example, a message for identifying a relay UE to a remote UE node in the vicinity or coverage area of ​​the relay UE node), a remote UE node can avoid selecting a node as a relay UE node that is actually unable to provide relay services to the remote UE node due to some link problem.

[0031] Information for identifying the type of link problem detected (e.g., whether the link problem is one of the following types: handover, congestion, link degradation, RLF, temporary / short-term, or long-term / permanent) 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 to indicate the reason or context for the detected link problem. In addition to identifying the type of link problem detected, the reason ID may represent the reason or context for the detected link problem, as described above.

[0032] According to a fourth aspect, a method for signaling a link problem in a wireless communication system is provided, as described in claim 53 of the appended claims. By having knowledge of a link problem that causes a relay UE node to send a reselection message, a remote UE node can make a more efficient decision on whether to maintain its connection to the relay UE node anyway, attempt to reconnect after a short time (taking into consideration that the congestion may be transient and may be relieved soon), or actually perform relay reselection.

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

[0034] Sidelink management messages include relay capability information indicating the relay capability of a relay UE node for relaying data through that relay UE node.

[0035] Sidelink management messages are either discovery messages or link management messages (such as direct link messages or direct communication messages). Discovery messages can be announcement or response messages sent in response to an received discovery solicitation message. Link management messages can be direct link establishment acceptance / rejection messages, direct link modification acceptance / rejection messages, direct link modification / release request messages, or direct communication acceptance / rejection messages.

[0036] According to a sixth aspect, a method is provided that is performed by a remote user equipment (UE) node of a wireless communication system, as described in claim 13.

[0037] Sidelink management messages include relay capacity information indicating the relaying capacity of the relay UE node for relaying data through the relay UE node.

[0038] Sidelink management messages are either discovery messages or link management messages (such as direct link messages or direct communication messages).

[0039] The relay capability information included in the sidelink management message may include one or more of the following: new connection information to indicate whether the relay UE node can accept new connections to new remote UE nodes; relay load information to indicate the current load on the relay UE node; QoS (Quality of Service) information to indicate the QoS level of each of the one or more communication flows currently provided by the relay UE node; sidelink measurement report information to indicate 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 to indicate the radio quality of the communication link between the relay UE node and the network nodes of the wireless communication system; bitrate information to indicate the maximum bitrate currently supported by the relay UE node; and network load information to indicate the current channel occupancy and the remaining bandwidth for new communications.

[0040] By identifying the relaying capabilities of a relay UE node and determining whether it can support relaying to one or more remote UE nodes, the relay UE node can proactively take action to avoid or minimize the risk of link problems by preventing or allowing new connections to one or more new remote UEs, and / or preventing or allowing changes to existing connections, and / or changing or releasing existing connections. The relay UE node can act proactively by sending sidelink management messages (such as discovery messages) that indicate whether relaying by the relay UE is supported (e.g., whether new connections are supported / allowed) and can provide additional or alternative 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 future link problems, the relay UE node can act proactively by stopping its sidelink management processes (e.g., the discovery process, or link management processes such as the direct link process or direct communication process) to refrain from sending or stop sending one or more sidelink management messages (discovery messages). By failing to send or stopping the sending of one or more sidelink management messages, UEs near the relay UE node will no longer receive information from it. For example, in the discovery process, UEs near the relay UE node will not consider that relay UE when performing relay (re)selection. Upon receiving a sidelink management message containing relay capability information, a remote UE node can decide what action to take based on that information (e.g., whether to request connection establishment with the relay UE node). If the sidelink management message contains information indicating the relay UE node's actual or current relay capability, the remote UE node has additional information to base its decision on what action to take.This allows the remote UE node to select the optimal action (for example, the best relay UE node to connect to in the case of a discovery process) based on the required QoS, bitrate, link quality, and load requirements.

[0041] According to the seventh aspect, a method is provided that is performed by a remote user equipment (UE) node in a wireless communication system, as described in claim 19.

[0042] If a relay UE node fails to send sidelink management messages, stops sending them, or halts the sidelink management process to stop forwarding, or if no sidelink management messages are received after a request message is sent, the relay UE notifies the new or remote UE node that it is overloaded or experiencing other limitations affecting the relay UE node's ability to support new and existing connections. For example, in the discovery process, if no discovery response message is received after a discovery request message is sent, or if there are no available relay UE nodes (for example, if the discovery request message is broadcast), or if the target relay UE (in the case of unicast) is overloaded or experiencing other limitations affecting the relay UE node's ability to support new connections to the remote UE node, the remote UE node is notified. Based on the information obtained by the remote UE, it can determine what actions it should take.

[0043] In summary, a method is proposed for a sidelink relay system to reduce link problem perturbations while ensuring QoS for relay traffic.

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

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

[0046] Further features of the present invention are described in other independent and dependent claims.

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

[0048] Furthermore, functions implemented in hardware may be implemented in software, and vice versa. Any references to software and hardware features in this specification should be interpreted accordingly. For example, according to another aspect of the present invention, a computer program is provided which, when executed by a processing unit, includes instructions causing the processing unit to perform any of the methods of the above-described aspects or embodiments, and a computer-readable storage medium for holding the computer program. [Brief explanation of the drawing]

[0049] Herein, different aspects of the present invention will be described, for illustrative purposes only, with reference to the following drawings: [Figure 1] A schematic diagram showing the configuration of sidelink relay with UE-to-network based relay and UE-to-UE based relay; [Figure 2A] This is a schematic diagram showing a UE-to-network user plane sidelink (SL) relay architecture with an adaptation layer in accordance with 3GPP TR 38.836; [Figure 2B] This is a schematic diagram showing a UE-to-UE user plane sidelink (SL) relay architecture with an adaptation layer in accordance with 3GPP TR 38.836; [Figure 3]This is a schematic diagram showing a 1:1 mapping between a wireless bearer (RB) and a PC5 RLC channel, and an N:1 mapping to a Uu RLC channel in Uu SRAP for UE-to-network sidelink relay; [Figure 4] This is a schematic diagram showing N:1 and 1:1 mapping between a radio bearer (RB) and a PC5 RLC channel, and N:1 mapping between a PC5 RLC channel and a PC5 SRAP for UE-to-UE sidelink relay; [Figure 5] This is a schematic diagram showing an example of a link problem signaling message format according to an embodiment of the present invention; [Figure 6A] This is a flowchart illustrating an exemplary method for detecting a link problem at a relay node and generating link problem feedback information, according to an embodiment of the present invention; [Figure 6B] This is a flowchart illustrating an exemplary method for processing link problem feedback information at an affected node according to an embodiment of the present invention; [Figure 7A] This is a flowchart illustrating an exemplary method at a relay node for generating a link problem signaling message containing information to indicate relay (re)selection feedback, according to an embodiment of the present invention; [Figure 7B] This is a flowchart illustrating an exemplary method at an affected node for processing information contained in a link problem signaling message generated by the method described with respect to Figure 7A, according to an embodiment of the present invention; [Figure 8A] This is a flowchart illustrating an exemplary method at a relay node for generating a link problem signaling message containing information to indicate link status change feedback, according to an embodiment of the present invention; [Figure 8B] This is a flowchart illustrating an exemplary method at an affected node for processing information contained in a link problem signaling message generated by the method described with respect to Figure 8A, according to an embodiment of the present invention; [Figure 9]This is a flowchart illustrating an exemplary method for signaling link problems in a sidelink relay system according to an embodiment of the present invention; [Figure 10] This is a flowchart illustrating an exemplary method for processing link problem feedback information at affected nodes in a sidelink relay system after receiving feedback from a relay UE, according to an embodiment of the present invention; [Figure 11A] This is a schematic diagram showing an example of the format of a link problem signaling message according to an embodiment of the present invention; [Figure 11B] This is a schematic diagram showing an example of the format of a link problem signaling message according to an embodiment of the present invention; [Figure 11C] This is a schematic diagram showing an example of the format of a link problem signaling message according to an embodiment of the present invention; [Figure 11D] This is a schematic diagram showing an example of the format of a link problem signaling message according to an embodiment of the present invention; [Figure 11E] This is a schematic diagram showing an example of the format of a link problem signaling message according to an embodiment of the present invention; [Figure 12] This is a schematic block diagram of an exemplary wireless communication device according to an embodiment of the present invention; [Figure 13] This is a flowchart of an exemplary method performed at a relay UE node according to an embodiment of the present invention; [Figure 14A] This is a flowchart illustrating an example of a method executed on a remote UE node according to an embodiment of the present invention; [Figure 14B] This is a flowchart illustrating an example of a method executed on a remote UE node according to an embodiment of the present invention. [Modes for carrying out the invention]

[0050] Figure 1 illustrates an example of a wireless communication system capable of supporting sidelink relay, showing a sidelink relay configuration or system including relay user equipment (UE) nodes and multiple nodes. A relay UE node relays data between at least one of the multiple nodes and at least one other of the multiple nodes. For example, in Figure 1, UE node 100 can act as a relay UE node relaying data between one of UE nodes 101, 102, and 103 (referred to as the remote UE node) and network node 107 in the case of UE-to-network relay, and / or can act as a relay UE node relaying data between one of UE nodes 101, 102, and 103 (referred to as the remote UE node) and another of UE nodes 101, 102, and 103 in the case of UE-to-UE relay. UE node 102 can also function as a relay node (for example, relaying data between UE 100 (in this case, the remote UE node) and network node 107, and between UE 100, 101, and 103 over the PC5 connection (part of which is not shown in Figure 1)). Thus, as shown in Figure 1, the 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] Multiple nodes may include at least two remote UE nodes (in Figure 1, UE node 100 is a relay node, and three remote UE nodes 101, 102, and 103 are shown), and may also include a network node 107. The network node 107 may be a base station of a radio network, such as a fifth-generation (5G) New Radio (NR) network or a Long-Term Evolution (LTE) network. For clarity, Figure 1 shows only base stations of radio networks. In the case of a 5G NR network, the network node 107 is called a gNB. Figure 1 (and some of the other figures) shows UE nodes represented by a vehicle, but the invention is not intended to be limited to UE nodes that are in or part of a vehicle. Each of the UE nodes (relay or remote) may be a radio communication device located in or part of a vehicle, or a Road Side Unit (RSU), or a Vulnerable Road User (VRU) radio communication device (e.g., a mobile or portable communication device of a pedestrian or cyclist, such as a smartphone, PDA, laptop, or similar device). Hereinafter, relay UE nodes will also be referred to as relay UEs, remote UE nodes as remote UEs, and network nodes as gNBs. In the following description, embodiments and examples of the present invention will be described in relation to a 5G NR network, but it will be understood that the present invention is not intended to be limited to 5G NR systems and can be used in any wireless communication system that supports sidelink (or peer-to-peer) relay communication.

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

[0053] The connection between a remote UE (such as remote UE1 101) and gNB107 can be established by establishing a PC5 connection between remote UE1 101 and relay UE100, with remote UE1 101 being the initiator of the connection. The Uu connection between relay UE100 and gNB107 is established via RRC setup (before or after the PC5 connection is established), with relay UE100 being the initiator of the connection. Then, remote UE1 101 initiates RRC setup with gNB107 via relay UE100, which forwards an RRC message from remote UE1 101 to gNB107 for an "RRC setup request" and forwards an RRC message from gNB to remote UE1 101 for an "RRC setup response".

[0054] In the example shown in Figure 1, UE100 can also act as a UE-to-UE relay by connecting remote UEs 101, 102, and 103 together in a UE-to-UE (or U2U) scenario. Therefore, for example, a communication path can be set up between remote UE1 101 and remote UE2 102 via relay UE100, which connects PC5 hops 101a and 102a together. In UE-to-UE relay, once a sidelink relay connection is established between two remote UEs, the remote UE sending data (packets, etc.) is identified as the source remote UE or source UE and is connected to the relay UE by a first PC5 hop or link, while the other remote UE receiving data (packets, etc.) is identified as the 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 can be a sending node or transmitter that sends packets to the destination or target UE via the relay UE and the two PC5 hops. In a U2U scenario, the two direct connections (PC5 hops) between the relay UE and the other two UEs (source UE and target UE) are established in the same way as when the PC5 connection is established in a U2N scenario, as described above. 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 configure relay traffic between a first node (remote UE) and a second node (gNB or remote UE), a sidelink relay architecture conforming to 3GPP TR 38.836 may be used. The user plane architecture or protocol stack is shown in Figures 2A and 2B and represents a sidelink relay adaptation layer called SRAP. The SRAP layer is introduced between the PDCP layer and the RLC layer at extreme nodes and above the RLC layer at relay UEs. This architecture was first documented in TR 38.836 and finally refined in 3GPP TS 38.351.

[0056] The architecture shown in Figure 2A represents the sidelink relay architecture for a UE-to-Network relay scenario. The architecture shown in Figure 2B represents the 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, in the case of UE-to-UE relay, the relay UE has two PC5 SRAP entities or layers 221 and 222.

[0057] As shown in Figure 2A for a 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 the relay UE (such as relay UE100), there are two SRAP layers to interface the PC5 hop 101a and the Uu hop 105a. The PC5 SRAP layer 202 is connected to the PC5 SRAP 201 of remote UE101 via the PC5 hop 101a, and the Uu SRAP layer or entity 203 is connected to the Uu SRAP layer 204 of gNB side 107 via the Uu link 105a. Remote UE101 establishes an End-to-End radio bearer 205 with gNB107. These radio bearers can be Signaling Radio Bearers (SRBs) or Data Radio Bearers (DRBs). Figure 2A shows an example of an E2E Uu DRB between remote UE101 and gNB107.

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

[0059] The mapping table takes 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 inlet PC5 RLC channel (or bearer) 206 as inputs, and identifies the outlet 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 by the Uu SRAP entity 203. An example of an entry in an uplink mapping table having one entry consisting of the Uu SRAP entity 203 is shown in Table 1 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 1 TIFF2026097950000002.tif21140

[0060] On the Uu side or on 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. This will be explained in more detail below.

[0061] In the downlink direction, data or packets transmitted from gNB107 arrive at relay UE100 via Uu link 105a. The ingress Uu RLC channels 100b and 100c in the Uu SRAP entity 203 of relay UE100 are mapped to the exit PC5 RLC channel 206 at PC5 hop 101a. The corresponding downlink packets are transmitted from Uu SRAP entity 203 to PC5 SRAP entity 202 and then to remote UE101 via PC5 RLC channel 206. Thus, a mapping table is required for the downlink, configured by gNB107 for the Uu SRAP entity 203 of relay UE100. The mapping table requires the L2-ID of remote UE101, the End-to-End radio bearer 205 ID, and the ingress Uu RLC channel (or bearer) IDs 100b and 100c as inputs, and sends the outgress PC5 RLC channel (or bearer) ID 206 to the PC5 SRAP entity 202 of the same relay UE100. The End-to-End radio bearer 205 is then mapped to the outgress PC5 RLC channel 206 at PC5 hop 101a. For example, the UE E2E bearer ID and remote UE ID can be obtained from the header of the packet received by the Uu SRAP entity 203. An example of a downlink mapping table with one entry configured in 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 TIFF2026097950000003.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 on the remote UE 101 has a corresponding receiver on the PC5 SRAP entity 202 on the UE-to-Network relay UE 100, and vice versa. Via the Uu interface 105a, the transmitter of the Uu SRAP entity 203 on the UE-to-Network relay UE 100 has a corresponding receiver on the Uu SRAP entity 204 on the gNB 107, and vice versa.

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

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

[0065] Figure 3 also shows the 1:1 mapping between the UE-to-Network relay radio bearers 101b, 101c, 102b, and 103b and PC5 RLC channels 206a through d. E2E RBs 101b, 101c, 102b, and 103b are mapped to PC5 RLC channels 206a, 206b, 206c, and 206d, respectively, on PC5 interfaces 101a, 102a, and 103a. Since the relay UE 100's Uu SRAP 203 supports N:1 bearer mapping, as shown in Figure 3, PC5 RLC channels 206a and 206c are mapped to the same Uu RLC channel 100b, while the remaining PC5 RLC channels 206b and 206d are mapped to the second Uu RLC channel 100c on Uu link 105a. N:1 mapping can exist for upstream (uplink) and downstream (downlink) packets or traffic.

[0066] In the case of UE-to-UE relay as shown in Figure 4, the mapping is performed over two PC5 hops. In other words, in an example scenario where remote UE1 101 communicates with remote UE2 102 via relay UE100, the mapping is performed at PC5 hop 101a between remote UE1 101 and relay UE100, and at PC5 hop 102a between relay UE100 and remote UE2 102. N:1 mapping is supported by the source UE's PC5 SRAP entity (e.g., SRAP entity 201 of remote UE1 101) for mapping between Remote UE SL Radio Bearers and the PC5 RLC channel for relay (e.g., the first PC5 hop 101a), as agreed in 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, an N:1 mapping can be applied if the bearers of the two destinations are mapped to the same RLC channel. The PC5 SRAP entity at the second PC5 hop 102a (e.g., the SRAP entity 222 at the relay 100) supports an 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 can apply an N:1 mapping by mixing the bearers of each source UE onto the same RLC channel to reach the same destination or target UE. The second PC5 SRAP entity 222 behaves similarly to the Uu SRAP entity 203 in the case of UE-to-Network relay.

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

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

[0069] Because various types of link problems can occur, such as congestion, link degradation, link failure, transient or long-term link problems, an object of embodiments 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 link problem feedback information to one or more nodes affected by the detected link problem, and / or all nodes currently connected to the relay UE node, and / or 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 associated with one or more communication flows affected by the detected link problem (e.g., affected nodes that perform packet transmission and / or reception) can be notified. A communication flow may be data or control flow of relay data or packets corresponding to one or more radio bearers and / or links (e.g., 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). Therefore, communication flows affected by a detected link problem may include communication flows having a corresponding, link-affected 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. The relay UE node determines the affected nodes and notifies at least one of the affected nodes. For example, the relay UE node notifies an affected node determined to be a source node (e.g., configured to transmit data) (e.g., by sending link problem feedback information), and / or notifies an affected node determined to be a destination node or target node (e.g., configured to receive data).When a sidelink relay connection is established between a source node, a relay node, and a destination node, the nodes associated with the affected communication flow may be the source node (e.g., source UE) and / or destination (or target) node (e.g., destination or target UE) associated with the affected communication flow (for example, the detected link problem may be related to at least one of the first link between the source node and the relay node, and the second link between the destination node and the relay node).

[0070] The following three scenarios are considered in which nodes affected by detected link problems 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 notifies the type of link problem, triggers a relay (re)selection to the remote UE, and optionally the relay UE releases the PC5 link with that remote UE. 3. Link status change feedback to notify affected nodes that the status of the corresponding link has changed (failed or recovered).

[0071] (Link problem feedback) As explained earlier, the relay UE100 monitors its internal buffer to detect congestion. As illustrated in the architecture diagrams (Figures 2A and 2B), the SRAP entities are located just above the RLC layer, allowing the relay UE100 to identify congestion on specific RLC channels. When the relay UE detects congestion on one or more RLC channels, the relay UE100 parses a mapping table to obtain correspondences to the affected E2E bearers, ingress RLC channels, and affected nodes, and creates link problem feedback (for example, identifying one or more communication flows affected by the detected link problem).

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

[0073] As shown in Figure 3, in an example where congestion occurs in uplink communication (UE-to-Network relay scenario), i.e., when remote UEs 101, 102, and 103 are the senders (e.g., source or sender nodes that send 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 their corresponding ingress PC5 RLC channels (e.g., PC5 RLC channels 206a and 206c) are mapped to the same congested egress Uu RLC channel 100b (for example, remote UE 1 DRB1 101b and remote UE 2 DRB1, as well as PC5 RLC channels 206a and 206c, are communication flows or paths affected by the link problem related to congestion on Uu RLC channel 100b). Then, based on the mapping table of the Uu SRAP layer 203 (see Table 1 for uplinks above), the relay UE 100 determines that the IDs of the corresponding ingress PC5 RLC channels 206a and PC5 RLC channels 206c mapped to the outgress Uu RLC channel 100b, and the IDs of the E2E Radio Bearers 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 then creates congestion link problem feedback (e.g., link problem feedback information) including the PC5 RLC channel IDs and E2E Radio Bearer IDs (e.g., to identify one or more communication flows or paths affected by the link problem). If relay UE100 determines that multiple nodes (UE1 101 and UE2 102) are affected by a congestion link problem, relay UE100 sends link problem feedback to these affected nodes.To reach the affected nodes, the relay UE100 may broadcast, multicast, or groupcast the congestion link problem feedback if an address exists for a group containing these affected nodes (the creation of groups is outside the scope of this specification). Alternatively, the relay UE100 may send the congestion link problem feedback individually (unicast) to each affected node. Another alternative is that the relay UE100 may create a separate congestion link problem feedback for each affected node, i.e., containing only the information relevant to the affected node instead of the information relevant to all affected nodes, and send this dedicated congestion link problem feedback unicast to the affected node.

[0074] As shown in Figure 4, in an example where congestion occurs in a UE-to-UE (U2U) relay case where communication from UE1 101 to UE2 102 and communication from UE3 103 to UE2 102 are relayed by relay UE100 respectively, relay UE100 detects congestion on PC5 RLC channel 102c. The relay UE100 determines, based on the PC5 SRAP layer 222 mapping table (see Table 3 for the U2U case described above), that the IDs of the corresponding inlet PC5 RLC channels 206a and 206d mapped to the outlet PC5 RLC channel 102c, the 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 the ID of the E2E Radio Bearer corresponding to SL DRB1 103b of remote UE3 103 encapsulated in PC5 RLC channel 4 206d are affected by a congested link problem (remote UE1 SL DRB1 101b, remote UE1 SL DRB2 101c, and remote UE3 SL DRB1 103b, as well as PC5 RLC channels 206a and 206d are affected by a congested link problem). (For example, a communication flow or path affected by a link problem related to congestion on RLC channel 102c). The relay UE 100 creates a congestion link problem feedback (e.g., link problem feedback information) which includes the PC5 RLC channel ID and E2E Radio Bearer ID (for example, to identify one or more communication flows or paths affected by the link problem). If the relay UE 100 determines that multiple nodes (UE1 101 and UE3 103 - in this case the source nodes) are affected by a congestion link problem, the link problem feedback is sent by the relay UE 100 to these affected nodes. To reach the affected nodes, the relay UE 100 may send the congestion link problem feedback by broadcast, or by groupcast if an address exists for a group containing these affected nodes (the creation of groups is outside the scope of this specification).Alternatively, the relay UE100 may send congestion link problem feedback individually (by unicast) to each affected node. Another alternative is for the relay UE100 to create a separate congestion link problem feedback for 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 congestion link problem feedback by unicast to the affected node.

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

[0076] If relay UE100 broadcasts congestion link problem feedback, this feedback may be received by all UEs in the vicinity of relay UE100, potentially informing all UEs that the relay UE is having some difficulty reaching a particular UE. This information can 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 (for example, as shown in Figure 1), in response to the detection of the link problem, the relay UE node generates link problem feedback information for the detected link problem, which includes information to identify the type of link problem detected, 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 (for example, as shown in Figure 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) the discovery process performed by the relay UE node to stop transmitting announcement messages (in the case of discovery model A as defined in 3GPP TS 23.303 for LTE or TS 23.304 for 5G systems, V17.1.1) or arbitrary response messages (in the case of discovery model B as defined in 3GPP TS 23.303 for LTE or TS 23.304 for 5G systems, V17.1.1). When discovery messages are stopped being sent, UEs near a relay UE node (such as relay UE100) will no longer 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 (for example, in response to a trigger event), and the relay UE node has stopped sending discovery messages, the remote UE will not receive a response message. In response to not receiving a response message to the discovery request message, the remote UE takes action. The remote UE may start a timer when sending the discovery request message and take action if a response message is not received within a certain time determined by the timer. Discovery request messages can be sent by broadcast, unicast, or groupcast.Actions may include (re)selecting or performing a discovery process for another relay UE node, or determining that there are (e.g., currently) no available relays in the vicinity of the remote UE node. Various types of link problems may include congestion, link degradation, radio link failure (RLF), and short-term / temporary or long-term link problems. Discovery messages may be broadcast autonomously by the relay UE in the usual manner of Discovery Model A, or they may be discovery messages 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 their level of interest in the state of the requested relay UE, such as the link or connectivity with other UEs. Discovery messages may be received by UEs in the vicinity of the relay UE or within its coverage area. 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 for the detected link problem. The identifier may be a reason ID that only indicates the type of link problem, as described below, or it may be a reason ID that indicates both the type of link problem and the reason or context for the link problem, as described below (see also Tables 4 and 5 for examples of reason IDs).

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

[0079] In an additional embodiment, the relay UE may detect congestion in a particular E2E Radio Bearer by monitoring the amount of data associated with each E2E Radio Bearer, which is determined by examining the SRAP header of each packet at the SRAP layer to obtain the packet's Bearer ID and determining the amount of data each E2E Radio Bearer has on the RLC channel. The relay UE may detect congestion in an E2E Radio Bearer if it determines that the data ratio 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 the PC5 hop, Uu hop, or E2E radio bearer by the relay UE (as a receiving node) which sends link problem feedback information to the remote UE to identify the link problem and the communication flow affected by the detected link problem, even if the remote UE is not the source node (e.g., the sending node that sends packets to the relay UE 100 for relay to another node). In other words, the relay UE may send link problem feedback information about the detected link problem to the source node and / or destination node. The remote UE configured as the destination node does not wait for packets from the gNB and does not request retransmission until the link is restored.

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

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

[0083] Congestion can occur at the link level, whether at the PC5 hop or the Uu hop, and therefore the source node or transmitter (or destination node or receiver, as mentioned above) may be notified of link problems by the relay UE according to the following different scenario examples: -If congestion occurs at PC5 hop 101a, The transmitting or source node is the remote UE1 101: Link problem feedback information is sent from the relay UE100 to the remote UE1 101 and includes the L2-ID of the remote UE1 101 (for example, in its information element as described later, referring to Figure 5). Thus, based on the link problem feedback information, the remote UE1 101 understands that congestion is occurring throughout the entire PC5 hop 101a. If there are multiple PC5 links between the remote UE1 101 and the relay UE100, the E2E Radio Bearer 101b and 101c IDs are included in the link problem feedback information to identify which radio bearers are affected. The transmitting or source node is gNB107 in the case of U2N relay (and the remote UE (e.g., UE2 102) in the case of U2U relay). Link problem feedback information, along with the L2-ID of remote UE1 101 connected to PC5 hop 101a, is sent by relay UE100 to the source node (optionally to the destination node or receiver). The E2E Radio Bearer 101b and 101c IDs are also identified to gNB107 by Uu SRAP entity 203 in the case of U2N relay to identify the affected radio bearers at PC5 hop 101a. In the case of U2U relay, link problem feedback, along with the L2-ID of the source remote UE and the affected SL Radio bearers IDs, is sent to the source node (e.g., source remote UE2 102) (which may also be sent to the destination node or receiver (e.g., destination remote UE UE1 101)). As mentioned above, the PC5 SRAP entity of the relay UE provides the SL Radio bearers ID which is mapped to the PC5 RLC channel. In other words, if a problem occurs with the PC5 link, the affected link 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 transmitting or source node is the remote UE1 101. Link problem feedback information is sent from the relay UE100 to the source node, for example, by identifying the L2-ID of the relay UE100 as the Uu link identifier. In another embodiment, a link problem without an arbitrary L2-ID value or default value indicates a problem on the Uu link. The remote UE1 101 understands that congestion is occurring on the Uu link 105a (U2N relay). The overall E2E Radio Bearer is congested at the Uu hop 105a (U2N relay). Therefore, in the case of the U2N relay, the Uu SRAP entity 203 identifies the E2E Radio BearerIDs 101b and 101c of the affected remote UE1 101 in the link problem feedback. The transmitting or source node is the gNB107 of the U2N relay. Link problem feedback information sent to the source node (optionally, the destination node or receiver) identifies, for example, the L2-ID of the relay UE100 (as an identifier for 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 (typically used to identify the UE) to notify the affected RLC channels in the congestion link problem feedback. The node receiving the congestion link problem feedback then determines the affected RLC channels. For example, if a problem occurs on a Uu link, the links affected by that problem can be identified by the L2-ID of the relay UE; in another example, a link problem without an L2-ID value or default value indicates a problem on the Uu link. In yet another example, if a problem occurs on a PC5 link, the links affected by the problem can be identified by the L2-ID of the remote UE connected to this link. In yet another example, the identification of the link experiencing the problem (i.e., the use of link identifiers, IDs, and information elements) 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, informing affected nodes of the potential for a link failure. Link failures can occur at the PC5 hop or Uu hop, potentially impacting large amounts of data traffic at that hop. In other words, in this particular scenario, the link problem feedback sent by the relay UE indicates link degradation with a potential for link failure to the affected nodes.

[0086] Link failures occur after link degradation. In one embodiment, a link failure is detected when the link quality (e.g., SNR or RSRP) falls below a critical threshold level. In another embodiment, a link failure is detected when the link degradation cannot be recovered (e.g., when link degradation is detected on a given link for a given period of time). In yet another embodiment, a link failure is detected by the expiration of a timer and / or a counter threshold. For example, the use of a counter N310 indicating the number of “out-of-sync” events received from the physical layer in addition to a timer T310, as defined in TS38.331, can trigger a wireless link failure. Information to be included in the link problem feedback for signaling a link failure or link degradation (e.g., information to identify one or more communication flows or paths affected by the link problem) is described later with reference to Figure 5.

[0087] On the other hand, in U2N relay, link problem feedback for link degradation (including link failure) is sent by the relay UE only to the uplink remote UE (e.g., the source or transmitting node) when Uu link degradation occurs. In U2U relay, link problem feedback is sent by the relay UE to the remote UE when the other remote UE suffers link quality degradation. For example, if link degradation occurs at the second PC5 hop between the relay UE and another remote UE acting / functioning as the destination UE or target UE, the second hop between the relay and the destination UE is hidden from the remote UE acting / functioning as the source remote UE (connected to the relay UE on the first PC5 hop), and the source UE is notified of link problem feedback reporting the link quality degradation at the second PC5 hop. Referring to Figure 1, as an example, remote UE1 101 is designated as the source remote UE (or source UE) connected to the relay UE100 by the first PC5 hop 101a and communicates with remote UE2 102, designated as the destination or target remote UE (or target UE). Target UE2 102 is connected to relay UE100 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. Subsequently, if there is a degradation in link quality on the second PC5 hop 102a, source UE1 101 receives link problem feedback information from relay UE100.

[0088] To distinguish between different link problems, as illustrated with an example and Figure 5, link problem feedback information may further include information to identify the type of link problem detected (e.g., whether the link problem is of the type of congestion, or link degradation, or RLF, or transient / short-term or long-term link problem). The information may include a reason identifier (ID) to identify the type of link problem detected. In an example, the reason ID may represent the reason or context for the detected link problem, in addition to identifying the type of link problem detected. For example, the reason ID may identify that the link problem is of the type of congestion on the PC5 hop, congestion on the Uu hop, congestion on the E2E Uu RB, congestion on the remote UE E2E RB, congestion on the Uu RLC channel / bearer, congestion on the PC5 RLC channel / bearer, link degradation, link-level congestion (on the PC5 hop or Uu hop), or RLF. In the exemplary configuration, the reason ID is included in the link problem signaling message that identifies the type of announced link problem at the corresponding hop. Reason identifiers can be numbers or other identifiers used to distinguish different types and / or reasons for link problems. For example, a reason ID equal to 1 indicates radio bearer congestion, and a reason ID equal to 5 indicates RLC channel congestion at PC5 hop. To provide more detailed information about the link problem, a reason ID equal to 1 may indicate radio bearer congestion due to the addition of a new QoS to the E2E DRB. See Tables 4 and 5 below for other examples of reason IDs. In another example, information to identify the type of link problem detected may include a link problem type identifier (e.g., a PDU type identifier) ​​that identifies the type of link problem detected (e.g., whether the link problem is congestion, or link degradation, or RLF, or transient, or long-term (e.g., permanent), or event-based 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 relay UEs and affected nodes and to properly notify affected nodes of link problems (see, for example, the discussion below, which refers to Figure 5 regarding additional information elements).

[0089] Link problem feedback information may be transmitted in link problem signaling messages to signal or indicate a link problem.

[0090] (Relay (re)selection feedback) After detecting a 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 (or 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). Sending a relay (re)selection signaling is intended to instruct the remote UEs to switch to another relay UE. For example, if the relay UE detects congestion on a low-priority QoS RLC channel due to a large amount of data being sent with high-priority QoS, the relay UE may decide that the affected remote UEs should move to another relay UE. In this example, the relay (re)selection signaling message would include information (such as a reason ID) corresponding to the congestion or congestion of the low-priority flow. In another example, if the relay UE detects a link failure at a Uu hop (between relay UE 100 and gNB 107), the relay UE may send a relay (re)selection signaling message containing a reason ID related to the link failure. Therefore, the reason ID can identify the type of link problem (e.g., whether the link problem is congestion, link degradation, or one of the RLF link problem types) and / or the context or reason for the link problem. Reason ID information can be divided into two parts: a main part containing the type of link problem, or more generally, the event that triggers relay (re)selection (wireless link failure, Uu wireless link failure, PC5 wireless link failure, congestion, relay handover, internal issues (low battery, CPU usage, user change, relay capability disabled, etc.), or other event), and an optional part for additional contextual information. This additional information may indicate whether the problem is permanent (long-term) or transient (short-term). If the reason ID indicates a wireless link failure, this additional information may indicate the nature of the affected link, i.e., the Uu link or PC5 link. Dividing the reason ID makes the relay (re)selection signaling message more compact and allows for the addition of additional information if needed by the relay UE. Examples of reason IDs are shown in the table below: Table 4 TIFF2026097950000005.tif44140Table 5 TIFF2026097950000006.tif76140

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

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

[0093] In another example, after detecting a link problem, the relay UE may decide to release one or more remote UEs connected to the relay UE (if there are more than one remote UE connected to the relay UE, then one or all of them). Therefore, when the relay UE decides to release the remote UEs, it sends link problem feedback information to the remote UEs, which includes flow information to identify one or more communication flows and information indicating link problem feedback information related to relay (re)selection feedback. Link problem feedback information may be sent in a link problem signaling message configured to indicate relay (re)selection. A link problem signaling message indicating relay (re)selection identifies the link problem type in the reason ID, requests or demands the release of the PC5 link with the remote UE, and triggers relay (re)selection. For example, if link congestion occurs at Uu hop 105a of a sidelink relay connection between remote UE1 101 and gNB107, relay UE100 may infer that it is better to free up its remote UE (remote UE1 101) so that the freed remote UE can (re)select another relay UE that is not experiencing link problems, regardless of whether it is uplink or downlink traffic. This step may help mitigate the link problem on the relay UE's side.

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

[0095] In one example, when a relay UE node detects a congestion link problem in a wireless communication system (for example, as shown in Figure 1), in response to the detection of the congestion link problem, the relay UE node generates link problem feedback information containing information indicating that a congestion link problem has been detected, and transmits the link problem feedback information in relay (re)selection signaling or relay (re)selection message. Relay (re)selection signaling may be transmitted to remote UEs affected by the congestion link problem, and may be transmitted to all remote UEs connected to the relay UE. The information indicating a congestion link problem may include an identifier that identifies the congestion type of the link problem, and may also include reason / context information indicating the reason or context of the congestion. The identifier may be a reason ID that only indicates the congestion type, as described above, or a reason ID that indicates both the congestion type and the 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, a link problem signaling message indicating relay (re)selection may include link problem feedback information, as described above with respect to link problem feedback, which includes link problem flow information (such as flow identifiers for the affected radio bearers and radio links) to identify one or more communication flows affected by the detected link problem.

[0097] (Link status change feedback) When a link problem is detected, the relay UE 100 may determine whether the link problem is transient / short-term (e.g., the link has recovered or will soon recover) or long-term (e.g., the link problem worsens, resulting in the link problem becoming unrecoverable (i.e., a permanent link problem)). For example, the relay UE may set a timer or start a counter to determine whether the link has recovered (e.g., responded). If the link does not respond after multiple retransmissions exceeding the timer's expiration or the counter's threshold, a link failure (e.g., Radio Link Failure (RLF)) is detected. If the relay UE determines that the link has recovered or is unrecoverable, the relay UE sends link problem feedback information (e.g., to the affected node) containing flow information to identify one or more communication flows affected by the detected link problem, and may further include information to identify the type of link problem detected (e.g., link degradation, RLF, etc.), and information indicating that the link problem feedback information relates to link status correction feedback information. Link status change feedback information may announce the recovery or deterioration of a link problem.

[0098] A link status correction feedback message may include all or part of the information elements shown in Figure 5. For example, a link problem signaling message indicating a link status change feedback includes link problem feedback information that includes flow information to identify one or more communication flows affected by the detected link problem (e.g., flow identifiers for the affected wireless bearers and wireless links, as described above for the link problem feedback scenario).

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

[0100] As described above, a link problem signaling message sent to at least one of the affected nodes (which may be for signaling link problem feedback, relay (re)selection feedback, or link status correction feedback) includes link problem feedback information for the detected link problem. For example, the link problem feedback information includes flow information to identify one or more communication flows affected by the detected link problem. Therefore, a link problem signaling message sent to an affected node may include information elements to provide link problem feedback information to identify one or more communication flows affected by the detected link problem. Additional information elements may be optionally added to provide better visibility (e.g., more detail) to the link problem. Some of the additional information elements may depend on information provided by other information elements.

[0101] A link problem signaling message can 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 IE503 and IE504 can 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 sent to the affected node in the link problem signaling message. The PDU type of the feedback can be, as described above, link problem feedback, relay (re)selection feedback, or link status correction feedback. The type of link problem signaling message helps to indicate one or more actions to take to the node receiving the link problem signaling message. 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 of congestion, link degradation, RLF, or temporary or long-term link problem). For example, PDU type IE501 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 link problem signaling message provides notification to affected nodes about a link problem, identifies the affected communication flow (e.g., affected bearer, 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 for the detected link problem. The relay (re)selection feedback type of link problem signaling message provides notification of relay (re)selection feedback to affected nodes to trigger a remote UE to (re)select another UE as the relay UE after the PC5 link with the relay UE is released. The relay (re)selection link problem signaling message indicates the type of link problem detected (e.g., congestion if a congestion link problem is detected) and may provide notification of the reason or context for the detected link problem. In this case, flow information identifying the affected communication flow may optionally be provided in the signaling message. In another example, a relay (re)selection feedback type link problem signaling message may identify the affected communication flow (e.g., the affected bearer or link) and the type of link problem (e.g., congestion, link degradation, RLF) that caused the relay (re)selection. A link status change feedback type link problem signaling message provides an affected node with a notification that signals link status change feedback to inform the affected node of the changes caused by the link problem. For example, in addition to identifying the affected communication flow, a link problem signaling message may provide information indicating that the link problem has been mitigated (or recovered) or intensified (or worsened). Link status correction feedback may be sent by the relay UE after the relay UE has first sent the link problem feedback type of the link problem signaling message to the affected node.

[0104] Information element 502 specifies the destination ID of the link problem signaling message. Therefore, information element 502 contains the identifier (such as the L2 ID) of the affected node. For example, considering a link failure at Uu hop 105a of uplink traffic, the destination of the link problem signaling message is the sending remote UE1 101, and its ID is included in information element 502. If there are multiple affected nodes and one link problem signaling message is sent for each affected node (such as unicast communication), IE502 contains 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, IE502 carries a list of node identifiers for all affected nodes (e.g., in the case of broadcast communication) or a group identifier (e.g., in the case of groupcast communication). This information in IE502 may be optional if it is added by other layers during the encapsulation process. For example, as described in Chapter 6.2.4 of TS38.321, the destination L2_ID is located in the MAC subheader of SideLink Shared Channel (SL-SCH) in the DST field.

[0105] If IE501 indicates the type of feedback to be sent to the affected node in the link problem signaling message, then 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 it 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 link problems. For example, the reason ID may identify that the link problem is of one of the following types: congestion on the PC5 hop, congestion on the Uu hop, congestion on the E2E Uu RB, congestion on the remote UE E2E RB, congestion on the Uu RLC channel / bearer, congestion on the PC5 RLC channel / bearer, link degradation, link-level congestion (on the PC5 hop or Uu hop), or 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 short-term or long-term nature of the link problem (i.e., a link problem that lasts longer than a given timing threshold).

[0106] In the alternative, as described above, the PDU type information element 501 may indicate the type of problem (congestion, link failure, etc.), and in this case, information element 503 may further indicate the reason for the detected link problem (new QoS flow, low priority of the QoS being offered, SNR degradation, etc.). For example, information element 503 may include 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 existence and meaning of information element 504 depend on the content of PDU type information element 501 and / or reason ID information element 503. Information element 504 may include information resulting from link problem detection, such as the available buffer size when the link problem type is congestion, which is 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, which is detected based on the link quality parameters. For example, if the reason ID described in information element 503 is related to wireless bearer congestion, information element 504 will specify the available buffer size. For example, see Figures 11A to 11E: Figures 11A and 11B show the information elements of example link problem signaling messages for congestion-type link problems, Figures 11C and 11D show the information elements of example link problem signaling messages for link degradation-type link problems, and Figure 11E shows the information elements of example link problem signaling messages for link-level congestion and RLF-type link problems.

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

[0109] Information indicating the QoS or priority level available on an affected bearer / channel compared to the QoS or priority level of other bearers / channels provided by the relay UE may be introduced into the link problem signaling message to help the affected node make decisions based on the services available on the bearer / channel. For example, if the relay UE provides a higher QoS than the QoS of the affected bearer or channel, the affected node may wisely release established connections or attempt to reconfigure the bearer affected by the link problem. This information element may include, for example, a list of QoS / priority levels for 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 available for one or more communication flows affected by the detected link problem.

[0110] The final information element 506 exclusively provides 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 information element 506, and may include one or more of the following: 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 or path ID (e.g., in the case of multiple relay connections for a remote UE), or a hop ID (e.g., if a remote UE uses multiple chained relay UEs to reach a destination node). The link ID may be based on the source node's L2_ID, and each link ID / path ID / hop ID list is shared between nodes during the connection process.

[0111] Link problem signaling messages for providing link problem feedback, relay (re)selection feedback, and link status correction feedback share the same format as in Figure 5, and information element 501 indicates different PDU types to show whether the link problem signaling message represents 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 it includes, the list of bearer or link IDs inserted in information element 506, and the L2 ID inserted in information element 502.

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

[0114] The MAC-CE specified in TS 38.321 can be used as a container for the link problem signaling messages described above. It may accept 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 transmitted. As a result, a new LCID value may be defined for each of the PDU types described above.

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

[0116] Figure 6A shows steps of Method 600 for signaling a link problem in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in Figure 1 and related diagrams) according to an embodiment of the present invention. Method 600 is performed at a relay UE node. The wireless communication system includes 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 as shown, and a network node 107). The relay UE node is configured to relay data (such as packets) between at least one 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 below with reference to Figure 12, along with a method as shown in Figure 6A, which is performed by a processing unit 1211.

[0117] As described in step 601, a link problem is detected in 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 to identify one or more communication flows affected by the detected link problem. In step 603, the relay UE 100 transmits the link problem feedback information. For example, the relay UE 100 transmits the link problem feedback information to at least one of a plurality of nodes associated with 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 (such as radio bearers or links) affected by the detected link problem in order to identify or determine at least one of a plurality of nodes associated with 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 the affected communication flow is identified (e.g., the affected E2E wireless bearer, RLC bearer / channel, PC5 and / or Uu link is identified), a mapping table may be used to identify the affected nodes (such as one or more remote UEs or gNBs), as described above with respect to link problem feedback scenarios and descriptions of different types of link problems. The affected nodes include at least one of the source node and the destination node. For example, in a sidelink relay system where a sidelink relay connection is established between the source node, the relay UE node, and the destination node, detecting a link problem may involve detecting a link problem related to at least one of the first links between the source node and the relay node, and the second link between the destination node and the relay node, and sending link problem feedback information to at least one of the source node and the destination node. In one example, relay UE 100 may send link problem feedback information to all nodes connected to relay UE 100.

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

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

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

[0121] 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 the exemplary format described above with respect to Figures 5 and 11A-11E. In this format, flow information (e.g., a flow identifier) ​​is provided in information element 506, information for identifying the type of link problem detected 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 sent is provided in information element 502 (i.e., the destination ID information element). The link problem signaling message may further include a PDU type information element 501 to indicate the type of link problem signaling message (i.e., 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 may also include information in information element 505 indicating the QoS or priority level secured by the relay node. Optionally, the link problem signaling message may also include information that provides notification of the magnitude or level of the link problem in information element 504, such as the available buffer size, the link quality parameters provided, or the criticality level that provides the affected node with an explicit view of the buffer status or link quality determined by the relay UE100.

[0122] Link problem signaling messages can be transmitted via unicast, multicast, or broadcast communication. If a relay UE determines (using a mapping table, for example) that only one node is affected by a detected link problem, the relay UE may use unicast to send link problem feedback information directly to that node. In this case, if the link problem feedback information is transmitted in a link problem signaling message having the format shown in Figure 5, IE502 will contain only one identifier to identify a single node. If multiple nodes are affected, multicast or groupcast may be used for the set of affected nodes if groups (with specific addresses) have already been defined / created. In all cases, link problem feedback information may be transmitted in a broadcast message, in which case affected nodes may filter according to the RLC ID, bearer ID, or link ID (checking whether the ID in the message corresponds to an ID used by the node) instead of using the message's destination address. 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 in the example where the link problem signaling message has the format shown in Figures 5 and 11A-11E, and PDU type IE501 indicates the link problem feedback type, the relay UE100 sets the PDU type in PDU type information element 501 to indicate the link problem feedback type. The reason ID in information element 503 is then identified based on the link problem type (congestion, link degradation, or link failure) and the corresponding bearer or link affected (e.g., flow ID). The table of reason IDs described above is used to map the problem detected in the bearer or RLC channel or link to the 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 information element 506 of the link problem signaling message.

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

[0125] The generated link problem feedback information and additional information are then sent to the affected node in a link problem signaling message (for example, as in step 603). The container type of the link problem signaling message is selected by the relay UE100 as a function of size, the criticality of the link problem, and the type of communication (unicast, multicast, or broadcast). The container type can be one of the following, as described above: MAC CE container, SRAP control PDU, RRC signaling, or PC5 signaling. The link problem signaling message may be sent by unicast, multicast, or broadcast based on the type of link problem detected.

[0126] Herein, we also refer to Figure 6B, which shows steps of method 604 for processing link problem feedback information at an affected node in a sidelink relay system of a wireless communication system according to an embodiment of the present invention (such as the wireless communication system shown in Figure 1 and related figures). The affected node may be at least one of several 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 in and described with reference to Figure 12 below, along with a method as shown in Figure 6B performed by a processing unit 1211.

[0127] Link problem feedback information transmitted by the relay UE 100 is received in step 605 by the affected nodes (e.g., remote UEs (such as remote UEs 101, 102, and / or 103) and / or gNB 107). The link problem feedback information received from the relay UE 100 includes flow information to identify 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, based on the flow information, one or more communication flows affected by the detected link problem, and evaluates the level of impact of the detected link problem on data communications at the node on 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 several different types of link problems, and the types of link problems include handover, congestion, link degradation, RLF, and temporary / short-term or long-term / permanent link problems. The link problem feedback information may further include information to identify the type of link problem (such as the reason ID or PDU type described above) that can be used by the node to evaluate the level of impact of the detected link problem. In addition to identifying the type of link problem detected, the reason ID may represent the reason or context of the detected link problem, as described above. The flow information may include flow identifiers to identify 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 nodes take action or perform operations on the affected nodes. Actions or operations are performed to mitigate the impact of the detected link problem if the assessment determines that the assessed impact level has reached a certain threshold. Actions or operations 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 the transmission of data (packets) by nodes on one or more affected communication flows (e.g., restarting or resuming). Note that although steps 607 and 606 are shown as separate steps, step 607 may be performed as part of the processing in step 606.

[0130] As described above, link problem feedback information received at a node may be included in a link problem signaling message, which may further include PDU type information to indicate the type of link problem signaling message. A link problem signaling message may be one of the following: 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 action at the node based on the type of 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 link problem feedback, the affected node acknowledges the link problem without being asked to take action from the affected node. The affected node then reads the remaining information elements to determine the type of link problem (whether it is at the bearer level, RLC channel level, or link level as identified by the reason ID). It also identifies the relevant information element (e.g., IE506) corresponding to the ID of the problematic bearer or link. After gathering information from the signaling message, the affected node initiates feedback processing, which includes evaluating the link problem and its impact on transmission, and deciding what action to take, based on the information received in the link problem signaling message.

[0132] Figure 7A shows steps of Method 700 for generating a link problem signaling message containing information to indicate relay (re)selection feedback in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in Figure 1 and related figures) according to an embodiment of the present invention. Figure 7B shows steps of Method 704 for processing the information contained 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 Figure 1 and related figures) according to an embodiment of the present invention. Method 700 is performed at a relay UE node, such as relay UE 100 in Figure 1 and related figures, and Method 704 is performed at a remote UE node affected by a link problem detected by the relay node (such as 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 Figure 12 below.

[0133] First, referring to Figure 7A, in this example, after the relay UE detects a link problem in step 701, the relay UE 100 assesses 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 requiring rapid action to mitigate the link problem. This case applies when the remote UE is the affected node.

[0134] In step 702, the relay prepares or generates information for a link problem signaling message to indicate relay (re)selection feedback, as well as information for a link problem signaling message to indicate link problem feedback (for example, as commonly discussed with respect to step 602). For example, the link problem signaling message generated in step 702 may include link problem feedback information, including the flow information described above, and may also include different PDU types indicating relay (re)selection triggers from the relay UE.

[0135] In another example, the link problem signaling message generated by the UE relay 100 in step 702 to indicate relay (re)selection may include link problem feedback information that includes information to identify the type of link problem detected (e.g., different types of link problems including congestion, link degradation, and Radio Link Failure (RLF)). The information to identify the type of link problem detected may include a reason identifier or another identifier to identify the type of link problem detected. The information may also include reason / context information to indicate the reason or context of the detected link problem. In addition to identifying the type of link problem, the reason ID may indicate the reason or context of the detected link problem, as described above. In this example, the link problem signaling message to indicate relay (re)selection does not have to 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 earlier, the size of the container for link problem signaling messages is determined by the criticality of the link problem, which requires low latency.

[0138] Referring here to Figure 7B, in step 705, the remote UE, having received a link problem signaling message from its relay UE to indicate relay (re)selection feedback, identifies the PDU type (e.g., within information element 501 of the message shown in Figures 5 and 11A-11E) that in this case requests or relates to relay (re)selection. The remote UE reads the following information elements 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 include a link affected by the detected link problem in the event of a link failure, or one or more communication flows (such as an RLC channel) affected by the detected link problem, and proceeds to relay (re)selection. In an implementation example (as described above) where a link problem signaling message indicating relay (re)selection does not contain flow information but identifies the type of link problem and includes a reason ID indicating the reason or context of the detected link problem, the remote UE may, in response to receiving the link problem signaling message, release the PC5 link and initiate a (re)selection procedure based on the reason ID included in the message.

[0139] Figure 8A shows steps of Method 800 for generating a link problem signaling message containing information to indicate link status correction feedback in a sidelink relay system of a wireless communication system (such as the wireless communication system shown in Figure 1 and related diagrams) according to an embodiment of the present invention. Figure 8B shows steps of Method 804 for processing the information contained 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 Figure 1 and related diagrams) according to an embodiment of the present invention. Method 800 is performed at a relay UE node, such as relay UE 100 in Figure 1 and related diagrams, and Method 804 is performed at an affected node (at least one of several nodes, such as a remote UE or network node) due to a link problem detected by the relay node (e.g., relay UE 100). Each of the relay UE node and the affected node may be implemented in a communication device 1200, as shown and described with reference to Figure 12 below.

[0140] When a link problem is detected, the relay UE 100 may determine (for example, using a timer or counter as described above) whether the link problem is transient or short-term (e.g., the link has recovered or will soon recover) or long-term (e.g., the link problem worsens and results in the link problem becoming unrecoverable (i.e., a permanent link problem)). If the relay UE 100 determines that the link has recovered or is unrecoverable, it sends link status correction feedback (for example, to the affected node). In this case, detecting a link problem involves the relay UE 100 detecting a change in the link status in step 801. Then, in step 802, information for a link problem signaling message to indicate the link status correction feedback is generated or prepared. 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 link status correction feedback. The following information elements (e.g., information elements 502-506 of the link problem signaling message in Figures 5 and 11A-11E) can be updated as a function to correct the link status. In other words, the information provided in the information elements of the link problem signaling message (e.g., IE502-506 in Figure 5) is updated based on the current status of the detected link problem.

[0141] In the case of congestion or link degradation, information elements related to the available buffer size and link quality parameters may be modified to update the criticality of the link problem. For example, in the case of a link degradation problem, when the evaluated link quality parameter changes from weak to medium, the link status change feedback sends the same information elements as the link problem feedback, which includes an update to the link quality parameter information element (IE504).

[0142] Congestion detected on a specific bearer or RLC channel can worsen and affect all RLC channels transmitted on the link (link-level congestion). Therefore, as an optimization method, link status correction feedback may be sent with the identifier of the link experiencing the problem, instead of a list of IDs for all affected channels. Furthermore, link status change feedback may be sent without notification of the available buffer size, thereby notifying affected nodes that the link problem has escalated to link-level congestion.

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

[0144] Referring here to Figure 8B, the affected node receives a link problem signaling message in step 804 to indicate link status correction feedback, and in its PDU type (for example, in information element 501 of the message, as shown in Figures 5 and 11A-11E), it identifies that the feedback concerns a link status correction. If available buffer size or link quality parameters are not indicated or included in the feedback, it may still indicate link-level congestion or a link failure, or that it has occurred. The reason ID in information element 503 identifies the type of link problem and the affected bearer / channel or link. For example, congestion occurring on an uplink Uu RLC channel may degrade, and the number of affected PC5 RLC channels may increase. The flow information in information element 506 identifies the affected communication flow. Thus, a link status change may be sent from the relay UE to the remote UE to indicate that congestion is still occurring on the Uu RLC channel, but the number of affected PC5 RLC channels has increased.

[0145] Feedback processing is performed by the affected node in step 805 to re-evaluate the link problem status. Link status correction feedback indicating that the link problem has ended may cause the relay node to reset a timer or counter used to determine whether the congestion is short-term or long-term (congestion is considered long-term when time reaches a predetermined threshold).

[0146] Figure 9 shows steps of 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 Figure 1 and related diagrams) according to an embodiment of the present invention. Method 900 is performed at a relay UE node. The wireless communication system has a relay UE node (for example, relay UE 100 as shown) and a plurality of nodes (for example, remote UEs 101, 102, 103 and two or more remote UE nodes such as 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 Figure 12 below, along with a method as shown in Figure 9, which is performed by a processing unit 1211. According to the exemplary method 900 in Figure 9, the relay UE 100 generates a link problem signaling message (for example, in the format shown in Figures 5 and 11A-11E, and illustrated with reference to Figure 11A-11E) containing information for signaling link problem / relay (re)selection / link status change feedback to the affected node (for example, according to general steps 601-603 in Figure 6A).

[0147] In step 901, the relay UE 100 detects a link problem or a change in link status (for example, a change in the link status of a previously detected link problem). Steps 903-904 involve the desired information identified by the relay UE 100 (for example, the information in information elements 502, 503, 504, and 506 of the format shown in Figure 5) to generate a link problem signaling message according to the example format shown in Figure 5.

[0148] In step 902, the relay UE 100 identifies one or more flows or communication flows affected by a link problem, whether it be one or more radio bearers, RLC channels, or links. Identifying the affected flows allows the relay UE 100 to define or determine the affected nodes. For example, it can define or identify the source node (or transmitter) and / or destination node (or receiver) to which the link problem feedback information included in the link problem signaling message should be sent. The relay UE 100 also determines flow information (also called a flow ID or flow data ID) that identifies one or more communication flows (such as radio bearers or links) identified as being affected by the detected link problem. For example, the flow data ID might consider a radio bearer ID or RLC bearer ID in the case of RB-level or RLC channel-level congestion. Link-level congestion and link failures require identifying the source of the link problem. For example, in this type of link problem, the flow information includes a link identifier (PC5 link ID or Uu link ID). Link failures in Uu are identified by the relay UE's L2-ID. Furthermore, wireless bearer IDs affected by link-level issues are reported in the flow information or flow data ID feedback (e.g., within information element 506). If multiple RLC channels or bearers are affected, a list of affected RLC channels / bearers (e.g., a list of RLC channel / bearer IDs) may be reported in the flow information (e.g., IE506).

[0149] The link problem feedback information included in the link problem signaling message further includes an identifier (e.g., within information element 502) to identify the determined affected node to which the link problem feedback information is to be sent. If the affected node is a remote UE, the L2-ID of the remote UE is identified by the Uu SRAP layer 203 in the case of U2N relay (or the second PC5 SRAP layer in the 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, the gNB is identified as the destination of the feedback, and the gNB ID is included in information element 502. In the case of U2U relay, the ID information or identifiers of the source UE and destination or target UE are candidate information included in the adaptation layer, and therefore, 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. When a 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 Uu SRAP layer 203 for U2N relay (or a second PC5 SRAP layer in the case of U2U relay), and destination nodes determined by the mapping tables configured for these SRAP entities as described above. Therefore, as previously stated, a list of destination IDs for all affected nodes may be provided.

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

[0152] The information from 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] Figure 10 illustrates steps of 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 shown in Figure 1 and related figures) according to an embodiment of the present invention. For example, Figure 10 shows how an affected node makes a decision and performs an operation (for example, according to steps 606-607 in Figure 6B) after receiving feedback from a relay UE 100 in a link problem signaling message. The affected node may be at least one of several 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 below with reference to Figure 12, along with a method as shown in Figure 10, performed by a processing unit 1211.

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

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

[0156] In the case of relay (re)selection feedback, the remote UE to which the link problem signaling message containing the feedback is desirable is requested to release the link corresponding to the communication flow affected by the detected link problem and perform relay (re)selection as in step 1005 (following the "relay releases RQ" branch from step 1002). 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 correction feedback may be sent by the relay UE 100. In this case, the link problem signaling message, including the link status correction feedback, announces the recovery of the link, and the affected node may resume transmission in step 1004 (following the "link recovery" branch from step 1002). For example, the affected node may resume sending data (such as packets) on one or more affected communication flows. If the link status correction feedback reports a worsening of the link problem, relay (re)selection may be considered in step 1004, as in step 1005.

[0158] As described in some aspects above, a link problem feedback signal may be used by a relay UE to notify a remote UE that all or part of its communication is being 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 Figures 6B, 7B, and 10).

[0159] In another aspect, a relay UE may experience some limitations that restrict its current relaying capacity, for example, its actual relaying capacity may be affected by radio conditions (e.g., RSRP, SINR, etc.) or the actual load on the relay UE. If a candidate remote UE attempting to connect to the relay UE does not consider such limitations and still requests a connection to the relay UE, and / or the link with an already connected remote UE is not changed or released, such limitations in relaying capacity may lead to further link problems (such as congestion).

[0160] Therefore, considering the capability limitations that could lead to link problems if one or more new connections to remote UEs are permitted or accepted, or if link changes with already connected remote UEs are permitted or accepted, or if links with already connected remote UEs are not changed or released, it may be valuable for relay UEs to proactively share such actual relay capabilities with remote UEs (e.g., during the discovery phase or during link management processes such as the direct link process or direct communication process) to prevent such link problems from occurring. For example, by ensuring that candidate remote UEs do not experience link problems by connecting to the relay UE or by changing or releasing links with already connected remote UEs.

[0161] Figure 13 shows steps of Method 1300 performed by a relay user equipment (UE) node of a wireless communication system (such as the wireless communication system shown in Figure 1 and related figures) according to an embodiment of the present invention. Method 1300 is performed at the relay UE node. The wireless communication system has a relay UE node (for example, relay UE 100 as shown in Figure 1 and related figures) and a plurality of nodes (for example, one or more remote UE nodes such as remote UE 101, 102, 103 as shown in Figure 1 and related figures, and a network node 107). The relay UE node is configured to relay data (such as 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 shown in and described below with reference to Figure 12, along with a method as shown in Figure 13 performed by a processing unit 1211.

[0162] The method shown in Figure 13 allows a relay UE node to manage new and existing remote UE connections during a sidelink management process or link management process (such as a direct link process or direct communication process), such as a discovery process, depending on the relay UE node's actual relaying capabilities. This method may also include sharing such relaying capabilities between the relay UE node and the remote UE nodes.

[0163] The 5G Proximity-based Services (ProSe) U2N / U2U relay UE supports two discovery models, Model A and Model B, as defined in 3GPP TS 23.304, V17.1.1. Model A uses one discovery protocol message (an Announcement message sent by the relay UE acting as the announcing UE), while Model B uses two discovery protocol messages (a Solicitation message sent from the remote UE acting as the discovering UE and a Response message from the relay UE acting as the discovering UE). In the latter case of Model B, the discovering UE may indicate in its discovery solicitation or request message its interest in the status of the requested relay UE (e.g., the relay UE's link or actual load, or connectivity with other UEs). Discovery solicitation messages can be sent by 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 one 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 a direct link process, the remote UE node sends a direct link establishment request message. If a relay UE node receives the direct link establishment request message and accepts the request to establish a direct link (such as over a PC5 link) with the remote UE node, the relay UE node responds by sending a direct link establishment acceptance message. In the case of UE-to-UE relay or multi-hop UE-to-Network (i.e., the remote UE reaches the gNB using multiple consecutive relay UEs), upon receiving the direct link establishment request message, if the relay UE node accepts the request to establish a direct link (such as over a PC5 link) with the remote UE node, the relay UE either forwards the direct link establishment request message or sends a new direct link establishment request message from its own device to establish a direct link connection (such as over another PC5 link) with the target UE or another relay UE. A relay UE sends a direct link establishment acceptance message to a remote UE in response to its own device when its direct link establishment request is accepted by the target UE or another relay UE, or to save time in the establishment process. However, if the direct link establishment with the target UE or another relay UE is rejected, the relay UE may accept the remote UE's direct link establishment request based solely on its own device's criteria, even if it later needs to release the direct link connection with the remote UE. When a relay UE node receives a direct link establishment request message, if it 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 rejection message in response. The direct link process also provides that a direct link change request can be sent from a UE (e.g., a relay UE) to another pair of UEs (e.g., a UE already connected to the relay UE) to initiate a direct link change procedure (e.g., changing the PC5 link between the relay UE node and the remote UE node). The direct link process also provides that a direct link release request can be sent from one UE (e.g., a relay UE) to another pair of UEs (e.g., a UE already connected to the relay UE) in order to initiate a direct link release procedure (e.g., releasing the PC5 link between a relay UE node and a remote UE node).

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

[0167] In step 1301, the relay UE node in Figure 13 identifies or verifies its relay capability for relaying data. 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 trigger event. A trigger event may include receiving a discovery request message, or receiving a direct link establishment / modification request, or receiving a direct communication request, or at least one of the following based on measurement results (for example, measurement results indicating a significant change in the relay UE node's capability such that it would be beneficial for the relay UE node to proactively notify nearby remote UE nodes of the change (e.g., a decrease in capability above a certain level, or a decrease in capability above a certain level)). 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. 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 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 for PC5 and Uu links), the QoS level, the bitrate of each of the one or more communication flows currently provided by the relay UE node, and / or network load (which may be based on the channel busy rate (CBR) and / or channel occupancy rate (CR) of each bandwidth / pool currently used by the relay UE node for data relay).

[0168] In step 1302, the relay UE node determines whether relaying by the relay UE node to one or more remote UE nodes (for example, one or more remote UE nodes that are new or added to remote UE nodes already serviced 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 the risk of link problems. For example, the relay UE checks whether the connection of one or more new or additional remote UEs could create a potential risk of link problems and whether it can accept the connection with the new remote UE node. In another example, the relay UE checks whether an existing connection with one or more remote UEs could create a potential risk of link problems and whether the existing connection needs to be corrected or released, or whether it can accept a correction request from the remote UE for the existing connection.

[0169] In step 1302, if the relay UE node determines that it cannot support relaying to one or more remote UE nodes without the risk of link problems, the relay UE node may decide to prevent new remote UE connections, prevent modification of existing remote UE connections, or modify or release existing remote UE connections in order to avoid the risk of future link problems.

[0170] In step 1304, in one example, in response to determining that relay UE node cannot support relaying to one or more remote UE nodes, the relay UE node sends a sidelink management message to indicate that relaying by the relay UE node to one or more remote UE nodes is not supported (for example, to prevent remote UE connections as shown by box 1306). The sidelink management message may include relay capability information indicating the relay UE node's relay capability for data relaying by the relay UE node (e.g., current relay capability). In an alternative example in step 1304, in response to determining that relay UE node cannot support relaying to one or more remote UE nodes, the relay UE node does not send one or more sidelink management messages. For example, the relay UE node may modify (e.g., stop) the sidelink management process running on the relay UE node to stop sending one or more sidelink management messages.

[0171] In an example where the relay UE node supports the discovery process (e.g., is running), the sidelink management message is a discovery message, and the relay UE node may send a discovery message indicating that it cannot support relaying by the relay UE node to one or more new remote UE nodes (e.g., to prevent remote UE connections, as shown by box 1306). The discovery message may include relay capability information indicating the relay UE node's relay capability for data relaying by the relay UE node (e.g., current relay capability). In an alternative example, the relay UE node may not send or forward one or more discovery messages (e.g., to a remote UE or target UE or subsequent relay UEs), or may stop doing so. In other words, a relay UE node may modify (for example, stop) the discovery process it performs to stop sending announcement messages (in the case of discovery model A as defined in 3GPP TS 23.304, V17.1.1) or response messages to received discovery request messages (in the case of discovery model B as defined in 3GPP TS 23.304, V17.1.1). By stopping the transmission of discovery messages, a UE relay node can prevent new remote UE connections from being established because UEs near the relay UE node (such as relay UE100) will no longer receive information from the relay UE node, thus not considering the relay UE when performing relay selection.

[0172] In examples where a relay UE node supports (e.g., is running) a link management process such as a direct link process or a direct communication process, the side link 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 to one or more remote UE nodes, the relay UE node may send a link management message indicating that relaying by the relay UE node to one or more remote UE nodes is not supported (e.g., to prevent remote UE connections as shown by box 1306), such as a direct link establishment denial message for a direct link process or a direct communication denial message for a direct communication process. The link management message may include relay capability information indicating the relay node's relay capability for data relay by the relay UE node (e.g., current relay capability). Link management messages may be sent in response to a link management request message. For example, a direct link establishment denial message for a direct link process may be sent in response to a direct link establishment request message. A direct communication denial message for a direct communication process may be sent in response to a direct communication request message. Relay capability information can, for example, notify the remote UE of the conditions under which a new connection will be accepted by the relay UE.

[0173] If the relay UE node supports the direct link process, in an alternative scenario, in response to determining that relaying by the relay UE node is not supported, the relay UE node may send link management messages to already connected remote UE nodes indicating that it can no longer support relaying to one or more remote UE nodes. These messages may include, for example, a direct link change request message to request a change in the link (PC5 link) between the relay UE node and the connected remote UE nodes, or a direct link release request message to request the release of the link (PC5 link) between the relay UE node and the connected remote UE nodes. The direct link change request message and / or direct link release request message may include relay capability information indicating the relay node's relay capability (e.g., current relay capability) for relaying data by the relay UE node.

[0174] Alternatively, similar to the discovery process, a relay UE node may choose not to send or forward one or more link management messages, such as link establishment messages, to the relay UE, target UE, or subsequent relay UEs. In other words, a relay UE node may modify (e.g., stop) the link management or establishment process running on it to stop sending response messages to received direct link establishment requests (as defined in 3GPP TS 24.587 V17.5.0) or response messages to received direct communication request messages (as defined in 3GPP TS 23.304, V17.1.1). By stopping the sending of link establishment messages, a UE relay node may prevent new remote UE connections to UEs in the vicinity of the relay UE node (such as relay UE100).

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

[0176] Therefore, there are two possible options for step 1304: - The relay UE will no longer perform sidelink management processes such as direct link processes, direct communication processes, or discovery processes, for example, the relay UE will not send an announcement message (in Model A) or a response message (in Model B). - A relay UE may indicate in a sidelink management message that it cannot support one or more remote UE nodes. Alternatively, a relay UE may share its relaying capabilities with a remote UE by adding a relaying capacity information element (described below) to sidelink management messages (such as discovery messages or link management messages) sent to the remote UE.

[0177] In step 1302, if the relay UE node determines that relaying by the relay UE node to one or more remote UE nodes is supported without the risk of link problems, the relay UE node sends a sidelink management message in step 1303 to indicate that relaying by the relay UE node to one or more remote UE nodes is supported (for example, to allow or enable remote UE connections as shown by box 1305). The sidelink management message may include relay capability information indicating the relay capability of the relay UE node for data relaying by the relay UE node (for example, current relay capability).

[0178] In an example where the relay UE node supports (e.g., is running) the discovery process, the sidelink management message is a discovery message, and the relay UE node may send discovery messages indicating that relaying by the relay UE node to one or more remote UE nodes is supported (e.g., to allow or enable remote UE connections, as indicated by box 1305). In this case, the relay UE node may perform the discovery process in the normal manner in step 1303. Discovery messages sent by the relay UE node may be sent as broadcast or announcement messages (for discovery model A as defined in 3GPP TS 23.304, V17.1.1) or as response messages in response to discovery request messages received from remote UE nodes (for discovery model B as defined in 3GPP TS 23.304, V17.1.1). Discovery messages may include relay capability information indicating the relay capability of the relay UE node for data relaying by the relay UE node (e.g., current relay capability).

[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 side link 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 possible without the risk of link problems, the relay UE node sends a link management message in step 1303 indicating that relaying by the relay UE node to one or more remote UE nodes is supported (e.g., to allow or enable remote UE connections, as shown by box 1305). Thus, in this case, the relay UE node may perform the link establishment process in the normal manner in step 1303. The link management message may be sent in response to a link management request message. In other words, a link management message sent by a relay UE node may be sent as a response message (e.g., a direct link establishment acceptance message) in response to a received direct link establishment request (defined in 3GPP TS 24.587, V17.5.0), or as a response message (e.g., a direct link change acceptance message) in response to a received direct link change request (defined in 3GPP TS 24.587, V17.5.0), or as a response message (e.g., a direct communication acceptance 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 UE-to-UE relay or multi-hop UE-to-Network, when a relay UE node receives a link management request message (such as 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 a remote UE node, the relay UE may forward the link management request message or send a new link management request message (such as a direct link establishment request message or a direct communication request message) to establish a direct link or direct communication (such as via another PC5 link) with the target UE or another relay UE.Link management messages may include relay capability information indicating the relay capability of the relay UE node for data relay by the relay UE node (e.g., current relay capability).

[0180] In step 1302, if the relay UE node determines that relaying by the relay UE node to one or more remote UE nodes is supported (and in step 1302, if the relay UE node determines that relaying by the relay UE node to one or more remote UE nodes is not supported), the relay capability information that may be included in the sidelink management message (for example, in a discovery message or link management message sent by the relay UE node) may include one or more of the information included in the relaying capacity Information Element, as described below. Therefore, the relay UE may share its relay capability with the remote UE by adding the relaying capacity Information Element to the sidelink management message (such as a discovery message or 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 some of the following information: - New connection accepted information: This information indicates the relay UE's ability to accept new remote UE connections. For example, this information indicates whether a 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. For example, "True" indicates acceptance, and "False" indicates non-acceptance. Alternatively, a single bit with the value "1" or "0" may indicate whether a UE node is able to accept a new connection. - Relay Load Information: This information reflects the load on the relay UE (such as the current load on the relay UE node). The load on the relay UE can be expressed in terms of the connected remote UEs. For example, this information may relate to the actual number of remote UEs connected to the relay UE, or any information that reflects this number, such as 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 levels of one or more flows currently accommodated by the relay UE, and the relay UE may serve multiple QoS flows with specific priority levels. For example, this QoS information shows the QoS level of one or more communication flows currently served or supported by the relay UE node. Served QoS information may include a list of all or some of the QoS levels served by the relay UE, or a list of all or some of the QoS levels not served by the relay UE. 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 properly served by choosing to join relay UE1, which has dedicated E2E Uu DRB and Uu RLC channels for the requested QoS level. - PC5 measurement report information: This PC5 or sidelink measurement report information indicates the radio quality of one or more communication links (such as PC5 links) between the relay node and at least one remote UE node. The relay UE may perform sidelink measurements on the PC5 link, such as SL-RSRP (Reference Signal Receive Power), SL-RSSI (Received Signal Strength Indicator), SL-CR (Channel Occupancy Ratio), and SL-CBR (Channel Busy Ratio), as defined in TS 38.215. These measurements may indicate poor radio conditions (busy channels, interference, etc.) on one or more PC5 links. For example, in the case of UE-to-UE relay, the relay UE may include information on the PC5 links involved in future communication between the remote UE and a potential target UE (identified, for example, by the PC5 measurement report information or the dest L2 id in the discovery model B request message, or by the target UE information). This allows the remote UE to choose to ignore candidate relay UEs with poor wireless conditions on the PC5 link (for example, the PC5 link from the remote UE to the target UE). -Uu measurement report information: This Uu or network link measurement report information indicates the radio quality of the communication link (such as the Uu link) between the relay node and the network node of the wireless communication system (such as the gNB). Various types of measurements on the Uu link may be requested by the gNB and reported periodically by the relay UE. Some of these measurements may be relevant to candidate remote UEs. For example, a relay UE showing low Uu-RSRP may suffer reduced bandwidth that can affect the Uu RLC channel and cannot guarantee uplink / downlink data rates. This information may be optional in UE-to-UE relays. - Acceptable bitrate information: Based on local measurements performed on the Uu link between the relay UE and the network node of the wireless communication system (such as a gNB), and / or on its PC5 link, the relay UE may indicate to the remote UE the target bitrate, or maximum bitrate, that can be processed on its Uu link and / or its PC5 link. For example, this information indicates the maximum bitrate currently supported by the relay UE node. - Network load information: This information shows the current channel occupancy and the remaining bandwidth for new communications.

[0181] The relaying capacity information element may be announced by the relay UE (Discovery Model A) or requested by the 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 response message (Model B) when performing L2 relaying. An additional announcement (Model A) used for L3 relay support may be used to share this information.

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

[0183] Hereinafter, we also refer to Figures 14A and 14B illustrating steps of methods 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 shown in Figure 1 and related figures) according to embodiments of the present invention. For example, Figure 14A shows steps performed at a remote UE node in response to receiving a sidelink management message from a relay UE node, and Figure 14B shows steps performed at a remote UE node in response to not receiving a response message in response to a request message sent by a remote UE node. The remote UE node may be one of the remote UEs 101, 102, and 103 shown and described in relation to the figures, and the relay UE node may be relay UE 100 shown and described in relation to the figures. The remote UE node may be implemented in a communication device 1200 as shown and described in reference to Figure 12 below, along with methods as shown in Figures 14A and 14B performed by a processing unit 1211.

[0184] Referring first to Figure 14A, in step 1401, the remote UE node receives a sidelink management message from the relay UE node indicating whether relaying by the relay UE node to one or more remote UE nodes is supported. The sidelink management message can 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 Figure 13. The link management message may include relay capability information indicating the relaying capability of the relay UE node for data relaying by the relay UE node (e.g., current relay capability). 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 takes action based on the received sidelink management message. Taking action may include performing a (re)selection in response to a determination that relaying by the relay UE node to one or more remote UE nodes is not supported based on the received sidelink management message, or performing a discovery process, a direct link establishment process, or a direct communication process to another relay UE node. Taking action may include, in response to a determination that relaying by the relaying UE node to one or more remote UE nodes is supported based on the received relaying capacity information, initiating the establishment of a connection with the relaying UE node (e.g., performing link establishment). As described above, if relaying capacity information is included in the sidelink management message along with one or more pieces of information contained in the relaying capacity Information Element, the remote UE node has additional information to determine whether the remote UE node requests a connection with the relaying UE node.For example, if a remote UE node receives relay capability information from two relay UE nodes, and the first relay UE (UE1) indicates in its relay capability information that it can provide a QoS level corresponding to the QoS level requested by the remote UE node, and the second relay UE (UE2) indicates in its relay capability information that it can provide a QoS level corresponding to a higher QoS level than the QoS level requested by the remote UE node, then the remote UE is more likely to be properly serviced when it chooses to join relay UE1, which has dedicated E2E Uu DRB and Uu RLC channels corresponding to the requested QoS level. Therefore, in this case, the remote UE node may decide to initiate the establishment of a connection with the first relay UE (UE1).

[0185] Referring here to Figure 14B, in step 1404, the remote UE node acting as the discoverer UE sends a request message to initiate communication with the relay UE node. For example, the request message could 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 can be sent by broadcast, unicast, or groupcast. In another example, the request message could 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 takes action (step 1405). For example, the remote UE node may start a timer when sending 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 take action. This action may include performing a (re)selection, or performing a discovery process, a direct link establishment process, or a direct communication process to another relay UE node, or determining that there are (for example, currently) no available relays in the vicinity of the remote UE node.

[0186] Therefore, by identifying the relaying capability of the relay UE node and determining whether relaying by the relay UE to one or more remote UE nodes is supported, the relay UE node may proactively check for the risk of link problems and prevent or allow new connections to one or more new remote UEs, and / or correct or release existing connections, in order to avoid or minimize the risk of link problems occurring in the future. The relay UE node may proactively act by sending sidelink management messages (such as discovery messages) indicating whether relaying by the relay UE is supported (e.g., whether new connections can be supported / allowed), and possibly with some restrictions. Sidelink management messages may include relay capability information that provides information indicating the actual or current relaying capability 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 future link problems, the relay UE node may proactively act by stopping the sidelink management process (e.g., the discovery process) to stop sending or not send sidelink management messages (e.g., discovery messages). By not sending discovery messages, or by stopping the sending of such messages, UEs in the vicinity of a relay UE node will no longer receive information from it. Therefore, in the discovery process, UEs in the vicinity of a relay UE node will not consider the relay UE when performing (re)selection of relaying. Upon receiving a sidelink management message containing relaying capacity information, a remote UE node may decide what action to take based on the relaying capacity information (e.g., whether to request the establishment of a connection with the relay UE node). If the discovery message contains information indicating the actual or current relaying capacity of the relay UE node (e.g., if the message contains one or more pieces of information included in the relaying capacity Information Element described above), the remote UE node will have additional information to base its decision on whether to initiate the establishment of a connection with the relay UE node.This helps the remote UE node select and connect to the optimal relay UE node (for example, based on the required QoS, bitrate, link quality, or load requirements). If the relay UE node does not send or has stopped sending sidelink management messages, the failure to receive a response after sending a link management request message (for example, if a discovery request message is sent and no discovery response message is received) indicates to the remote UE node that there are no available relay UE nodes (for example, the discovery request message is broadcast) or that the target relay UE (in the case of unicast) is overloaded or is experiencing other limitations that affect the relay UE's ability to support new connections to the remote UE node as described above.

[0187] Figure 12 is a schematic diagram of an exemplary wireless communication device (apparatus) according to one or more exemplary embodiments of the present disclosure.

[0188] The wireless communication device 1200 may preferably be a wireless communication device such as a microcomputer or workstation or a mobile device or a lightweight portable device or a fixed device. The communication device 1200 preferably includes a communication bus 1213 to which the following are connected: - This is a processing unit 1211 such as a microprocessor, and is shown as the CPU in Figure 12. The processing unit 1211 may be a single processing unit or processor, or it 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 assignment of processing functions to the central processing unit 1211 are design choices for those skilled in the art. - Memory for storing data and computer programs, including instructions for the operation of the communication device 1200. The computer program may include a plurality of different program elements (modules) or subroutines, including instructions for various operations and for carrying out 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 shown in Figure 1. The at least one communication interface 1202 may be connected to a communication network 1203, such as a wireless access network of the wireless communication system, through which digital data packets or frames or control frames are transmitted.

[0189] Each of the relay nodes and multiple nodes (e.g., remote UEs and network nodes) in a sidelink relay configuration or system can constitute such a communication device 1200.

[0190] Memory may include the following: - A read-only memory 1207, indicated by ROM, for storing a computer program for carrying out a method according to one or more embodiments of the present invention. - Random access memory 1212, indicated by RAM, for storing executable code for a method according to one or more embodiments of the present invention, and registers adapted for recording variables and parameters necessary for carrying out a method according to one or more embodiments of the present invention.

[0191] Optionally, the communication 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 carrying out a method according to one or more embodiments of the present invention. - A disk drive 1205 for disk 1206, the disk drive is adapted to read data from disk 1206 or write data to said disk. - A screen 1209 for displaying decoded data and / or for functioning as a graphical interface with the user via a keyboard 1210 or other user input means.

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

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

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

[0195] The processing unit 1211 is preferably adapted to control and direct the execution of instructions or portions of software code of the program according to the present invention, and these 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 technology described herein. Furthermore, the technology may be fully implemented in one or more circuits or logic elements.

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

[0197] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude plural. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

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

[0199] Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one location to another, for example, according to a communication protocol. Thus, computer-readable media may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to obtain instructions, code and / or data structures for carrying out the technology described herein. Computer program products may include computer-readable media.

[0200] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices, or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. It is also appropriate to refer to any connection as a computer-readable medium. For example, if 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, or microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, or microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media, but rather refer to non-transient tangible storage media. As used herein, the terms "disk" and "disc" include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy disks, and Blu-ray discs, where discs typically reproduce data magnetically, and discs reproduce data optically using a laser. Any combination of the above should also be included within the scope of computer-readable media.

Claims

1. A method performed by a relay user equipment (UE) node in a wireless communication system including a relay UE node and a plurality of nodes, wherein the relay UE node relays data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes, and the method in the relay UE node is The relay UE node identifies the relay capability for relaying data, Based on the identified relay capabilities, it is determined whether relaying to one or more remote UE nodes by the relay UE node is supported, In response to the determination that relaying by the relay UE node is possible to support relaying to one or more remote UE nodes, the relay UE node sends a sidelink management message indicating that relaying to one or more remote UE nodes is possible. In response to a determination that relaying by the relay UE node is not supported for one or more remote UE nodes, the relay UE node sends a sidelink management message indicating that relaying by the relay UE node to one or more remote UE nodes is not supported, or does not send one or more sidelink management messages. method.

2. The side link management message includes relay capability information indicating the relay capability of the relay UE node for relaying data by the relay UE node. The method according to claim 1.

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

4. One or more relay parameters include one or more of the following: the current load of the relay UE node, the network load, the number of remote UE nodes currently connected, the radio conditions on each communication link between the relay UE node and one or more nodes through which the relay UE node is relaying data, the QoS level for each of the one or more communication flows currently provided by the relay UE node, and the bitrate for each of the one or more communication flows currently provided by the relay UE node. The method according to claim 3.

5. The aforementioned side link management message is either a discovery message or a link management message. The method according to any one of claims 1 to 4.

6. The side link management message is a discovery message, and sending the side link management message includes broadcasting the discovery message. The method according to any one of claims 1 to 4.

7. The aforementioned side link management message is a discovery message, and sending a side link management message includes sending a discovery message as an announcement message. The method according to any one of claims 1 to 4.

8. The aforementioned side link management message is a discovery message, and the method further This includes receiving a discovery request message from a remote UE node, Sending a sidelink management message includes sending a discovery response message in response to the received discovery request message. The method according to any one of claims 1 to 4.

9. The method described above is This further includes receiving discovery request messages from remote UE nodes, In response to the determination that relaying by the relay UE node is not supported, not sending one or more sidelink management messages includes not sending a discovery response message in response to the received discovery request message. The method according to any one of claims 1 to 4.

10. The aforementioned side link management message is a link management message, and the method is This further includes receiving link management request messages from remote UE nodes, Sending a side link management message includes sending a link management message in response to a received link management request message. The method according to any one of claims 1 to 4.

11. The aforementioned method, This further includes receiving link management request messages from remote UE nodes, The failure to send one or more sidelink management messages in response to the determination that relaying by the relay UE node is not supported includes not sending a link management response message in response to the received link management request message. The method according to any one of claims 1 to 4.

12. The aforementioned side link management message is a direct link message, and the method is Sending a sidelink management message in response to a determination that relaying by the relay UE node is not supported further includes sending a direct link change request message or a release request message in response to a determination that relaying by the relay UE node is not supported. The method according to any one of claims 1 to 4.

13. A method performed at a remote user equipment (UE) node in a wireless communication system, wherein the wireless communication system includes the remote UE node, a relay UE node, and a plurality of other nodes, the relay UE node relays data between at least one of the plurality of nodes and at least one of the other nodes, and the method at the remote UE node is: The relay UE node receives a sidelink management message indicating whether relaying by the relay UE node to one or more remote UE nodes is supported, This includes taking action based on the received side link management message. method.

14. The side link management message includes relay capability information indicating the relay capability of the relay UE node for data relay by the relay UE node. The method according to claim 13.

15. Taking action in response to a determination, based on the received sidelink management message, that relaying by the relay UE node to one or more remote UE nodes is not supported, includes performing (re)selection, or performing at least one of the following for a different relay UE node: a discovery process, a direct link establishment process, or a direct communication process. The method according to claim 13 or claim 14.

16. Taking 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 supported, includes initiating the establishment of a connection with the relay UE node. The method according to any one of claims 13 to 15.

17. The aforementioned side link management message is either a discovery message or a link management message. The method according to any one of claims 13 to 16.

18. The sidelink management message includes relay capability information indicating the relay capability of the relay UE node for data relay by the relay UE node, and the relay capability information is, New connection information to indicate whether the relay UE node can accept a new connection to a new remote UE node, Relay load information to indicate the current load of the relay UE node, QoS (Quality of Service) is information that indicates the QoS level of one or more communication flows currently provided by the aforementioned relay UE node, Sidelink measurement report information for indicating the wireless 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 wireless quality of the communication link between the relay UE node and the network node of the wireless communication system, Bitrate information to indicate the maximum bitrate currently supported by the aforementioned relay UE scattering, Network load information to indicate current channel occupancy, and one or more of the following: The method according to any one of claims 1 to 17.

19. A method performed at a remote user equipment (UE) node in a wireless communication system, wherein the wireless communication system includes the remote UE node, relay UE nodes, and a plurality of other nodes, the relay UE node relays data between at least one of the plurality of nodes and at least one of the other nodes, and the method at the remote UE node is: 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, the system performs an action including at least one of the following: performing a (re)selection, or performing a discovery process, a direct link establishment process, or a direct communication process for a different relay UE node, or determining that no relay UE node is available for the remote UE node. method.

20. A method for signaling a link problem in a wireless communication system, wherein the wireless communication system includes a relay user equipment (UE) node and a plurality of nodes, the relay UE node relays data between at least one node of the plurality of nodes and at least one other node of the plurality of nodes, and the method in the relay UE node is To detect link problems in the aforementioned wireless communication system, In response to the detection of the link problem, generate link problem feedback information for the detected link problem, wherein the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. This includes transmitting the aforementioned 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 communication flows affected by the detected link problem. The method according to claim 20.

22. The transmission of link problem feedback information further includes 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 includes transmitting the link problem feedback information to at least one of the determined plurality of nodes. The method according to claim 20.

23. At least one of the plurality of nodes determined above includes at least one of a source node and a destination node. The method according to claim 22.

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

25. The link problem feedback information further includes an identifier for identifying at least one of the plurality of nodes to which the link problem feedback information should be sent. The method according to any one of claims 21 to 24.

26. A sidelink relay connection is established between the source node, the relay UE node, and the destination node. Detecting a link problem includes detecting a link problem related to at least one of the first link between the source node and the relay UE node, and the 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. 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. The method according to any one of claims 20 to 26.

28. The link problem feedback information further includes information for identifying the type of link problem detected. The method according to any one of claims 20 to 27.

29. The detected link problem is at least one of several different types of link problems, which include handover, congestion, link degradation, and radio link failure (RLF). The method according to claim 28.

30. The aforementioned congestion-type link problem includes at least one of the following: radio bearer (RB) congestion, RLC channel congestion, link-level congestion, or upper-layer congestion. The method according to claim 29.

31. Whether the detected link problem is a short-term or long-term problem The method according to any one of claims 28 to 30.

32. The flow information includes a flow identifier for identifying one or more communication flows affected by the detected link problem. The method according to any one of claims 20 to 31.

33. The process further includes determining one or more affected communication flows by the detected link problem using a mapping table that maps the detected link problem to one or more affected communication flows identified by their respective flow identifiers. The method according to any one of claims 20 to 32.

34. The flow identifier (ID) is one of the following: Data Radio Bearer (DRB) identifier (ID), Signaling Radio Bearer (SRB) ID, Sidelink (SL) DRB ID, SL SRB ID, RLC Bearer ID, RLC Channel ID, or Link ID for identifying the link associated with the detected link problem. The method according to claim 32 or claim 33.

35. Transmitting the link problem feedback information includes transmitting a link problem signaling message containing the link problem feedback information. The method according to any one of claims 20 to 34.

36. The link problem signaling message is transmitted in a container, which includes one of the following: a MAC CE container, a Sidelink Relay Adaptation Protocol (SRAP) control packet data unit (PDU), or RRC signaling. The method according to claim 35.

37. Transmitting the link problem feedback information includes transmitting the link problem signaling message via unicast, multicast, or broadcast communication. The method according to claim 35 or claim 36.

38. The link problem signaling message includes an information element of the flow information, and further includes at least one of the following: an information element indicating the type of the link problem signaling message; an information element identifying at least one of the plurality of nodes to which the link problem feedback information is sent; an information element identifying the type of the detected link problem; an information element indicating the reason for the detected link problem; an information element indicating the level of quality of service (QoS) or priority ensured by the relay UE node; and an information element indicating the size or level of the detected link problem. The method according to any one of claims 35 to 37.

39. The type of the link problem signaling message includes one of the following: a link problem feedback type, a (re)selection feedback type, or a link status change feedback type. The method according to claim 38.

40. A method for processing link problem feedback information at a node of a wireless communication system, wherein the link problem feedback information signals a link problem in the wireless communication system, the wireless communication system includes the node, a relay UE node, and at least one other node, and the method is Receiving link problem feedback information from the relay UE node, wherein the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. The link problem feedback information is processed to determine one or more communication flows affected by the detected link problem based on the flow information, and the level of impact of the detected link problem on data communication at the nodes on one or more determined communication flows is evaluated. This includes taking action at the node based on the evaluated level of the impact of the detected link problem. A method characterized by the following:

41. The link problem is at least one of several different types of link problems, the types of several link problems include 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. The method according to claim 40.

42. The flow information includes a flow identifier for identifying one or more communication flows affected by the detected link problem. The method according to any one of claims 40 to 41.

43. The flow identifier (ID) is one of the following: a Data Radio Bearer (DRB) identifier (ID), a Signaling Radio Bearer (SRB) ID, a Sidelink (SL) DRB ID, an SL SRB ID, an RLC bearer ID, an RLC channel ID, or a link ID for identifying the link associated with the detected link problem. The method according to claim 42.

44. Receiving link problem feedback information includes receiving a link problem signaling message containing the link problem feedback information. The method according to any one of claims 40 to 43.

45. The received link problem signaling message is contained in a container, which includes either a MAC CE container, a Sidelink Relay Adaptation Protocol (SRAP) control packet data unit (PDU), or RRC signaling. The method according to claim 44.

46. The link problem signaling message includes an information element of the flow information, and further includes at least one of the following: an information element indicating the type of the link problem signaling message; an information element identifying at least one of the plurality of nodes to which the link problem feedback information is sent; an information element identifying the type of the detected link problem; an information element indicating the reason for the detected link problem; an information element indicating the level of quality of service (QoS) or priority ensured by the relay UE node; and an information element indicating the size or level of the detected link problem. The method according to claim 44 or claim 45.

47. The process further includes determining the type of the link problem signaling message based on the information elements for indicating the type of the link problem signaling message, wherein the type of the link problem signaling message is one of a link problem feedback type, a (re)selection feedback type, or a link status change feedback type. The method according to claim 46.

48. Deciding whether to take action includes deciding whether to take action at the node based on the determined type of link problem signaling message and the assessed level of the impact of the detected link problem. The method according to claim 47.

49. Taking action at the node includes releasing and (re)selecting links associated with one or more affected communication flows, waiting for new link problem feedback information, and adapting data transmission on one or more affected communication flows. The method according to any one of claims 40 to 48.

50. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, wherein 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, and the method in the relay UE node is To detect link problems in the aforementioned wireless communication system, The process involves generating link problem feedback information for the detected link problem, wherein the link problem feedback information includes information for identifying the type of the detected link problem. Sending a discovery message containing the aforementioned link problem feedback information, method.

51. The link problem feedback information includes contextual information to indicate the context of the detected link problem. The method according to claim 50.

52. Sending a discovery message includes broadcasting the discovery message. The method according to claim 50 or claim 51.

53. Sending a discovery message includes sending the discovery message as an announcement message. The method according to any one of claims 50 to 51.

54. This further includes receiving discovery request messages from remote UE nodes, Sending a discovery message includes sending the discovery message in response to a discovery request message received. The method according to any one of claims 50 to 51.

55. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, wherein the relay UE node relays data between at least one of the plurality of nodes and at least one other node of the plurality of nodes, and the method in the relay UE node is To detect link problems in the aforementioned wireless communication system, This includes stopping the transmission of one or more discovery messages in response to detecting the aforementioned link problem. method.

56. The detected link problem is at least one of several different types of link problems, which include handover, congestion, link degradation, radio link failure (RLF), and short-term or long-term link problems. The method according to any one of claims 50 to 55.

57. A method for signaling a link problem in a wireless communication system including a relay user equipment (UE) node and a plurality of nodes, wherein the relay UE node relays data between at least one of the plurality of nodes and at least one other node of the plurality of nodes, and the method in the relay UE node is To detect congestion link problems in wireless communication systems, In response to the detection of the aforementioned congestion link problem, link problem feedback information is generated that includes information indicating that a congestion link problem has been detected. This includes transmitting the link problem feedback information in relay (re)selection signaling. method.

58. A computer program that, when executed by a computer, includes an instruction causing the computer to execute the control method described in any one of claims 1 to 57.

59. A computer-readable medium for carrying the computer program described in claim 58.

60. A device for a relay user equipment (UE) node of a wireless communication system, wherein the relay UE node relays 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, and the device, The relay capabilities for relaying data by the aforementioned relay UE node are identified, Based on the identified relay capability, it is determined whether relaying to one or more remote UE nodes by the relay UE node is supported. In response to the determination that the relay UE node can support relaying to one or more remote UE nodes, the relay UE node sends a sidelink management message indicating that it can support relaying to one or more remote UE nodes. The system includes one or more processing units configured to either send a sidelink management message indicating that the relay UE node cannot support relaying to one or more remote UE nodes, or to refrain from sending one or more sidelink management messages, in response to a determination that the relay UE node cannot support relaying to one or more remote UE nodes. 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. The apparatus according to claim 60.

62. A device for a remote user equipment (UE) node for a wireless communication system, wherein the device is The relay UE node receives a sidelink management message indicating whether the relay UE node can support relaying data to one or more remote UE nodes. Includes one or more processing units configured to perform actions based on the received side link 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. The apparatus according to claim 62.

64. A device for a remote user equipment (UE) node of a wireless communication system, wherein the device is Send a request message to initiate communication with the relay UE node. The system includes one or more processing units configured to perform actions including, in response to not receiving a message in response to the request message, performing a (re)selection, or performing a discovery process, a direct link establishment process, or a direct communication process for a different relay UE node, or determining that no relay UE nodes are available for the remote UE node. Device.

65. A device for a relay user equipment (UE) node of a wireless communication system, wherein the relay UE node relays 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, and the device, The link problem of the wireless communication system is detected, In response to the detection of the link problem, link problem feedback information for the detected link problem is generated, and the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. Includes one or more processing units configured to transmit feedback information about the link problem. Device.

66. One or more of the processing units are further configured to perform the method according to any one of claims 21 to 39. The apparatus according to claim 65.

67. A device for a node of a wireless communication system, wherein the device, The relay UE node receives link problem feedback information signaling a link problem in the wireless communication system, and the link problem feedback information includes flow information for identifying one or more communication flows affected by the detected link problem. Based on the flow information, one or more communication flows affected by the detected link problem are determined, and on one or more determined communication flows, the level of impact of the detected link problem on the data communication of the node is processed, and the link problem feedback information is processed. Includes one or more processing units configured to perform actions on the node based on the evaluated level of the impact of the detected link problem. Device.

68. One or more of the processing units are further configured to perform the method described in any one of claims 41 to 49. The apparatus according to claim 67.

69. A device for a relay user equipment (UE) node of a wireless communication system, wherein the relay UE node relays 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, and the device, The link problem of the wireless communication system is detected, The system generates link problem feedback information for the detected link problem, and the link problem feedback information includes information for identifying the type of the detected link problem. Includes one or more processing units configured to send discovery messages containing the aforementioned link problem feedback information. Device.

70. A device for a relay user equipment (UE) node of a wireless communication system, wherein the relay UE node relays 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, and the device, The link problem of the wireless communication system is detected, Includes one or more processing units configured to stop sending one or more discovery messages in response to detecting the aforementioned link problem. Device.

71. A device for a relay user equipment (UE) node of a wireless communication system, wherein the relay UE node relays 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, and the device, The congested link problem of the wireless communication system is detected, In response to the detection of the aforementioned congestion link problem, link problem feedback information is generated, which includes information indicating that a congestion link problem has been detected. Includes one or more processing units configured to transmit the link problem feedback information in relay (re)selection signaling. Device.

72. A relay UE node in a wireless communication system including multiple nodes, wherein the relay UE node is At least one communication interface for relaying data between at least one of the plurality of nodes and at least one other node among the plurality of nodes, A processing unit connected to at least one of the communication interfaces and configured to perform the method described in any one of claims 1 to 12, 18, 20 to 39, or 50 to 57, is included. Relay UE node.

73. A node in a wireless communication system, which includes a relay UE node and at least one other node, wherein the node is At least one communication interface for communicating data between the node and at least the relay UE node, A processing unit connected to at least one of the communication interfaces and configured to perform the method described in any one of claims 13 to 19, 40 to 49, is included. node.

Images