DYNAMIC ROUTE SELECTION IN INTEGRATED ACCESS AND BACKHAUL SYSTEMS

Abstract

A method comprising receiving, by at least one integrated access and backhaul node and a donor distributed unit, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology. The method further includes sending at least one link event notification, and receiving at least one link event notification. The method also includes adapting at least one of the uplink route and the downlink route based on the preference information and at least one link event notification.

Description

Description DYNAMIC ROUTE SELECTION IN INTEGRATED ACCESS AND BACKHAUL SYSTEMS Invention Engineering Field The description in accordance with exemplary embodiments of the present invention relates generally to integrated access and backhaul networks. More specifically, the description in accordance with exemplary embodiments relates to routing in an integrated access and backhaul system. Background of the Invention 3GPP defines standards and specifications for NR Integrated Access and Backhaul (e.g., via TR38.874). Various layer 2 (L2) and layer 3 (L3) based solutions have been proposed in RAN2 / RAN3 meetings. In L2 based solutions, the IAB node contains the DU and packets are forwarded by the radio layers (below PDCP). In L3 based solutions, the IAB node contains the DU and / or gNB, and packets are forwarded to layers above PDCP. In both cases, the IAB nodes perform hop-by-hop routing to maintain connectivity between the MT serving the IAB and the Donor node. An MT or IAB can have multiconnectivity to multiple IABs or donors, so more than one path can exist at any given time. Multi-hop backhauling provides greater range than single-hop backhauling. This is particularly beneficial for backhauling at frequencies above 6GHz due to limited range. Multi-hop backhauling further enables backhauling around obstacles, such as buildings and other clutter in urban environments where line-of-sight between nodes is obstructed. Certain abbreviations that may be found in the description and / or in the Drawings are hereby defined as follows: AMF Access and Mobility Management Function ARQ Automatic Retry Request AUSF Authentication Server Function CU Central Unit (from RAN) Dual Connectivity DC Distributed Unit DU F1AP Fronthaul Application Protocol (F1) gNB Node B enhanced 5G (Transmitter) GTP GPRS Tuning Protocol HARQ Hybrid Auto-Repeat Request IAB: Integrated Access and Backhaul IAB MT (IAB UE node): MT function on IAB node IAB DU (IAB node DU): The gNB DU function on the IAB node LTE Long-term evolution MEC Multi-access edge computing MCG Master Cell Group MME Mobility Management Entity MT Mobile Termination NCE Network Control Element NF Network Function NG-AP Next Generation Application Protocol NGC Next Generation Core New NR Radio Network N / W PCI Physical Cell ID PDCP Packet Data Convergence Protocol Protocol Data Unit PDU RAN Radio Access Network RLC Radio Link Control PRC Radio Resource Control RRM Radio Resource Management SCG Secondary Cell Group SMF Session Management Function Secondary Node SN TM Topology Management TRP Total radiated power UDM User Data Management UDP User Datagram Protocol EU User Equipment UPF User Field Function 5G Fifth generation cellular communication system Brief Description of the Invention The following summary includes examples and is intended for illustrative purposes only. This summary is not intended to limit the scope of the claims. In accordance with one aspect, an example method comprises receiving, by at least one integrated access and backhaul node and a donor distributed unit, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology. The method further includes sending at least one link event notification, and receiving at least one link event notification. The method also includes adapting at least one uplink route and a downlink route based on the preference information and at least one link event notification. In accordance with another aspect, an example method comprises receiving, by at least one integrated access and backhaul node and a donor distributed unit, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology, sending at least one link event notification, receiving at least one link event notification, and adapting at least one uplink route and downlink route based on the preference information and at least one link event notification. In accordance with another aspect, an example apparatus comprises means for configuring, by at least one donor central unit, at least one of at least one donor distributed units and at least one integrated access and backhaul node with route information to reach at least one mobile terminal and at least one donor, means for configuring at least one of at least one donor distributed units and at least one intermediate integrated access and backhaul node with preference information; and means for transmitting the route information and preference information to at least one branch node and at least one integrated access and backhaul node. In accordance with another aspect, an example apparatus comprises means for receiving, at at least one branch node, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology; means for generating at least one link event notification; means for receiving at least one link event notification; and means for adapting at least one of the uplink route and the downlink route based on the route preference and at least one link event notification. Short Description of Image The above and other aspects of the embodiments of the present invention are made more apparent in the following Detailed Description, when read in conjunction with the accompanying Drawings, wherein: Figure 1 is a block diagram of one possible and unlimited example system in which the example embodiments may be practiced; Figure 2 shows an illustration of an example of backhauling for multi-hops; Figure 3 shows an illustration of example scenarios for routing packets in an IAB node topology; Figure 4 (which includes Figure 4A and Figure 4B) is an illustration of an example of improved route selection in an integrated access and backhaul system; Figure 5 shows a method according to an exemplary embodiment that can be carried out with the apparatus; and Figure 6 shows another method according to an exemplary embodiment that can be carried out with the apparatus. Complete Description of the Invention In exemplary embodiments as described herein, the methods and apparatus provide dynamic route selection in an integrated access and backhaul system. Turning to Figure 1, this figure shows a block diagram of one possible and non-limiting example system in which an exemplary embodiment may be practiced. In Figure 1, a mobile terminal (MT) (110) is in wireless communication with a wireless network (100). An MT is a wireless device, typically mobile, capable of accessing a wireless network. The MT (110) includes one or more processors (120), one or more memories (125), and one or more transceivers (130) interconnected via one or more buses (127). Each of the one or more transceivers (130) includes a receiver (Rx) (132) and a transmitter (Tx) (133). The one or more buses (127) may be an address, data, or control bus, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The one or more transceivers (130) are connected to one or more antennas (128).One or more memories (125) include computer program code (123). One or more memories (125) and computer program code (123) may be configured, with one or more processors (120), to cause the MT (110) to perform one or more operations as described herein. The MT (110) communicates with the device (170) via a wireless link (111). The device (170) may be either a donor IAB node (220) or an IAB node (12) in Figure 2 for example. In this example the transmitter (170) has gNB features or components. The wirelessly attached IAB node, the Donor IAB node, and the conventional gNB may be implemented on identical hardware or may include different hardware, but some core components such as processors, memories, receivers, and transmitters reside in each.Figure 1 is only intended to show a simplified version of some of the components of an IAB node, an IAB Donor node, and a conventional gNB, but it is understood that there are differences between a wireless IAB node and an IAB Donor / gNB node. The gNB (170) is a transmitter (e.g., for 5G / LTE) that provides access by a wireless device such as an MT (110) to a wireless network (100). The gNB (170) includes one or more processors (152), one or more memories (155), one or more network interfaces (N / WI / F) (161), and one or more transceivers (160) interconnected via one or more buses (157). Each of the one or more transceivers (160) includes a receiver (Rx) (162) and a transmitter (Tx) (163). The one or more transceivers (160) are connected to one or more antennas (158). The one or more memories (155) include computer program code (153). One or more memories (155) and computer program code (153) are configured to, by one or more processors (152), cause the gNB (170) to perform one or more operations as described herein. One or more network interfaces (161) communicate over a network such as via links (176) and (131).Two or more gNBs (170) communicate using, for example, a link (176). The link (176) may be wired or wireless or both and may be implemented using, for example, an X2 or Xn interface. One or more buses (157) may be address, data, or control buses, and may include any interconnection mechanism, such as a set of lines on a motherboard or integrated circuit, fiber optic or other optical communication equipment, wireless channels, and the like. For example, one or more transceivers (160) may be implemented as a remote radio header (RRH) (195), with other elements of the gNB (170) physically located at different locations from the RRH, and one or more buses (157) may be implemented in part as fiber optic cables to connect other elements of the gNB (170) to the RRH (195). It should be noted that the description here indicates that cells perform functions, but it should be clear that the gNBs that make up a cell will perform those functions. The cells are part of a gNB. This means that there can be multiple cells per gNB. For example, there might be three cells for a single gNB carrier frequency and associated bandwidth, each cell covering one-third of the 360-degree area, so that a gNB's coverage area covers an approximate oval or circle. Furthermore, each cell can be associated with a single carrier, and a gNB can use multiple carriers. So if there are three 120-degree cells per carrier and two carriers, then the gNB has a total of 6 cells. The wireless network (100) may include one or more network elements (190). For example, with EPC, the network elements (190) may include MME (Mobility Management Entity) and / or SGW (Service Gateway) functionality. As another example, with 5G core network (5GCN), the network elements may include Access and Mobility Management Function (AMF), SMF (Session Management Function) and / or UPF (User Plane Gateway) functionality. Connectivity with further networks may be provided, such as the telephone network and / or data network (e.g., the Internet). The gNB / eNB (170) is coupled via a link (131) to the network element (190). The link (131) may be implemented as, for example, an S1 or NG interface. The network element (190) includes one or more processors (175), one or more memories (171), and one or more network interfaces (N / WI / F) (180), interconnected via one or more buses (185). The one or more memories (171) include computer program code (173).One or more memories (171) and computer program code (173) to be configured, by one or more processors (175), to cause the network element (190) to perform one or more operations. Those skilled in the art will appreciate that the various network elements and network element components shown in Figure 1 can be implemented differently in future wireless networks, and are not limited to 4G, LTE, or 5G wireless networks (e.g., MT and gNB / DU are components of the IAB node). For example, the terms PCRF, MME, and SGW are terms generally used for core elements in LTE networks. In contrast to LTE, future wireless networks may perform network functions (NFs) by a number of cooperating devices. The different NFs may include, for example, Access and Mobility Management Functions (AMF), Session Management Functions (SMF), Policy Control Functions (PCF), Application Functions (AF), Authentication Server Functions (AUSF), User Plane Functions (UPF), and User Data Management (UDM). These NFs can be virtual functions created on a suitable platform, such as a cloud infrastructure.For example, certain protocols (such as non-punctual protocols) can be executed by one or more centralized units (CUs) in the cloud infrastructure, while one or more distributed units (DUs) operate the remaining protocols (e.g., punctual protocols) from the 5G radio interface. In this way, various NFs can be shared among CUs and DUs. Together, the CU, the underlying DU, and. RRH can be thought of as a logical transmission formation (which can be represented by gNB (170) in Figure 1 for example). A wireless network (100) may implement network virtualization, which is the process of combining hardware and software resources and network functionality into a single software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as external, combining multiple networks, or portions of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entity resulting from network virtualization is still implemented, to some extent, using hardware such as processors (152) or (175) and memory (155) and (171), and also that the virtualized entity creates technical effects. The computer-readable memories (125), (155), and (171) may be of any type suitable to the local technical environment and may be implemented using suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer-readable memories (125), (155), and (171) may be means for performing storage functions. The processors (120), (152), and (175) may be of any type suitable to the local technical environment, and may include one or more of general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), and processors based on multi-core processor architectures, as non-limiting examples.The processors (120), (152), and (175) may be means for performing functions, such as controlling the MT (110), eNB / gNB (170), and other functions as described herein. Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., application-specific integrated circuits), or a combination of software and hardware. In example embodiments, the software (e.g., application logic, instruction set) is maintained on any of various conventional computer-readable media. In the context of this document, computer-readable media may be any media or means that can contain, store, communicate, transmit, or transport instructions for use by or connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer being described and illustrated, for example, in Figure 1.Computer-readable media may consist of computer-readable storage media or other devices which may be any media or means capable of containing or storing instructions for use by or in connection with an instruction execution system, equipment, or device, such as a computer. In certain embodiments, an IAB node, may include an MT portion similar to MT (110) for communication with a donor node or the RAN portion of host IAB nodes, in a multi-hop embodiment, and an RAN / DU portion that may be similar to network entity / gNB (170) for communication with an access UE or the MT portion of a next-hop IAB node. Therefore, in certain embodiments, an IAB node may include at least two processors, at least two transceivers, at least two memories, and at least two antennas. In other embodiments the processors, transceivers, memories and / or antennas may be shared between the MT portion and the RAN portion of the IAB node. Nodes may contain any combination of MT, DU, CU, gNB, and UPF (e.g., different for certain nodes), etc. Thus, having introduced a suitable but not limiting technical context for the practice of exemplary embodiments of the present invention, the exemplary embodiments will now be described with greater specificity. Referring to Figure 2, an example illustration of integrated access and backhaul for multi-hop (200) is shown. As shown in Figure 2, the donor central unit (CU) (210) may be connected to the donor distributed unit (DU) (220), which may be connected to the MT (110) (indicated as MT1 (110-1)) via the IAB nodes (230) (such as, for example, IAB11, IAB12, IAB21, IAB22, and IAB32). A donor can be a gNB that terminates the wireless backhaul radio interfaces of one or more IAB nodes. The donor can have other functions to support the IAB. The donor has wired / fiber connectivity to the network. The donor contains a CU and one or more DUs. The CU of the gNB can also support DUs in downstream IAB nodes. The donor can serve directly connected IAB nodes such as nodes IAB11 and IAB12, and IABs chained through multiple wireless backhaul hops such as IAB21, IAB22, and IAB32. The donor can also serve directly connected UEs. A CU is a logical node that can include functions (e.g., gNB functions) such as user data transfer, mobility control, radio access network sharing, positioning, session management, etc., except for functions allocated exclusively to the DU. The CU can control the operation of the DU through the front-haul interface (Fs). A DU is a logical node that can include a subset of functions (e.g., gNB functions), depending on the functional separation option. The operation of the DU can be controlled by the CU. According to an example embodiment, as described in connection with Figure 2, each IAB node logically contains a mobile terminal (MT) that maintains connectivity with one or more upstream nodes (e.g., dual connectivity). Similar to conventional user equipment (which contains MTs), the IAB node MT may use radio resource control (RRC) signals to supply radio link measurements from alternate upstream nodes to the currently serving gNB CU. Based on signal strength, signal quality, and other factors, the handover of the IAB node to a different upstream node may be triggered by the RRC. The RRC may also add or remove dual / Multi-Connectivity (DC / MC) legs by sending RRC Connection Reconfiguration messages. Therefore, the IAB topology, as shown in Figure 2, may not be static. The IAB topology may change over time as radio conditions fluctuate, and as nodes move, are added, or removed.DC leg handover and addition / removal can be designed to operate on a time scale of seconds to minutes, corresponding to the macroscopic movement of MTs through the cellular network. Referring now to Figure 3, an illustration of example scenarios for packet routing in an IAB node topology (300) is shown. As per an example embodiment, at mm-wave frequencies, the channel accessed (e.g., experienced) by the MT (110) may experience a momentary blockage event that may result in a sudden sharp drop in signal strength (e.g., of the order of 30 dB) due to physical objects blocking the MT-TRP link as shown (e.g., between IAB32 (230-32) and the MT (110) in scenario 1, (310)). Based on the Urban Macro blockage (UMi) model described in the NR TR 38900 channel model, for a blockage speed of 30 km / h, the average blockage duration of a single blockage event is 600 microseconds. To improve reliability, multiple routes may be set up for the MT using techniques such as DC / MC as described above in relation to Figure 2.In cases where radio link problems arise for the current route, for example, radio link problems between MT (110) and its serving IAB (230), or between IAB (230) and its parent node, the IAB system is required to select an alternative route (e.g., on the fly). Example embodiments provide mechanisms that adapt the topology in a manner sufficient to adapt to blocking on mm-wave, which occurs on a very short time scale. In contrast, RRC mechanisms that adapt the topology, including handovers and multiple connectivity changes, may be insufficient. With regard to DC, 3GPP specifies that packet routing to MCG vs SCG is done at the PDCP layer (see TS37.340). In the L2 architecture, the PDCP layer resides at the donor-CU, as shown in Figure 3. Consequently, for a packet to be rerouted, it must be sent a second time from the donor-CU to the branch point. For example, in scenario 2 (320), due to a link outage between IAB21 (230-21) and IAB32 (230-32), IAB11 (230-11) cannot send a DL packet to IAB21 (230-21) without first receiving the packet a second time from the donor-CU (210). This may require the donor-CU to resend the DL packet to IAB11 after a failure is detected downstream in cases where IAB11 (230-11) has already successfully received it. Only then can IAB11 (23011) send the packet via the alternative path (via IAB22 (230-22)). In this case, there is no need to resend the DL packet to IAB11. Issues related to packet routing as described by 3GPP are addressed by an example embodiment. The example embodiment eliminates (e.g., eliminates) the requirement for the donor CU to resend the DL packet to the IAB11 (230-11) after a failure is detected downstream in cases where the IAB11 (230-11) has successfully received it. With respect to the donor-CU (210), in an exemplary embodiment, the systems described herein configure the donor DU nodes (220) and IAB (230) with route information, or topology information from which route information can be derived for subsequent nodes to reach the MT (110) and the donor. The Donor-CU (210) may send routes and preferences to branch nodes (e.g., an intermediate IAB node (230), or a Donor-DU (220)). The preference information may indicate the preferred route via at least one route identifier and an identifier of the next hop. Branch nodes may include nodes that provide branch points when routing communications through several different connected nodes (e.g., an IAB node (230-11) provides a branch point to an IAB node (230-21) or (230-22)). The information may be sent via C-plane signaling using RRC or F1AP, or U-plane signaling by adding the preference information in an adaptation header, or both.The preference information indicates the preferred route (e.g., via the route ID or via the next IAB node / next hop identifier), and may also indicate circumstances when the branch point should switch to a less preferred route / branch or start duplicating packets and send them on both branches. When configuring the preferences, the donor-CU (210) may take into account the overall knowledge of the IAB topology as well as certain carrier characteristics, QoS flows or knowledge of the MT service (110) or network slice information used. For example, for traffic requiring very low delay, the donor-CU (210) may set the preferred route to one with fewer hops even if that route is more congested at some point in time etc.The CU can also send preference information to all IAB nodes to request all IAB nodes to generate link event notifications when an IAB node detects a link / route status change. In an example embodiment the donor IAB and DU nodes receive route and preference information from a CU (e.g., donor-CU (210)) via the C-plane or U-plane. The Donor IAB and DU nodes may generate link event notifications based on the configured preference information received from the CU. The preferences may indicate when link event notifications should be generated and sent to the downstream node, or the upstream node. The branch node may receive link event notifications (e.g., link event indications) from downstream and / or upstream IAB nodes (230) or donors. Link event notifications may occur under various circumstances, which may be configured or predetermined, for example, when the performance characteristics of the link change significantly. Alternatively, link event notifications may occur when the number of HARQ retransmissions on the link reaches a certain number. In a further example, link event notifications may occur when the number of RLC ARQ retransmissions reaches a certain number. In a further example, link event notifications may occur when the signal strength is below a threshold, or above a threshold. The branch node may adapt uplink and / or downlink routes based on route preferences and link event notifications. The branch node may also propagate link event notifications to all next hop routes. Link event notifications may be binary (e.g., no route available or link resumed after declaring no route available). Link event notifications may also have multiple levels indicating link quality (e.g., rating 1 to In an example embodiment the IAB node 230, or donor-DU 220 may generate link event notifications based on configured preference information received from the CU, or based on its implementation if the CU does not provide preference information. Link events may be associated with a downstream IAB node, or an upstream IAB node.Link event notifications may be binary (e.g., no route available or link resumed after stating that no route is available). Link event notifications may have multiple levels indicating the quality of the link (e.g., a rating of 1 to 10). The IAB node (230), or Donor-DU (220) may propagate the link event notification to the next downstream IAB node (230), or upstream node. Intermediate IAB nodes may aggregate the received link event notifications, and include them as part of the link event notification then sent to the next downstream IAB node (230), or upstream node (230). Figure 4 (illustrated by the linked Figures 4A and 4B) is an example illustration of a call flow for enhanced route selection in an integrated access and backhaul system (400). Figure 4 includes signaling between MT1 (110-1), donor-DU (220), donor-CU (210) and IAB (230) (IAB11 (230-11) through IAB 32 (230-32)). In step 405, IAB (230) can form a connection with another IAB (230). For example, IAB32 is connected to IAB21 and IAB22. IAB21 and IAB22 are connected to IAB11. IAB11 and IAB12 are connected to Donor-DU). In step 410, MT1 (110-1) can connect to the primary node and add a secondary node (SN). For example, MT (1101) connects to IAB32, then adds IAB12 as SN). In step 415, according to an example embodiment, the donor-CU (210) configures the donor-DU (220), and the IAB node (230) on how to route DL traffic to MT1 (110-1). The configuration may only require messages to inform (e.g., to notify) the DU (or intermediate IAB node 230) about the next IAB node (230) to reach MT1 (110-1). According to an example embodiment, the configuration defined by the donor-CU (210) may be DU: {IAB11, IAB12}; both IAB11 and IAB12 can be the next node (i.e., the next node in the routing sequence) to reach MT1 (110-1) (from DU (220)). In other words, donor-CU (210) configures donor-DU (220) to choose from either (or both) IAB11 and IAB12. Similarly, donor-CU (210) can configure IAB11 (230-11) : {IAB21, IAB22}; both IAB21 (230-21) and IAB22 (230-22) can be (selected as) the next node to reach MT1 (110-1). IAB21: {IAB32}; IAB32 can be the next node to reach MT1. IAB22: {IAB32}; IAB32 can be the next node to reach MT1. For branching nodes (e.g., DU(220) and IAB11(23011)), the configuration may also include preferences. For example, for donor-DU(220), the configuration may indicate that IAB11(230-11) is preferred over IAB12(230-12). Alternatively, these preferences can be set for each DL package. In this case, the preferences can be included in the adaptation header of each DL package. Further implementations may include both preferences indicated in the initial configuration and a preference set that is updated per each DL packet. For example, when the adaptation header of a DL packet does not include a preference, the configured preference may be used. When the adaptation header of a DL packet includes a preference, the received preference may be used instead of the configured preference. The preference information may also include circumstances when the branching node should switch to a less preferred route / branch or start duplicating packets and transmitting them on both branches. The configuration may also include UE context (110), for example, quality of service (QoS) for each dedicated radio bearer (DRB) and / or QoS flow. The preference information may also include circumstances when link event notifications need to be sent to upstream or downstream nodes (e.g., performance degradation, number of HARQ or ARQ retransmissions, signal strength, etc.). In step 420, the donor-CU (210), in some example embodiments, sends DL data to the donor-DU (220) for MT1 (110-1). The donor-DU (220) may send DL data to IAB11 (230-11), which is then sent to MT1 (110-1) via IAB21 (230-21) -> IAB32 (230-32) -> MT1 (110-1). The donor-CU / DU may also include additional information in the adaptation header. For example, the donor-CU / DU may indicate IAB21 (230-21) is preferred over IAB22 (230-22). This information may be used by the branching node (e.g., IAB11 (230-11)) to determine the next node to reach MT1 (110-1). In step 425, IAB21 can detect a radio link outage between IAB21 and IAB32. In this example, because IAB21 has no other nodes that it can use to reach MT1, IAB21 informs its upstream IAB (230), for example, IAB11 (230-11), about the link event. For example, IAB21 (230-21) is unusable for MT1 (110-1). In step 430, the donor-CU (210) can send DL data to the donor-DU (220). The donor-DU (220) can then send DL data to IAB11 (230-11). Based on the previously received configuration and link events, IAB11 (230-11) can choose a different route, for example, via IAB22, for MT1 (110-1). DL data can be sent to MT1 (110-1) via IAB11 (230-11) IAB22 (230-22) - IAB32 (230-32) - MT1 (110-1). In this case, IAB11 may have at least one alternative route to MT (110), so IAB11 (230-11) cannot forward the link event notification to its upstream node. In step 435, for example at a later time, IAB22 (230-22) may also detect a radio link outage between IAB22 (23022) and IAB32 (230-32). In this example, since IAB22 (230-22) has no other nodes that can be used to reach MT1 (110-1), IAB22 (230-22) may inform its upstream IAB (230) (e.g., IAB11 (230-11)) of the link event. For example, (the upstream IAB (230) may be informed that) IAB22 (230-22) is unavailable for MT1 (110-1). In step 440, IAB11 (230-11) may determine (i.e., learn) that both nodes have problems (e.g., are currently unable to route data). Since IAB11 (230-11) has no other nodes that can be used to reach MT1 (110-1), IAB11 (230-11) may inform its upstream node, e.g., donor-DU (220), in this example. The donor-DU may (then) learn that IAB11 (230-11) cannot be used to reach MT1 (110-1). Based on the configuration received in step 415 and the link events, donor-DU (220) may know (i.e., determine based on the configuration) that IAB12 (230-12) can be used to reach MT (110). In step 445, the donor-CU (210) may send DL data to the donor-DU (220). The donor-DU (220) may choose a different route, for example, via IAB12 (230-12), to MT1 (110). DL data may be sent to MT1 (110-1) (for example, via IAB12 (23012) - MT1 (110-1)). At step 450, for example, at a later time, IAB22 (230-22) may detect that the radio link to IAB32 (230-22) has resumed. IAB22 (230-22) may inform the upstream IAB node (230), for example, IAB11 (230-11), that IAB22 (230-22) is available for MT1 (110-1). In step 455, since IAB11(230-11) does not have an active route for MT1(110-1), IAB11(230-11) can inform its upstream node, e.g., donor-DU, that IAB11(230-11) can be used for MT1(110-1). Since IAB11(230-11) is preferred based on the previous configuration received in step 415, donor-DU(220) can use IAB11(230-11) for further DL data delivery to MT1(110). Donor-CU (210) can send DL data to donor-DU (220). Donor-DU (220) can send DL data to MT1 (110-1) via the route, IAB11 (230-11) - IAB22 (230-22) - IAB32 (230-32) - MT1 (110-1). The link event notification used in steps 425 / 435 / 450 may have the following characteristics. Link event notifications may indicate to the upstream IAB node (230) that an outage has occurred or poor radio link quality, or that the node (230) has recovered from an outage, that a change in the link quality of the radio link with the downstream IAB node (230), or that MT access (110) has been detected. Link event notifications may also be upstream node-related. They may be used by the downstream IAB node (230) to select the upstream IAB node (230) in the event of a UL radio link problem or recovery with the current upstream IAB node (230) (not shown in the call flow in Figure 4). Detection may be based on the pre-configured or pre-defined conditions mentioned above (e.g., throughput degradation, number of HARQ or ARQ retransmissions, signal strength, etc.). The IAB node implementation may determine how / when link event notifications are detected, based on the configuration received from the donor-CU. Notifications can be sent in the following manner: Within the adaptation layer header of the F1-U (or data) packet of the IAB MT sent to the donor-CU (210). In the case where the link event notification is placed at the adaptation layer, not only the donor-CU (210), but all intermediate nodes can read and interpret this information properly and act on the information included in the link event notification immediately. Alternatively, notifications can be sent in RRC messages between the IAB MT and the Donor-CU. In this case, the information is not interpreted by the intermediate nodes and will traverse them transparently. In this case, the intermediate nodes only relay the message and do not inspect the message content. Upon receiving a link event notification from a particular IAB MT, the donor-CU (210) will be required to disseminate this information to all affected IAB nodes, either via RRC signaling to the IAB MTs or via F1-AP signaling to the DU IAB. Providing a notification in the adaptation layer header can result in fewer signaling delays and layer headers. Figure 4 illustrates the message in the adaptation layer header. Figure 5 is an example flow diagram (500) illustrating a method according to an example embodiment that can be carried out with the apparatus. In block 510, the donor-CU device (210) (e.g., an apparatus, module or component) may configure the donor-DU device (220) and the IAB node (230) with route information. In some cases, the donor-CU device (210) may configure the devices directly with route information. Alternatively, the donor-CU device (210) may configure with topology information whereby route information may be derived for subsequent nodes to reach the MT (110) and the donor.

[0025] At block 520, the donor-CU device (210) may configure the donor-DU device (220) and the IAB node (230) with a preference. The preference information may indicate a preferred route (e.g., via a route ID or via a next hop / next IAB node identifier), and may also indicate circumstances when the branch point should switch to a less preferred route / branch or start duplicating packets and transmitting them on both branches. The preference information may also include circumstances when link event notifications need to be sent to the upstream or downstream node (e.g., when the throughput is below or above a threshold, or when the number of HARQ or ARQ retransmissions exceeds or falls below a threshold, or when the signal strength is below or above a threshold, etc.). When configuring a preference, the donor-CU (220) may consider the overall knowledge of the IAB topology as well as specific carrier characteristics, QoS flows or knowledge of the MTs (110) services or network slice information used. Network slices are defined in TS23.501. Network slices are used to allocate resources in the network according to: 1 - Slice / Service Type (SST), which refers to the expected behavior of the network slice in terms of features and services; and 2 A Slice Differentiator (SD), which is optional information that complements the Slice / Service type to differentiate between multiple Network Slices of the same Slice / Service type. SST can differentiate between, for example, ultra-low latency of mobile broadband of the Internet of Things (IoT). SD can be an example of separate services between two customers (for example, between Citibank and Wells Fargo [tm]). At block 530, the donor-CU (220) may transmit routes and preferences to the branch node. The donor-CU (220) may transmit the information via C-plane signaling using RRC or F1AP, or U-plane signaling by adding preference information in the adaptation header, or both. The donor-CU (220) may also transmit routes and preference information to all associated IAB nodes via C-plane signaling using RRC or F1AP, or U-plane signaling by adding preference information in the adaptation header, or both. Figure 6 is an example flow diagram 600 illustrating a method in accordance with an example embodiment that can be performed with the apparatus. At block 610, a branching IAB node (230) or a donor-DU (220) may receive routes and preference information from a donor-CU (210). The branching IAB node (230) or a donor-DU (220) may receive routes and preference information from a CU (210) via a C-plane or a U-plane. Other IAB nodes (230) may also receive preference information from a CU (210) via a C-plane or a U-plane. At block 620, an IAB node (230) or a donor-DU (220) may generate a link event notification based on configured preference information received from the donor-CU (210). In the event that the donor-CU (210) does not provide preference information regarding when a link event should be generated, the IAB node (230) may generate a link event notification based on its implementation. The IAB node (230) or donor-DU (220) may send the link event notification to a downstream node, or an upstream node. The link event notification may be propagated by the intermediate IAB node brokers until it reaches a branch node (e.g., an IAB node (230), or donor-DU (220)). At block 630, a branch node (e.g., an IAB node (230) or a donor-DU (220)) may receive link event notifications from downstream and / or upstream IAB nodes (230) or donors. Link event notifications may occur under various circumstances, which may be configured or predetermined, e.g., when the throughput characteristics of the link change significantly, when the number of HARQ retransmissions on the link reaches a certain number, when the number of RLC ARQ retransmissions reaches a certain number, etc. At block 640, the IAB branch node (230) or donor-DU (220) may adjust the uplink and / or downlink routes based on route preferences and link event notifications. At block 650, the IAB node (230) or donor-DU (220) may propagate a link event notification to all next-hop routes. Without in any way limiting the scope, interpretation, or applicability of the claims appearing below, the technical effect of one or more example embodiments disclosed herein is that routes can be adapted to current radio conditions much more quickly than with RRC signaling. In some instances, for example, a sudden blockage of the radio path may result in very poor radio conditions. In this case, the use of RRC signaling may not be feasible (or advisable) because it is highly likely that necessary RRC messages will not be sent to the target node (e.g., measurement reports from MT (110) to donor-CU (210)). Another technical effect is that fewer signals are required. For example, the donor-CU may not be aware of the route selection, but the CU still has control by providing configuration preference information.Example embodiments can be implemented to access the UE or MT portion of an IAB node (in both cases, the UE / MT is connected to two separate upstream IAB nodes using Dual Connectivity). Example embodiments may provide a method comprising configuring, by at least one donor central unit, at least one of at least one donor distributed units and at least one integrated access and backhaul node with route information to reach at least one mobile terminal and at least one donor; configuring at least one of at least one donor distributed units and at least one integrated access and backhaul node with preference information; and sending the route information and preference information to at least one branch node and at least one integrated access and backhaul node. In accordance with an example embodiment as described in the paragraph above, wherein configuring at least one of the at least one donor distributed unit and the at least one integrated access and backhaul node with route information further comprises at least one of: configuring at least one of the at least one donor distributed unit and the at least one integrated access and backhaul node directly with route information; and configuring at least one of the at least one donor distributed unit and the at least one integrated access and backhaul node with topology information from which route information can be derived. In accordance with an example embodiment as described in the paragraph above, wherein the sending of the route information and preference information further comprises: sending the route information and preference information via at least one of: C-plane signaling using at least one of the radio resource control and fronthaul application protocols, and U-plane signaling by adding preference information in at least one of the adaptation headers. In accordance with an example embodiment as described in the paragraph above, wherein the preference information indicates a preferred route via at least one route identifier and a next hop identifier. In accordance with an example embodiment as described in the paragraph above, wherein the preference information further indicates at least one state where the branch point is to switch to a less preferred route, a state where the branch point is to begin duplicating packets and sending duplicate packets on each of the at least two branches at the branch point, and a state where the integrated access and backhaul nodes send link event notifications. In accordance with an example embodiment as described in the paragraph above, wherein configuring at least one of the at least one donor distributed unit and at least one integrated access and backhaul node with preference information further comprises: configuring at least one of the at least one donor distributed unit and at least one integrated access and backhaul node based on at least one of aggregate knowledge of the integrated access and backhaul node topology; at least one characteristic of at least one particular carrier; at least one quality of service flow; and utilizing network slice information. An example embodiment may provide a method comprising receiving, by at least one integrated access and backhaul sample and a donor distributed unit, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology and at least one of; transmitting at least one link event notification; receiving at least one link event notification; and adapting at least one uplink route and downlink route based on the preference information and at least one link event notification. In accordance with an example embodiment as described in the paragraph above, wherein the preference information indicates a preferred route via at least one route identifier and a next hop identifier. In accordance with an example embodiment as described in the paragraph above, wherein the received preference information further indicates at least one of: a state where the branch point is to switch to a non-preferred route, a state where the branch point is to start duplicating packets and sending the duplicated packets to each of at least two branches at the branch point, and a state where the integrated access and backhaul nodes send link event notifications. In accordance with an example embodiment as described in the paragraph above, wherein transmitting at least one link event notification when at least one of: the performance characteristics of a link change significantly; retransmitting a number of hybrid auto-repeat requests on the link reaches a certain number; and the available radio links or available routes are changed. In accordance with an example embodiment as described in the paragraph above, wherein transmitting at least one link event notification further comprises: transmitting at least one link event notification to at least one of at least one downstream integrated access and backhaul nodes, and a donor. In accordance with the example embodiment as described in the above paragraph, wherein receiving at least one link event notification further comprises: receiving at least one notification from at least one downstream integrated access and backhaul node, the donor. In accordance with an example embodiment as shown in the above paragraph, wherein the at least one subsequent link event notification comprises at least one of: a binary indication of an available radio link, or an available route, or a link resumed after indicating no available route; and multiple levels indicating the quality of the radio link. An example embodiment may provide an apparatus comprising means for configuring, with at least one donor central unit, at least one of at least one donor distributed units and at least one integrated access and backhaul node with route information to reach at least one mobile terminal and at least one donor; means for configuring at least one of at least one donor distributed units and at least one intermediate integrated access and backhaul node with preference information; and means for sending route information and preference information to at least one branch node and at least one integrated access and backhaul node. In accordance with an example embodiment as described in the paragraph above, wherein the means for configuring at least one donor distributed unit and at least one intermediate integrated access and backhaul node with routing information further comprises at least one of: means for configuring at least one of the at least one donor distributed unit and at least one integrated access and backhaul node directly with routing information; and means for configuring at least one of the at least one donor distributed unit and at least one integrated access and backhaul node with topology information from which such routing information may be derived. In accordance with an example embodiment as described in the paragraph above, wherein the means for sending route information and preference information further comprises: means for sending route information and preference information via at least one of: C-plane signaling using at least one radio resource control and fronthaul application protocol, and U-plane signaling by adding preference information in at least one adaptation header. In accordance with an example embodiment as described in the paragraph above, wherein the preference information indicates a preferred route via at least one route identifier and a next hop identifier. In accordance with an example embodiment as described in the paragraph above, wherein the preference information further indicates at least one state where the branch point is to switch to a less preferred route, a state where the branch point is to start duplicating packets and sending the duplicated packets at each of at least two branches at the branch point, and a state where the integrated access and backhaul nodes send link event notifications. An example embodiment may provide an apparatus comprising means for receiving, by at least one branch node, route information and preference information to reach at least one mobile terminal and at least one donor in an integrated access and backhaul node topology; means for generating at least one link event notification; and means for adapting at least one uplink route and a downlink route based on the route preference and at least one link event notification. In accordance with an example embodiment as described in the paragraph above, wherein the means for receiving at least one link event notification further comprises: means for receiving at least one link event notification from at least one of the at least one downstream integrated access and backhaul node, at least one upstream integrated access and backhaul node, and a donor. An example embodiment may be provided in an apparatus comprising one processor; and at least one nontransitory memory comprising computer program code, the at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to: configure, with the at least one donor central unit, at least one of the at least one donor distributed units and at least one integrated access and backhaul node with route information to reach at least one mobile terminal and at least one donor; configure at least one of the at least one donor distributed units and at least one integrated access and backhaul node with preference information; and send the route information and preference information to at least one branch node and at least one integrated access and backhaul node. In accordance with an example embodiment as described in the above paragraph, wherein, when configuring at least one of at least one donor distributed unit and at least one integrated access and backhaul node with route information, the at least one memory and computer program code may further be configured to, with at least one processor, cause the apparatus to at least one of: configure at least one of at least one donor distributed unit and at least one donor distributed unit and backhaul node directly with route information; and configure at least one of at least one donor distributed unit and at least one integrated access and backhaul node with topology information from which the route information may be derived. In accordance with an example embodiment as described in the above paragraph, wherein, when transmitting route information and preference information, at least one memory and computer program code may be configured to, with at least one processor, cause the apparatus to transmit route and preference information via at least one of: plane C signaling using at least one radio resource control and fronthaul application protocol, and plane U signaling by adding preference information in at least one adaptation header. In accordance with an example embodiment as described in the paragraph above, wherein the preference information indicates a preferred route via at least one route identifier and a next hop identifier. In accordance with an example embodiment as described in the paragraph above, wherein the preference information further indicates at least one state where the branch point is to switch to a less preferred route, a state where the branch point is to start duplicating packets at every two branches at the branch point, and a state where the integrated access and backhaul nodes send link event notifications. In accordance with an example embodiment as described in the preceding paragraph, wherein, when configuring at least one donor distributed unit and at least one integrated access and backhaul node with preference information, at least one memory and computer program code may further be configured to, with at least one processor, cause the apparatus to configure at least one of the at least one donor distributed unit and at least one integrated access and backhaul node based on one of the aggregate knowledge of the integrated access and node topology; at least one characteristic of at least one particular carrier; at least one quality of service flow; and utilizing network slice information. An example embodiment may be provided in an apparatus comprising at least one processor; and at least one non-transitory memory comprising computer program code, the at least one memory and computer program code may be configured to, with the at least one processor, cause the apparatus to: receive, by the at least one integrated access and backhaul node and the donor distributed unit, route information and preference information to reach at least one mobile terminal and at least one donor in the integrated access and backhaul node topology; transmit at least one link event notification; receive at least one link event notification; and adapt at least one uplink and downlink route based on the preference information and at least one link event notification. In accordance with an example embodiment as described in the paragraph above, wherein the preference information indicates a preferred route via at least one route identifier and a next hop identifier. In accordance with an example embodiment as described in the paragraph above, wherein the preference information achieved further indicates at least one of: a state where the branch point is to switch to a less preferred route, a state where the branch point is to start duplicating packets and sending the duplicated packets at every at least two branches at the branch point, and a state where the integrated access and backhaul nodes send link event notifications. Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., application-specific integrated circuits), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, instruction set) is maintained on one of various conventional computer-readable media. In the context of this document, “computer-readable media” may be any medium or means that can contain, store, communicate, transmit, or transport instructions for use with or in connection with an instruction-executing system, device, or device, such as a computer, with one example of a computer being described and depicted, for example, in Figure 1.A computer-readable medium may comprise a computer-readable storage medium (e.g., memory 125, 155, 171 or other device) which may be any medium or device capable of containing, storing, and / or transporting instructions for use with or in connection with an instruction-executing system, apparatus, or device, such as a computer. The computer-readable storage medium does not comprise signal propagation. If desired, the different functions described here can be performed in a different order and / or in conjunction with each other. Thus, if desired, one or more of the functions described above can be optional or can be combined. Although some aspects are set out above, other aspects comprise combinations of other features of the described embodiments, and not just the combinations described above. It is also noted herein that while describing exemplary embodiments, these descriptions should not be viewed in a limited sense. Rather, there are several variations and modifications that can be made without departing from the scope of the present invention. Although various aspects of the present invention are set forth in the independent claims, other aspects of the present invention consist of combinations of other features of the described embodiments and / or dependent claims with features of the independent claims, and are not and are not only combinations set forth explicitly in the claims. It is also noted herein that while describing the above exemplary embodiments, these descriptions should not be viewed in a limited sense. Rather, there are several variations and modifications that can be made without departing from the scope of the present invention as specified in the appended claims. In general, various embodiments can be implemented in hardware or special purpose circuits, software, logic or combinations thereof. For example, some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software executable by a controller, microprocessor or other computing device, although the present invention is not limited thereto. While various aspects of the present invention are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that the blocks, apparatus, systems, techniques or methods described herein can be implemented in, for example, not limited to, hardware, software, firmware, special purpose circuits or logic, special purpose hardware or controllers or other computing devices, or some combination thereof. These embodiments can be implemented in various components, such as integrated circuit modules. Integrated circuit design is generally a highly automated process. Complex and powerful software tools are available to convert logic-level designs into semiconductor circuit designs ready for etching and forming on semiconductor substrates. The word “exemplary” is used herein to mean “serving as an example, or “illustrative. Any embodiment described herein as an “exemplary” need not be construed as being preferable or advantageous over other embodiments. All embodiments described in this detailed description are exemplary embodiments provided to enable one skilled in the art to make or use the invention and do not limit the scope of the invention defined by these claims. The foregoing description has been provided as an example and not as a limitation, with a complete and informative explanation of the best methods and apparatus currently considered by the inventors for carrying out their invention. However, various modifications and adaptations may be apparent to those skilled in the relevant art in the foregoing description, when read in conjunction with the accompanying drawings and appended claims. However, all modifications and so forth of the teachings of the present invention remain within the scope of the present invention. It should be noted that the terms “connected,” “coupled,” or variations thereof, mean a connection or pairing, whether direct or indirect, between two elements, and may include the presence of one or more intermediate elements between the two elements being “connected” or “coupled” together. The connection or link between the elements may be physical, logical, or a combination thereof. As used herein two elements may be considered to be “connected” or “coupled” together by means of one or more wires, cables and / or printed electrical connections, also by means of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, microwave region and optical region (whether visible or invisible), as some non-limiting and non-exhaustive examples. Thus, some features of the preferred embodiment of the present invention are used to advantage without resorting to other features. As such, the foregoing explanation should be considered only as an illustration of the principles of the invention, and not as a limitation thereof.

Claims

1. An apparatus comprising at least one processor; and at least one non-transitory memory that includes computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to at least: receive route information to reach at least one mobile terminal and at least one donor distributed unit in an integrated access and backhaul node topology; receive preference information indicating at least a preferred route to reach at least one mobile terminal and / or at least one donor distributed unit in an integrated access and backhaul node topology; send and / or receive at least one link event notification; and adapt at least one uplink route and a downlink route based on the preference information and at least one link event notification.

2. The apparatus according to claim 1, wherein said apparatus comprises, or is contained in, an integrated access and backhaul node or a donor distributed unit.

3. The apparatus according to claim 1, wherein the preference information indicates the preferred route via at least a route identifier.

4. The apparatus according to claim 1, wherein it sends at least one link event notification when at least one of: a performance characteristic of the link changes significantly; a number of hybrid auto-repeat request retransmissions on the link reaches a certain number; a number of radio link control auto-repeat request retransmissions reaches a certain number, and the radio link availability or route availability is changed.

5. The apparatus according to claim 1, wherein the apparatus to send the at least one link event notification is made to send the at least one link event notification to at least one of at least one downstream integrated access and backhaul node, at least one upstream integrated access and backhaul node, and a donor distributed unit; and / or wherein the apparatus to receive the at least one link event notification is made to receive the at least one link event notification from at least one of at least one downstream integrated access and backhaul node, at least one upstream integrated access and backhaul node, and the donor distributed unit.

6. The apparatus according to claim 1, wherein the at least one link event notification comprises at least one of: a binary indication of radio link availability, or route availability, or link resumption after declaring no route available; and multiple levels indicating the quality of the radio link.

7. The apparatus according to claim 1, wherein the route information comprises at least one fronthaul application protocol signaling message and the preference information is contained in an adaptation header of the downlink data packet.

8. The apparatus according to claim 1, wherein the apparatus to send the route information and preference information is made to: send the route and preference information via at least one of: C-plane signaling using at least one of the radio resource control and fronthaul application protocols, and U-plane signaling by adding the preference information in at least one adaptation header.

9. An apparatus comprising at least one processor; and at least one non-transitory memory comprising computer program code, the at least one memory and the computer program code being configured to, with the at least one processor, cause the apparatus to at least: configure at least one of at least one donor distributed unit and at least one integrated access and backhaul node with route information to reach at least one mobile terminal and at least one donor distributed unit; configure at least one of at least one donor distributed unit and at least one integrated access and backhaul node with preference information indicating at least a preferred route; and send the route information and preference information to at least one branch node and at least one integrated access and backhaul node.

10. The apparatus according to claim 9, wherein said apparatus comprises, or is contained within, a donor center unit.

11. The apparatus according to claim 9, wherein the apparatus causing the configuration of at least one of the at least one donor distributed unit and at least one integrated access and backhaul node with route information is made so as to: configure at least one of the at least one donor distributed unit and at least one integrated access and backhaul node directly with route information; or configure at least one of the at least one donor distributed unit and at least one integrated access and backhaul node with topology information from which route information can be derived.

12. The apparatus according to claim 9, wherein the apparatus to send the route information and preference information is made to: send the route and preference information via at least one of: C-plane signaling by using at least one of the radio resource control and fronthaul application protocols, and U-plane signaling by adding the preference information in at least one adaptation header.

13. The apparatus according to claim 9, wherein the preference information indicates the preferred route via at least a route identifier.

14. The apparatus according to claim 9, wherein the route information comprises at least one fronthaul application protocol signaling message and the preference information is contained in an adaptation header of the downlink data packet.

15. A method comprising: receiving route information to reach at least one mobile terminal and at least one donor distributed unit in an integrated access and backhaul node topology; receiving preference information indicating at least a preferred route to reach at least one mobile terminal and / or at least one donor distributed unit in an integrated access and backhaul node topology; sending and / or receiving at least one link event notification; and adapting at least one uplink route and a downlink route based on the preference information and at least one link event notification.

16. The method according to claim 15, wherein the preference information indicates a preferred route via at least a route identifier.

17. The method according to claim 15, wherein sending at least one link event notification when at least one of: the performance characteristics of the link change significantly; a number of hybrid auto-repeat request retransmissions on the link reaches a certain number; a number of radio link control auto-repeat request retransmissions reaches a certain number, and the radio link availability or route availability is changed.

18. The method according to claim 15, wherein sending at least one link event notification comprises sending at least one link event notification to at least one of at least one downstream integrated access and backhaul node, at least one upstream integrated access and backhaul node, and a donor distributed unit; and / or wherein receiving at least one link event notification comprises receiving at least one link event notification from at least one of at least one downstream integrated access and backhaul node, at least one upstream integrated access and backhaul node, and a donor distributed unit.

19. The method according to claim 15, wherein the at least one link event notification comprises at least one of: a binary indication of radio link availability, or route availability, or link resumption after declaring no route available; and multiple levels indicating the quality of the radio link.

20. The method according to claim 15, wherein the route information comprises at least one fronthaul application protocol signaling message and the preference information is contained in an adaptation header of the downlink data packet.

Images