Backhaul Link Problems 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 generally relates to backhaul link problems in an Integrated Access and Backhaul (IAB) network of a wireless communication system. More specifically, the present invention relates to link detection problems in an IAB network.

Background Art

[0002] Wireless communication systems are widely deployed to support a wide range of applications, from mobile broadband, massive machine type communication to ultra-reliable low-latency communication (URLLC). In such a system, multiple user devices (UEs) or mobile terminals can share the wireless medium to exchange multiple types of data contents (e.g., video, audio, messaging, etc.) over a radio access network (RAN) via one or more base stations. Base stations have conventionally been wired-connected (e.g., fiber, etc.) to a core network to form an intermediate network called a backhaul (BH).

[0003] Examples of such wireless multi-connection communication systems include systems based on 3rd Generation Partnership Project (3GPP is a registered trademark) standards such as the 4th Generation (4G) Long Term Evolution (LTE) or the recent 5th Generation (5G) New Radio (NR), and IEEE 802.11-based systems such as WiFi.

[0004] The demand for higher network density (e.g., high-density deployment of base stations) is increasing due to the growth in the number of users and the requirement for higher throughput.

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

[0006] Because IAB eliminates the burden of base station cabling and allows for scalable and rapid deployment, it is a competitive alternative to fiber-based backhaul in high-density or hard-to-cover areas.

[0007] An IAB network includes one IAB base station (also called an IAB donor) that is directly connected to the core network via one IAB node or 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 IAB nodes that serve the UE, also called “access IAB nodes” from the UE's perspective. Each of the multiple backhaul paths between the IAB donor and the access IAB nodes includes several intermediate IAB nodes, forming alternative data paths within the multi-hop IAB network.

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

[0009] Similar to conventional 5G base stations (gNBs), an IAB donor consists of a central unit (CU or gNB-CU function) and one or more distributed units (DU or gNB-DU function). The IAB donor CU hosts higher-layer protocols for controlling the operation of one or more DUs, and each of the one or more IAB donor DUs contains lower-layer protocols, including the physical layer and radio frequency portion. The IAB donor CU and one or more IAB donor DUs can be located geographically separated from each other, and a wired IP network (typically fiber optic) exists to interconnect these different devices. The advantage of having multiple DUs connected 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, high-speed retransmission, and segmentation are performed in the DUs. As a result, there can be multiple backhaul paths downstream from the IAB donor CU to the IAB node via different IAB donor DUs. Similarly, in the upstream direction, there can be multiple possible backhaul paths from the source IAB node to the IAB donor CU via different IAB donor DUs.

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

[0011] IAB is most likely to operate in millimeter wave (mmWave) to achieve the requested data rate of Gbps (gigabits per second).

[0012] However, millimeter waves are known to experience significant signal attenuation under certain weather conditions (rain, fog) and can be interfered with if there are obstacles in the path between the radiator and receiver, which can frequently result in radio link failures.

[0013] To address these potential wireless link failures, topology redundancy is provided within the IAB framework, and multiple backhaul paths are established between the IAB donor and 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 to which data is preferably transmitted is defined as the default. Additionally, one or more backup paths through different sets of IAB nodes are defined as those that may be used if a Radio Link Failure (RLF) occurs on any link in the default path. A link is defined between two consecutive IAB nodes in the backhaul network. Backup paths are also useful in cases of congestion due to application traffic demand exceeding the capacity of the default link (which may vary depending on link quality). Rerouting traffic to backup paths or load balancing between the default path and one or more backup paths may be activated to mitigate congestion.

[0015] RLF and congestion are two types of backhaul (BH) link issues. Traffic rerouting or load balancing can help mitigate short-term BH link issues (RLF / BH link quality / congestion) (e.g., transient). In other words, short-term BH link issues are BH link problems that are short-lived and quickly resolved (e.g., by a rapid recovery of link quality). However, traffic rerouting or load balancing can increase the risk of congestion at other IAB nodes because the IAB node performing the rerouting is unaware of the congestion level at the distant IAB node.

[0016] Thus, while local rerouting, which enables high-speed link adaptation, may provide an efficient means of mitigating the impact of short-term BH link problems, it may not be suitable for long-term BH link problems (such as recurring or prolonged issues). Because only IAB donors are nodes that are aware of the entire IAB network topology, long-term BH link challenges may require IAB donors to reconfigure the routing settings of all or some of their IAB nodes.

[0017] The 3GPP Release 16 standard provides little for reporting local BH link issues to IAB donors. In this regard, there is no provision whatsoever for signaling for reporting long-term BH link issues. As discussed previously, even if short-term BH link issues can be mitigated by IAB nodes through local rerouting, long-term BH link issues may require all or some IAB nodes to configure new routing to adapt to the new situations arising from them. However, IAB donors (as of Release 16) do not have knowledge of short-term or long-term local IAB issues.

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

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

[0020] Therefore, by detecting link problems and sending link failure notifications to donor CUs in response to the detection of link problems, link problems can be identified at IAB nodes. When a link problem is detected, a link failure notification is sent to the donor CU 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 some or all of the routing settings of the IAB nodes in the IAB network, if necessary to ensure early and efficient handling of link problems to minimize service disruption. Link failure notifications from IAB nodes in the IAB network provide the donor CU with information about local link problems occurring at the IAB nodes, allowing the donor CU to have a more detailed understanding of the link problems in the IAB network and to decide on a more efficient reconfiguration of the IAB network necessary to resolve the link problems compared to when the donor CU does not have information about the local link problems.

[0021] Information associated with the cause of a link problem may include information indicating the cause of the detected link problem, or information indicating the type of cause of the detected link problem. For example, the type of detected link problem may be one of two things: 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 causes of link problems may include one of the following: link recovery failure, slow recovery of link problems, or recurring link problems. For example, each of these causes is a long-term cause that leads to a long-term link problem or long-term failure.

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

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

[0025] Therefore, long-term link problems are identified at the IAB node, and notifications may be sent to the donor CU upon detection of a long-term link problem. This allows the donor to identify the cause of the long-term link problem and reconfigure the routing settings of some or all IAB nodes in the IAB network, ensuring early and efficient handling of long-term link problems to minimize service disruption. In other words, long-term link problems are distinguished from short-term link problems and can be efficiently handled by the donor CU via link failure notifications.

[0026] Long-term link problems or long-term failures require reconfiguration of the routing settings 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 short-term link problems or short-term failures can be handled locally at the IAB node. A long-term link problem is a recurring, or repeated, or continuous link problem, or a link problem that takes a long time to recover or does not recover, and requires reconfiguration of the routing settings of the IAB network by the donor CU. A short-term failure or short-term BH link problem is a temporary one with a short duration and can be recovered early (e.g., by early recovery of link quality or link disconnection, and / or local actions at one or more IAB nodes), and is a short-term failure or BH link problem that does not require reconfiguration of some or all of the routing settings of the IAB node to the donor CU. A long-term failure or long-term BH link problem is a failure or BH link problem that is irrecoverable, or repeats in a short period, or is not recovered early, and all of them require reconfiguration of all or some of the routing settings of the IAB nodes in the IAB network by the donor CU.

[0027] The detected link problem can be a radio link failure (RLF) of the backhaul link or a congestion that affects 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 the detected link problem, information identifying the link quality of the backhaul link, and link problem time information indicating the time between the detection of the link problem and the transmission of the link failure 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 transmitting a link failure notification to the donor CU are 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 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.

[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, 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 appended claims is provided.

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

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

[0036] According to a fifth aspect, a method in a donor Central Unit (CU) of an Integrated Access and Backhaul (IAB) network including a plurality of IAB nodes is provided, the method including: Sending backhaul link failure setting information including the following from the CU to the plurality of IAB nodes: Information indicating the maximum number of consecutive link problems detected in data transmission on the backhaul link, and Recovery timeout information indicating the maximum period between the time a link problem is detected and the time it takes to recover from the detected link problem, A link problem recovery time window having a predetermined length in which the maximum number of consecutive link problems can be detected.

[0037] A sixth aspect of the present invention provides a method for an Integrated Access and Backhaul (IAB) node in an IAB network including a donor Central Unit (CU), which includes the following: Detects data transmission link problems on the IAB network backhaul, In response to a determination that a predetermined link failure criterion (also known as a predetermined link problem criterion) for data transmission on the backhaul link has been met, a link failure notification is sent to the donor CU containing information associated with the predetermined link failure criterion that has been determined to have been met (the link failure notification includes link identification information that identifies the backhaul link and link problem information related to the detected link problem).

[0038] A defined link problem criterion represents the cause of a link problem, and the information associated with the defined link problem criterion may include information indicating the cause of the detected link problem or the type of cause of the detected link problem. For example, the type of cause of the detected link problem may be either 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 causes of link problems may include one of the following: link recovery failure, slow recovery of link problems, or recurring link problems. For example, each of these causes is a long-term cause that leads to a long-term link problem or long-term failure.

[0040] The method may further include determining whether the detected link problem is related to a backhaul link recovery failure, and, if so, determining whether a predetermined link failure criterion is met.

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

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

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

[0044] In summary, when one or more BH links face long-term BH link problems, new methods and related Information Elements will be added to the existing 3GPP IAB framework to mitigate service disruptions.

[0045] In summary, when one or more BH links face long-term BH link problems, new methods and related Information Elements will be added to the existing 3GPP IAB framework to mitigate service disruptions.

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

[0047] Any feature in one aspect of the present invention may be applied to other aspects of the present invention in any suitable combination. In particular, aspects of methods may be applied to aspects of apparatus / devices / units, and vice versa.

[0048] Furthermore, functions implemented in hardware may also be implemented in software, and vice versa. Any references to software and hardware features in this specification should be interpreted accordingly. For example, according to another aspect of the present invention, a computer-readable storage medium is provided which records at least one computer program that, when executed by a processing unit, causes a processing unit to perform a method according to any of the above-described aspects or examples.

[0049] It should also be understood that specific combinations of the various functions described and defined in any embodiment of the present invention may be independently implemented and / or supplied and / or used. [Brief explanation of the drawing]

[0050] Different aspects of the present invention will be described by reference to the following drawings, for illustrative purposes only. [Figure 1] This is a schematic diagram illustrating a wireless communication system, including a wireless Integrated Access and Backhaul (IAB) network. [Figure 2a] This is a schematic diagram showing the stack of multiple protocol layers included in IAB operations. [Figure 2b] This is a schematic diagram showing the stack of multiple protocol layers included in IAB operations. [Figure 3] This is a schematic diagram showing the format of a BAP Protocol Data Unit (PDU) or packet. [Figure 4] This is a schematic diagram illustrating routing management in an IAB network. [Figure 5] This shows the fields in the routing table of an IAB node according to 3GPP TS 38.300. [Figure 6] This is a schematic diagram showing an example topology of an IAB network configuration in which the present invention may be implemented according to one or more exemplary embodiments. [Figure 7] An exemplary method for managing the detection of long-term BH link problems according to embodiments of the present invention is shown using a flowchart. [Figure 8] This 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] An exemplary method in an IAB node for managing the detection of long-term BH link problems according to embodiments of the present invention is shown using a flowchart. [Figure 10] This is a schematic block diagram of an example of a wireless communication device implementing an embodiment of the present invention. [Figure 11] An exemplary method for managing long-term BH link problems in an IAB donor CU according to embodiments of the present invention is shown with a flowchart. [Modes for carrying out the invention]

[0051] Figure 1 shows an example of a wireless communication system 100, in particular a mobile wireless communication system such as fifth-generation (5G) New Radio (NR) including a wireless Integrated Access and Backhaul network. In the following description, embodiments and examples of embodiments of the present invention will be described in relation to a 5G NR system, but the present invention is not intended to be limited to a 5G NR system and is understood to be applicable to any wireless communication system having an Integrated Access and Backhaul network in which a wireless access link and a wireless backhaul link share wireless resources.

[0052] System 100 comprises multiple User Equipment (UEs) 132, 133, 131, and 134, a remote core network 110, a primary 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] The main base station 120 (also known as IAB donor 120, and hereafter 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 examples of embodiments of the present invention, the IAB donor 120 is a 5G NR gNB with additional functionality to support IAB functionality (as defined in the 3GPP TS 38.300 v16.2.0 standard document).

[0054] To extend the network coverage of IAB donor 120 and reach the distant UEs 132, 133, and 131, IAB stations 121 and 122 (also known as IAB nodes 121 and 122) have been installed by the operator. By acting as relay nodes between IAB donor 120 and UEs 132 and 133, IAB nodes 121 and 122 can overcome reachability issues resulting from the presence of building 108 (which is an obstacle to radio wave propagation and therefore hinders direct connections and further communications between the UEs and the IAB donor). This is especially true when communications between IAB donor 120 and UEs 132 and 133 are operating on millimeter-wave frequencies, which are highly sensitive to shadowing.

[0055] IAB Donor 120 also provides services to UE134, which is directly connected to its own device. 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 the following: -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] Since IAB nodes 121 and 122 are connected to UEs 131, 132, and 133 respectively, they are considered access IAB nodes for the UEs they are connected to.

[0058] An IAB donor 120 is a logical node that provides NR-based radio backhaul and consists of a central unit (CU or gNB-CU function) and connected donor distributed units (DU or gNB-DU function). An IAB donor CU or donor CU (hereinafter also referred to as IAB donor CU) hosts one or more DUs containing lower-layer protocols such as RLC, MAC, and physical layer protocols, and one or more IAB donor DUs or donor DUs, and higher-layer protocols such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) to control the operation of each. An IAB donor CU or donor CU and an IAB donor DU or donor DU may be located far apart from each other, or they may be located on the same physical device. The gNB-DU function is defined in 3GPP TS 38.401. The aim is to terminate the NR access interface at the UE and the next-hop IAB node, and to terminate the F1 protocol at the IAB node gNB-CU function, as shown in Figures 2a and 2b discussed below.

[0059] IAB nodes capable of serving multiple wireless sectors are wirelessly backhauled to IAB donor 120 via one or more hops on intermediate IAB nodes. They form an effective acyclic graph (DAG) topology with the IAB donor in their route as the 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 called IAB-DU, enables downstream (towards the UE) connections to the next hop IAB. The IAB-MT function includes the functionality (e.g., physical layer, layer 2, RRC and non-accessible stratum (NAS function)) for connecting to the gNB-DU of an upstream IAB node (e.g., IAB donor 120 when connecting to IAB donor gNB-CU (i.e., core network 110) for initialization, registration, and configuration).

[0061] In this DAG topology, adjacent nodes on the IAB-DU' interface are called child nodes, and adjacent nodes on the IAB-MT' interface are called parent nodes. The direction toward child nodes is further called downstream, and the direction toward parent nodes is called upstream.

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

[0063] Figures 2a and 2b show an overview of the stack of several protocol layers included in IAB operations.

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

[0065] In 5G NR, F1-C is a functional interface in the control plane (CP) between the IAB donor CU and the IAB node DU (e.g., the DU of IAB node 2), and between the IAB-donor CU and the IAB donor DU. F1-U is a functional interface in the user plane (UP) of the same unit. F1-C and F1-U are shown by reference 212 in Figure 2a. In this example, F1-U and F1-C are transmitted over two backhaul hops (from the 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 known User Datagram Protocol (UDP) is a transport layer protocol suitable for use with the IP protocol, providing best-effort datagram services.

[0067] In the control plane, box 210 represents the F1-AP layer (F1 Application Protocol), and box 211 represents the SCTP (Stream Control Transmission Protocol) layer. The F1 Application Protocol (as defined in 3GPP TS38.473 and TS 38.401) provides signaling services between IAB donor CUs and IAB node DUs, or services associated with UEs. These services include, for example, initialization and configuration. The known SCTP layer provides reliable, congestion-controlled sequential message forwarding.

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

[0069] Transfers between IAB donor DUs and IAB donor CUs also utilize the IP transport layer over various media, such as wired or fiber optic, when the IAB donor CU is far from the IAB donor DU or when the IAB donor CU and IAB donor DU are in local virtual instances on the same physical machine. IAB-specific transfers between IAB donor CUs and IAB donor DUs are specified in 3GPP TS 38.401.

[0070] In Figure 2, L1 and L2 represent the transport and physical layers appropriate for the medium being used, respectively.

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

[0072] On the wireless backhaul, the IP layer itself is transmitted over a Backhaul Adaptive Protocol (BAP) sublayer that enables routing over multiple hops. The BAP sublayer is defined in TS 38.340.

[0073] IP traffic from an IAB-DU is routed over the radio backhaul via a BAP sublayer. Downstream, upper-layer packets are encapsulated by the BAP sublayer in the IAB donor DU, forming BAP packets, packet data units (PDUs), or data packets. BAP packets are routed by the BAP layer or entities of intermediate IAB nodes, if any (and the corresponding BAP entities in IAB-DUs and IAB-MTs). BAP packets are finally decapsulated by the BAP sublayer of the destination IAB node (which may be the access IAB node if the upper-layer packets within the BAP packet are destined for the UE).

[0074] Upstream, upper-layer packets are encapsulated by the BAP sublayer of the initiator IAB node (which may be the access IAB node if the upper-layer packets originate from the UE), forming BAP packets, data units (PDUs), or data packets. BAP packets are routed by the BAP layer of any intermediate IAB nodes (and their corresponding BAP entities in IAB-DUs and IAB-MTs). Finally, BAP packets are decapsulated by the BAP sublayer of the IAB donor DU.

[0075] On the BAP sublayer, packets are routed based on the BAP routing ID (transmitted 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., the 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 standardization version 3GPP TS38.340 release 16.3.0.

[0076] The payload section 307 is typically an IP packet. The header 30 contains fields 301 through 306. Field 301 is called the D / C field and is a Boolean indicating 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 (by the IAB donor CU of the IAB network). Field 306 carries a path ID that identifies the routing path, and the BAP packet should follow this destination in the IAB topology. The routing path, including the path ID, is configured at the IAB node (by the IAB donor CU of the IAB network) for routing purposes.

[0079] The BAP header is added to the packet when it arrives at the BAP layer from a higher layer and removed at the BAP layer when it reaches the destination node. The selection of the packet's BAP routing ID is set 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 could be an access IAB node if the upper-layer packet comes from a UE)), the BAP header with the BAP routing ID is constructed 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. At the intermediate IAB node, the fields of the BAP header are already identified within the BAP packet being forwarded.

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

[0082] The use of these tables (and other tables) for performing routing is described below with reference to Figure 5.

[0083] To transfer messages over the 5G NR radio medium, three additional sublayers (RLC, MAC, and physical) are implemented at each IAB node under the BAP sublayer. The RLC (Radio Link Control) sublayer is responsible for packet segmentation or reconfiguration. It also handles requests for retransmission of lost packets. The RLC layer is further defined in TS38.322. The MAC (Medium Access Channel) protocol sublayer is responsible for selecting the available transmission format for user data and mapping from logical channels to transport channels. MAC also handles part of the hybrid automatic retransmission request scheme. The MAC layer is detailed in TS 38.321. At the sending or transmitting end, MAC encapsulates data packets issued from the RLC. It adds a header that transmits the information necessary for MAC functionality. At the receiving end, MAC decapsulates data packets issued from the PHY, removes the header, and passes the remaining data to the RLC. The physical sublayer provides an electrical interface to the transmission medium (air) by converting the information stream into a physically modulated signal at the transmitting end and then into a carrier frequency. At the receiving end, it converts the physically modulated signal back into an information stream. The physical layer is defined in TS 38.201, TS 38.211, TS 38.212, TS 38.213, and TS 38.214.

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

[0085] The PDCP sublayer handles IP header compression / decompression, encryption / decryption, and, if necessary, data packet integrity. It forces packets to be numbered at the sending end and reorders them at the receiving end. The PDCP sublayer is defined in 3GPP TS38.323.

[0086] The SDAP sublayer 220 for the user plane handles Quality of Service, as defined in TS38.324. On the UE side, the SDAP sublayer exchanges payload data with the user's applications (voice, video, etc., not shown in Figure 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 protocol entities in the user plane protocol stack. It is defined in TS38.331. It handles, among other things, the broadcasting of information necessary for the UE to communicate with the cell, sending of paging messages, management of connections including bearer configuration, mobility functions, measurement configuration and reporting, and device functions.

[0088] Interfaces between nodes (both CP and UP) using PDCP, RLC, MAC, and physical layers refer to NR-Uu. This primarily concerns interfaces with UEs.

[0089] The interface between nodes (both CP and UP) that uses the BAP, RLC, MAC, and PHY layers is called a 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., access IAB nodes (both CP and UP)).

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

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

[0093] BAP routing configurations can be manually configured at each IAB node in the IAB network. Preferably, BAP routing configurations can be constructed, 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 setup and throughout the lifespan of the IAB network. As described above, BAP routing configurations can be constructed by the IAB donor CU based on the IAB network topology and its evolution over time (e.g., if some radio links disappear or recover or the quality of those links changes).

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

[0095] Figure 5a schematically shows entry 500 of the Backhaul Routing Configuration table specified in 3GPP TS 38.300, V16.4.0, Chapter 6.11.3 for the BAP sublayer. It is used by the IAB node to select the input link on which to forward or transmit BAP packets or PDUs (Protocol Data Units).

[0096] Field 501 defines the BAP Routing ID (a concatenation of the PATH field 306 and the DESTINATION field 305 as defined in Figure 3), and field 502 identifies the next-hop BAP Address (for example, the BAP address of the next IAB node along the path corresponding to routing ID 501). Thus, the Next Hop BAP Address 502 identifies the input link or backhaul link for forwarding or transmitting BAP packets.

[0097] The Backhaul Routing Configuration table may have multiple entries for the same destination BAP address, but with different Path IDs and next-hop BAP Addresses in Information Element 502. The first entry provides the default next-hop BAP Address corresponding to the default path to reach the destination, while other entries for the same destination BAP address may relate to a backup redundant path selected when the default link is unavailable (e.g., a radio link failure (RLF) or congestion associated with that link).

[0098] Figure 5b shows an overview of entry 510 of the BH RLC channel mapping configuration 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. It is used by an IAB node acting as a relay (e.g., an intermediate IAB node) to identify the Backhaul (BH) RLC channel on which BAP packets or PDUs are forwarded over a pre-selected output link using the Backhaul Routing Configuration table.

[0099] Information element (IE) 511 stores the next-hop BAP address, which is predefined and usually obtained from the Backhaul Routing Configuration table. IE512 stores the prior-hop BAP address (e.g., the BAP address of the previous IAB node from which the BAP packet arrived). IE513 identifies the input RLC channel ID (e.g., the identifier of the RLC channel on which the BAP packet will be received). IE514 stores the output RLC channel ID, which provides the RLC channel that the IAB node will use to forward the BAP packet.

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

[0101] Figures 5c and 5d show the equivalent BH RLC channel mapping configuration for IAB nodes that do not operate as intermediate IAB relay entities. These 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). It is used by an initiator IAB node (not an IAB donor DU) that has constructed a BAP packet or PDU from a BAP SDU (Service Data Unit) received from a higher layer to identify the Backhaul (BH) RLC channel to which packets are sent in the upstream direction on a pre-selected output link using the Backhaul Routing Configuration table defined in Figure 5a.

[0103] IE521 identifies the Traffic Type Identifier for the SDU received from the upper layer, IE522 indicates the next-hop BAP address which is predefined and usually obtained from the Backhaul Routing Configuration table, and IE523 identifies the outgoing BH RLC channel which provides the RLC channel that the IAB node uses to send BAP packets.

[0104] The table in Figure 5d is called the Downlink Traffic to BH RLC Channel Mapping Configuration table 530. It is used to identify the Backhaul (BH) RLC channel for sending downstream BAP packets on a pre-selected output link using the Backhaul Routing Configuration table, from an IAB donor DU that has constructed a BAP packet or PDU from a BAP SDU (Service Data Unit) received from a higher layer.

[0105] IE531 is the IPv6 flow label used to classify IPv6 flows, IE532 identifies the DSCP (Differentiated Services Code Point) which is usually shown in the IPv6 header of the packet, IE533 indicates the destination IP address, IE534 specifies the next-hop BAP Address as defined above, and IE535 specifies the output BH RLC channel ID which provides the RLC channel that the IAB node uses to send BAP packets. The tables in Figures 5b, 5c, and 5d consist of multiple rows (entries), and each row / entry contains the IE (or field) shown in the respective figure.

[0106] The Next-hop BAP address and output link are synonymous, as they specify the same portion of the IAB network (backhaul link) between the current IAB node with that Next-hop BAP address and the next IAB node. Therefore, they can be used interchangeably to specify such IAB network links.

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

[0108] Returning to Figure 4, typically, the BAP sublayer of IAB node 402 routes BAP packets using the BAP routing IDs 305+306 of the BAP packets. The BAP address (DESTINATION path 305) is used for the following purposes: 1) Determining whether a BAP packet has reached its destination node (e.g., an IAB node or IAB donor DU) on the BAP sublayer. A BAP packet reaches its destination node if the BAP address 305 in the packet's BAP header 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 BAP packets that have not reached their destination. This applies to BAP packets that have arrived from a previous hop IAB node on the BAP sublayer, or to BAP packets that have been received from a higher layer.

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

[0110] IAB node 402 resolves the next-hop BAP address 502 to the physical backhaul link (link 420 or link 430). To do this, it searches table 500 for an entry with 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 for the same destination BAP address but with different BAP Routing IDs (different BAP Path IDs). These entries may correspond to the same or different output BH links. If a Radio Link Failure (RLF) occurs on the BH link matching the BAP Routing ID of a BAP packet, typically the IAB node may select another output BH link (next-hop BAP address) based on the routing entry for the same destination BAP address (for example, by ignoring the BAP path ID). In this way, BAP packets may be delivered via an alternative path if the indicated path is unavailable.

[0112] For example, if a wireless link failure occurs on BH link 420, IAB node 402 may select another BAP routing ID, including BH link 430, for the same destination BAP address.

[0113] Next, IAB node 402 derives the output BH RLC channel of the selected output BH link (on which BAP packets are transmitted or forwarded). To do this, IAB node 402 uses either the BH RLC channel mapping configuration table, 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 the uplink / upstream or downlink / downstream direction).

[0114] For example, at an intermediate or relay IAB node, IE511, 512, and 513 are inputs for BH RLC channel lookup processing, and IE514 is an output. IAB node 402 routes the input BAP packet received from input BH RLC channel ID 513 (belonging to the input BH link identified by prior-hop BAP address 512) to output BH RLC channel ID 514 (which is pre-selected and belongs to the output BH link identified by next-hop BAP address 511).

[0115] For an initiator IAB node that wants to send BAP packets upstream to an IAB donor, IE521 and 522 are inputs in the BH RLC channel lookup process, and IE523 is an output. IAB node 402 selects the output BH RLC Channel 523 corresponding to entry 520 in the table where Traffic Type Identifier 521 matches the traffic type of the original BAP SDU (next-hop BAP address 522 matches the next-hop BAP address pre-selected by the Backhaul Routing Configuration table). This applies to BAP SDUs (non-F1-U packets) in the control plane as well as BAP SDUs (F1-U packets) in the user plane. 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 that wants to send BAP packets downstream to a destination IAB node or UE, IE531, 532, 533, and 534 are inputs for the BH RLC channel lookup process, and IE535 is an output. The IAB node selects the output BH RLC Channel 535 corresponding to table entry 530, which matches the original BAP SDU's Designation IP address 533, IPv6 Flow Label 531 (only for BAP SDUs encapsulating IPv6 packets), and Differentiated Services Code Point (DSCP) 532 (where the 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 no matching entry is found, the default BH RLC ID Channel may be selected.

[0118] Such routing processes can be implemented at various IAB nodes in the IAB network.

[0119] Figure 6 shows an example topology of an IAB network 600 that provides network path diversity in embodiments and examples of embodiments of the present invention. In one example implementation, the BH radio link operates on a millimeter-wave frequency band (e.g., above 30 GHz) that is highly sensitive to radio channel interference.

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

[0121] Since IAB nodes 604, 607, 608, and 609 provide services to UE640, 670, 680, and 690 respectively, they also function as access IAB nodes for each UE.

[0122] Redundant paths may exist between sets of IAB nodes. For example, the path between IAB donor 601 and IAB node 608 includes a first default BAP path via IAB nodes 602, 605, and 608, a second BAP path involving IAB nodes 602, 603, 605, and 608, and a third BAP path involving IAB nodes 602, 606, and 608.

[0123] The following example explanation considers the following BAP paths: -PATH1: Associated with Routing ID1, connects IAB node 608 to IAB donor 601 via IAB nodes 605 and 602, and through BH radio links 658, 625 and 612. This may be the default path between 601 and 608. -PATH2: Related to Routing ID2, connects IAB node 608 to IAB donor 601 via IAB nodes 605, 603, and 602, and through BH radio links 658, 635, 623, and 612. -PATH3: In relation to Routing ID3, connect IAB node 608 to IAB donor 601 via IAB nodes 606 and 602, and through BH radio links 668, 626 and 612.

[0124] The BH radio link 625 between IAB nodes 602 and 605 may experience radio link shortages (e.g., poor link quality) due to unexpected interference or shadowing phenomena (e.g., radio link failure (RLF)). If the radio link shortage (link quality) reaches or falls below the RLF threshold for detecting RLF, the default BAP path PATH1 may become unavailable 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 radio link failures on the BH radio links. IAB node 605 is therefore the detecting IAB node. More precisely, the IAB-MT of IAB node 605 can detect radio link failures on BH radio links 625 (and 635). It can warn its child IAB nodes (i.e., IAB nodes 607 and 608) of the radio link failure using BH RLF indicator messages. BH RLF indicator messages can also be forwarded by child IAB nodes to their own child IAB nodes, if any.

[0126] The following types of BH RLF display messages may be considered: The Type 2 BH RLF indication message is sent by the detecting IAB node as soon as an RLF is detected on one of its BH links. The Type 3 BH RLF indication message is sent by the detecting IAB node when RLF is recovered on one of the BH links. The Type 4 BH RLF indication message is sent by the detecting IAB node when it detects an RLF recovery failure, as specified in TS38.340. An RLF recovery failure may indicate that the IAB node was unable to recover from the RLF.

[0127] In one embodiment of the present invention, as will be discussed in more detail below, RLF detection may also be performed on the IAB-DU of an IAB node (for example, the IAB-DU of IAB node 605 can detect radio link failures on BH radio links 657 and 658). Thus, in an example where a radio link failure (RLF) occurs on BH link 625 and PATH1 is unavailable, PATH2 and PATH3 may be used as alternative paths. For example, IAB node 605 may select PATH2 as an alternative path for routing BAP packets to IAB donor 601. IAB node 605 may select BH link 635 as another output BH link (next-hop BAP address) based on a routing entry in the Backhaul Routing Configuration table that has the same destination BAP address as IAB donor 601 (for example, by ignoring the BAP path ID). In this way, BAP packets 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 the BAP layer or entity) that buffers data routed between nodes in the IAB network node (e.g., BAP packets or PDUs). Congestion problems in the IAB node are detected when the buffer load (e.g., the amount of data buffered in the buffer) exceeds or reaches a predetermined level (also known as the congestion threshold), or when it overflows. The IAB-MT or IAB-DU may detect whether there is a congestion problem depending on whether the affected backhaul link is connected to a parent IAB node or a child IAB node. Therefore, an IAB node such as IAB node 608 may experience congestion at its own buffer level (IAB-DU buffer). Therefore, if the buffer load exceeds or reaches a predetermined level, IAB node 608 may warn its parent node (e.g., IAB node 605) that congestion has been detected at IAB node 608 by sending a flow control feedback message as defined in TS38.340. IAB node 608 may also send a flow control feedback message to IAB node 605 if it receives a flow control polling message from IAB node 605. The flow control feedback message typically includes information indicating the buffer size available at the IAB node. Thus, this information in the flow control feedback message can provide notification when the buffer load of the IAB-DU or IAB-MT at the IAB node exceeds or reaches a predetermined level, and can therefore indicate a congestion problem with the backhaul link (e.g., congestion affecting data transmission on the backhaul link).It is understood that congestion on a backhaul link may result from excessive data being routed over that backhaul link (e.g., due to rerouting data from other IAB nodes), or from excessive data being routed over a backhaul link due to a decrease in link quality that reduces the link capacity or the maximum throughput of the backhaul link (e.g., the amount of data that can be routed or transmitted over the backhaul link is reduced due to a decrease in link quality).

[0129] The IAB-DU BAP entity of an IAB node may contain at least one buffer (typically one buffer per RLC channel) to receive BAP PDUs (downstream communications) sent to child IAB nodes over the backhaul link from the IAB-MT BAP entity of the IAB node, and to receive BAP PDUs (upstream communications) sent to the IAB-MT BAP entity of the IAB node from the child IAB node. Similarly, the IAB-MT BAP entity of an IAB node may contain at least one buffer (typically one buffer per RLC channel) to receive BAP PDUs (upstream communications) sent to a parent IAB node (which may be an IAB donor DU) over the backhaul link from the IAB-DU BAP entity of the IAB node, and to receive PDUs sent to the IAB-DU BAP entity of the IAB node from the parent IAB node (which may be an IAB donor DU). If the buffer load of a BAP entity's buffer (in IAB-DU or IAB-MT) on an IAB node exceeds a predetermined level (for example, if 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 (such as a parent node) in an IAB-MT on an IAB node, the BAP entity (in IAB-DU or IAB-T) generates a flow control feedback message containing information indicating the available buffer size in the BAP entity on the IAB-MT and / or IAB-DU, and sends it to the IAB node. Therefore, this information in the flow control feedback message provides notification when the buffer load of a BAP entity's buffer (in IAB-DU or IAB-MT) on an IAB node exceeds a predetermined level, indicating a congestion problem with the backhaul link.

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

[0131] Similarly, following the detection of congestion issues in data transmission on the backhaul link at an IAB node, the IAB node may perform local actions to minimize the impact of the congestion issue, such as local rerouting or load balancing (e.g., performed by the IAB node's BAP entity), and / or bitrate adaptation (e.g., performed by the IAB node's scheduler), and / or buffering and queue management. Furthermore, following the detection of congestion issues, the radio conditions / link quality may improve, and / or local actions may be performed at the IAB node as described above, resulting in reduced congestion at the IAB node. When the buffer load at the IAB node reaches or falls below a recovery level (also known as the congestion recovery threshold), the IAB node may consider the backhaul link to be recovered (the congestion issue has been resolved and no longer exists). The IAB node may, if necessary, or in response to a flow control polling message, send a flow control feedback message (for example, based on the available buffer size indicated in the flow control feedback message) that contains information indicating that the congestion problem has been resolved.

[0132] Because a local IAB node does not have knowledge of the congestion or link problem situation of all nodes in the IAB network, any local action taken to address RLF / congestion issues may create link problems at other IAB nodes in the IAB network (e.g., far from the local IAB node). Therefore, any such local action should preferably be applied for a limited period of time.

[0133] For example, early recovery of link quality may allow for a short recovery time from RLF or congestion issues. For these short-term or transient link problems, local actions at the IAB node, such as local rerouting for RLF issues or local rerouting, load balancing, and / or bitrate adaptation for congestion issues, can provide effective means to reduce or mitigate the impact of the link problem. Because they are only needed for a short period, the impact on other nodes in the IAB network is minimized. However, for some link problems (referred to as long-term link problems), such as recurring or continuous link problems that take a long time to recover from, long-lasting link problems, or links that do not recover, taking local actions at the local IAB node (such as local rerouting or load balancing) can have a significant impact on other nodes in the IAB network, potentially creating link problems. Such long-term link problems, therefore, require the IAB donor CU to reconfigure the routing settings for all or some nodes in the IAB network, as only the IAB donor CU has a complete understanding of the entire IAB network topology.

[0134] Techniques for distinguishing long-term link problems that require a donor CU (or IAB donor CU) to reconfigure the routing settings of the IAB network from short-term link problems that can be resolved locally at the IAB node are described by several embodiments and examples of 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 also described by several embodiments and examples of embodiments of the present invention.

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

[0136] In step 901, an IAB node (for example, node 605 in Figure 6) detects a link problem or issue (also known as a BH link problem) in data transmission over a backhaul link (also known as a BH link or BH radio link) of the IAB network. The link problem may relate to a BH link between IAB node 605 and a parent IAB node (for example, if IAB node 602, the affected BH link is BH link 625), or between IAB node 605 and a child IAB node (for example, if IAB node 607, the affected BH link is BH link 657), or between a parent or child IAB node of IAB node 605 and another IAB node (for example, 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, IAB node 605 may determine whether there is a link problem with BH link 623 based on information relayed to IAB node 605 from a parent or child IAB node (e.g., an RLF indication message or a flow control feedback message). A link problem or BH link problem (e.g., the type of link problem or BH link problem) may be a radio link failure (RLF) on the backhaul link or congestion affecting data transmission on the backhaul link. For example, congestion may occur in an IAB node or an IAB node connected to that IAB node that may affect the backhaul link or one or more other BH links. In other words, a link problem or link issue relates to a problem or issue that (negatively) affects data transmission on the BH link. The cause or source of a link problem or issue may be at least one of the following: 1) the quality of the link, or 2) the amount of data being transmitted over the backhaul, or 3) radio link recovery failures, or 4) recurring link problems or link problems that take too long to recover.

[0137] In response to the detection of a link problem, IAB node 605 sends a link failure notification to the donor CU (or IAB donor CU). For example, in step 902, 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 the donor CU (or IAB donor CU) to reconfigure the routing settings in the IAB network (e.g., some or all IAB nodes in the IAB network), while a short-term link problem is handled locally at the IAB node. For example, a long-term link problem is a recurring or continuous link problem, or a long-term link problem that takes a long time to recover from, or an unrecoverable link problem. In step 903, in response to the determination that the detected link problem will result in a long-term link problem, IAB node 605 sends a link failure notification to the donor CU. A link failure notification includes link identification information that identifies a backhaul link (e.g., a backhaul link affected by a long-term link problem) and link problem information related to the detected link problem (including information about the cause or source of the detected link problem (e.g., a long-term link problem)). Information related to the cause of the link problem may include information indicating the cause of the detected link problem or the type of cause of the detected link problem. For example, the type of cause of the detected link problem may be either 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). Long-term causes of a detected link problem may include one of the following: a link recovery failure, a slow recovery of the link problem, or a recurring link problem. Short-term causes may include excessive data transmitted over the backhaul over a short period (e.g., recovers quickly) that causes congestion as a short-term link problem, and / or backhaul link quality below a short-term threshold (e.g., recovers quickly) that causes a radio link failure (RLF) as a short-term link problem.

[0138] IAB Node 605 may determine whether a detected link problem will result in a long-term link problem by determining whether one of a predetermined set of link failure criteria (also known as predefined link problem criteria) is met. Each of the predefined link problem criteria represents a cause, source, or consequence of a long-term link problem, which can be determined by checking whether one of its predefined link problem criteria is met. For example, sending a link failure notification to a donor CU may be a response to a determination that a predefined link problem criterion has been met based on a detected link problem (for example, that the met predefined link problem criterion is one of a set of link problem criteria). Link problem information regarding a detected link problem includes information indicating the predefined link problem criterion that was determined to be met.

[0139] With respect to Figure 7, as will be discussed in more detail below, three causes or three predetermined link problem criteria (each resulting in a long-term link problem) may be considered for a long-term link problem: 1) Link recovery failure (unrecoverable RLF failure recovery or congestion) 2) Slow link recovery (for example, RLF failures or congestion that take too long to recover from a link problem, exceeding a predetermined threshold) 3) Recurring or recurring link problems - Recurring BH link problems (repeated or consecutive RLF detection / RLF recovery and / or congestion detection / congestion recovery).

[0140] BH link problems can be detected by the IAB-MT or IAB-DU unit of an IAB node, and this detection can occur directly (e.g., detected at the IAB-MT or IAB-DU's own level) or indirectly (detected based on the IAB-MT or IAB-DU receiving a BH link problem message from the connected IAB node). In this regard, 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 transmitted by IAB node 605 includes link identification information that identifies the link problem with respect to the backhaul link and the detected link problem (including information about the cause of the long-term link problem (e.g., Long Term BH Link Issue Cause information indicating the cause of the long-term link problem (e.g., link recovery failure, slow link recovery, or BH link problems that occur continuously or repeatedly) and / or Long Term BH Link IssueTypeofCause information indicating the type of cause of the long-term link problem (e.g., long-term cause or short-term cause))).

[0142] Link identification information or BH link information may include at least one of the following: The unique addresses of the IAB nodes at both ends 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. RLC channel identifiers that identify RLC channels in a backhaul link (related to faulty or link problems). BAP routing identifier.

[0143] Link problem information in link failure notification messages sent by IAB nodes includes, in addition to information associated with the cause of the long-term link problem, all or part of the following information: - The nature of the BH link problem (e.g., a long-term link problem). For example, Long Term BH Link Issue Indication information indicating that a long-term failure or link problem 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). For example, RLF Indication information indicating a long-term fault or link problem caused by a BH radio link fault (RLF), and Congestion Indication information indicating a long-term fault or link problem caused by congestion. - BH Link Quality. For example, Link Quality Information (e.g., SINR, congestion level, etc.) that indicates the quality of BH links affected by BH link problems. - Fault aging (e.g., time elapsed since the problem was detected). For example, aging information that provides timing information about the moment a BH link problem was detected. Link problem time information may indicate the time between the detection of the link problem and the sending of the link failure notification.

[0144] In the example, IAB node 605 sends a link failure notification to the donor CU when it detects a problem with the BH link. In the example, IAB node 605 sends the link failure notification upon receiving a polling request from the donor CU.

[0145] The MT of an IAB node may send a link failure notification to the donor CU. For example, the MT of an IAB node may send a link failure notification in an RRC message such as the UEInformationResponse message or the MCGFailureInformation message as defined in 3GPP TS 38.331. See Figure 8 for other examples, which are provided below.

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

[0147] In another example, an IAB node's DU may send a link failure notification in an NR user plane protocol frame, such as the ASSISTANCE INFORMATION DATA frame specified in 3GPP TS 38.425. This frame is transmitted via the GTP-U protocol, more specifically, the “NR RAN Container” GTP-U extension header specified in TS 29.281.

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

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

[0150] An IAB node, such as IAB node 605 in the IAB network 600 in Figure 6, is configured in step 701 by an IAB donor, such as IAB donor 601, to distinguish between long-term and short-term BH link problems in the operating mode in state 702. IAB donor 601 configures IAB node 605 during the initial configuration process and may also configure or reconfigure IAB node 605 during the lifetime of the IAB network 600. For this reason, step 701 is shown as a dotted line in Figure 7.

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

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

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

[0154] In step 703, the IAB node (605) detects a BH link problem. Several different natures or categories of BH link problems may be considered and detected, as discussed below. Different categories may include different types of BH link problems, such as RLF type link problems (RLF on a BH link) or congestion type link problems (congestion affecting data transmission on a BH link). Different categories may also include different types of BH link problems and methods for detecting them. For example, one category is RLF detected by monitoring the quality of the link, and another category is RLF detected by a Type 2 RLF indication message. The link issues may relate to BH links between IAB node 605 and its parent IAB node (for example, if IAB node 602, the affected BH link is BH link 625), or to BH links between IAB node 605 and its child IAB node (for example, if IAB node 607, the affected BH link is BH link 657), or to BH links between the parent or child IAB node of IAB node 605 and other IAB nodes (for example, 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 RLF link problems for data transmission on a backhaul link involves monitoring the link quality of the backhaul link (e.g., by the MT or DU of IAB node 605) and detecting the backhaul RLF when the link quality falls below or reaches the RLF threshold. In other words, by monitoring the link quality, the MT or DU of the IAB node can directly detect RLF link problems. Alternatively, detection of RLF link problems for data transmission on a backhaul link involves IAB node 605 (e.g., in the MT of IAB node 605) receiving RLF indicator messages regarding the backhaul link and indicating an RLF or RLF recovery failure (e.g., a Type 2 or Type 4 RLF indicator message). RLF indicator messages may be transmitted by a parent IAB node (such as IAB node 602) or forwarded to IAB node 605 by a remote IAB node (two or three hops away). In other words, by receiving an RLF indication message, the IAB node can indirectly detect a problem with the RLF link.

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

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

[0158] For example, the IAB-MT may assume that a BH radio link or BH link is disconnected if the measured Reference Signal Receive Power (RSRP) falls below a predetermined threshold, or if decoding of either the Physical Downlink Control Channel (PDCCH) or Physical Downlink Shared Channel (PDSCH) fails due to insufficient power signal quality (e.g., low RSRP or low Reference Signal Receive Quality (RSRQ)). A person skilled in the art may discover other methods for detecting radio link failures in the IAB-MT.

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

[0160] For example, an IAB-DU may assume that a BH radio link or radio link is disconnected if the Signal-to-intererence-plus-Noise ratio (SINR) from a child IAB-MT falls below a predetermined threshold, or if it does not detect an acknowledgment message (e.g., no ACK or NACK) from a child IAB-MT on the Physical Downlink Shared Channel (PDSCH) (e.g., it does not receive it, or it receives it but cannot decode it). A person skilled in the art may discover other methods for detecting radio link failures in an IAB-DU.

[0161] In one example, the IAB-MT of IAB node 605 detects a BH radio link failure on the parent IAB's input BH link by receiving a radio link failure indication message from the parent IAB node in step 703. In one embodiment, 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 embodiment, this 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 IAB node 605 was relayed from another IAB node in the IAB network to its parent IAB node.

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

[0163] In one example, the IAB-MT on 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) by receiving a flow control feedback message from the child IAB-MT in step 703 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 was relayed by a child IAB node (such as IAB node 608).

[0166] In one example, a 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 methods for detecting congestion in IAB-DU and / or IAB-MT.

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

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

[0170] For example, a BH link recovery failure is related to the detection by the MT unit of the IAB node that the BH link was unable to recover from the previous RLF.

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

[0172] In one example, a BH link recovery failure is related to the detection by the DU unit of the IAB node that the BH link was unable to recover from the previous RLF.

[0173] For example, if an IAB-DU does not receive an acknowledgment of receipt following a PDU transmission after a certain period of time, it can be assumed that an RLF (Recovery Limit Failure) has occurred on the BH link and cannot be recovered.

[0174] In one example, a BH link recovery failure is related to the reception of a Type-4 RLF indication message by an IAB node (e.g., the MT unit of an IAB node) as discussed in step 703.

[0175] In one example, a BH link recovery failure is related to the reception of flow control feedback messages from a child IAB node (such as child IAB node 608) that indicate congestion affecting data transmission on a BH link (such as BH link 658 with IAB node 608) from an IAB node (e.g., by IAB-DU of an IAB node).

[0176] In one example, a BH link recovery failure is related to the IAB node (e.g., the IAB-DU of IAB node 605) receiving flow control feedback messages from a child IAB node (such as child IAB node 608) that indicate congestion affecting data transmission on the BH link (such as BH link 658 with IAB node 608), and the IAB-DU being unable to apply corrective measures to mitigate the congestion at the child IAB node.

[0177] If a BH link problem is detected (YES at the branch in step 704) relating to a BH link recovery failure (for example, a long-term type of cause), IAB node 605 determines whether the detected link problem will result in a long-term link problem (for example, whether one of the predetermined link problem criteria representing the cause or source of the long-term link problem is met), and triggers the 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 at the branch in step 704), IAB node 605 checks in step 705 whether the maximum number of consecutive BH link problems has been reached. In other words, IAB node 605 checks whether the number of detected consecutive link problems has reached or exceeded a threshold corresponding to the maximum number of consecutive BH link problems (for example, whether the cause is a long-term type cause). The maximum number can be an integer in the range of 3 to 10. For example, the maximum number can be an integer in the range of 4 to 8. For example, the maximum number can be 3 or 4.

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

[0180] When the counter is incremented and reaches the maximum number of continuous BH link problems (or a threshold) (or, if the counter is decremented, when the counter counts down from the maximum number of continuous BH link problems to zero), IAB node 605 determines that the detected link problem will result in a long-term link problem (for example, that one of the predetermined link problem criteria representing the cause or source of a long-term link problem has been met), and triggers a long-term BH link in step 707. This includes sending a link failure notification to the donor CU.

[0181] For example, one local BH link problem counter might relate to one category or nature of a BH link problem discussed in step 703. For instance, one BH link problem counter might be used to track a BH link problem associated with the reception of Type-2 RLF indication messages, while another BH link problem counter might be used to track a BH link problem associated with the detection of BH radio link faults in the input BH link with the 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 problem in that link was detected. In other examples, the category might depend on the type of link problem; that is, one local BH link problem counter might count detected RLF link problems, and another local BH link problem counter might count detected congestion problems.

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

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

[0184] In one example, IAB node 605 uses the ConsecutiveIssuesTimeWindow set by IAB donor 601 in step 701 as a sliding time window or link problem recovery time window of a predetermined length for managing the BH link problem counter. In such a case, the BH link problem counter is decremented (or incremented in the case of a countdown) each time a past BH link problem is no longer detected within the sliding time window. IAB node 605 checks whether the number of consecutive link problems detected during the sliding time window has reached or exceeded a threshold, and if the number of detected link problems has reached or exceeded the threshold, IAB node 605 determines that the detected link problem will result in a long-term link problem. 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 several hours. In one example, the length of the sliding time window can range from 2 seconds to 2 hours. In another example, the length of the sliding time window can range from 1 second to 10 hours. When using a sliding time window with a threshold, multiple link issues occurring over a long period (e.g., 10 days) are not considered long-term link issues, but multiple link issues occurring over a short period (e.g., 1 hour) are considered long-term link issues.

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

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

[0187] In one example, if IAB node 605 (for example, IAB-MT on IAB node 605) receives an RLF indicator message (Type-3 RLF indicator message) from its parent IAB node indicating that the previous BH RLF has been restored, the BH link problem is resolved.

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

[0189] For example, if IAB node 605 assumes that the BH radio link or BH link is no longer disconnected in relation to the disconnection conditions considered in step 703, then the BH link problem is recovered. For example, by monitoring the BH link quality of the BH link, if the BH link quality reaches or exceeds a recovery threshold, IAB-MT may assume that the BH link is no longer disconnected. For example, if the measured Reference Signal Receive Power (RSRP) reaches or exceeds a predetermined threshold, and demodulation of either the Physical Downlink Control Channel (PDCCH) or the Physical Downlink Shared Channel (PDSCH) is successful, IAB-MT may assume that the BH radio link is no longer disconnected.

[0190] For example, if the IAB-DU of IAB node 605 assumes that the BH radio link is no longer disconnected in relation to the disconnection conditions considered in step 703, the BH link problem is recovered. For example, by monitoring the BH link quality of the BH link, if the BH link quality reaches or exceeds a recovery threshold, the IAB-DU may assume that the BH link is no longer disconnected and has been recovered. For example, if the Signal-to-interference-plus-noise ratio (SINR) from the child IAB-MT reaches or exceeds a predetermined threshold, or if the IAB-DU detects an acknowledgment message (e.g., no ACK or NACK) from the child IAB-MT on the Physical Downlink Shared Channel (PDSCH), the IAB-DU may assume that the BH radio link or radio link is no longer disconnected. For example, if the IAB-MT or IAB-DU of IAB node 605 detects that there is no congestion due to a local buffer load not exceeding a certain level, the BH link problem is recovered.

[0191] When IAB node 605 receives a Type-4 RLF indication message from its parent IAB node in step 706 indicating a BH RLD recovery failure, IAB node 605 determines that the link problem it has detected will result in a long-term link problem (for example, one of the predetermined link problem criteria representing the cause or source of a 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 IAB node 605 determines in step 706 that the BH link problem detected in step 703 was not recovered quickly enough (for example, in response to determining that the detected link problem was not recovered within the recovery timeout period), IAB node 605 determines that the detected link problem will result in a long-term link problem (for example, one of the predetermined link problem criteria representing the cause or resource 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.

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

[0194] Figure 8 shows an exemplary message flow 800 for reporting a long-term link problem of the BH link from an IAB node 811 that has detected a BH link problem to an IAB donor CU, according to embodiments and examples of the present invention, as discussed above with reference to Figures 7 and 9.

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

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

[0197] In one example, message 802 embeds a BHLinkIssueInfo Information Element (IE) containing all or part of the following information for a given BH link problem detected according to the method described above for Figure 7 or 9: - BH Link information (identifies the BH link to which the link problem was detected). This BH Link information may include all or part of the following: 1) the BAP addresses of the IAB nodes at both ends of the BH Link, 2) Cell ID information (identifies the cell to which the BH Link belongs), 3) one or more RLC channel IDs (identifies one or more RLC channels affected by the detected problem), and 4) one or more BAP routing IDs (identifies BAP routing information (e.g., BAP address and Path ID) associated with the faulty BH link affected by the detected problem). - Long-Term BH Link Issue Indication Information (Indicates that a long-term failure 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 long-term link problems). This information may indicate BH link recovery failure, slow BH link recovery, or continuous (or recurring or recurring) BH link problems, as discussed above with reference to Figures 7 and / or 9. - Long-Term BH Link Issue Type of Cause Information (Refer to Figures 7 and / or 9 to show the type of cause of the long-term link problem discussed above (e.g., long-term or short-term cause)) - RLF Indication information (refer to Figures 7 and / or 9 to indicate long-term failures or link problems caused by BH radio link faults (RLFs) as discussed above) - Congestion Indication Information (Refer to Figures 7 and / or 9 to show long-term disruptions or link problems caused by congestion, as discussed above) - Link Quality Information (Indicates the quality of BH links affected by BH link problems, such as SINR and congestion level) - Ageing information (provides timing information regarding the moment of detection of BH link problems).

[0198] In one embodiment of the present invention, message 801 is a UEInformationRequest 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 an MCGFailureInformation message as defined in 3GPP TS 38.331.

[0200] In one embodiment of the present invention, message 802 is an SCGFailureInformation message as 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 MeasurementReport 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 identifies the NR user plane protocol as defined in 3GPP TS 38.425. The ASSISTANCE INFORMATION DATA frame is transmitted via the GTP-U protocol, more specifically by the “NR RAN Container” GTP-U extension header as defined in TS 29.281.

[0205] Figure 11 shows steps of method 1100 performed in a donor CU (also called 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) in an IAB network that includes multiple IAB nodes. The donor CU may be an 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, performed by a central processing unit 1011.

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

[0207] In step 1102, the donor CU determines, based on the received link failure notification, whether or not the routing configurations of all or some of the IAB nodes in the IAB network need to be reconfigured. In response to the determination that reconfiguration is necessary (YES at the branch in step 1102), the donor CU sends reconfiguration information to reconfigure the routing configurations of all or some of the IAB nodes (for example, by sending configuration information that updates the Backhaul Routing Configuration table as described above with reference to Figure 5a, and / or configuration information that updates some or all of that table as described with reference to Figures 5b to 5d).

[0208] Figure 10 shows a schematic diagram of an example of a communication device or station according to one or more embodiments and examples of the present disclosure.

[0209] The communication device 1000 may preferably be a microcomputer, a workstation, or a lightweight portable device. The communication device 1000 may preferably include a communication bus 1013 with connections to the following: - Central Processing Unit 1011 (e.g., microprocessor), referred to as CPU. - Memory for storing data and computer programs, including instructions for the operation of the communication device 1000. The computer program may include a number of different program elements or subroutines, which include instructions for various operations and for implementing the present invention. For example, the program elements may include elements for implementing BAP entities that route data packets between different MTs and DUs of IAB nodes and between different network nodes in the IAB network, as discussed above. - At least one communication interface 1002 connected to a wireless communication network 100 (for example, a wireless communication network conforming to 5G NR Release 16) on which digital data packets or frames or control frames are transmitted. Frames are written from the FIFO transmit memory of RAM 1012 to the network interface for transmission and read from the network interface for reception and writing to the FIFO receive memory in RAN 1012, under the control of a software application running on CPU 1011.

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

[0211] The central processing unit 1101 may be a single processor that performs the processing necessary for the operation of the communication device 1000, or it may include two or more processors. The number of processors and the allocation of processing functions to the central processing unit 1011 are design choices for those skilled in the art.

[0212] Memory may include the following: - A read-only memory 1007 (referred to as ROM) for storing a computer program for implementing the present invention. - Random access memory 1012 (referred to as RAM) for storing code that can execute the method according to one or more embodiments of the present invention, as well as registers suitable for recording variables and parameters necessary to implement the method according to one or more embodiments of the present invention.

[0213] If necessary, the communication device 1000 may also include the following components: - Data recording means 1004 (e.g., hard disk) for recording a computer program for implementing a method according to one or more embodiments of the present invention. - Disk drive 1005 for disk 1006, adapted to read data from disk 1006 or write data to that disk. - Screen 1009 for displaying decoded data and / or for providing a graphical interface with the user using the keyboard 1010 or any other pointing means.

[0214] Preferably, the communication bus provides communication and interoperability between various elements included in or connected to the communication device 1000. The representation of the bus is not limited, and in particular, the central processing unit can be operated to communicate commands to any element of the communication device 1000, either directly or through other elements of the communication device 1000.

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

[0216] The executable code may be recorded, as needed, in read-only memory 1007, hard disk 1004, or removable digital media (e.g., disk 1006 as described earlier). According to an optional variation, the code of the executable program may be received by the communication network 1003 via interface 1002 to be recorded in one of the storage means (e.g., hard disk 1004) of the communication device 1000 before execution.

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

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

[0219] Local rerouting can be effective in mitigating congestion and load balancing. Furthermore, local rerouting can be triggered by Type-2 RLF indications or hop-by-hop flow control notifications.

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

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

[0222] In this regard, long-term BH link issues may require IAB donors to reconfigure all or some of the routing settings of their IAB nodes.

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

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

[0225] To address the above issues, it is proposed to distinguish between short-term BH link problems that can be handled at the IAB node level, for example by applying local rerouting, and long-term BH link problems that require the reconfiguration of all or part of the topology at the IAB donor level.

[0226] BH link problems can result from radio link failures or congestion across multiple IAB nodes and may affect one or more BH links. Multiple causes can trigger long-term BH link problems (e.g., RLF recovery failures, or a series of RLF detection / RLF recovery, or a series of congestion detection / congestion recovery).

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

[0228] Therefore, when a long-term link problem is detected, the IAB node may notify the IAB donor of such a problem.

[0229] To enable IAB donors to apply efficient reconfigurations to resolve or at least mitigate this problem, IAB nodes may provide IAB donors with information about one or more BH links experiencing the BH link problem (e.g., BAP address, RLC Channel ID, or BAP routing ID) and information about the long-term cause of the BH link problem (e.g., recovery failure, recurring BH link problems). IAB nodes may also inform other IAB nodes whether the BH link problem was caused by an RLF or congestion phenomenon.

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

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

[0232] It is also suggested that IAB nodes may be able to inform IAB donors of the causes of long-term BH link problems (e.g., recovery failure, recurrent BH link problems).

[0233] It is also proposed that the IAB node may indicate whether the BH link problem resulted from RLF or congestion.

[0234] It is also proposed that IAB nodes may notify IAB donors of BH link problems using RRC or F1-AP messages.

[0235] While the present invention has been described with reference to embodiments, it should be understood that the present invention is not limited to the disclosed embodiments. 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 invention as defined in the appended claims. All of the functions disclosed herein (including any appended claims, abstract and drawings) and / or all of the steps of any disclosed methods or processes can be combined in any combination, except for any combination in which at least the functions and / or steps are mutually exclusive. Each of the functions disclosed herein (including any appended claims, abstract and drawings) can be replaced by alternative functions that serve the same, equivalent or similar purposes unless otherwise specified. Thus, unless otherwise specified, each of the disclosed functions is merely a general set of examples of equivalent or similar functions.

[0236] In the claims, the term “includes” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude the plural form. The mere fact that different features are enumerated in different dependent claims does not imply that a combination of those features cannot be used advantageously.

[0237] Reference numerals appearing in the claims are illustrative only and do not limit the scope of the claims.

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

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

[0240] For example, and not limited to, 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 used to store desired program code in the form of instructions or data structures and which can be accessed by a computer. Also, any connection is appropriately called a computer-readable medium. For example, if instructions are transmitted from a website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology (infrared, radio, and microwave), then coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology (infrared, radio, and microwave) are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals or other temporary media, but instead are directed toward non-temporary, tangible storage media. In this specification, the terms "disk" and "disc" include compact discs (CDs), laser discs, optical discs, digital multipurpose discs (DVDs), floppy discs, and Blu-ray discs, where a "disk" typically reproduces data magnetically, and a "disc" reproduces data optically using a laser. Any combination of the above should also be included within the scope of computer-readable media.

Claims

1. A method in an IAB (Integrated Access and Backhaul) node of an IAB network, The aforementioned IAB network includes a Donor Central Unit (CU), The aforementioned method, A step of detecting congestion affecting data transmission on the backhaul link of the IAB network, The process involves, after detecting the congestion, sending a notification to the donor CU that includes link identification information identifying the backhaul link, information indicating the detected congestion, and an RLC channel identifier identifying one or more Radio Link Control (RLC) channels congested on the backhaul link. A method that includes this.

2. The method according to claim 1, further comprising determining whether the detected congestion will result in long-term congestion, wherein transmitting the notification to the donor CU is a response to the determination that the detected congestion will result in long-term congestion.

3. Determining whether the detected congestion will result in a long-term link problem includes determining whether one of a plurality of predetermined congestion criteria is met based on the detected congestion, where each of the plurality of predetermined congestion criteria represents a respective factor of long-term congestion. Determining that the detected congestion will result in long-term congestion includes determining that a predetermined congestion criterion affecting data transmission on the backhaul link has been met. Sending the notification to the donor CU is a response to determining that a predetermined congestion criterion affecting data transmission on the backhaul link has been met. The method according to claim 2, wherein the information indicating the detected long-term congestion factors includes information indicating that the predetermined congestion criteria have been determined to be met.

4. The method according to claim 2, comprising determining whether the detected congestion will result in long-term congestion, confirming whether the detected congestion is related to a backhaul link recovery failure, and if the detected congestion is related to a backhaul link recovery failure, determining that the detected congestion will result in long-term congestion.

5. The method according to claim 4, further comprising determining whether the detected congestion will result in long-term congestion by checking whether the number of detected continuous congestion reaches a threshold corresponding to the maximum number of continuous congestion if the detected congestion is not related to a backhaul link recovery failure, and determining that the detected congestion will result in long-term congestion if the number of detected continuous congestion reaches the threshold.

6. The method according to claim 4, further comprising determining whether the detected congestion will result in long-term congestion by checking whether the number of continuous congestion detected during a congestion recovery time window of a predetermined length reaches a threshold if the detected congestion is not related to a backhaul link recovery failure, and determining if the number of detected congestion reaches the threshold, that the detected congestion will result in long-term congestion.

7. The method according to claim 5, further comprising determining whether the detected congestion will result in long-term congestion, determining whether the detected congestion will recover if the number of detected congestion does not reach the threshold, and determining that the detected congestion will result in long-term congestion in response to a determination that the detected congestion will not recover within the recovery timeout period, or in response to a determination of a backhaul link recovery failure.

8. The link identification information that identifies the aforementioned backhaul link is The unique addresses of the IAB nodes at both ends of the aforementioned backhaul link, The BAP address of the IAB node of the aforementioned backhaul link, A cell identifier that identifies the cell associated with the backhaul link, BAP routing identifier and The method according to claim 1, comprising at least one of the following.

9. The method according to claim 1, further comprising receiving a request for link information from the donor CU, wherein the transmission includes transmitting the notification in response to the received request.

10. The method according to claim 1, wherein the IAB node includes Mobile Termination (MT), and the MT of the IAB node is used to detect congestion affecting data transmission on the backhaul link and to transmit the notification to the donor CU.

11. The method according to claim 10, wherein the transmission includes the transmission of the notification in a Radio Resource Control (RRC) message by the MT of the IAB node.

12. The method according to claim 1, wherein the IAB node includes a Distributed Unit (DU), and the DU of the IAB node is used to detect congestion affecting data transmission on the backhaul link and to transmit the notification to the donor CU.

13. The method according to claim 12, wherein the transmission includes transmitting the notification in an F1 Application Protocol (F1-AP) layer message by the DU of the IAB node.

14. A method in a donor Central Unit (CU) of an Integrated Access and Backhaul (IAB) network including multiple IAB nodes, An IAB node receives a notification containing information indicating that congestion affecting data transmission on the backhaul links of the IAB network has been detected, and the notification includes link identification information that identifies the backhaul links, information that identifies the detected congestion, and RLC channel identifiers that identify one or more Radio Link Control (RLC) channels that are congested on the backhaul links. Based on the received notification, determine whether it is necessary to reconfigure the routing settings of all or some of the multiple IAB nodes. A method comprising sending reconfiguration information to reconfigure the routing settings of all or some of the plurality of IAB nodes in response to a decision that reconfiguration is necessary.

15. The link identification information that identifies the backhaul link is The unique addresses of the IAB nodes at both ends of the aforementioned backhaul link, The BAP address of the IAB node of the aforementioned backhaul link, A cell identifier that identifies the cell associated with the backhaul link, BAP routing identifier and The method according to claim 14, comprising at least one of the above.

16. The method according to claim 14, wherein receiving the notification includes receiving the notification in a Radio Resource Control (RRC) message from the Mobile Termination (MT) of the IAB node, or receiving the notification in an F1 Application Protocol (F1-AP) layer message from the Distributed Unit (DU) of the IAB node.

17. Information indicating the maximum number of continuous congestion detected for data transmission on the aforementioned backhaul link, Recovery timeout information indicating the maximum period between the time of detection of the congestion and the time of recovery from the detected congestion, A congestion recovery time window having a predetermined length and being a period during which the maximum number of continuous congestion events can be detected, The method according to claim 14, further comprising transmitting backhaul link failure configuration information, including the above, to the plurality of IAB nodes via the CU.

18. An IAB (Integrated Access and Backhaul) node in an IAB network, A donor Central Unit (CU) and at least one communication interface for communicating with at least one other IAB node in the IAB network, A central processing unit coupled to at least one communication interface and configured to perform the method according to claim 1, IAB nodes including this one.

19. A donor Central Unit (CU) in an IAB (Integrated Access and Backhaul) network that includes multiple IAB nodes, At least one communication interface, A central processing unit coupled to at least one communication interface and configured to perform the method according to claim 14, Donor CUs including this one.

20. A computer program, wherein when the computer program is executed by a computer, the computer program causes the computer to execute the method according to claim 1.

21. A computer-readable storage medium on which the computer program described in claim 20 is stored.

Images