Improvements related to failure modes in multi-hop networks

Abstract

The present disclosure relates to a communication method and system for converging a 5G communication system that supports a higher data rate than a 4G (4th-Generation) system using Internet of Things (IoT) technology. The present disclosure can be applied to intelligent services based on 5G communication technology and IoT-related technology, such as smart homes, smart buildings, smart cities, smart cars, connected cars, healthcare, digital education, smart retail, security, and safety services. A fault recovery method for defining a route in a multi-hop network having multiple nodes is disclosed, the method comprising the steps of: determining that a fault exists between two nodes (B, C) among the multiple nodes; and performing a hierarchical fault recovery process.

Description

Technology Field

[0001] The present invention relates to a multi-hop network. In particular, the present invention relates to a multi-hop network of a telecommunication system. More specifically, the present invention relates to an improvement in fault recovery in an Integrated Access and Backhaul (IAB) system of a telecommunication network used in a 5G (Fifth Generation) or NR (New Radio) system. Background Technology

[0002] Efforts are being made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic following the establishment of 4G communication systems. For this reason, 5G or pre-5G communication systems are referred to as 'Beyond 4G networks' or 'Post-LTE systems'. 5G wireless communication systems are considered to be implemented in higher frequency (mmWave) bands (e.g., the 60 GHz band) to achieve higher data transmission rates. To reduce radio wave propagation loss and increase transmission distance, technologies such as beamforming, massive MIMO, full Dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antennas are being discussed for 5G communication systems. In addition, to improve the system network, technologies such as advanced small cell, cloud radio access network (cloud RAN), ultra-dense network, device-to-device (D2D) communication, wireless backhaul, mobile network, cooperative communication, Coordinated Multi-Points (CoMP), and receiver interference cancellation are being developed in 5G communication systems.In 5G systems, advanced coding modulation (ACM) technologies such as FQAM (hybrid frequency shift keying and quadrature amplitude modulation) and SWSC (sliding window superposition coding), as well as advanced access technologies such as FBMC (filter bank multi carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed.

[0003] The Internet, a human-centered connectivity network where humans generate and consume information, is now evolving into the Internet of Things (IoT), where distributed entities such as objects exchange and process information without human intervention. The Internet of Everything (IoE) has emerged, combining IoT technology with big data processing technology through connections with cloud servers. As technological elements such as "sensing technology," "wired / wireless communication and network infrastructure," "service interface technology," and "security technology" are required for IoT implementation, research on sensor networks, Machine-to-Machine (M2M) communication, and Machine Type Communication (MTC) is currently underway. This IoT environment can provide intelligent Internet technology services that create new value in human life by collecting and analyzing data generated between connected objects. Through the convergence and integration of existing Information Technology (IT) with various industrial applications, IoT can be applied to diverse fields such as smart homes, smart buildings, smart cities, smart or connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0004] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, Machine Type Communication (MTC), and Machine-to-Machine (M2M) communication can be implemented using beamforming, MIMO, and array antennas. Additionally, the application of cloud radio access networks (RAN) as the aforementioned processing technology can be considered an example of convergence between 5G technology and IoT technology.

[0005] In conventional technology for IABs, several architectural reference models using a CU / DU (Central Unit / Distributed Unit) partitioned architecture have been proposed. To enable hop-by-hop forwarding between IAB nodes, an adaptation layer to be introduced into the User Plane (UP) of IAB nodes (both donors and relays) containing routing and bearer mapping information across hops has been proposed. According to the current proposal, the current UP adaptation layer is complemented by a Control Plane (CP) corresponding module that determines bearer mapping / path management by updating mapping tables within the UP adaptation layer headers. Alternatively, control signaling may be transmitted using UP, i.e., DRB (Data Radio Bearer). For reference, the literature regarding data routing between IAB nodes is as follows: SONY CORPORATION: "COMMUNICATIONS SYSTEM, INFRASTRUCTURE EQUIPMENT, COMMUNICATION TERMINAL AND METHOD", US 2016 / 0212706 A1 (2016-07-21) QUALCOMM Incorporated: "TRAFFIC FLOW MIGRATION IN BACKHAUL NETWORKS", US 2017 / 0006499 A1 (2017-01-05) AT&T Intellectual Property I, LP: "INTEGRATED ACCESS BACKHAUL UNDER A NON-STANDALONE NETWORK ARCHITECTURE FOR 5G OR OTHER NEXT GENERATION NETWORK", US 2019 / 0223002 A1 (2019-07-18)LG Electronics Inc: "METHOD AND APPARATUS TO SUPPORT MOBILITY IN LWA", US 2020 / 0100212 A1 (2020-05-26) The problem to be solved

[0006] There are issues in managing communication failures between nodes, and it is desirable to be able to recover quickly from individual node failures without negatively impacting other nodes in the system or significantly increasing signaling overhead across the entire system. means of solving the problem

[0007] Embodiments of the present invention solve node failure problems in multi-hop networks.

[0008] According to the present invention, the apparatus and method described in the appended claims are provided. Other features of the present invention will become apparent from the dependent claims and the following description.

[0009] According to one aspect of the present invention, a fault recovery method for defining a route in a multi-hop network having a plurality of nodes is provided, the method comprising the steps of: determining that a fault exists between two nodes (B, C) among the plurality of nodes; and performing a hierarchical fault recovery process. An embodiment of the present invention essentially attempts to resolve the problem by using the nodes that were in use immediately before the failure occurred. If this is not possible, one or more additional nodes are progressively used to bypass the failed link and rebuild the route. This is what is meant by "hierarchical" in this context.

[0010] In one embodiment, failure recovery includes finding an alternative path or performing another bearer mapping for one or more existing paths.

[0011] In one embodiment, the hierarchical failure recovery process includes the step of attempting to recover from the failure using only the nodes that are active in the route at the time the failure is determined.

[0012] In one embodiment, the hierarchical fault recovery process includes the step of routing data through an adjacent node (E) that can communicate with two nodes (B, C) that are in between. This step and the preceding step may be performed in any order as needed. While it may be preferable to attempt the preceding step first before configuring the adjacent node, this can be implemented as required by the network designer or operator.

[0013] In one embodiment, the hierarchical fault recovery process includes the step of routing data from an adjacent node (E) to a second node (C) among two nodes (B, C) that are in between, through an additional non-adjacent node (F).

[0014] In one embodiment, the hierarchical fault recovery process includes the step of performing an end-to-end route recalculation to bypass the link between two nodes (B, C) that are in between.

[0015] In one embodiment, the multi-hop network is an Integrated Access and Backhaul (IAB) network in a telecommunications network.

[0016] In one embodiment, high-speed bearer reconfiguration is triggered based on one or more of the following criteria:

[0017] A1 If the expected or estimated change in link quality is below a specific threshold;

[0018] If the QoS of the UE bearer delivered by the CU prior to A2 can be maintained;

[0019] If the QoS loss of UE bearers delivered by the A3 CU can be maintained within predetermined limits;

[0020] A4 When the number of new backhaul bearers can be kept below a defined threshold;

[0021] A5 If the new set of DRBs has characteristics similar to the previous set of DRBs; or

[0022] A6 When the signaling overhead change is within the agreed limits.

[0023] In one embodiment, adjacent nodes (E) are selected based on one or more of the following criteria:

[0024] Requirements for forming DRBs between nodes so that B1 CU satisfies QoS requirements for UE bearers shared by B1 CU;

[0025] B2 Expected change in latency, determined based on historical information regarding the number of new hops and / or the latency of individual hops;

[0026] B3 Loading of adjacent nodes (E) indicated by feedback from neighboring nodes.

[0027] In one embodiment, end-to-end route recalculation is performed by CU(A).

[0028] In one embodiment, CU(A) caches preferred alternative routes in one or more DUs (B, G), along with conditions that must be satisfied for them to be used without triggering messages for CU(A).

[0029] In one embodiment, the QoS information provided by CU(A) includes an expiration timestamp after the time when a route recalculation message for CU(A) is required.

[0030] In one embodiment, the hierarchical failure recovery process includes the incremental addition of additional nodes as needed to complete the route.

[0031] In one embodiment, the first step includes the addition of zero additional nodes, and has additional steps for adding nodes as needed up to a final step in which a complete end-to-end route recalculation is performed.

[0032] In one embodiment, a network comprising a plurality of nodes is provided, and the network may operate to perform the method of any one of the aforementioned claims.

[0033] In general, the steps of a hierarchical process may be performed in any order and may be initiated from any one of the steps. The order presented herein is merely an example and suggests a logical means of escalation, but is by no means intended to be a limitation.

[0034] Hop-by-hop forwarding between adjacent IAB nodes as described above relies on the NR Uu interface. In embodiments of the present invention, triggers for connecting / initiating path management are defined.

[0035] These include one or more of the following:

[0036] ㆍ Changes in bearer mapping information (e.g., based on changes in channel state between IAB nodes);

[0037] ㆍ Topology change (new node / connection established);

[0038] Changes in network loading / congestion levels.

[0039] The range, physical location, and period of the above-mentioned changes may have different effects on the stability of routing / bearer mapping information through the network, all of which are taken into account in the embodiments of the present invention. Effects of the invention

[0040] Because route management (CP function) is centralized, if a decision is made to change the route even slightly, in conventional technology, a fully updated mapping table is generally transmitted to the entire set of DUs, including the donor DU. However, by applying triggers according to embodiments of the present invention based on Quality of Service (QoS) information already shared with the DUs, the DUs can locally change the UE bearer to an IAB bearer mapping, thereby enabling faster mapping changes without the intervention of the CU.

[0041] Embodiments of the present invention demonstrate how allowing route management in the DUs of different IAB nodes enables processing various changes in the aforementioned environment with less impact on route change latency, while producing faster mapping change operations regardless of CU intervention. The triggers defined in the embodiments of the present invention help to achieve this.

[0042] More specifically, embodiments of the present invention relate to hierarchical fault evaluation, notification, and signaling between corresponding CP-adaptation layers to implement such changes or updates as needed after dynamically determining the scope of necessary bearer mapping changes or route updates.

[0043] Generally, the CU determines the mapping between the UE DRBs and the inter-node DRBs for the entire path to the IAB node to which the UE is connected. The CU provides the mapping tables and QoS parameters to the DU. Embodiments of the present invention relate to a method for determining when high-speed bearer reconfiguration may be triggered and how it is implemented. Brief explanation of the drawing

[0044] Although some preferred embodiments of the present invention have been illustrated and described, those skilled in the art will understand that various changes and modifications may be made without departing from the scope of the invention as defined in the appended claims. For a better understanding of the present invention and to show how embodiments of the present invention can be implemented, reference will now be made to the attached schematic drawings merely as examples. FIG. 1 illustrates a schematic diagram of a network illustrating a partial link failure between two nodes according to an embodiment of the present invention. FIG. 2 illustrates a schematic diagram of a network illustrating a total link failure between two nodes according to an embodiment of the present invention. FIG. 3 illustrates a schematic network diagram illustrating partial path recovery according to an embodiment of the present invention. FIG. 4 illustrates a schematic network diagram illustrating end-to-end route recalculation and recovery according to an embodiment of the present invention. FIG. 5 illustrates a flowchart illustrating a method according to one embodiment of the present invention. Specific details for implementing the invention

[0045] Embodiments of the present invention provide a hierarchical management approach for the failure of all or part of a link between nodes. This approach allows for the handling of as many minor local problems as possible through a stepwise escalation that includes a full recalculation of the route only if previous alternatives have failed to re-establish the entire route. Several steps of this hierarchical approach are schematically illustrated in FIGS. 1 through 4, which show various approaches to handling a break between two nodes in a multi-hop network.

[0046] One variant of the present invention applies when a partial link failure is detected between one source IAB node and another sink IAB node. This applies when the expected / estimated change in link quality is below a specific threshold (e.g., measured by channel quality feedback from the sink to the source); and / or when the QoS of UE bearers previously delivered by the CU can be maintained; and / or when the QoS loss of UE bearers delivered by the CU can be maintained within predetermined limits; and / or when the number of new backhaul bearers can be maintained below a specific threshold; and / or when the set of new DRBs has "similar" characteristics to the set of previous DRBs (one similarity metric may be latency and throughput requirements; an improvement thereto is that similarity only needs to be applied to specific QoS-sensitive traffic rather than best-effort traffic). And / or if the change in signaling overhead is within agreed limits, fast bearer reconfiguration between sink / source nodes is triggered, affecting only the bearer mapping between the two. In an improvement to this embodiment, fast bearer reconfiguration is triggered based on the type of traffic transmitted by UE bearers—for example, if the traffic is latency critical.

[0047] FIGS. 1 through 4 illustrate a typical multi-hop network topology used in an IAB. Node A is the central unit (CU). It is a controller for two distributed units (DU) (nodes B and G). Nodes C, D, E, F, and H are IAB nodes. The intent of each figure is to allow data traffic to flow from node A to node D through the configured nodes.

[0048] FIG. 1 illustrates a scenario in which a partial link failure is detected between one source IAB node (B) and another sink IAB node (C). In this scenario, basically four active nodes (A, B, C, and D) are involved in the communication. Although other nodes (E, F, G, and H) shown may carry other data traffic, they are not referred to as active nodes here because they do not form part of the multi-hop network of interest.

[0049] In this case, fast bearer reconfiguration is triggered between the sink / source nodes, affecting only the bearer mapping between the two nodes without broader network involvement. In an additional embodiment, fast bearer reconfiguration is triggered based on the type of traffic transmitted by the UE bearer—for example, if the traffic is latency critical.

[0050] To trigger high-speed bearer reconstruction, one or more of the following may be detected:

[0051] A1 If the expected or estimated change in link quality is below a specific threshold (e.g., measured by channel quality feedback from the sink to the source);

[0052] If the QoS of UE bearers delivered by CU prior to A2 can be maintained;

[0053] If the QoS loss of UE bearers delivered by the A3 CU can be maintained within predetermined limits;

[0054] A4 When the number of new backhaul bearers can be maintained below a specific threshold;

[0055] A5. When a new DRB set has "similar" characteristics to a previous DRB set. One similarity metric relates to latency and throughput requirements, and the improvement is that the similarity requirement applies only to specific QoS-sensitive traffic, rather than best-effort traffic.

[0056] A6 When the signaling overhead change is within the agreed limits.

[0057] FIG. 2 illustrates a scenario in which there is a total link failure (disruption) between one source IAB (B) node and another node (C), and a high-speed local recovery message is triggered from the source node (B) to one adjacent node (E) to establish a connection between the source node and the sink nodes. The selection of the "new" intermediate node (E) may be determined according to an embodiment of the present invention by one or more of the following:

[0058] Requirements for forming inter-node DRBs to satisfy QoS requirements for UE bearers shared by B1 CU;

[0059] B2 Expected change in latency determined using historical information regarding the number of new hops and / or the latency of individual hops;

[0060] B3 Loading of a new node indicated by feedback from neighboring nodes.

[0061] Therefore, this approach affects only local bearer mapping between nodes adjacent to the source. In an improvement to this embodiment, throughput and latency trade-offs caused by various expected topology and link quality variations are calculated offline and cached locally, and thus can be used as a lookup table when determining whether the source node will trigger high-speed local recovery.

[0062] In Figure 2, the active nodes are A, B, E, C, and D.

[0063] In further improvements, a scenario is assumed in which high-speed local recovery is applied only to a subset of incoming DRBs, while for other DRBs (e.g., those that cannot satisfy some or all of the requirements listed above), an end-to-end route recalculation message is triggered to the CU. For additional details, refer to the content related to Figure 4 below.

[0064] FIG. 3 illustrates a scenario in which, when a failure between nodes B and C cannot be resolved locally (e.g., because the conditions listed above in relation to FIG. 2 cannot be satisfied), a partial path recovery message is triggered to establish a path between a source node and a sink node by affecting the bearer mapping between two nodes adjacent to the source (B) and at least one non-adjacent node (F). As can be seen here, this path is recovered through nodes E and F, where node E cannot directly form a link to node C, but node E can form a link to node F, and node F can form a link to node C. Thus, traffic originally intended to travel directly from node B to node C now follows a path from node B to node E, node F, and node C.

[0065] This approach requires the use of non-adjacent nodes, and since additional nodes are now included compared to the scenario illustrated in Figure 2, additional hop delay occurs.

[0066] In Fig. 3, the active nodes are A, B, E, F, C, and D.

[0067] FIG. 4 illustrates a scenario in which, when a failure cannot be resolved by partial path recovery as illustrated in FIG. 3, an end-to-end route recalculation message is triggered toward any location where a CU, or route / path management controller, resides. This affects at least all nodes on the route. Generally, in the prior art, this was the only or preferred option, and the CU typically provides relevant mapping tables and QoS parameters to the DU to form the route. By performing end-to-end route recalculation, the failed link (in this example, the link between B and C) is excluded from the calculation. Nodes (B and C) where the failed link exists are not necessarily excluded if they can be used to form a route by avoiding the failed link.

[0068] In Fig. 4, the active nodes are A, G, H, and D.

[0069] In the improvement of this embodiment, the CU can cache the conditions that must be satisfied for it to be used without triggering messages for the CU, and various preferred alternatives of the DU. This provides some autonomy to network elements and can reduce signaling overhead.

[0070] In an additional embodiment, QoS information shared by CU(A) may have an expiration timestamp, after which a route recalculation message for CU(A) must be triggered.

[0071] FIG. 5 is a flowchart illustrating a method according to one embodiment of the present invention and clearly showing the hierarchical characteristics of the embodiments of the present invention.

[0072] This process starts at S10, and at S20, the relay nodes and route search process are initialized in a known manner.

[0073] In S30, a test is performed to determine whether a partial link failure has occurred (as shown in FIG. 1). This can be detected when one of the previously defined triggers A1 to A6 is detected.

[0074] If one of these triggers is detected, high-speed bearer reconstruction begins in step S40, and data traffic continues to flow from Node B to C, although, for example, the data processing speed may differ.

[0075] In step S50, a check is performed to determine whether a full link outage has occurred between nodes B and C (shown in FIG. 2). If positive, a high-speed local recovery message is triggered from the source node (B) to (at least) one adjacent node (E). In this case, local path recovery is initiated in step S60 by including the adjacent node (E) in a multi-hop network to be interposed between nodes B and C.

[0076] In step S70, a check is performed to determine whether there is a total local interruption (as illustrated in FIG. 3). This is triggered by a partial path recovery message in the response from the adjacent node (E) to the source node (B), indicating that the non-adjacent node (F) is the only path toward node C and then D. This affects the bearer mapping between the two nodes adjacent to the source (B) and at least one non-adjacent node (F) to establish a path between the given source and sink nodes.

[0077] In this case, partial path recovery is initiated at step S80, and accordingly, non-adjacent nodes (F) are introduced so that data traffic flows from node B to node E and to node C. This introduces additional nodes beyond those introduced in the previous step.

[0078] In step S90, a check is performed to determine whether there has been a complete path interruption. This is initiated based on a notification from Node B to Node A attributable to the discovery of an interruption in any path toward Node D (i.e., via C or E).

[0079] In step S100, to avoid the identified problematic nodes, a full end-to-end recalculation is performed at node A as a CU. In this case, data traffic is rerouted through nodes G and H, and accordingly, traffic flows from A to D.

[0080] A feature of the embodiments of the present invention is that attempts are made to solve the problem locally as much as possible. Neighboring nodes are used only when this is not possible, then non-neighboring nodes are used, and finally the route is completely recalculated. This has the effect of minimizing signaling and ensuring fast resolution.

[0081] In this description, the term 'route' is used to denote an interconnection between a source and a sink. Specifically, the routes represent, for example, ABCD in FIG. 1, ABECD in FIG. 2, ABEFCD in FIG. 3, and AGHD in FIG. 4. Thus, while the source and sink are the same in each case, the routes differ depending on the nodes being used.

[0082] The term 'path' is used to denote a subset of routes and generally refers to local rerouting that allows routes to be preserved as much as possible without the need to perform full end-to-end route recalculation (see Fig. 4).

[0083] At least some of the exemplary embodiments described herein may be constructed in part or wholly using dedicated special-purpose hardware. Terms such as 'component,' 'module,' or 'unit' as used herein may include, but are not limited to, hardware devices such as circuits in the form of discrete or integrated components, Field Programmable Gate Arrays (FPGAs), or Application Specific Integrated Circuits (ASICs) that perform specific tasks or provide related functions. In some embodiments, the described elements may be configured to reside in a tangible, persistent, and addressable storage medium and may be configured to execute on one or more processors. In some embodiments, these functional elements may include, for example, software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. Although exemplary embodiments have been described with reference to the components, modules, and units discussed herein, these functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be understood that the described features may be combined in any suitable combination. In particular, features of any exemplary embodiment may be appropriately combined with features of any other embodiment, except where such combinations are mutually exclusive. Throughout this specification, the terms “comprising” or “comprising” mean including the specified component(s) but not excluding the presence of other components.

[0084] In connection with this application, attention should be paid to all documents and literature that are submitted simultaneously with or prior to this specification and are subject to public examination together with this specification, the contents of all such documents and literature are incorporated by reference into this specification.

[0085] All features disclosed in this specification (including the appended claims, summary, and drawings) and / or all steps of any method or process disclosed herein may be combined in any combination, except for at least some of these features and / or steps being mutually exclusive combinations.

[0086] Each feature disclosed herein (including the appended claims, abstract, and drawings) may be replaced by an alternative feature that provides the same, equivalent, or similar purpose, unless otherwise expressly stated. Accordingly, unless otherwise expressly stated, each disclosed feature is merely an example of a general series of equivalent or similar features.

[0087] The present invention is not limited to the details of the foregoing embodiment(s). The present invention extends to any novel feature or any novel combination of the features disclosed herein (including the appended claims, summary, and drawings), or any novel step or any novel combination of the steps of any method or process disclosed herein.

Claims

Claim 1 A method for a first IAB (integrated access and backhaul) node in a mobile communication system, comprising: receiving from a CU (central unit) a first setting for a first path for data routing to a destination and a second setting for a second path for data routing to the destination; obtaining data to be routed to the destination; identifying the second IAB node associated with the first path for data routing to the destination based on information associated with the second IAB node included in the first setting and a mapping between the first path; if a link failure is detected for a link between the first IAB node and the second IAB node, selecting the third IAB node associated with the second path for data routing to the destination based on information associated with the third IAB node included in the second setting and a mapping between the second path; and routing the data to the third IAB node. Claim 2 A method of a first IAB node according to claim 1, wherein the first setting and the second setting are received through an interface between the DU (distributed unit) of the first IAB node and the CU, and the third IAB node corresponds to the next hop on the second path. Claim 3 A method of a first IAB node according to claim 1, further comprising the step of selecting a bearer corresponding to a link between the first IAB node and the third IAB node. Claim 4 A method of a first IAB node according to claim 3, characterized in that at least one channel is configured for the selected bearer based on QoS (quality of service) requirements. Claim 5 A method of a first IAB node according to claim 1, wherein the link failure is detected based on one or more of the following: A1 when the planned or measured change in link quality is below a threshold; A2 when the quality of service (QoS) of a bearer previously communicated by the CU can be maintained; A3 when the loss of the QoS of the bearer previously communicated by the CU is maintained within a preset limit; A4 when the new number of backhaul bearers is maintained below a defined threshold; A5 when a new set of data radio bearers (DRB) has the same characteristics as a previous set of DRBs; or A6 when the change in signaling overhead is within an agreed limit. Claim 6 A first IAB (integrated access and backhaul) node in a mobile communication system, wherein the first IAB node receives from a CU (central unit) a first configuration for a first path for data routing to a destination and a second configuration for a second path for data routing to the destination, obtains data to be routed to the destination, identifies the second IAB node associated with the first path for data routing to the destination based on information related to the second IAB node included in the first configuration and a mapping between the first path, and when a link failure is detected for a link between the first IAB node and the second IAB node, selects the third IAB node associated with the second path for data routing to the destination based on information related to the third IAB node included in the second configuration and a mapping between the second path, and includes an adaptation layer of a user plane for routing the data to the third IAB node. Claim 7 In claim 6, the first setting and the second setting are received through an interface between the DU (distributed unit) of the first IAB node and the CU, and the third IAB node corresponds to the next hop on the second path, characterized in that the first IAB node is a first IAB node. Claim 8 In claim 6, the first IAB node is characterized in that the adaptation layer of the user plane controls the selection of a bearer corresponding to the link between the first IAB node and the third IAB node. Claim 9 In claim 8, the first IAB node is characterized in that at least one channel is configured for the selected bearer based on QoS (quality of service) requirements. Claim 10 A first IAB node characterized in that, in claim 6, the link failure is detected based on one or more of the following: A1 when the planned or measured change in link quality is below a threshold; A2 when the quality of service (QoS) of the bearer previously communicated by the CU can be maintained; A3 when the loss of the QoS of the bearer previously communicated by the CU is maintained within a preset limit; A4 when the new number of backhaul bearers is maintained below a defined threshold; A5 when a new set of data radio bearers (DRB) has the same characteristics as the previous set of DRBs; or A6 when the change in signaling overhead is within an agreed limit. Claim 11 delete Claim 12 delete Claim 13 delete Claim 14 delete Claim 15 delete

Images