Backhaul link issues in Integrated Access and Backhaul Networks

Abstract

A method is disclosed in an IAB node of an Integrated Access and Backhaul (IAB) network. The IAB network includes a donor Central Unit (CU). The method includes detecting a link problem of data transmission on a backhaul of the IAB network and, in response to detecting the link problem, sending a land fault notification to the donor CU. The link fault notification includes link identification information identifying a backhaul link and link problem information regarding the detected link problem including information associated with a cause of the detected link problem. The cause of the detected link problem can be one of a link recovery failure, a slow recovery of the link problem, or a recurring link problem.

Description

[Technical field]

[0001] The present invention relates generally to backhaul link problems in Integrated Access and Backhaul (IAB) networks of wireless communication systems, and more particularly to link detection problems in IAB networks. [Background technology]

[0002] Wireless communication systems have been widely deployed to accommodate a wide range of applications, from mobile broadband, massive scale machine type communications, to ultra-reliable low latency communications (URLLC). In such systems, multiple User Equipments (UEs) or mobile terminals can share a wireless medium to exchange multiple types of data content (e.g., video, voice, messaging, etc.) over a Radio Access Network (RAN) via one or more base stations. The base stations are traditionally wired (e.g., fiber, etc.) connected to a core network, forming an intermediate network called the backhaul (BH).

[0003] Examples of such wireless multiple-access communication systems include systems based on 3rd Generation Partnership Project (3GPP) standards such as Fourth Generation (4G) Long Term Evolution (LTE) or the more recent Fifth Generation (5G) New Radio (NR), as well as IEEE 802.11-based systems such as WiFi.

[0004] The demand for network densification (eg, dense deployment of base stations) is increasing due to an increasing number of users and a demand for higher throughput.

[0005] Faced with the high deployment costs and time issues of wired backhaul networks due to network densification, 3GPP proposed wireless backhaul, also known as Integrated Access and Backhaul (IAB), in its recent Release 16 for 5G NR, where a portion of the radio (e.g., radio) spectrum instead of fiber is used for backhaul connecting base stations. Wireless backhaul communications or links (between base stations) may use the same radio resources as access communications or links (between base stations and UEs).

[0006] IAB proves to be a competitive alternative to fiber-based backhaul in high-density or hard-to-cover areas because it is scalable and quick to install, without the burden of base station cabling.

[0007] An IAB network includes one IAB node or one IAB base station (also called an IAB donor) that is directly connected to a core network via a non-IAB backhaul (e.g., fiber-based backhaul), and multiple IAB nodes or multiple IAB base stations. Multiple backhaul paths are established between the IAB donor and the IAB node that serves the UE, also called an "access IAB node" from the UE. In each of the multiple backhaul paths between the IAB donor and the access IAB node, several intermediate IAB nodes are included, forming alternative data paths in the multi-hop IAB network.

[0008] In the IAB network topology, the direction from the IAB donor to the access IAB node (and UE) is called downstream, and defines a parent IAB node and a child IAB node for each link. The direction towards the IAB donor is called upstream. Each IAB node, directly or indirectly associated with an IAB donor, consists of an IAB donor with an IAB-MT (IAB-Mobile Terminal) for upstream communication, and an IAB-DU (IAB-Distributed Unit) for downstream communication.

[0009] Similar to a conventional 5G base station (gNB), the IAB donor consists of a central unit (CU or gNB-CU functionality) and one or more distributed units (DU or gNB-DU functionality). The IAB donor CU hosts the higher layer protocols for controlling the operation of one or more DUs, and each of the one or more IAB donor DUs includes the lower layer protocols, including the physical layer and radio frequency part. The IAB donor CU and one or more IAB donor DUs may be located remotely from each other, and a wired IP network (typically fiber connection) exists to interconnect between these different devices. The advantage of multiple DUs connecting to a single CU is the centralization and resource sharing of less time-critical operations in the CU (virtualization), while time-critical operations such as scheduling, fast retransmission, segmentation, etc. are performed in the DUs. As a result, in the downstream direction, there may be multiple backhaul paths from the IAB donor CU to the IAB node via different IAB donor DUs. Similarly, in the upstream direction, there may be multiple possible backhaul paths from the source IAB node to the IAB donor CU via different IAB donor DUs.

[0010] To enable routing over multiple backhaul hops, a specific IAB protocol sublayer, Backhaul Adaptation Protocol (BAP), is introduced, as specified in the 3GPP Release 16 standard TS 38.340 (version 16.3.0). There is one BAP entity in the IAB-MT, one in the IAB-DU, and one in the IAB Donor DU. A unique BAP address is assigned to each IAB node, each IAB Donor DU by the IAB Donor CU, which is responsible for managing the IAB network. The BAP sublayer encapsulates IP Service Data Units (SDUs) into BAP Protocol Data Units (PDUs), and each BAP PDU consists of a BAP header and a payload section containing the IP SDUs.

[0011] The IAB will most likely operate in millimeter wave (mmWave) to achieve the required gigabit per second (Gbps) data rates.

[0012] However, mmWave is known to suffer from strong attenuation of signal strength in some weather conditions (rain, fog) and is disrupted by obstacles in the path between emitter and receiver, which can result in frequent failures of the radio link.

[0013] To address these potential radio link failures, topology redundancy is provided within the IAB framework, where multiple backhaul paths are established between the IAB donor and the access IAB nodes via multiple intermediate IAB nodes that provide alternative backhaul paths as discussed above.

[0014] A path through a set of IAB nodes along which data is preferably sent is defined as a default. Also, one or more backup paths through a different set of IAB nodes are defined that may be used in case of radio link failure (RLF) on any link of the default path. The links are defined between two consecutive IAB nodes in the backhaul network. The backup paths also help in case of congestion due to application traffic demands exceeding the capacity of the default link (which may vary depending on the quality of the link). Rerouting of traffic to the backup paths or load balancing between the default path and one or more of the backup paths may be activated to alleviate the congestion.

[0015] RLF and congestion are two types of backhaul (BH) link issues. Traffic rerouting or load balancing can help mitigate short-term (e.g., transient) BH link issues (RLF / BH link quality / congestion) phenomena. In other words, short-term BH link issues are BH link problems that are short-lived and recover quickly (e.g., due to quick recovery of link quality). However, traffic rerouting or load balancing can increase the risk of congestion at other IAB nodes, since the IAB node performing the rerouting is not aware of the congestion level of the distant IAB node.

[0016] Thus, even though local rerouting that allows for fast link adaptation provides an efficient means to mitigate the impact of short-term BH link problems, it may not be suitable for long-term (recurring or long-lasting) BH link problems. Since the IAB donor is the only node that has knowledge of the entire IAB network topology, a long-term BH link issue may require the IAB donor to reconfigure the routing configuration of all or some of the IAB nodes.

[0017] The 3GPP Release 16 standard specifies little service for reporting local BH link problems to the IAB donor. In this regard, no signaling is specified for reporting long-term BH link problems. As discussed before, even though short-term BH link problems can be mitigated by the IAB nodes through local re-routing, long-term BH link problems may require new routing configurations in all or some of the IAB nodes to adapt to the new situation caused by the long-term BH link problems. However, the IAB donor has no knowledge (as of Release 16) of short-term or long-term local IAB problems.

[0018] Therefore, some new mechanisms are required to overcome the above mentioned challenges while limiting the processing complexity and delays caused by such processing at the IAB nodes. Summary of the Invention

[0019] According to a first aspect of the present invention, there is provided a method in an Integrated Access and Backhaul (IAB) node of an IAB network including a donor Central Unit (CU), the method comprising: detecting a link problem in data transmission on a backhaul of the IAB network, and in response to detecting the link problem, transmitting a link failure notification to the donor CU, the link failure notification including link identification information identifying the backhaul link and link problem information relating to the detected link problem including information associated with a cause of the detected link problem.

[0020] Thus, a link problem can be identified at an IAB node by detecting the link problem and sending a link failure notification to a donor CU in response to detecting the link problem, and a link failure notification is sent to the donor CU upon detection of the link problem along with information associated with the cause of the link problem so that the donor can identify the cause or type of cause and reconfigure the routing configuration of some or all of the IAB nodes in the IAB network, if necessary, to ensure early and efficient handling of the link problem to minimize service interruptions. Because the link failure notification from an IAB node in the IAB network can provide the donor CU with information about the local link problem occurring at the IAB node, the donor CU can have a more detailed understanding of the link problems in the IAB network and can determine a more efficient reconfiguration of the IAB network required to resolve the link problem, as compared to when the donor CU does not have information about the local link problem.

[0021] The information associated with the cause of the link problem may include information indicative of a cause of the detected link problem or information indicative of a type of cause of the detected link problem, for example, the type of the detected link problem is one of a long-term cause (e.g., causing a long-term link problem) or a short-term cause (causing a short-term link problem).

[0022] The detected cause of the link problem may include one of a link recovery failure, a slow recovery of the link problem, and a recurring link problem, for example, each of such causes being a long-term cause that causes a long-term link problem or a long-term failure.

[0023] Short-term causes may include excess data on the backhaul link that lasts for a short period of time (e.g., that recovers quickly) causing congestion as a short-term link issue, or link quality on the backhaul link that is below a threshold that lasts for a short period of time (e.g., that recovers quickly) causing radio link failure (RLF) as a short-term link issue.

[0024] The method further includes determining whether the detected link problem will cause a long-term link problem, and sending a link failure notification to the donor CU is in response to determining that the detected link problem will cause a long-term link problem.

[0025] Thus, by determining whether the detected link problem results in a long-term link problem, and by sending a link fault notification to the donor CU in response to determining that the detected link problem results in a long-term link problem, a long-term link problem may be identified at the IAB node and a notification may be sent to the donor CU upon detection of the long-term link problem so that the donor can identify the cause of the long-term link problem and reconfigure the routing configuration of some or all of the IAB nodes in the IAB network to ensure early and efficient handling of the long-term link problem to minimize service interruptions. In other words, the long-term link problem may be distinguished from a short-term link problem and efficiently handled at the donor CU via the link fault notification.

[0026] A long-term link problem or failure requires a reconfiguration of the routing configuration in the IAB network (e.g., some or all of the IAB nodes in the IAB network) by the donor CU (or IAB donor CU), while a short-term link problem or failure can be handled locally at the IAB node. A long-term link problem is a recurring or continuous link problem or a long-lasting link problem that takes a long time to recover or never recovers, and requires a reconfiguration of the routing configuration of the IAB network by the donor CU. A short-term failure or BH link problem is a short-term failure or BH link problem that is temporary in duration and can be recovered quickly (e.g., by early recovery of link quality or link loss and / or local action at one or more IAB nodes) and does not require a reconfiguration of the routing configuration of some or all of the IAB nodes to the donor CU. A long-term failure or long-term BH link problem is a failure or BH link problem that is irreparable, or that recurs in a short period of time, or that is not quickly recovered from, all of which require the donor CU to reconfigure the routing configuration of all or part of the IAB nodes in the IAB network.

[0027] The detected link problem may be a Radio Link Failure (RLF) on the backhaul link or congestion affecting data transmission on the backhaul link.

[0028] In one example, the link problem information related to the detected link problem further includes information indicating the nature of the detected link problem, information identifying the type of link problem detected, information identifying the link quality of the backhaul link, and link problem time information indicating the time between detection of the link problem and sending of a link fault notification.

[0029] In one example, the IAB node includes a mobile terminal (MT), and detecting a link problem in data transmission on the backhaul link and sending a link failure notification to the donor CU is performed by the MT of the IAB node.

[0030] In one example, the link failure notification may be sent by the MT of the IAB node in an RRC message.

[0031] In one example, the IAB node includes a Distributed Unit (DU), and detecting link problems in data transmission on the backhaul link and sending link failure notifications to the donor CU are performed by the DU of the IAB node.

[0032] In one example, the link failure notification may be sent by the DU of the IAB node in an F1 Application Protocol (F1-AP) layer message.

[0033] According to a second aspect, there is provided a method in a Donor Central Unit (CU) of an Integrated Access and Backhaul (IAB) network as referred to in any one of claims 24 to 33 of the accompanying patent claims.

[0034] According to a third aspect, there is provided an Integrated Access and Backhaul (IAB) node as referred to in claim 34.

[0035] According to a fourth aspect, there is provided a Donor Central Unit (CU) as referred to in claim 35.

[0036] According to a fifth aspect, there is provided a method in a donor Central Unit (CU) of an Integrated Access and Backhaul (IAB) network including a plurality of IAB nodes, the method including: Send backhaul link fault configuration information from the CU to multiple IAB nodes, including: information indicating a maximum number of consecutive link problems detected in data transmission on the backhaul link; recovery timeout information indicating a maximum period between the time of detection of a link problem and the time of recovery from the detected link problem; A link problem recovery time window having a predetermined length within which a maximum number of consecutive link problems can be detected.

[0037] According to a sixth aspect of the present invention, there is provided a method in an Integrated Access and Backhaul (IAB) node of an IAB network including a donor Central Unit (CU), comprising: Detect link problems in data transmission on the backhaul of the IAB network; In response to determining that a predetermined link failure criterion (also referred to as a predetermined link problem criterion) for data transmission on the backhaul link has been met, send a link failure notification to the donor CU including information associated with the predetermined link failure criterion that has been determined to have been met (wherein the link failure notification includes link identification information that identifies the backhaul link and link problem information related to the detected link problem).

[0038] The predefined link problem criteria may represent a cause of the link problem, and the information associated with the predefined link problem criteria may include information indicating a cause of the detected link problem or a type of cause of the detected link problem, for example, the type of cause of the detected link problem may be one of a long-term cause (e.g., causing a long-term link problem) or a short-term cause (causing a short-term link problem).

[0039] The detected cause of the link problem may include one of a link recovery failure, a slow recovery of the link problem, and a recurring link problem, for example, each of such causes being a long-term cause that causes a long-term link problem or a long-term failure.

[0040] The method may further include determining whether the detected link problem is associated with a restoration failure of the backhaul link, and if the detected link problem is associated with a restoration failure of the backhaul link, a predetermined link failure criterion is met.

[0041] The method may further include, if the detected link problem is not associated with a recovery failure of the backhaul link, determining whether the detected consecutive link problems reach a threshold corresponding to a maximum number of consecutive link problems, and determining that a predetermined link failure criterion is met if the number of detected consecutive link problems reaches the threshold.

[0042] The method may further include, if the detected link problem is not associated with a recovery failure of the backhaul link, determining whether a number of consecutive link problems detected during a link problem recovery time window having a predetermined length reaches a threshold, and determining that a predetermined link failure criterion is met if the number of detected link problems reaches the threshold.

[0043] The method may further include determining whether the detected link problems have been recovered if the number of detected link problems has not reached a threshold, and determining that a predetermined link failure criterion is met in response to a determination that the detected link problems have not been recovered within a recovery timeout period or in response to a determination of a backhaul link recovery failure.

[0044] In summary, new methods and associated Information Elements are added to the existing 3GPP IAB framework to mitigate service interruptions when one or more BH links experience long-term BH link problems.

[0045] In summary, new methods and associated Information Elements are added to the existing 3GPP IAB framework to mitigate service interruptions when one or more BH links experience long-term BH link problems.

[0046] Further features of the invention are characterized in the other independent or dependent claims.

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

[0048] Furthermore, functionality implemented in hardware may be implemented in software and vice versa. References herein to any software and hardware features should be construed accordingly. For example, according to another aspect of the invention, there is provided a computer-readable storage medium having recorded thereon at least one computer program comprising instructions which, when executed by a processing unit, cause the processing device to perform a method according to any aspect or example described above.

[0049] It should also be understood that certain combinations of the various features described and defined in any aspect of the present invention may be implemented and / or provided and / or used independently. [Brief description of the drawings]

[0050] Different aspects of the invention will now be described, by way of example only, with reference to the following drawings, in which: [Figure 1] FIG. 1 is a schematic diagram illustrating a wireless communication system including a wireless Integrated Access and Backhaul (IAB) network. [Figure 2a] FIG. 1 is a schematic diagram showing a stack of multiple protocol layers involved in IAB operations. [Figure 2b] FIG. 1 is a schematic diagram showing a stack of multiple protocol layers involved in IAB operations. [Diagram 3] 1 is a schematic diagram showing the format of a BAP Protocol Data Unit (PDU) or packet. [Figure 4] FIG. 2 is a schematic diagram showing routing management in an IAB network. [Diagram 5] 1 shows the fields of the routing table of an IAB node according to 3GPP TS 38.300. [Figure 6] FIG. 1 is a schematic diagram illustrating an example topology of an IAB network deployment in which the present invention may be implemented in accordance with one or more exemplary embodiments. [Figure 7] A flow chart illustrates an exemplary method for managing detection of long-term BH link problems according to an embodiment of the present invention. [Figure 8] FIG. 2 is a schematic and simplified diagram illustrating an exemplary message flow for reporting long-term BH link problems from an IAB node to an IAB donor according to an embodiment of the present invention. [Figure 9] 1 illustrates, with the aid of a flow chart, an exemplary method in an IAB node for managing detection of long-term BH link problems according to an embodiment of the present invention. [Figure 10] 1 is a block schematic diagram of an example wireless communication device implementing an embodiment of the present invention; [Figure 11] 1 illustrates an exemplary method in an IAB donor CU for managing long-term BH link issues according to an embodiment of the present invention with a flowchart. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0051] 1 illustrates an example of a wireless communication system 100, in particular a mobile wireless communication system such as a fifth generation (5G) New Radio (NR) that includes a wireless Integrated Access and Backhaul network. In the following description, embodiments and example embodiments of the present invention are described with respect to a 5G NR system, but it is understood that the present invention is not intended to be limited to a 5G NR system and may be used in any wireless communication system having an Integrated Access and Backhaul network in which a wireless access link and a wireless backhaul link share radio resources.

[0052] The system 100 includes multiple User Equipment (UE) 132, 133, 131 and 134, a remote core network 110, a main base station 120, and two Integrated Access and Backhaul (IAB) stations or IAB nodes 121 and 122 (hereinafter also referred to as IAB nodes).

[0053] A primary base station 120 (also referred to as IAB donor 120, hereinafter also referred to as IAB donor) is connected to the core network 110 via a wired link 101 (preferably optical fiber or any other wired means). In embodiments and example embodiments of the present invention, the IAB donor 120 is a 5G NR gNB with additional functionality (as defined in the 3GPP TS 38.300 v16.2.0 standard document) to support IAB functionality.

[0054] To extend the network coverage of the IAB donor 120 and reach distant UEs 132, 133 and 131, IAB stations 121 and 122 (also called IAB nodes 121 and 122) are installed by the operator. By acting as relay nodes between the IAB donor 120 and the UEs 132 and 133, the IAB nodes 121 and 122 are able to overcome reachability problems resulting from the presence of buildings 108 (which are obstacles for the propagation of radio waves and therefore for direct connection and further communication between the UEs and the IAB donor). This is especially true when the communication between the IAB donor 120 and the UEs 132 and 133 operates at mmWave frequencies, which are highly sensitive to the shadowing phenomenon.

[0055] The IAB donor 120 also provides services to UEs 134 that are directly connected to it. IAB donor 120 and IAB stations 121 and 122 thus form a backhaul network or IAB network accommodating UEs 132, 133, 131 and 134.

[0056] The Integrated Access and Backhaul (IAB) standard spans multiple 3GPP standard documents, including: -TS 38.300 RAN architecture (V16.2.0) - TS 38.321 MAC protocol (V16.1.0) - TS 38.331 radio Resource Control (RRC) protocol (V16.1.0) - TS 38.340 Backhaul Adaptation Protocol Layer (V16.1.0) -TS 38.401 RAN architecture (V16.2.0) - TS 38.473 F1 Application Protocol (V16.2.0)

[0057] Because IAB nodes 121 and 122 are connected to UEs 131, 132 and 133, respectively, they are considered to be access IAB nodes for the UEs connected to them.

[0058] The IAB donor 120 is a logical node providing NR-based radio backhaul and consists of a central unit (CU or gNB-CU functionality) and connected donor distributed units (DU or gNB-DU functionality). The IAB donor CU or donor CU (hereinafter also referred to as IAB donor CU) hosts one or more DUs including lower layer protocols such as RLC, MAC and physical layer protocols and higher layer protocols such as Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) for controlling the operation of one or more IAB donor DUs or donor DUs, respectively. The IAB donor CU or donor CU and the IAB donor DU or donor DU may be located remotely from each other or may be located in the same physical device. The gNB-DU functionality is specified in 3GPP TS 38.401. As shown in Figures 2a and 2b discussed below, it is intended to terminate the NR access interface at the UE and the next-hop IAB node and terminate the F1 protocol at the IAB node gNB-CU functionality.

[0059] IAB nodes that may serve multiple wireless sectors are wirelessly backhauled to the IAB donor 120 via one or more hops over intermediate IAB nodes. They form a directed acyclic graph (DAG) topology rooted at the IAB donor at its root.

[0060] An IAB node consists of an IAB-DU (hereinafter also referred to as IAB DU) and an IAB-MT (IAB-Mobile Termination) (hereinafter also referred to as IAB MT). The gNB-DU function on an IAB node, also referred to as IAB-DU, enables downstream (towards the UE) connection to the next hop IAB. The IAB-MT function includes functions (e.g., physical layer, Layer 2, RRC and non-access stratum (NAS functions)) for connecting to the gNB-DU of an upstream IAB node (e.g., including the IAB donor 120 when connecting to the IAB donor gNB-CU (i.e., core network 110) for initialization, registration, configuration).

[0061] In this DAG topology, the neighboring node on the IAB-DU' interface is called the child node, and the neighboring node on the IAB-MT' interface is called the parent node. The direction towards the child node is further called downstream, and the direction towards the parent node is called upstream.

[0062] The IAB donor 120 performs centralized resource, topology, and route management for the entire IAB topology, including configuring IAB nodes according to the network topology to perform proper routing of data packets.

[0063] 2a and 2b show an overview of the stack of several protocol layers involved in IAB operation.

[0064] The F1 interface supports the exchange of signaling information between the endpoints and the transmission of data to each endpoint. From a logical point of view, the F1 interface is a point-to-point interface between the endpoints.

[0065] In 5G NR, F1-C is a functional interface in the control plane (CP) between IAB-Donor CU and IAB Node DU (e.g., DU of IAB Node 2) and between IAB-Donor CU and IAB Donor DU. F1-U is a functional interface in the user plane (UP) of the same units. F1-C and F1-U are indicated by reference 212 in FIG. 2a. In this example, F1-U and F1-C are transmitted over two backhaul hops (from IAB-Donor to IAB Node 1 and then from IAB Node 1 to IAB Node 2).

[0066] In the user plane, box 210 in the IAB donor CU and IAB node DU refers to the GTP-U layer and box 211 refers to the UDP layer. GTP-U stands for GPRS Tunnelling Protocol User Plane. A GTP-U tunnel carries encapsulated PDUs and signaling messages between a given pair of GTP-U tunnel endpoints (here, IAB donor CU and IAB node DU box 210, see 3GPP TS 29.281 for more details). The well-known User Datagram Protocol (UDP) is a transport layer protocol suitable for use with IP protocols, providing a best-effort datagram service.

[0067] In the control plane, box 210 indicates the F1-AP layer (F1 Application Protocol) and box 211 indicates the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (specified in 3GPP TS 38.473 and TS 38.401) provides signaling services between the IAB donor CU and the IAB node DU or services associated with the UE. These services are e.g. initialization, configuration, etc. The known SCTP layer provides reliable, in-sequence delivery of messages with congestion control.

[0068] F1-U and F1-C rely on the IP transport layer between the IAB donor CU and the IAB node DU as specified in 3GPP TS 38.401.

[0069] The transport between the IAB Donor DU and the IAB Donor CU also uses the IP transport layer over various media, e.g., wired or optical fiber, when the IAB Donor CU is remote from the IAB Donor DU, or when the IAB Donor CU and the IAB Donor DU are in a local virtual instance on the same physical machine. The IAB specific transport between the IAB Donor CU and the IAB Donor DU is specified in 3GPP TS 38.401.

[0070] L1 and L2 on FIG. 2 represent the transport and physical layers appropriate to the medium in use, respectively.

[0071] The IP layer may also be used for non-F1 traffic, such as Operation, Administration and Maintenance traffic.

[0072] Over the wireless backhaul, the IP layer is itself transported over a Backhaul Adaptation Protocol (BAP) sublayer that allows routing over multiple hops. The BAP sublayer is specified in TS 38.340.

[0073] IP traffic in the IAB-DU is routed over the wireless backhaul via the BAP sublayer. In the downstream direction, upper layer packets are encapsulated by the BAP sublayer in the IAB donor DU to form BAP packets or packet data units (PDUs) or data packets. The BAP packets are routed by the BAP layers or entities of intermediate IAB nodes, if any (and corresponding BAP entities in the IAB-DU and IAB-MT). The BAP packets are finally decapsulated by the BAP sublayer of the destination IAB node (which could be the access IAB node if the upper layer packets in the BAP packet are destined for the UE).

[0074] In the upstream direction, the upper layer packets are encapsulated by the BAP sublayer of the initiator IAB node (which could be the access IAB node if the upper layer packets come from a UE) to form BAP packets or data units (PDUs) or data packets. The BAP packets are routed by the BAP layers of intermediate IAB nodes (and corresponding BAP entities in the IAB-DU and IAB-MT), if any. The BAP packets are finally decapsulated by the BAP sublayer of the IAB donor DU.

[0075] On the BAP sublayer, packets are routed based on the BAP Routing ID (carried in the BAP header of the BAP packet and set by the BAP sublayer of the originating IAB donor DU or initiator IAB node (e.g., a network node in the IAB network that generates the BAP packet). Figure 3 shows the format of the BAP Data Protocol Data Unit (PDU) or packet. It is specified in paragraph 6.2 of the standardized version of 3GPP TS 38.340 Release 16.3.0.

[0076] The payload section 307 is typically an IP packet. The header 30 includes fields 301 to 306. Field 301 is called the D / C field and is a Boolean that indicates whether the corresponding BAP packet is a BAP Data packet or a BAP Control packet. Fields 302-304 are 1-bit reserved fields, preferably set to 0 (ignored by the receiver).

[0077] Fields 305 and 306 together indicate the BAP routing ID of the BAP packet. The BAP Address field 305 (also called the DESTINATION field) is located in the leftmost 10 bits, and the BAP path identity field 306 (also called the PATH field) is located in the rightmost 10 bits.

[0078] Field 305 carries the BAP address (e.g., on the BAP sublayer) of the destination IAB node or IAB donor DU of the BAP packet. For routing purposes, each IAB node and IAB donor DU in the IAB network is configured with a unique BAP address assigned to it (by the IAB donor CU of the IAB network). Field 306 carries a path ID that identifies the routing path, to which the BAP packet should follow in the IAB topology. The routing path, including the path ID, is configured in the IAB node (by the IAB donor CU of the IAB network) for routing purposes.

[0079] The BAP header is added to a packet when it arrives at the BAP layer from higher layers and is removed at the BAP layer when it reaches the destination node. The selection of the BAP Routing ID for a packet is configured by the IAB donor CU.

[0080] For example, when a BAP packet is generated by a node (e.g., an IAB donor DU in downstream transmission or an initiator in upstream transmission (which can be an access IAB node if the upper layer packet comes from a UE)), a BAP header with a BAP routing ID is built by this node according to a configuration table specified in 3GPP TS 38.340. This table is called the Downlink Traffic to Routing ID Mapping Configuration table in the IAB donor DU or the Uplink Traffic to Routing ID Mapping Configuration table in the initiator IAB node. In intermediate IAB nodes, the fields of the BAP header are already specified in the BAP packet they forward.

[0081] As mentioned above, these configuration tables that define the BAP paths (i.e., the routing strategy and configuration for a given IAB network topology) are typically defined by IAB donor CUs and sent to IAB nodes for configuration.

[0082] The use of these tables (and other tables) to perform routing is described below with reference to FIG.

[0083] To transfer messages over the 5G NR wireless medium, three further sublayers (RLC, MAC and physical) are implemented in each IAB node under the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconfiguration. It is also responsible for requesting retransmission of lost packets. The RLC layer is further specified in TS 38.322. The MAC (Medium Access Channel) protocol sublayer is responsible for the selection of the available user data transmission format and for mapping logical channels to transport channels. MAC also handles part of the hybrid automatic repeat request scheme. The MAC layer is detailed in TS 38.321. At the origination or transmission side, the MAC encapsulates the data packets issued by the RLC. It adds a header that carries the information required for the MAC function. At the reception side, the MAC decapsulates the data packets issued by the PHY, removes the header and passes the remaining data to the RLC. The physical sublayer provides the electrical interface to the transmission medium (air) by converting the information stream into a physical modulated signal and then converting it to a carrier frequency at the source, and converting the physical modulated signal back into an information stream at the destination. The physical layer is specified in TS 38.201, TS 38.211, TS 38.212, TS 38.213 and TS 38.214.

[0084] Two other sublayers are used in the UE and IAB donor CU to pass messages to the user plane or control plane: the Packet Data Convergence Protocol (PDCP) sublayer and the Service Data Adaptation Protocol (SDAP) sublayer for user plane communication or the Radio Resource Control (RRC) sublayer for control plane communication.

[0085] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and optionally data packet integrity. It enforces packet numbering on the source side and packet reordering on the receiver side. The PDCP sublayer is specified in 3GPP TS 38.323.

[0086] The SDAP sublayer 220 for the user plane handles Quality of Service. It is specified in TS 38.324. On the UE side, the SDAP sublayer exchanges payload data with user applications (voice, video, etc., not shown in Fig. 2). On the IAB donor CU side, the SDAP sublayer exchanges data with the core network 110 (internet traffic, cloud, etc.).

[0087] The RRC sublayer 220 for the control plane handles the configuration of the protocol entities of the user plane protocol stack. It is specified in TS 38.331. It handles, among other things, the broadcasting of information necessary for the UE to communicate with cells, the sending of paging messages, the management of connections including the configuration of bearers, mobility functions, measurement configuration and reporting, and device functionality.

[0088] The interfaces between nodes (both CP and UP) that use the PDCP, RLC, MAC and physical layers are referred to as NR-Uu, which primarily concerns the interface with the UE.

[0089] The interface between nodes (both CP and UP) that uses the BAP, RLC, MAC and PHY layers is called the BackHaul RLC Channel (BH RLC Channel). This refers to the interface between IAB nodes.

[0090] NR-Uu is the interface between the UE and the radio access network (e.g., the access IAB nodes (both CP and UP)).

[0091] Figure 2b is taken from 3GPP TS 38.300 v16.4.0 and shows the protocol stack for the support of RRC and NAS connection for IAB-MT. The Non-Access Stratum (NAS) protocol handles messages between the core network and the user equipment or IAB node. It manages the establishment of communication sessions and maintains communication in case of IAB node or user equipment movement. 5G NAS is specified in 3GPP TS 24.501. The 5G Core Access and Mobility Management Function (AMF) is a function in the core network that receives all connection and session related information from UEs connecting to IAB nodes and similar information to IAB nodes. The AMF is only responsible for handling connection and mobility management tasks. The IAB-MT establishes the signaling of Radio Bearers SRBs (bearers that carry RRC and NAS messages) with the IAB donor CU. These SRBs are transferred between the IAB-MT and its parent node over the NR-Uu interface.

[0092] Figure 4 shows the routing management in an IAB network. The routing management in an IAB node acting as a relay attempts to determine, based on the BAP routing configuration, from one BH RLC channel of an input link or backhaul link on which the BAP packet is received, a BH RLC channel of an output link or backhaul link on which the received BAP packet is forwarded.

[0093] The BAP routing configuration may be manually configured in each IAB node of the IAB network. Preferably, the BAP routing configuration may be constructed and updated over time by the IAB donor CU and transmitted from the IAB donor CU to the IAB nodes via F1-AP signaling during the initial configuration and the lifetime of the IAB network. As mentioned above, the BAP routing configuration may be constructed by the IAB donor CU based on the IAB network topology and its evolution over time (e.g., when some wireless links disappear or recover or the quality of the links changes).

[0094] The BAP routing configuration of an IAB node includes various routing tables (four of which are shown in FIG. 5).

[0095] 5a shows a schematic of a Backhaul Routing Configuration table entry 500 defined in 3GPP TS 38.300, V16.4.0, chapter 6.11.3 for the BAP sublayer, which is used by an IAB node to select an incoming link on which to forward or transmit a BAP packet or Protocol Data Unit (PDU).

[0096] Field 501 specifies the BAP Routing ID (the concatenation of PATH field 306 and DESTINATION field 305 as specified in FIG. 3), and field 502 specifies the next-hop BAP Address (e.g., the BAP address of the next IAB node along the path corresponding to Routing ID 501). Thus, Next Hop BAP Address 502 specifies the ingress link or backhaul link for forwarding or transmitting the BAP packet.

[0097] The Backhaul Routing Configuration table may have multiple entries for the same destination BAP address with different Path IDs and next-hop BAP Addresses in information element 502. The first entry may provide a default next-hop BAP Address corresponding to a default path to reach the destination, and other entries for the same destination BAP address may relate to backup redundant paths that are selected when the default link is unavailable (e.g., due to Radio Link Failure (RLF) or congestion associated with that link).

[0098] 5b shows a schematic diagram of a BH RLC channel mapping configuration entry 510 as specified in 3GPP TS 38.300, Chapter 6.11.3 and / or 3GPP TS 38.340, V16.3.0, Chapter 5.2.1.4.1 for the BAP sublayer, which is used by an IAB node acting as a relay (e.g., an intermediate IAB node) to identify a Backhaul (BH) RLC channel that forwards BAP packets or PDUs on an output link preselected using a Backhaul Routing Configuration table.

[0099] Information element (IE) 511 stores a next-hop BAP address that is predefined and typically obtained from a Backhaul Routing Configuration table. IE 512 stores a prior-hop BAP address (e.g., the BAP address of the previous IAB node from which the BAP packet arrived). IE 513 identifies an input RLC channel ID (e.g., an identifier of the RLC channel on which the BAP packet is received). And IE 514 stores an output RLC channel ID that provides the RLC channel that the IAB node uses to forward the BAP packet.

[0100] Note that for BH RLC channels in the downstream direction (parent to child, e.g., IAB node 402 to IAB node 403 in FIG. 4), the BH RLC channel ID is included in the F1-AP configuration of the BH RLC channel. For BH RLC channels in the upstream direction (child to parent, e.g., IAB node 402 to IAB node 401), the BH RLC channel ID is included in the RRC configuration of the corresponding logical channel.

[0101] 5c and 5d show the equivalent BH RLC channel mapping configurations for an IAB node that does not act as an intermediate IAB relay entity, which are specified in 3GPP TS 38.340, chapters 5.2.1.4.2 and 5.2.1.4.3.

[0102] The table in Figure 5c is called the Uplink Traffic to BH RLC Channel Mapping Configuration table (520), which is used by an initiator IAB node (not an IAB donor DU) that constructs a BAP packet or PDU from a BAP SDU (Service Data Unit) received from higher layers to identify a Backhaul (BH) RLC channel on which to transmit packets in the upstream direction on an output link preselected using the Backhaul Routing Configuration table defined in Figure 5a.

[0103] IE521 specifies the Traffic Type Identifier for the SDU received from the upper layer, IE522 indicates the predefined next-hop BAP address, typically obtained from the Backhaul Routing Configuration table, and IE523 specifies the outgoing BH RLC channel that provides the RLC channel used by the IAB node to transmit the BAP packets.

[0104] The table in Fig. 5d is called Downlink Traffic to BH RLC Channel Mapping Configuration table 530. It is used by an IAB donor DU that constructs a BAP packet or PDU from a BAP SDU (Service Data Unit) received from an upper layer to identify a Backhaul (BH) RLC channel for transmitting the BAP packet in the downstream direction on an output link preselected using the Backhaul Routing Configuration table.

[0105] IE531 is an IPv6 flow label used to classify IPv6 flows, IE532 specifies the Differentiated Services Code Point (DSCP) that is usually indicated in the IPv6 header of the packet, IE533 indicates the destination IP address, IE534 specifies the next-hop BAP Address as specified above, and IE535 specifies the output BH RLC channel ID that provides the RLC channel that the IAB node uses to transmit the BAP packet. The tables in Figures 5b, 5c and 5d are made up of multiple rows (entries), with each row / entry containing the IEs (or fields) shown in the respective figures.

[0106] The next-hop BAP address and the output link are synonymous because they specify the same part of the IAB network (the backhaul link) between the current IAB node and the next IAB node with that next-hop BAP address, and therefore they may be used interchangeably to specify such an IAB network link.

[0107] As a result of all the tables configured in the IAB nodes, and more specifically the Routing ID of IE501, multiple BAP paths are defined through multiple IAB nodes.

[0108] Returning to Figure 4, typically, the routing of the BAP packet by the BAP sublayer of the IAB node 402 uses the BAP routing ID 305+306 of the BAP packet. The BAP address (DESTINATION path 305) is used for the following purposes: 1) Determining whether the BAP packet has reached the destination node (e.g., IAB node or IAB donor DU) on the BAP sublayer. The BAP packet reaches the destination node if the BAP address 305 in the BAP header of the packet matches the BAP address configured via the RRC on the IAB node or the F1-AP on the IAB donor DU. 2) Determining the next-hop IAB node for a BAP packet that has not reached its destination. This applies to a BAP packet arriving from a previous-hop IAB node on the BAP sublayer or a BAP packet received from an upper layer.

[0109] For packets arriving from a previous-hop IAB node or from an upper layer, the determination of the next-hop IAB node is based on the Backhaul Routing Configuration table 500 .

[0110] The IAB node 402 resolves the next-hop BAP address 502 to a physical backhaul link (link 420 or link 430). To do so, it searches in a table 500 for an entry with a field 501 that matches the BAP Routing ID 305+306 of the BAP packet. The corresponding field 502 provides the next-hop BAP address.

[0111] The Backhaul Routing Configuration table may have multiple entries 500 with the same destination BAP address but different BAP Routing IDs (different BAP Path IDs). These entries may correspond to the same or different outgoing BH links. If a radio link failure (RLF) occurs in the BH link that matches the BAP Routing ID of the BAP packet, the IAB node may typically select another outgoing BH link (next-hop BAP address) based on the routing entry for the same destination BAP address (e.g., by ignoring the BAP path ID). In this way, the BAP packet may be delivered via an alternative path if the indicated path is unavailable.

[0112] For example, if a radio link failure occurs in the BH link 420, the IAB node 402 may select another BAP routing ID that includes the BH link 430 instead with the same destination BAP address.

[0113] The IAB node 402 then derives the output BH RLC channel of the selected output BH link (over which the BAP packet is transmitted or forwarded) by using the BH RLC Channel Mapping Configuration Table or the Uplink Traffic to BH RLC Channel Mapping Configuration Table or the Downlink Traffic to BH RLC Channel Mapping Configuration Table depending on its role (intermediate or relay IAB node, initiator IAB node or IAB donor DU transmitting in uplink / upstream or downlink / downstream direction).

[0114] For example, in an intermediate or relay IAB node, IEs 511, 512, 513 are the inputs of the BH RLC channel lookup process, and IE 514 is the output. The IAB node 402 routes incoming BAP packets received from the incoming BH RLC channel ID 513 (belonging to the incoming BH link identified by the prior-hop BAP address 512) to the outgoing BH RLC channel ID 514 (belonging to the outgoing BH link previously selected and identified by the next-hop BAP address 511).

[0115] In an initiator IAB node that wants to send a BAP packet in the upstream direction to an IAB donor, IEs 521, 522 are the inputs in the BH RLC channel lookup process and IE 523 is the output. The IAB node 402 selects the output BH RLC Channel 523 corresponding to the table entry 520 whose Traffic Type Identifier 521 matches the traffic type of the original BAP SDU (next-hop BAP address 522 matches the next-hop BAP address preselected by the Backhaul Routing Configuration table). This applies to BAP SDUs in the control plane (non-F1-U packets) as well as BAP SDUs in the user plane (F1-U packets). The Traffic Type Identifier 521 must correspond to the destination IP address and TEID (Tunnel End Point Identifier) ​​of the BAP SDU.

[0116] For an IAB donor DU wanting to transmit a BAP packet in the downstream direction towards a destination IAB node or UE, IEs 531, 532, 533, 534 are the inputs of the BH RLC channel lookup process, and IE 535 is the output. The IAB node selects the output BH RLC Channel 535 corresponding to the table entry 530 whose Destination IP address 533, IPv6 Flow Label 531 (only for BAP SDUs encapsulating IPv6 packets) and Differentiated Services Code Point (DSCP) 532 of the original BAP SDU match (next-hop BAP address 534 matches the next-hop BAP address pre-selected by the Backhaul Routing Configuration table). This applies to control plane BAP SDUs (non-F1-U packets) as well as user plane BAP SDUs (F1-U packets).

[0117] If there is no matching entry, a default BH RLC ID channel may be selected.

[0118] Such a routing process may be implemented in various IAB nodes of the IAB network.

[0119] 6 illustrates an example topology of an IAB network 600 that provides network path diversity in accordance with embodiments and example embodiments of the present invention. In an example implementation, the BH radio links operate on the mmWave frequency band (e.g., above 30 GHz), which is highly susceptible to radio channel impairments.

[0120] The IAB network 600 includes one IAB donor 601 (similar to IAB donor 120 in FIG. 1) and multiple IAB donors 602, 603, 604, 605, 606, 607, 608, 609, and 610 (similar to IAB nodes 121 and 122 in FIG. 1). These IAB nodes are connected via backhaul links 612, 6110, 623, 625, 626, 634, 635, 657, 658, 668, 669, 689, and 6106 (also referred to as BH radio links).

[0121] As IAB nodes 604, 607, 608, and 609 serve UEs 640, 670, 680, and 690, respectively, they also act as access IAB nodes for each UE.

[0122] Redundant paths may exist between pairs of IAB nodes. For example, a path between IAB donor 601 and IAB node 608 may include a first default BAP path through IAB nodes 602, 605, and 608, a second BAP path including IAB nodes 602, 603, 605, and 608, and a third BAP path including IAB nodes 602, 606, and 608.

[0123] In the following exemplary description, the following BAP paths are considered: PATH1: Associated with Routing ID1, connects IAB node 608 to IAB donor 601 via IAB nodes 605, 602, and passes through BH radio links 658, 625, and 612. This may be the default path between 601 and 608. PATH2: Associated with Routing ID2, connecting IAB node 608 to IAB donor 601 via IAB nodes 605, 603, 602, and passing through BH radio links 658, 635, 623, and 612 - PATH3: Associated with Routing ID3, connects IAB node 608 to IAB donor 601 via IAB nodes 606, 602, and passes through BH radio links 668, 626 and 612.

[0124] The BH radio link 625 between IAB nodes 602 and 605 may experience radio link deficiencies (e.g., link quality deficiencies) due to unexpected interference or shadowing phenomena (e.g., radio link failure (RLF)). When the radio link deficiencies (link quality) reach or fall below the RLF threshold for detecting RLF, the default BAP path PATH1 may become unusable between IAB nodes 601 and 608. Then, only the second and third paths (PATH2 and PATH3) may be used as alternative rerouting paths.

[0125] As described above, IAB node 605 can detect the radio link shortage of the BH radio link. IAB node 605 is therefore the detecting IAB node. More precisely, the IAB-MT of IAB node 605 can detect the radio link shortage of the BH radio link 625 (and link 635). It can alert its child IAB nodes (i.e., IAB nodes 607 and 608) of the radio link shortage using a BH RLF indication message. The BH RLF indication message can also be forwarded by the child IAB node to its own child IAB nodes, if any.

[0126] The following types of BH RLF indication messages may be considered: A Type 2 BH RLF indication message is sent by a detecting IAB node as soon as an RLF is detected on one of its BH links. A Type 3 BH RLF indication message is sent by the detecting IAB node when RLF is restored on one of the BH links. The Type 4 BH RLF indication message is sent by a detecting IAB node upon detection of an RLF recovery failure, as specified in TS 38.340. An RLF recovery failure may indicate that the IAB node was unable to recover from an RLF.

[0127] In one aspect of the present invention, as discussed in more detail below, RLF detection may also be performed by the IAB-DU of an IAB node (e.g., the IAB-DU of IAB node 605 may detect radio link failure of BH radio links 657 and 658). Thus, in an example where a radio link failure (RLF) occurs in the BH link 625 and PATH1 is unavailable, PATH2 and PATH3 may be used as alternative paths. For example, the IAB node 605 may select PATH2 as an alternative path for routing BAP packets to the IAB donor 601. The IAB node 605 may select the BH link 635 as another outgoing BH link (next-hop BAP address) based on a routing entry in the Backhaul Routing Configuration table that is the same destination BAP address as the IAB donor 601 (e.g., by ignoring the BAP path ID). In this manner, the BAP packet may be delivered via PATH2 as an alternative path when PATH1 is unavailable.

[0128] As discussed above, each IAB node includes an IAB-DU and an IAB-MT. Each IAB-MT and IAB-DU of an IAB node includes a buffer (implemented in a BAP layer or entity) that buffers data (e.g., BAP packets or PDUs) routed between nodes in the IAB network node. A congestion problem in an IAB node is detected when the load of the buffer (e.g., the amount of data buffered in the buffer) exceeds or reaches a predefined level (also called a congestion threshold) or overflows. The IAB-MT or IAB-DU may detect if there is a congestion problem depending on whether the affected backhaul link is connected to a parent IAB node or a child IAB node. Thus, an IAB node such as IAB node 608 may experience congestion at its own buffer level (IAB-DU buffer). Therefore, if its buffer load exceeds or reaches a predetermined level, the IAB node 608 may alert its parent node (e.g., IAB node 605) that congestion has been detected at the IAB node 608 by sending a flow control feedback message as specified in TS 38.340. The IAB node 608 may also send a flow control feedback message to the IAB node 605 if it receives a flow control poll message from the IAB node 605. The flow control feedback message typically includes information indicating the available buffer size at the IAB node. Thus, the information in the flow control feedback message may provide a notification if the IAB-DU or IAB-MT buffer load at the IAB node exceeds or reaches a predetermined level, and thus may indicate a congestion problem on the backhaul link (e.g., congestion affecting the transmission of data on the backhaul link).It is understood that congestion on a backhaul link may be the result of too much data being routed on that backhaul link (e.g., due to rerouting of data from other IAB nodes) or may be the result of too much data being routed on the backhaul link due to a degradation in link quality of the backhaul link that reduces the capacity of the link or the maximum throughput of the backhaul link (e.g., the amount of data that can be routed or transmitted on the backhaul link is reduced due to a degradation in link quality).

[0129] The BAP entity of the IAB-DU of the IAB node may include at least one buffer (typically one buffer per RLC channel) for receiving BAP PDUs (downstream communication) transmitted over the backhaul link from the BAP entity of the IAB-MT of the IAB node to a child IAB node and for receiving BAP PDUs (upstream communication) transmitted from the child IAB node to the BAP entity of the IAB-MT of the IAB node. Similarly, the BAP entity of the IAB-MT of the IAB node may include at least one buffer (typically one buffer per RLC channel) for receiving BAP PDUs (upstream communication) transmitted over the backhaul link from the BAP entity of the IAB-DU of the IAB node to a parent IAB node (which may be an IAB donor DU) and for receiving PDUs transmitted from the parent IAB node (which may be an IAB donor DU) to the BAP entity of the IAB-DU of the IAB node. When the buffer load of the buffer of the BAP entity (of IAB-DU or IAB-MT) of the IAB node exceeds a predetermined level (e.g., the number of data units in the buffer exceeds a predetermined level) or in response to a flow control polling message from an IAB node (e.g., a parent node) in the IAB node's IAB-MT, the BAP entity (of IAB-DU or IAB-T) generates and transmits to the IAB node a flow control feedback message including information indicating the available buffer size in the BAP entity (of IAB-MT and / or IAB-DU). Thus, the information in the flow control feedback message provides a notification when the buffer load of the buffer of the BAP entity (of IAB-DU or IAB-MT) of the IAB node exceeds a predetermined level, indicating a congestion problem on the backhaul link.

[0130] Following detection of an RLF problem on a backhaul link at an IAB node, the IAB node (referred to as a local IAB node) may perform local actions such as local rerouting (e.g., performed by a BAP entity in the IAB node) in which data may be rerouted to the destination IAB to minimize the impact of the RLF problem. Additionally, following detection of an RLF problem, radio conditions may improve resulting in an increase in the radio link quality level of the backhaul link. When the radio link quality reaches or exceeds an RLF recovery threshold, the IAB node may consider its backhaul link to have recovered (e.g., the RLF problem has recovered and is no longer present). The IAB node may then send a Type 3 BH RLF indication message for the recovered BH link and begin using the backhaul link again to route data.

[0131] Similarly, following detection of a congestion problem in the transmission of data on the backhaul link at the IAB node, the IAB node may perform local actions such as local re-routing or load balancing (e.g., performed by the BAP entity of the IAB node), and / or bit rate adaptation (e.g., performed in the scheduler of the IAB node), and / or buffering and queue management to minimize the impact of the congestion problem. Furthermore, following detection of a congestion problem, radio conditions / link quality may improve and / or local actions may be performed at the IAB node as indicated above, resulting in a reduction in congestion at the IAB node. When the buffer load at the IAB node reaches or falls below a recovery level (also referred to as a congestion recovery threshold), the IAB node may consider the backhaul link to be recovered (the congestion problem has recovered and no longer exists). The IAB node may then, if necessary, or in response to a flow control poll message, send a flow control feedback message that includes information indicating that the congestion problem has been resolved (e.g., based on the available buffer size indicated in the flow control feedback message).

[0132] Because a local IAB node does not know the congestion or link problem status of all nodes in the IAB network, any local actions to handle RLF / congestion issues may create link problems in other IAB nodes in the IAB network (e.g., away from the local IAB node), and therefore any such local actions should preferably be applied for a limited period of time.

[0133] For these short-term or transient link problems that may require a short time to recover from RLF or congestion problems (e.g., due to early link quality recovery), local actions at the IAB node, such as local re-routing for RLF problems and local re-routing or load balancing and / or bit rate adaptation for congestion problems, may provide an effective means to reduce or mitigate the impact of the link problems. Since they are only required for a short period of time, the impact on other nodes of the IAB network is minimized. However, for some link problems (called long-term link problems), such as repeated or continuous link problems that require a long time to recover, long-lasting link problems, or link problems that do not recover, taking local actions at the local IAB node (such as local re-routing or load balancing) may have a significant impact on other nodes of the IAB network, creating link problems. Such long-term link problems may therefore require the IAB donor CU to reconfigure the routing configuration of all or some nodes in the IAB network, since only the IAB donor CU has knowledge of the entire IAB network topology.

[0134] Techniques for an IAB node to distinguish long-term link problems that require a donor CU (or IAB donor CU) to reconfigure the IAB network routing configuration from short-term link problems that can be resolved locally at the IAB node are described in accordance with several embodiments and example embodiments of the present invention. Methods for an IAB node to notify a donor CU (or IAB donor CU) of long-term link problems are described in accordance with several embodiments and example embodiments of the present invention.

[0135] FIG. 9 shows steps of a method 900 performed in an IAB node (also called IAB-node) according to an embodiment of the present invention. The IAB node is part of an IAB network consisting of a number of IAB nodes and a donor CU (also called IAB donor CU) that is part of an IAB donor in the IAB network. With reference to FIG. 1, the IAB node may be node 121 and the donor CU may be node 120. With reference to FIG. 6, the IAB node may be node 605 of an IAB network 600 and the donor CU may be node 601. The IAB node may be implemented in a communication device 1000 shown in FIG. 10 below, using the method described with reference to FIG. 9, executed by a central processing unit 1011. The method may be executed in a Mobile Terminal (MT) of the IAB node or a Distributed Unit (DU) of the IAB node. For example, a program element executed by the CPU 1011 of FIG. 10 to implement a BAP entity (part of DU or MT) of the BAP sublayer may execute the method described with reference to FIG. 9. The method of FIG. 9 may be applied to communications in either the upstream or downstream direction.

[0136] In step 901, an IAB node (e.g., node 605 in FIG. 6) detects a link issue or problem (which may also be referred to as a BH link issue) in data transmission on a backhaul link (which may also be referred to as a BH link or a BH radio link) of an IAB network. The link issue may be related to the BH link between IAB node 605 and a parent IAB node (e.g., for IAB node 602, the affected BH link is BH link 625), or related to IAB node 605 and a child IAB node (e.g., for IAB node 607, the affected BH link is BH link 657), or related to a parent or child IAB node of IAB node 605 and another IAB node (e.g., BH link 623 between parent IAB node 603 and IAB node 602, or BH link 689 between child IAB node 608 and IAB node 609). In the latter case, the IAB node 605 may determine the presence or absence of a link problem in the BH link 623 based on information (e.g., an RLF indication message or a flow control feedback message) relayed to the IAB node 605 from a parent or child IAB node. A link problem or a BH link problem (e.g., a type of link problem or a BH link problem) may be a radio link failure (RLF) in the backhaul link or congestion affecting data transmission on the backhaul link. For example, congestion may occur in the IAB node or an IAB node connected to that IAB node, which may affect the backhaul link or one or more other BH links. In other words, a link problem or a link problem relates to a problem or problem that (negatively) affects data transmission on the BH link. The cause or source of the link problem or problem may be at least one of 1) link quality, or 2) the amount of data to send on the backhaul, or 3) radio link recovery failure, or 4) recurring link problems or link problems that take too long to recover, etc.

[0137] In response to detecting the link problem, the IAB node 605 sends a link failure notification to the donor CU (or IAB donor CU). For example, in step 902, the IAB node 605 determines whether the link problem is a long-term link problem (e.g., or a short-term (e.g., transient) link problem). A long-term link problem requires a reconfiguration of the routing configuration in the IAB network (e.g., some or all IAB nodes in the IAB network) by the donor CU (or IAB donor CU), while a short-term link problem is handled locally in the IAB node. For example, a long-term link problem is a recurring or recurring or continuous link problem, or a long-lasting link problem that takes time to recover, or an unrecoverable link problem. In step 903, in response to determining that the detected link problem results in a long-term link problem, the IAB node 605 sends a link failure notification to the donor CU. The link failure notification includes link identification information identifying a backhaul link (e.g., the backhaul link affected by the long-term link problem) and link problem information related to the detected link problem (including information regarding a cause or source of the detected link problem (e.g., long-term link problem)). The information related to the cause of the link problem may include information indicating the cause of the detected link problem or a type of cause of the detected link problem. For example, the type of cause of the detected link problem is one of a long-term cause (e.g., resulting in a long-term link problem) or a short-term cause (e.g., resulting in a short-term link problem). The long-term cause of the detected link problem may include one of a link recovery failure, a slow recovery of the link problem, and a recurring link problem. The short-term causes may include too much data transmitted on the backhaul for a short period of time (e.g., recovers in a short time) resulting in congestion as a short-term link problem, and / or link quality of the backhaul link below a threshold for a short period of time (e.g., recovers in a short time) resulting in Radio Link Failure (RLF) as a short-term link problem.

[0138] The IAB node 605 may determine whether the link problem results in a long-term link problem by determining whether one of a plurality of predefined link failure criteria (also referred to as predefined link problem criteria) is met based on the detected link problem. Each of the plurality of predefined link problem criteria represents a cause or source of or a result of the long-term link problem, where the long-term link problem can be determined by checking whether the one of the predefined link problem criteria is met. For example, sending a link failure notification to the donor CU may be in response to determining that a predefined link problem criterion is met (e.g., the met predefined link problem criterion is one of the plurality of link problem criteria) based on the detected link problem. The link problem information regarding the detected link problem includes information indicating the predefined link problem criterion determined to be met.

[0139] As will be discussed in more detail below with respect to FIG. 7, three causes or three predefined link problem criteria (each of which may result in a long-term link problem) may be considered for long-term link problems: 1) Link recovery failure (irrecoverable RLF failure recovery or congestion) 2) Slow link recovery (e.g., RLF failure or congestion that takes too long to recover from such a link problem, such that the time it takes to recover from the problem exceeds a predefined threshold). 3) Recurring or Repeated Link Problems - Repeated BH link problems (repeated or continuous RLF detection / RLF recovery and / or congestion detection / congestion recovery).

[0140] A BH link problem may be detected in an IAB-MT or IAB-DU unit of an IAB node, which may be directly (e.g., the IAB-MT or IAB-DU detects at its own level) or indirectly (the IAB-MT or IAB-DU detects based on receiving a BH link problem message from a connected IAB node). In this respect, it may be advantageous for BH link problem messages (e.g., RLF indication messages, flow control feedback messages) to be forwarded by the IAB node.

[0141] As discussed above, the link failure notification sent by the IAB node 605 includes link specification information that identifies the backhaul link and link issue information regarding the detected link issue (including information regarding the cause of the long-term link issue (e.g., Long Term BH Link Issue Cause information indicating the cause of the long-term link issue (e.g., link recovery failure, slow link recovery, or continuous or recurring BH link issues) and / or Long Term BH Link IssueTypeof Cause information indicating the type of cause of the long-term link issue (e.g., long-term cause or short-term cause)).

[0142] The link specific information or BH link information may include at least one of the following: Unique addresses of the IAB nodes on each end of the backhaul link (e.g., unique BAP addresses) A cell identifier (e.g., Cell ID) that identifies the cell associated with the backhaul link. An RLC channel identifier that identifies the RLC channel (related to the faulty or problematic link) of the backhaul link The BAP routing identifier.

[0143] The link problem information in a Link Failure Notification message sent by an IAB node may convey all or some of the following information in addition to information associated with the cause of the long-term link problem: - The nature of the BH link issue (e.g., a long-term link issue), e.g., Long Term BH Link Issue Indication information indicating that a long-term fault or link issue has occurred in the BH link identified by the BH link information described above. - the type of fault or link problem (e.g. RLF or congestion), e.g. BH Radio Link Failure (RLF) Indication information indicating a long-term fault or link problem caused by RLF, and Congestion Indication information indicating a long-term fault or link problem caused by a congestion phenomenon; -BH Link Quality. For example, Link Quality Information (e.g., SINR, congestion level, etc.) indicating the quality of the BH link affected by the BH link problem. - Aging of the fault (e.g., the time since the problem was detected). For example, Ageing information provides timing information about the moment of detection of the BH link problem. Link problem time information may indicate the time between the detection of the link problem and the sending of the link fault notification.

[0144] In an example, the IAB node 605 sends a link failure notification to the donor CU upon detection of a problem with the BH link. In an example, the IAB node 605 sends the link failure notification following receipt of a polling request from the donor CU.

[0145] The MT of the IAB node may send the link failure notification to the donor CU. For example, the MT of the IAB node may send the link failure notification in an RRC message, such as a UEInformationResponse message defined in 3GPP TS 38.331 or an MCGFailureInformation message defined in 3GPP TS 38.331. Another example is provided below with reference to FIG. 8.

[0146] The DU of the IAB node may send a link failure notification to the donor CU. For example, the DU of the IAB node may send the link failure notification in an F1-AP layer message, such as a GNB-DU STATUS indication message defined in 3GPP TS 38.473.

[0147] In another example, the DU of the IAB node may send the link failure notification in an NR user plane protocol frame, such as an ASSISTANCE INFORMATION DATA frame as specified in 3GPP TS 38.425, which is carried in the GTP-U protocol, more specifically in the "NR RAN Container" GTP-U extension header as specified in TS 29.281.

[0148] Regardless of whether the IAB node 605 detects a long-term or short-term BH link problem in step 902, it may attempt to apply local countermeasures or local actions, if possible, to mitigate the BH link problem in step 904. For example, the IAB node 605 may attempt to mitigate the effects of the RLF or congestion event by local re-routing, such as selecting an alternative routing path as discussed in FIG. 6, and / or performing bit rate adaptation, and / or load balancing, and / or buffering and queue management.

[0149] More details of how an IAB node may detect a link problem for data transmission on the backhaul and how an IAB node may determine whether a detected BH link problem results in a long-term BH link problem are also described with reference to FIG. 7. FIG. 7 illustrates an example of a method for detecting and managing a long-term BH link problem according to an embodiment or example of the present invention using a flowchart 700. The method may be performed in an MT of an IAB node or a DU of an IAB node. For example, a program element executed by the CPU 1011 of FIG. 10 for implementing a BAP entity (DU or MT part) of a BAP sublayer may perform the example method described with reference to FIG. 7. The method of FIG. 7 may be applied to communication in an upstream or downstream direction.

[0150] An IAB node, such as IAB node 605 of IAB network 600 of Figure 6, is configured in step 701 by an IAB donor, such as IAB donor 601, in an operational mode in state 702 such that it can distinguish between long-term and short-term BH link problems. The IAB donor 601 configures the IAB node 605 during an initialization process and may also configure or reconfigure the IAB node 605 during the lifetime of the IAB network 600. Thus, step 701 is shown in Figure 7 as a dotted line.

[0151] As an example, the IAB donor 601 configures the IAB node 605 by sending a dedicated Information Element or backhaul link failure configuration information, which may consist of all or part of the following information: In relation to steps 705 and 706 of the flowchart 700, the maximum number of consecutive backhaul link issues (or maxConsecutiveIssues) detected by the IAB node. For example, information indicating the maximum number of link issues (e.g., including previously detected link issues) detected for data transmission on the backhaul link. A BH link issue recovery time window (or ConsecutiveIssuesTimeWindow), which is a period of time (e.g., having a predetermined length) during which a maximum number of consecutive BH link issues are detected, in relation to step 705 of flowchart 700. - Maximum recovery timeout (or maxRecoveryTimeout) for recovering from a previous BH link problem, in relation to step 706 of flowchart 700. For example, recovery timeout information indicating the maximum period between the time of detection of a link problem and the time of recovering from the detected link problem.

[0152] The dedicated Information Element described above may be used by the IAB donor 601 to configure the IAB-MT units of IAB nodes (such as IAB node 605) in the IAB network 600. In one example, the message used to transmit this Information Element is the RRCReconfiguration message defined in the TS38.331 standard.

[0153] The above-mentioned dedicated Information Element may be used by the IAB donor 601 to configure the IAB-DU units of IAB nodes (such as IAB node 605) in the IAB network 600. In one example, the message used to transmit this Information Element is the GNB-CU CONFIGURATION UPDATE message defined in the 3GPP TS 38.473 standard or the Access And Mobility Indication message defined in 3GPP TS 38.473.

[0154] In step 703, the IAB node (605) detects a BH link problem. As discussed below, multiple different natures or categories of BH link problems can be considered and detected. Different categories can include different types of BH link problems, such as RLF type link problems (RLF on the BH link) and congestion type link problems (congestion affecting data transmission on the BH link). Different categories can also include different types of BH link problems and methods of detecting them. For example, one category is RLF detected by monitoring the link quality and another category is RLF detected by Type 2 RLF indication message. The link problem may be related to a BH link between IAB node 605 and a parent IAB node (e.g., for IAB node 602, the affected BH link is BH link 625), or related to a BH link between IAB node 605 and a child IAB node (e.g., for IAB node 607, the affected BH link is BH link 657), or related to a BH link between a parent or child IAB node of IAB node 605 and another IAB node (e.g., BH link 623 between parent IAB node 603 and IAB node 602, or BH link 689 between child IAB node 608 and IAB node 609).

[0155] Detecting an RLF link problem for data transmission on the backhaul link includes monitoring (e.g., by an MT or DU of the IAB node 605) the link quality of the backhaul link and detecting an RLF on the backhaul when the link quality falls below or reaches an RLF threshold. In other words, by monitoring the link quality, an MT or DU of the IAB node may directly detect an RLF link problem. Additionally or alternatively, detecting an RLF link problem for data transmission on the backhaul link includes receiving an RLF indication message on the backhaul link at the IAB node 605 (e.g., at an MT of the IAB node 605) and indicating an RLF or RLF recovery failure (e.g., a Type 2 or Type 4 RLF indication message). The RLF indication message may be sent by a parent IAB node (such as the IAB node 602) or an RLF indication message sent by a remote IAB node (two or three hops away) may be forwarded to the IAB node 605. In other words, in response to receiving the RLF indication message, the IAB node may indirectly detect a problem with the RLF link.

[0156] IAB node 605 may monitor the status and link quality of BH wireless link 625 via periodic exchange of signals at the PHY layer (e.g., for antenna adjustments, radio power negotiation, etc.) with IAB node 602 (and IAB nodes 603, 607, 608 for other BH wireless links) connected to IAB node 605.

[0157] In one example, the IAB-MT of IAB node 605 detects a BH radio link failure on an incoming link with a parent IAB node (e.g., BH link 625 with parent IAB node 602) in step 703 by monitoring the quality of the BH link.

[0158] For example, the IAB-MT may assume that the BH radio link or the BH link is disconnected if the measured Reference Signal Receive Power (RSRP) falls below a predefined threshold or if it fails to decode either the Physical Downlink Control Channel (PDCCH) or the Physical Downlink Shared Channel (PDSCH) due to insufficient power signal quality (e.g., low RSRP or low Reference Signal Receive Quality (RSRQ)). Those skilled in the art may find other ways to detect radio link failure in the IAB-MT.

[0159] In one example, the IAB-DU of IAB node 605 detects a BH radio link failure in an outgoing BH link with a child IAB node (e.g., BH link 658 with IAB node 608) in step 603 by monitoring the quality of the BH link.

[0160] For example, the IAB-DU may assume that the BH radio link or radio link is disconnected if the signal-to-interference-plus-noise ratio (SINR) from the child IAB-MT falls below a predefined threshold or if it does not detect (e.g., does not receive or receives but cannot decode) an acknowledgement message (e.g., no ACK or NACK) from the child IAB-MT on the Physical Downlink Shared Channel (PDSCH). Those skilled in the art may find other ways to detect radio link failure in the IAB-DU.

[0161] In one example, the IAB-MT of the IAB node 605 detects a BH radio link failure on the incoming BH link of the parent IAB by receiving a radio link failure indication message from the parent IAB node in step 703. In an aspect, the radio link failure indication message may indicate that a BH RLF recovery failure has been detected by the IAB-MT of the IAB node (Type-4 RLF indication message). In another aspect, the radio link failure indication message may indicate that a BH RLF has been detected by the IAB-MT of the parent IAB node (Type-2 RLF indication message). As an example, the radio link failure indication message received by the IAB node 605 was relayed to its parent IAB node from another IAB node in the IAB network.

[0162] Detecting a congested link problem in data transmission on the backhaul link may include monitoring (e.g., by an MT or DU of the IAB node 605) a load on a buffer (associated with the backhaul) of the IAB node. When the load exceeds or reaches a congestion threshold, congestion in the buffer, i.e., congestion of data transmission on the backhaul link, is detected. Additionally or alternatively, detecting a congested link problem in data transmission on the backhaul may include receiving at the IAB node 605 (e.g., at an MT or DU of the IAB node 605) a flow control feedback message regarding the backhaul link and indicating congestion affecting data transmission on the backhaul link and determining congestion on the backhaul link from the flow control feedback message. Other mechanisms for detecting congested link issues or problems at the IAB node, such as detecting packet delays, may also be used.

[0163] In one example, the IAB-MT of IAB node 605 detects congestion in step 703 from a local buffer load exceeding a certain level.

[0164] In one example, the IAB-DU of IAB node 605 detects congestion in a child IAB-MT of a child IAB node (such as IAB node 608) in step 703 by receiving a flow control feedback message from the child IAB-MT indicating that the buffer load of the IAB-MT exceeds a certain level.

[0165] In one example, a flow control feedback message received by an IAB node is relayed by a child IAB node (such as IAB node 608).

[0166] In one example, the flow control feedback message received by an IAB node was sent by a parent IAB node (such as IAB node 603).

[0167] Those skilled in the art may discover other ways to detect congestion in the IAB-DU and / or IAB-MT.

[0168] IAB node 605 then determines whether the detected link problem will cause a long-term link problem, via steps 704, 705, and 706. For example, IAB node 605 checks the cause of the detected link problem and determines whether the cause is a long-term cause.

[0169] In step 704, the IAB node 605 determines whether the detected BH link problem is related to a BH link restoration failure.

[0170] As an example, a BH link recovery failure relates to the detection by the MT unit of the IAB node that the BH link has failed to recover from a previous RLF.

[0171] For example, an IAB-MT may attempt to reconnect to its parent IAB node when an RLF occurs. If the IAB-MT is unable to successfully reconnect to the parent IAB node after a certain period of time, the IAB-MT may determine that the BH link failure has not been recovered and a BH link recovery failure has occurred.

[0172] In one example, a BH link recovery failure relates to a detection by a DU unit of an IAB node that the BH link has failed to recover from a previous RLF.

[0173] For example, if the IAB-DU does not receive an acknowledgement following the transmission of a PDU after a certain period of time, it may be considered that the BH link has experienced an RLF and cannot be recovered.

[0174] In one example, the BH link recovery failure is associated with receipt of the Type-4 RLF indication message discussed in step 703 by an IAB node (eg, an MT unit of the IAB node).

[0175] In one example, a BH link recovery failure is associated with receipt of a flow control feedback message from a child IAB node (such as child IAB node 608) indicating congestion affecting data transmission on a BH link (such as BH link 658 with IAB node 608) by the IAB node (e.g., by the IAB node's IAB-DU).

[0176] In one example, a BH link recovery failure is associated with receipt by an IAB node (e.g., the IAB-DU of IAB node 605) of a flow control feedback message from a child IAB node (such as child IAB node 608) indicating congestion affecting data transmission on a BH link (such as BH link 658 with IAB node 608), and the IAB-DU being unable to apply corrective action to alleviate the congestion phenomenon at the child IAB node.

[0177] If a BH link problem is detected (YES branch of step 704) related to a BH link recovery failure (e.g., the cause is a long-term type cause), the IAB node 605 determines whether the detected link problem results in a long-term link problem (e.g., determines whether one of the predefined link problem criteria representing the cause or source of the long-term link problem is met) and triggers a long-term BH link problem in step 707. This includes sending a link failure notification to the donor CU.

[0178] If the BH link problem detected in step 704 is not related to a BH link recovery failure (NO in the branch of step 704), the IAB node 605 checks whether the maximum number of consecutive BH link problems has been reached in step 705. In other words, the IAB node 605 checks whether the number of consecutive link problems detected has reached or exceeded a threshold corresponding to the maximum number of consecutive BH link problems (e.g., the cause is a long-term type cause). The maximum number may be an integer in the range of 3 to 10. As an example, the maximum number may be an integer in the range of 4 to 8. As an example, the maximum number may be 3 or 4.

[0179] If the maximum number of consecutive BH link problems has not yet been reached or exceeded, the IAB node 605 increments (or decrements) a local BH link problem counter and waits for an update of the recovery status of the ongoing BH link problem in step 706.

[0180] If the counter is incremented and reaches the maximum number of consecutive BH link problems (or reaches a threshold value) (if the counter is decremented, the counter counts down from the maximum number of consecutive BH link problems until it reaches zero), the IAB node 605 determines that the detected link problem results in a long-term link problem (e.g., determines that one of the predefined link problem criteria, which represents the cause or source of the long-term link problem, is met) and triggers a long-term BH link problem in step 707. This includes sending a link failure notification to the donor CU.

[0181] As an example, one local BH link problem counter is associated with one category or nature of BH link problems discussed in step 703. For example, one BH link problem counter is used to track BH link problems associated with receiving a Type-2 RLF indication message, and another BH link problem counter is used to track BH link problems associated with detecting a BH radio link failure in an incoming BH link with a parent IAB node by monitoring the quality of the BH link. In this example, the category depends not only on the type of BH link problem (e.g., RLF type vs. congestion type) but also on how the link problem was detected. In another example, the category may depend on the type of link problem. That is, one local BH link problem counter counts detected RLF link problems and one local BH link problem counter counts detected congestion problems.

[0182] In one example, the local BH link problem counters relate to any combination of properties or categories of BH link problems as discussed in step 703 .

[0183] In one example, the IAB node 605 uses the maxConsecutiveIssues information set by the IAB donor 601 in step 701 as a threshold to determine whether the maximum number of consecutive BF link issues has been reached.

[0184] In one example, the IAB node 605 uses the ConsecutiveIssuesTimeWindow set by the IAB donor 601 in step 701 as a sliding time window or link problem recovery time window having a predetermined length for managing the BH link problem counter. In such a case, the BH link problem counter is decremented (or incremented in case of countdown) for each moment when past BH link problems are no longer detected within the sliding time window. The IAB node 605 checks whether the number of consecutive link problems detected during the sliding time window reaches or exceeds a threshold, and if the detected link problems reach or exceed the threshold, the IAB node 605 determines that the detected link problems cause long-term link problems. The threshold corresponds to the maximum number of consecutive BH link problems discussed above. The length of the sliding time window can range from a few seconds to a few hours. In one example, the length of the sliding time window can range from 2 seconds to 2 hours. In one example, the length of the sliding time window can range from 1 second to 10 hours. When a sliding time window is used in conjunction with a threshold, multiple link issues that occur over a long period of time (e.g., 10 days) are not considered long-term link issues, but multiple link issues that occur over a short period of time (e.g., 1 hour) are considered long-term link issues.

[0185] In step 706, the IAB node 605 waits for an update on the recovery status of the ongoing BH link problem detected in step 703. As an example, the IAB node 605 determines whether the detected link problem (detected in step 703) has recovered.

[0186] If the ongoing BH link problem detected on the BH link in step 703 is resolved, the IAB node 605 detects that the BH link has been resolved, returns to operational mode in step 702, and restarts the process with the detection of a new link problem in step 703.

[0187] In one example, the BH link problem is resolved when the IAB node 605 (e.g., the IAB-MT of the IAB node 605) receives an RLF indication message (a Type-3 RLF indication message) from its parent IAB node indicating that the previous BH RLF has been resolved.

[0188] In one example, the BH link problem is resolved when an IAB node 605 (e.g., an IAB-DU of the IAB node 605) receives a flow control feedback message from a child IAB node indicating that the buffer load of the child IAB node does not exceed a certain level.

[0189] In one example, the BH link problem is restored when the IAB node 605 assumes that the BH radio link or the BH link is no longer broken in relation to the broken link condition considered in step 703. For example, by monitoring the BH link quality of the BH link, the IAB-MT may assume that the BH link is no longer broken when the BH link quality reaches or exceeds a restoration threshold. For example, the IAB-MT may assume that the BH radio link is no longer broken when the measured Reference Signal Receive Power (RSRP) reaches or exceeds a predefined threshold, or when the IAB-MT successfully demodulates either the Physical Downlink Control Channel (PDCCH) or the Physical Downlink Shared Channel (PDSCH).

[0190] In one example, the BH link problem is restored when the IAB-DU of the IAB node 605 assumes that the BH radio link is no longer broken in relation to the broken link condition considered in step 703. For example, by monitoring the BH link quality of the BH link, the IAB-DU may assume that the BH link is no longer broken and restored when the BH link quality reaches or exceeds a restoration threshold. For example, the IAB-DU may assume that the BH radio link or radio link is no longer broken when the Signal-to-Interference-Plus-Noise Ratio (SINR) from the child IAB-MT reaches or exceeds a predefined threshold or when the IAB-DU detects an acknowledgement message (e.g., no ACK or NACK) from the child IAB-MT on the Physical Downlink Shared Channel (PDSCH). In one example, the BH link problem is restored when the IAB-MT or IAB-DU of the IAB node 605 detects that there is no congestion due to local buffer load not exceeding a certain level.

[0191] When the IAB node 605 receives a Type-4 RLF indication message from its parent IAB node indicating a BH RLD recovery failure in step 706, it determines that the link problem it detected results in a long-term link problem (e.g., one of the predefined link problem criteria representing the cause or source of the long-term link problem is met) and triggers a long-term BH link problem in step 707. This includes sending a link failure notification to the donor CU.

[0192] If the IAB node 605 determines in step 706 that the BH link problem detected in step 703 was not recovered quickly enough (e.g., in response to determining that the detected link problem was not recovered within a recovery timeout period), the IAB node 605 determines that the detected link problem gives rise to a long-term link problem (e.g., one of the predefined link problem criteria indicative of a cause or resource of the long-term link problem has been met) and triggers a long-term BH link problem in step 707. This includes sending a link failure notification to the donor CU.

[0193] In one example, the IAB node 605 starts an internal timeout counter upon detection of a BH link problem in step 703. If this internal timeout counter reaches a certain recovery timeout value (e.g., it specifies the maximum recovery timeout period between detection of a link problem and recovery from the detected link problem) before recovery of the BH link problem in step 706 (or if the internal timeout counter decreases over time, the counter counts down from the certain recovery timeout value until it reaches zero), as previously discussed, the IAB node 605 determines that the detected link problem is a long-term link problem (e.g., one of the predefined link problem criteria representing the cause or source of the long-term link problem is met) and triggers a long-term BH link problem in step 707. In one example, the IAB node 605 uses the maxRecoveryTimeout information set by the IAB node 701 in step 701 as the recovery timeout value. The recovery timeout period between detection of a link problem and recovery from the detected link problem can range from a few seconds to a few hours. In one example, the length of the sliding time window can range from 1 second to 1 hour. In one example, the length of the sliding time window can range from 1 second to 30 minutes.

[0194] FIG. 8 illustrates an exemplary message flow 800 for reporting a long-term link problem of a BH link from an IAB node 811 that detects a BH link problem to an IAB donor CU, as discussed above with reference to FIGS. 7 and 9, in accordance with embodiments and examples of the present invention.

[0195] In one example, upon detection of a long-term link problem (e.g., a BH RLF problem), an IAB node 811 (e.g., IAB node 605 in FIG. 6 ) may notify an IAB donor CU 801 (e.g., the CU of IAB donor 601 in FIG. 6 ) of such detection by sending a link failure notification using a BH link FAILURE INFORMATION message 802.

[0196] In one example, an IAB donor CU 810 (e.g., IAB donor 601) may send a request to an IAB donor 811 (e.g., IAB node 605) to provide link information (e.g., information about potential long-term link problems (e.g., long-term BH RLF problems) detected by the IAB node 811) by sending a BH link FAILURE POLLING message 801. In response to this message 801, the IAB node 811 notifies the IAB donor 810 of the link problem it detected by sending a link failure notification using a BH link FAILURE INFORMATION.

[0197] In one example, message 802 embeds a BHLinkIssueInfo Information Element (IE) that contains all or part of the following information for a given BH link issue detected according to the methods described above with respect to FIG. 7 or 9: - BH Link information (identifying the BH link on which the link problem was detected). This BH Link information may include all or part of: 1) BAP addresses of the IAB nodes at both ends of the BH Link; 2) Cell ID information (identifying the cell to which the BH Link belongs); 3) one or more RLC channel IDs (identifying one or more RLC Channels affected by the detected problem); and 4) one or more BAP Routing IDs (identifying BAP Routing information (e.g., BAP address and Path ID) related to the faulty BH link affected by the detected problem). - Long Term BH Link Issue Indication information (indicating that a long-term fault or link problem has occurred on the BH link identified by the BH Link information above) - Long Term BH Link Issue Cause information (indicating the cause of the long term link issue). This information may indicate a BH link recovery failure, a slow recovery of the BH link, or a continuous (or recurring or reoccurring) BH link issue, as discussed above with reference to Figures 7 and / or 9. - Long Term BH Link Issue Type of Cause information (indicating the type of cause of the long-term link issue (e.g., long-term cause or short-term cause), as discussed above with reference to Figures 7 and / or 9) - RLF Indication information (indicating long-term failures or link problems due to BH Radio Link Failure (RLF), as discussed above with reference to Figures 7 and / or 9) - Congestion Indication information (indicating long-term failures or link problems due to congestion phenomena, as discussed above with reference to Figures 7 and / or 9) - Link Quality information (indicating the quality of the BH link affected by the BH link problem (e.g. SINR, congestion level, etc.)) - Ageing information (provides timing information about the moment of detection of a problem in the BH link).

[0198] In one embodiment of the present invention, message 801 is a UEInformationRequest message as defined in 3GPP TS 38.331, and message 802 is a UEInformationResponse message as defined in 3GPP TS 38.331.

[0199] In one embodiment of the present invention, message 802 is the MCGFailureInformation message defined in 3GPP TS 38.331.

[0200] In one embodiment of the present invention, message 802 is the SCGFailureInformation message defined in 3GPP TS 38.331.

[0201] In one embodiment of the present invention, message 802 is a FailureInformation message as defined in 3GPP TS 38.331.

[0202] In one embodiment of the present invention, message 802 is a Measurement Report message as defined in 3GPP TS 38.331.

[0203] In one embodiment of the present invention, message 802 is a GNB-DU STATUS indication message as defined in 3GPP TS 38.473.

[0204] In one embodiment of the present invention, message 802 is an ASSISTANCE INFORMATION DATA frame that specifies the NR user plane protocol defined in 3GPP TS 38.425. The ASSISTANCE INFORMATION DATA frame is carried by the GTP-U protocol, more specifically the "NR RAN Container" GTP-U extension header defined in TS 29.281.

[0205] Figure 11 shows steps of a method 1100 performed in a donor CU (also referred to as an IAB donor CU) according to an embodiment of the present invention. The donor CU is part of an IAB donor (e.g., IAB donor 601 in Figure 6) of an IAB network including multiple IAB nodes. The donor CU may be the IAB donor CU 810 shown in Figure 8. The donor CU may be implemented in a communication device 1000 shown in Figure 10 below in a manner described with reference to Figure 11 executed by a central processing unit 1011.

[0206] Briefly, in step 1101, a donor CU receives a link failure notification from an IAB node (e.g., IAB node 605 in FIG. 6 or IAB node 811 in FIG. 8). The link failure notification includes link problem information regarding a detected link problem (e.g., a long-term link problem) in data transmission on a backhaul link of the IAB network, and link information identifying the backhaul link. The link problem information includes information identifying the exposed link problem and information related to the cause of the detected link problem. Details of the link failure notification (e.g., messages that may be used to send the notification and the content of the notification) are discussed above with reference to FIGS. 7 to 9.

[0207] The donor CU determines whether reconfiguration of all or a part of the routing configurations of the IAB nodes in the IAB network is necessary based on the received link failure notification in step 1102. In response to determining that reconfiguration is necessary (YES at branch 1102), the donor CU transmits reconfiguration information to reconfigure the routing configurations of all or a part of the IAB nodes (e.g., by transmitting configuration information to update the Backhaul Routing Configuration table described above with reference to FIG. 5a and / or configuration information to update some or all of that table described with reference to FIGS. 5b to 5d).

[0208] FIG. 10 illustrates a schematic diagram of an example of a communications device or station, according to one or more embodiments and examples of the present disclosure.

[0209] The communication device 1000 can preferably be a microcomputer, a workstation or a lightweight portable device. The communication device 1000 preferably includes a communication bus 1013 with connections to: - A central processing unit 1011 (e.g., a microprocessor), denoted as CPU - memory for storing data and computer programs containing instructions for operation of the communications device 1000. The computer programs may include a number of different program elements or subroutines containing instructions for various operations and for implementing the present invention. For example, the program elements may include elements for implementing a BAP entity that routes data packets between different MTs and DUs of an IAB node and between different network nodes in the IAB network, as discussed above. - at least one communication interface 1002 for connecting to a wireless communication network 100 (for example a wireless communication network according to 5G NR Release 16) over which digital data packets or frames or control frames are transmitted. Frames are written from a FIFO transmit memory in RAM 1012 to the network interface for transmission and read from the network interface for reception and writing to a FIFO receive memory in the RAN 1012 under the control of a software application running in the CPU 1011.

[0210] Each donor CU, IAB network node and donor DU may include such a communications device 1000.

[0211] Central processing unit 1101 may be a single processor or may include two or more processors that perform the processing necessary for the operation of communications device 1000. The number of processors and the allocation of processing functions to central processing unit 1101 are a matter of design choice for those skilled in the art.

[0212] The memory may include: - a read-only memory 1007 (denoted ROM) for storing a computer program for implementing the invention; - a Random Access Memory 1012 (denoted RAM) for storing code capable of executing the methods according to one or more embodiments of the invention, as well as registers adapted to record variables and parameters necessary for implementing the methods according to one or more embodiments of the invention.

[0213] Optionally, the communications device 1000 may also include the following components: - a data recording means 1004 (e.g. a hard disk) for recording a computer program for implementing the method according to one or more embodiments of the invention; a disk drive 1005 for the disk 1006, adapted to read data from the disk 1006 or to write data onto the disk; - a screen 1009 for displaying the decoded data and / or serving as a graphical interface to the user, by means of a keyboard 1010 or any other pointing means.

[0214] Preferably, a communication bus provides communication and interoperability between various elements included in or connected to the communication device 1000. The representation of a bus is not limiting, in particular a central processing unit is operable to communicate instructions to any element of the communication device 1000, either directly or via other elements of the communication device 1000.

[0215] Disk 1006 may be replaced, if desired, by any information medium (e.g., a rewritable or non-rewritable compact disk (CD-ROM), a ZIP disk, a USB key or a memory card, and in general terms any information recording medium readable by a microcomputer or microprocessor, which may or may not be integrated into the device, which may be removable, and which is adapted to store one or more programs, the execution of which enables the implementation of the methods according to embodiments of the present invention).

[0216] The executable code may, as appropriate, be recorded on a read-only memory 1007, on the hard disk 1004 or on a removable digital medium (for example the previously described disk 1006). According to an optional variant, the code of the executable program may be received by the communication network 1003, via the interface 1002, in order to be recorded on one of the storage means of the communication device 1000 (for example the hard disk 1004) before being executed.

[0217] The central processing unit 1011 is preferably adapted to control and direct the execution of instructions or parts of the software code of a program according to the invention. The instructions are recorded in one of the storage means mentioned above. On power-up, the program stored in a non-volatile memory (for example the hard disk 1004) or in the read-only memory 1007 is transferred to the random access memory 1012. The random access memory 1012 then holds the executable code of the program and registers recording variables and parameters necessary to implement the invention.

[0218] In an embodiment, the device is a programmable device that uses software to implement the invention, but alternatively the invention may be implemented in hardware (e.g. in the form of an application specific integrated circuit or ASIC).

[0219] Local rerouting can be useful for congestion relief and load balancing. Additionally, local rerouting can be triggered by a Type-2 RLF indication or a hop-by-hop flow control notification.

[0220] In this respect, local rerouting may mitigate short-term (transient) BH link problems (RLF / BH link quality / congestion) phenomena.

[0221] However, this local re-routing may increase the risk of congestion at other IAB nodes (e.g., shifting the problem from one location to another). Therefore, local re-routing may be performed for a limited period of time. That is, even if local re-routing provides an efficient means of mitigating the impact of local BH link problems (by enabling fast link adaptation), it may not be suitable for long-term BH link problems.

[0222] In this regard, long-term BH link problems may require the IAB donor to reconfigure the routing configuration of all or part of the IAB nodes.

[0223] Even if the short-term problem can be addressed by local re-routing, the long-term RLF / congestion may require new routing configuration of IAB nodes to adapt to the new situation. However, IAB donors are not aware (as of Release 16) of both short-term and long-term local BH link problems.

[0224] In this regard, it can be seen that 3GPP Release 16 provides very little service for notifying IAB donors of BH link problems, and in particular there is no means to signal long / short term BH link problems.

[0225] To solve the above problems, it is proposed to distinguish between short-term BH link problems that can be handled at the IAB node level, e.g. by applying local rerouting, and long-term BH link problems that require a full or partial reconfiguration of the topology at the IAB donor level.

[0226] BH link problems may result from radio link failures or congestion at multiple IAB nodes, affecting one or more BH links. Multiple causes may trigger long-term BH link problems (e.g., RLF recovery failure, or RLF detection / RLF recovery streaks, or congestion detection / congestion recovery streaks).

[0227] Each of the IAB-MT and IAB-DU may detect such a BH link problem at its own level or by receiving a feedback message such as an RLF indication message (Type 1, 2 or 4) or a flow control feedback message.

[0228] Therefore, upon detection of long-term link problems, IAB nodes may notify IAB donors of such problems.

[0229] To enable the IAB donor to apply an efficient reconfiguration to solve or at least mitigate this problem, the IAB node may provide the IAB donor with information on one or more BH links experiencing BH link problems (e.g., BAP address, RLC Channel ID, or BAP Routing ID) and information on the cause of the long-term BH link problem (e.g., recovery failure, recurring BH link problem). The IAB node may also inform the IAB node whether the BH link problem is caused by an RLF or congestion event.

[0230] Since such long-term BH link problems may be detected in the MT unit or DU unit of the IAB node, both RRC and F1-AP protocols may be considered for the IAB node to notify the IAB donor of the detection of a long-term BH link problem.

[0231] Therefore, in conjunction with the above observations, it is proposed that IAB nodes may inform IAB donors of detection of long-term BH link problems (problems in the BH link that require reconfiguration at the IAB donor level).

[0232] It is also proposed that IAB nodes may indicate the cause of long-term BH link problems (eg, recovery failures, recurring BH link problems) to IAB donors.

[0233] It is also proposed that an IAB node may indicate whether a BH link problem is the result of RLF or congestion.

[0234] It is also proposed that the IAB node may inform the IAB donor of a problem in the BH link using an RRC or F1-AP message.

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

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

[0237] Reference signs appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

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

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

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

Claims

1. A method in an IAB (Integrated Access and Backhaul) node of an IAB network, wherein the IAB network includes a donor Central Unit (CU), the method includes detecting a link problem in data transmission on a backhaul link of the IAB network, in response to detecting the link problem, transmitting a link failure notification including link identification information for identifying the backhaul link and link problem information related to the detected link problem including information related to a cause of the detected link problem to the donor CU A method comprising the above.

2. The method according to claim 1, wherein the information related to the cause of the link problem includes information indicating the cause of the detected link problem or information indicating a type of the cause of the detected link problem.

3. The method according to claim 2, wherein the type of the cause of the detected link problem is one of a long-term cause or a short-term cause.

4. The method according to claim 1, wherein the cause of the detected link problem includes one of a link recovery failure, a slow recovery of a link problem, and a recurring link problem.

5. The method according to claim 1, further comprising determining whether the detected link problem results in a long-term link problem, and transmitting the link failure notification to the donor CU is in response to determining that the detected link problem results in a long-term link problem.

6. Determining whether the detected link problem results in a long-term link problem includes determining whether one of a plurality of predetermined link problem criteria is satisfied based on the detected link problem, and each of the plurality of predetermined link problem criteria represents a respective factor of a long-term link problem, Determining that the detected link problem results in a long-term link problem includes determining that a predetermined link problem criterion for data transmission on the backhaul link is satisfied, Transmitting the link failure notification to the donor CU is in response to determining that a predetermined link problem criterion for data transmission on the backhaul link is satisfied, The method according to claim 5, wherein the information indicating the cause of the detected long-term link problem includes information indicating that it has been determined that the predetermined link problem criterion has been met.

7. Determining whether the detected link problem results in a long-term link problem includes checking whether the detected link problem is related to a backhaul link recovery failure, and if the detected link problem is related to a backhaul link recovery failure, determining that the detected link problem results in a long-term link problem. The method according to claim 5.

8. Determining whether the detected link problem results in a long-term link problem, when the detected link problem is not related to a backhaul link recovery failure, includes checking whether the number of detected consecutive link problems reaches a threshold corresponding to the maximum number of consecutive link problems, and if the number of detected consecutive link problems reaches the threshold, determining that the detected link problem results in a long-term link problem. The method according to claim 7, further comprising.

9. Determining whether the detected link problem results in a long-term link problem, when the detected link problem is not related to a backhaul link recovery failure, includes checking whether the number of detected consecutive link problems within a link problem recovery time window having a predetermined length reaches a threshold, and if the number of detected link problems reaches the threshold, determining that the detected link problem results in a long-term link problem. The method according to claim 7, further comprising.

10. Whether all of the detected link problems among the detected link problems occur at different times and are link problems of the same category, or whether the number of detected link problems includes at least two detected link problems of different categories. The method according to claim 8.

11. Determining whether the detected link problem results in a long-term link problem, if the number of the detected link problems does not reach the threshold, determining whether the detected link problem is recovered, and in response to a determination that the detected link problem is not recovered within a recovery timeout period, or in response to a determination of a backhaul link recovery failure, further determining that the detected link problem results in a long-term link problem, the method according to claim 8 further comprising.

12. The method according to claim 1, wherein the detected link problem is a radio link failure (RLF) of the backhaul link.

13. The method according to claim 1, wherein the detected link problem is a congestion that affects data transmission on the backhaul link.

14. The link problem information regarding the detected link problem is information indicating the nature of the detected link problem, information identifying the type of the detected link, information indicating the link quality of the backhaul link, link problem time information indicating the time between the detection of the link problem and the transmission of the link failure notification, The method according to claim 1, further comprising at least one of.

15. The link information identifying the backhaul link is the unique addresses of the IAB nodes at both ends of the backhaul link, the BAP address of the IAB node of the backhaul link, a cell identifier identifying the cell associated with the backhaul link, an RLC channel identifier identifying the RLC channel associated with the link problem of the backhaul link, BAP routing identifier, The method according to claim 1, comprising at least one of.

16. Further comprising receiving a request for link information from the donor CU, and the transmitting comprises transmitting the link failure notification in response to the received request, the method according to claim 1.

17. Detecting a link problem in data transmission on the backhaul link is monitoring the link quality of the backhaul link, and when the link quality is lower than a radio link failure (RLF) threshold, detecting the RLF of the backhaul link, and the detected link problem is RLF, Receiving an RLF indication message associated with the backhaul link and indicating RLF or RLF failure recovery, where the detected link problem is RLF, Monitoring the load of the buffer of the IAB node, where the buffer is associated with the backhaul link, and detecting congestion in the buffer when the load exceeds a congestion threshold, where the detected link problem is congestion in data transmission on the backhaul link, Receiving a flow control feedback message associated with the backhaul link and determining congestion on the backhaul link from the flow control feedback message, where the detected link problem is congestion in data transmission on the backhaul link, The method according to claim 1, including at least one of the above.

18. The method according to claim 1, where the IAB node includes Mobile Termination (MT), and detecting a link problem in data transmission on the backhaul link and sending a link failure notification to a donor CU are performed by the MT of the IAB node.

19. The method according to claim 18, where the sending includes the MT of the IAB node sending the link failure notification in an RRC message.

20. The method according to claim 18, where detecting a link problem in data transmission on the backhaul link includes detecting a Radio Link Failure (RLF) of the backhaul link in response to a decoding failure of a Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH) transmitted on the backhaul link by the MT of the IAB node, and the detected link problem is RLF.

21. The method according to claim 1, where the IAB node includes a Distributed Unit (DU), and detecting a link problem in data transmission on the backhaul link and sending a link failure notification to the donor CU are performed by the DU of the IAB node.

22. The method according to claim 21, wherein the transmitting comprises transmitting, by the DU of the IAB node, the link failure notification in an F1 Application Protocol (F1-AP) layer message.

23. The method according to claim 21, wherein detecting a link problem in data transmission on the backhaul link is determined by the DU of the IAB node as to whether an acknowledgment message for data transmitted on the backhaul link is detected at the DU of the IAB node, and in response to a determination that no acknowledgment message is detected at the DU of the IAB node, detecting a radio link failure (RLF) of the backhaul link, and the detected link problem is an RLF.

24. A method in a donor Central Unit (CU) of an Integrated Access and Backhaul (IAB) network including a plurality of IAB nodes, comprising: receiving, from an IAB node, a link failure notification including link problem information related to a link problem detected for data transmission on a backhaul link of the IAB network and link information identifying the backhaul link, wherein the link problem information includes information identifying the detected link problem and information associated with a cause of the detected link problem; determining, based on the received link failure notification, whether resetting of all or some of the routing settings of the plurality of IAB nodes is required; transmitting, in response to a determination that resetting is required, resetting information for resetting all or some of the routing settings of the plurality of IAB nodes.

25. The method according to claim 24, wherein the information associated with the cause of the link problem includes information indicating the cause of the detected link problem or information indicating a type of the cause of the detected link problem.

26. The method according to claim 25, wherein the type of the cause of the detected link problem is one of a long-term cause or a short-term cause.

27. The method according to claim 24, wherein the detected link problem includes one of a link recovery failure, a slow recovery of a link problem, and a repeated link problem.

28. The method according to claim 24, wherein the detected link problem includes a radio link failure (RLF) of the backhaul link. **Claim 29** The method according to claim 24, wherein the detected link problem includes congestion that affects data transmission on the backhaul link. **Claim 30** The link problem information is information indicating the nature of the detected link problem, information identifying the type of the detected link problem, information indicating the link quality of the backhaul link, link problem time information indicating the time between the detection of the link problem and the transmission of the link failure notification, and further includes at least one of the above, according to the method of claim 24. **Claim 31** The link information for identifying the backhaul link is the unique addresses of the IAB nodes at both ends of the backhaul link, the BAP address of the IAB node of the backhaul link, a cell identifier for identifying the cell associated with the backhaul link, an RLC channel identifier for identifying the RLC channel associated with the link problem of the backhaul link, a BAP routing identifier, and includes at least one of the above, according to the method of claim 24. **Claim 32** Receiving a link failure notification includes receiving the link failure notification in an RRC message from the Mobile Termination (MT) of the IAB node, or receiving the link failure notification in an F1 Application Protocol (F1-AP) layer message from the Distributed Unit (DU) of the IAB node, according to the method of claim 24. **Claim 33** Information indicating the maximum number of consecutive link problems detected for data transmission on the backhaul link, Recovery time-out information indicating the maximum period between the detection of a link problem and the recovery from the detected link problem, A link problem recovery time window, which is a period during which the maximum number of consecutive link problems can be detected and has a predetermined length, and further includes transmitting, by the CU, the backhaul link failure setting information including the above to the plurality of IAB nodes, according to the method of claim 24. **Claim 34** An IAB (Integrated Access and Backhaul) node in an IAB network, At least one communication interface for communicating with a donor Central Unit (CU) and at least one of the other IAB nodes in the IAB network, A central processing unit coupled to the at least one communication interface and configured to execute the method according to claim 1, An IAB node comprising the same.

35. A donor Central Unit (CU) in an IAB (Integrated Access and backhaul) network comprising a plurality of IAB nodes, At least one communication interface, A central processing unit coupled to the at least one communication interface and configured to execute the method according to claim 24, A donor CU comprising the same.

36. A computer program which, when executed by a computer, causes the computer to execute the method according to claim 1.

37. A computer-readable storage medium having stored thereon the computer program according to claim 36.

Images