Patent Description:
3GPP determines standards and specifications for NR Integrated Access and Backhaul (for example, via TR38. Various layer <NUM> ("L2") and layer <NUM> ("L3") based solutions have been proposed in RAN2/RAN3 meetings. In the "L2"-based solutions, the IAB node contains a DU and packets are forwarded by the radio layers (below PDCP). In the L3 based solutions, the IAB node contains a DU and/or a gNB, and packets are forwarded at layers above PDCP. In both cases IAB nodes perform hop-by-hop routing to maintain connectivity between the MT serving IAB node and the Donor. The MT or the IAB may have multi-connectivity to multiple IABs or donors, so more than one path may be present at a given time.

Multi-hop backhauling provides greater range extension than single hop backhauling. This is especially beneficial for backhaul at frequencies above-<NUM> due to limited range. Multi-hop backhauling further enables backhauling around obstacles, for example, buildings and other clutter in urban environments where line-of-sight between nodes is obstructed. 3GPP TSG-RAN WG2 R2-<NUM> relates to hop-by-hop RLC ARQ in an IAB relay architecture. <CIT> describes self-organising network concepts for small cells backhauling.

Certain abbreviations that may be found in the description and/or in the Figures are herewith defined as follows:.

The invention is defined by the independent claims; the dependent claims define particular embodiments of the invention. There is hereby provided an apparatus according to claim <NUM> and a method according to claim <NUM>.

The foregoing and other aspects of embodiments of this invention are made more evident in the following Detailed Description, when read in conjunction with the attached Drawing Figures, wherein:.

In the example embodiments as described herein a method and apparatus provides dynamic route selection in an integrated access and backhaul system.

Turning to <FIG>, this figure shows a block diagram of one possible and non-limiting example system in which the example embodiments may be practiced. In <FIG>, the mobile terminal (MT) <NUM> is in wireless communication with the wireless network <NUM>. The MT is a wireless, typically mobile, device that can access the wireless network. The MT <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. Each of the one or more transceivers <NUM> includes a receiver (Rx) <NUM> and a transmitter (Tx) <NUM>. The one or more buses <NUM> may be address, data, or control buses, 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 memories <NUM> and the computer program code <NUM> may be configured to, with the one or more processors <NUM>, cause the MT <NUM> to perform one or more of the operations as described herein. The MT <NUM> communicates with the apparatus <NUM> via a wireless link <NUM>. <NUM> may be any one of the IAB donor <NUM> or the IAB nodes <NUM> in <FIG> for example. In this example the base station <NUM> has features or components of a gNB. A wireless attached IAB node, a Donor IAB node and a conventional gNB may be implemented on identical hardware or may include different hardware, but some of the core components such as processor(s), memory(ies), receiver(s) and transmitter(s) are present in each. <FIG> is merely intended to show a simplified version of some of the components of a IAB node, a Donor IAB node and a conventional gNB, but it is understood that there is a differentiation between a wireless IAB node and a Donor IAB node/gNB.

The gNB <NUM> is a base station (for example, for <NUM>/LTE) that provides access by wireless devices such as the MT <NUM> to the wireless network <NUM>. The gNB <NUM> includes one or more processors <NUM>, one or more memories <NUM>, one or more network interfaces (N/W I/F(s)) <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. Each of the one or more transceivers <NUM> includes a receiver (Rx) <NUM> and a transmitter (Tx) <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the gNB <NUM> to perform one or more of the operations as described herein. Two or more gNBs <NUM> communicate using, for example, link <NUM>. The link <NUM> may be wired or wireless or both and may implement, for example, an X2 or Xn interface.

The one or more buses <NUM> may be address, data, or control buses, 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, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM>, with the other elements of the gNB <NUM> being physically in a different location from the RRH, and the one or more buses <NUM> could be implemented in part as fiber optic cable to connect the other elements of the gNB <NUM> to the RRH <NUM>.

It is noted that description herein indicates that "cells" perform functions, but it should be clear that the gNB that forms the cell will perform the functions. The cell makes up part of an gNB. That is, there can be multiple cells per gNB. For instance, there could be three cells for a single gNB carrier frequency and associated bandwidth, each cell covering one-third of a <NUM> degree area so that the single gNB's coverage area covers an approximate oval or circle. Furthermore, each cell can correspond to a single carrier and an gNB may use multiple carriers. So if there are three <NUM> degree cells per carrier and two carriers, then the gNB has a total of <NUM> cells.

The wireless network <NUM> may include one or more network elements <NUM>. For example, with a EPC the network elements <NUM> may include MME (Mobility Management Entity) and/or SGW (Serving Gateway) functionality. As another example, with a <NUM> 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 a further network may be provided, such as a telephone network and/or a data network (for example, the Internet). The gNB/eNB <NUM> is coupled via a link <NUM> to the network element <NUM>. The link <NUM> may be implemented as, for example, an S1 or NG interface. The network element <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the network element <NUM> to perform one or more operations.

Those skilled in the art will appreciate that the various network element and network element components shown in <FIG> may be implemented differently in future wireless networks, and are not limited to <NUM>, LTE or <NUM> wireless networks (for instance, MT and gNB/DU are components of the IAB node). For example, the terms PCRF, MME, and SGW are terms generally used for the core elements in a LTE network. In contrast to LTE, future wireless networks may carry out network functions (NFs) by a plurality of cooperating devices. The different NFs, may include for example, Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Application Function (AF), Authentication Server Function (AUSF), User Plane Function (UPF), and User Data Management (UDM). These NFs may be a virtualized function instantiated on an appropriate platform, such as a cloud infrastructure. For example, certain protocols (such as non real-time protocols for example) may be performed by one or more centralized units (CUs) in a cloud infrastructure, while one or more distributed units (DUs) operate the remaining protocols (e.g. real-time protocols) of the <NUM> radio interface. In this way, the various NFs may be split between CUs and DUs. Together a CU, underlying DUs, and RRHs may be considered as forming a logical base station (which may be represented by gNB <NUM> in <FIG> for example).

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any 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 <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> 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 a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions, such as controlling the MT <NUM>, eNB/gNB <NUM>, and other functions as described herein.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example of an embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium or other device that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

In certain embodiments, an IAB node, may include a MT part which is similar to MT <NUM> for communication with the donor node or a parent IAB node's RAN part, in a multi-hop embodiment, and a RAN/DU part which may be similar to a network entity/gNB <NUM> for communication with access UEs or a next hop IAB node MT part. In certain embodiments, therefore, a single 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 part and the RAN part of the IAB node. The nodes may contain some (for example, various different for particular nodes) combination of MT, DU, CU, gNB, and UPF, etc..

Having thus introduced one suitable but non-limiting technical context for the practice of the example embodiments of this invention, the example embodiments will now be described with greater specificity.

Referring to <FIG>, an example illustration of integrated access and backhaul for multiple-hop <NUM> is shown.

As shown in <FIG>, a donor central unit (CU) <NUM> may be connected to a donor distributed unit (DU) <NUM>, which may be connected to a MT <NUM> (shown as MT1 <NUM>-<NUM>) via IAB nodes <NUM> (such as, for example, IAB11, IAB12, IAB21, IAB22, and IAB32).

The donor may be a gNB that terminates wireless backhaul radio interface from one or more IAB nodes. The donor may have other functionalities to support IAB. The donor has wired/fiber connectivity with the network. The donor contains a CU and one or more DU. The CU of the gNB may also support the DU in downstream IAB nodes. A donor may serve directly connected IAB nodes such as IAB11 and IAB12, and IAB nodes that are chained over multiple wireless backhaul hops such as IAB21, IAB22 and IAB32. A donor may also serve directly connected UEs.

A CU is a logical node which may include the functions (for example, gNB functions) such as transfer of user data, mobility control, radio access network sharing, positioning, session management etc., except those functions allocated exclusively to the DU. A CU may control the operation of DUs over a front-haul (Fs) interface. A DU is a logical node which may include a subset of the functions (for example, gNB functions), depending on the functional split option. The operation of the DU may be controlled by the CU.

According to example embodiments, as described with respect to <FIG>, each IAB node logically contains a mobile terminal (MT) that maintains connectivity with one or more upstream nodes (for example, dual connectivity). Similar to a conventional user equipment (which contains a MT), the IAB node MT may use radio resource control (RRC) signalling to supply radio link measurements of alternative upstream nodes to its current serving gNB CU. Based on signal strength, signal quality and other factors, a handover of an IAB node to a different upstream node may be triggered by RRC. RRC may also add or remove dual/Multi-Connectivity (DC/MC) legs by sending RRC Connection Reconfiguration messages. Hence the IAB topology, such as the one shown in the <FIG>, may not be static. The IAB topology may change over time as radio conditions fluctuate, and as nodes move, are added or removed. Handover and addition / removal of DC legs may be designed to work on a time scale of seconds to minutes, corresponding to macroscopic movement of MTs through a cellular network.

Referring now to <FIG>, an example illustration of scenarios for packet routing in an IAB node topology <NUM> is shown.

According to example embodiments, at mmWave frequencies, the channel accessed (for example, experienced) by a MT <NUM> may suffer from momentary blockage events that could result in sudden sharp drops in signal strength (for example, of the order of <NUM> dB) due to physical objects blocking the MT-TRP link as shown (for example, between IAB32 <NUM>-<NUM> and MT <NUM> in scenario <NUM>, <NUM>). Based on blockage model A Urban Macro (UMi) described in the NR channel model TR <NUM>, for a <NUM>/hr blocker velocity, the mean blockage duration of a single blockage event is <NUM> microseconds. To improve reliability, multiple routes may be setup for the MT using techniques such as DC/MC as described herein above with respect to <FIG>. In instances in which a radio link issue arises for a current route, for example, a radio link issue between the MT <NUM> and the serving IAB <NUM>, or between the IAB <NUM> and its parent node, the IAB system is required to (for example, quickly) select an alternate route. The example embodiments provide mechanisms that adapt the topology in a sufficient manner to adapt to the blocking in mmWave, which happens over very short time-scales. In contrast, RRC mechanisms that adapt the topology, including handover and changes in dual-connectivity, may be insufficient.

With regard to DC, 3GPP specifies that packet routing to the MCG vs SCG is done at the PDCP layer (see TS37. In the L2 architectures, the PDCP layer is in the donor-CU, as indicated in the <FIG>. Consequently, for a packet to be rerouted the packet must first be sent a second time from the donor-CU to the branching point. For example, in scenario <NUM><NUM>, due to the link outage between IAB21 <NUM>-<NUM> and IAB32 <NUM>-<NUM>, IAB11 <NUM>-<NUM> cannot send the DL packets to IAB21 <NUM>-<NUM> without first receiving the packet a second time from the donor-CU <NUM>. This may require the donor CU to resend the DL packets to IAB11 after failure has been detected downstream in instances in which IAB11 <NUM>-<NUM> already successfully received them. Only then can IAB11 <NUM>-<NUM> send the packet over the alternative path (through IAB22 <NUM>-<NUM>). In these instances, it is unnecessary to re-send those DL packets to IAB11.

The problems associated with packet routing as described by 3GPP are addressed by the example embodiments. The example embodiments remove (for example, obviate) the requirement for the donor CU to resend the DL packets to IAB11 <NUM>-<NUM> after failure has been detected downstream in instances in which IAB11 <NUM>-<NUM> already successfully received them.

With regard to the donor-CU <NUM>, in example embodiments, the systems described herein configure the donor DU <NUM> and IAB nodes <NUM> with routing information, or topology information from which routing information can be derived for the next node to reach MT <NUM> and the donor.

The donor-CU <NUM> may send the routes and preferences to branching nodes (for example, an intermediate IAB node <NUM>, or a Donor-DU <NUM>). The preference information may indicate a preferred route via at least one of route identifier and an identifier of a next hop. Branching nodes may include nodes that provide a branching point when routing communications through multiple different connected nodes (for example, IAB node <NUM>-<NUM> provides a branching point to IAB node <NUM>-<NUM> or <NUM>-<NUM>). The information may be sent via C-plane signalling using RRC or F1AP, or U-plane signalling by adding the preference information in an adaptation header, or both. Preference information indicates a preferred route (for example, via route ID or via the identifier of the next hop / next IAB node), and may additionally indicate circumstances when a branching point should switch to the less preferred route/branch or start duplicating packets and send them on both branches. When configuring preferences, donor-CU <NUM> may take into account the overall knowledge of the IAB topology as well as characteristics of the particular bearer, QoS flow or knowledge of the MTs <NUM> service or utilized network slice information. For example, for traffic requiring very low delay, donor-CU <NUM> may set a preferred route to the one having less hops even though that route is more congested at some point in time etc. The CU may also send the preference information to all IAB nodes to ask all IAB nodes to generate link event notification when the IAB node detects the link/route status is changed.

In example embodiments the IAB node and donor DU receive the routes and preference information from the CU (for example, donor-CU <NUM>) via C-plane or U-plane. The IAB node and Donor DU may generate link event notifications based on the configured preference information received from the CU. The preference may indicate when the link event notification should be generated and transmitted to a downstream node, or an upstream node.

The branching node receives the link event notification (for example, a link event indication) from the downstream and/or upstream IAB nodes <NUM> or donor. A link event notification may occur under several circumstances, which may be configurable or pre-specified, for example, when the throughput characteristics of a link changes significantly. Alternatively, a link event notification may occur when the number of HARQ retransmissions on a link reaches a certain number. In a further example, a link event notification may occur when the number of RLC ARQ retransmissions reaches a certain number. In a further example, a link event notification may occur when the signal strength is below a threshold, or above a threshold.

The branching node may adapt the uplink and/or downlink routes based on the route preference and the link event notifications. The branching node may also propagate the link event notification to all next-hop routes. The link event notifications may be binary (for example, no route available or link is resumed after declaring no route available). The link event notifications may also have several levels indicating link quality (for example, ranked <NUM> to <NUM>).

In example embodiments the IAB node <NUM>, or donor-DU <NUM> may generate link event notifications based on the configured preference information received from the CU, or based on its implementation if CU did not provide the preference information. The link event may be related to the downstream IAB node, or upstream IAB node. Link event notifications may be binary (for example, no route available or link is resumed after declaring no route available). Link event notifications may have several levels indicating link quality (for example, ranked <NUM> to <NUM>). The IAB node <NUM>, or Donor-DU <NUM> may propagate the link event notification to next downstream IAB node <NUM>, or upstream node. An intermediate IAB node may consolidate the received link event notification, and include it as part of the link event notification send to next downstream IAB node <NUM>, or upstream node <NUM>.

<FIG> (which is illustrated by connected <FIG> and <FIG>) is an example illustration of a call flow for an enhanced route selection in an integrated access and backhaul system <NUM>. <FIG> includes signalling between MT1 <NUM>-<NUM>, donor-DU <NUM>, donor-CU <NUM> and TABs <NUM> (IAB11 <NUM>-<NUM> to IAB <NUM><NUM>-<NUM>).

At step <NUM>, the IABs <NUM> may form connections with other IABs <NUM>. For example, IAB32 connects to IAB21 and IAB22. IAB21 and IAB22 connect to IAB11. IAB11 and IAB12 connect to Donor-DU).

At step <NUM>, MT1 <NUM>-<NUM> may connect to a primary node and add a secondary node (SN). For example, MT <NUM>-<NUM> connects to IAB32, then add IAB12 as SN).

At step <NUM>, according to an example embodiment, donor-CU <NUM> configures donor-DU <NUM>, and IAB nodes <NUM> on how to route the DL traffic to MT1 <NUM>-<NUM>. The configuration may only require messaging to inform (for example, to tell) the DU (or intermediate IAB node <NUM>) about the next IAB node <NUM> to reach MT1 <NUM>-<NUM>.

According to an example embodiment, the configuration determined by the donor-CU <NUM> may be DU: {IAB <NUM>, IAB12}; both IAB11 and IAB12 can be the next node (for example, the next node in a routing sequence) to reach MT1 <NUM>-<NUM> (from DU <NUM>). In other words, donor-CU <NUM> configures donor-DU <NUM> to select from an option of either (or both) IAB11 and IAB12. Similarly, donor-CU <NUM> may configure IAB11 <NUM>-<NUM>: {IAB21, IAB22}; both IAB21 <NUM>-<NUM> and IAB22 <NUM>-<NUM> can be (selected as) the next node to reach MT1 <NUM>-<NUM>. IAB21: {IAB32}; IAB32 can be the next node to reach MT1. IAB22: {IAB32}; IAB32 can be the next node to reach MT1.

For branching node (for example, DU <NUM> and IAB11 <NUM>-<NUM>), the configuration also includes a preference. For example, for donor-DU <NUM>, the configuration may indicate that IAB11 <NUM>-<NUM> is preferred than IAB12 <NUM>-<NUM>. Alternatively, this preference may be set per every DL packet. In that case, the preference may be included in the adaptation header of every DL packet.

A further implementation may include both a preference indicated in the initial configuration and an updated preference set per every DL packet. For example, when the adaptation header of the DL packet does not include a preference, the configured preference may be used. When the adaptation header of the DL packet includes a preference, the received preference may be used, instead of the configured preference. The preference information may also include circumstances when a branching node should switch to the less preferred route/branch or start duplicating packets and send them on both branches. The configuration may also include the UE's <NUM> context, for example, quality of service (QoS) for each dedicated radio bearer (DRB) and/or QoS flow. The preference information may also include circumstances when the link event notification needs to be sent to upstream or downstream nodes (for example, throughput drop, number of HARQ or ARQ retransmissions, signal strength, etc.).

At step <NUM>, donor-CU <NUM>, in some example embodiments, sends the DL data to donor-DU <NUM> for MT1 <NUM>-<NUM>. Donor-DU <NUM> may decide to send the DL data to IAB11 <NUM>-<NUM>, which is then sent to MT1 <NUM>-<NUM> via IAB21 <NUM>-<NUM> → IAB32 <NUM>-<NUM> → MT1 <NUM>-<NUM>. The donor-CU/DU may also include additional information in the adaptation header. For example, the donor-CU/DU may indicate IAB21 <NUM>-<NUM> is preferred then IAB22 <NUM>-<NUM>. This information may be used by the branching node (for example, IAB11 <NUM>-<NUM>) to determine the next node to reach MT1 <NUM>-<NUM>.

At step <NUM>, IAB21 may detect a radio link outage between IAB21 and IAB32. In this instance, since IAB21 does not have any other node that can be used to reach MT1, IAB21 informs its upstreaming IAB <NUM>, for example, IAB11 <NUM>-<NUM>, about the link event. For example, IAB21 <NUM>-<NUM> cannot be used for MT1 <NUM>-<NUM>.

At step <NUM>, donor-CU <NUM> may send DL data to donor-DU <NUM>. Donor-DU <NUM> may then send the DL data to IAB11 <NUM>-<NUM>. Based on the previously received configuration and the link event, IAB11 <NUM>-<NUM> may select a different route, for example, via IAB22, for MT1 <NUM>-<NUM>. DL data may be sent to MT1 <NUM>-<NUM> via IAB11 <NUM>-<NUM> - IAB22 <NUM>-<NUM> - IAB32 <NUM>-<NUM> - MT1 <NUM>-<NUM>. In this case, IAB11 may have at least one alternative route to MTs <NUM>, so IAB11 <NUM>-<NUM> may not forward the link event notification to its upstream nodes.

At step <NUM>, for example at a later time, IAB22 <NUM>-<NUM> may also detect a radio link outage between IAB22 <NUM>-<NUM> and IAB32 <NUM>-<NUM>. In this instance, since IAB22 <NUM>-<NUM> does not have any other node that can be used to reach MT1 <NUM>-<NUM>, IAB22 <NUM>-<NUM> may inform its upstreaming IAB <NUM> (for example, IAB11 <NUM>-<NUM>) about the link event. For example, (the upstreaming IAB <NUM> may be informed that) IAB22 <NUM>-<NUM> cannot be used for MT1 <NUM>-<NUM>.

At step <NUM>, IAB11 <NUM>-<NUM> may determine (for example, know) that both nodes have problems (for example, are currently incapable of routing data). Since IAB11 <NUM>-<NUM> does not have any other node that can be used to reach MT1 <NUM>-<NUM>, IAB11 <NUM>-<NUM> may inform its upstream node, for example, donor-DU <NUM>, in this example. Donor-DU may (then) know that IAB11 <NUM>-<NUM> cannot be used to reach MT1 <NUM>-<NUM>. Based on the configuration received in step <NUM> and link event, donor-DU <NUM> may know (for example, determine based on the configuration) that IAB12 <NUM>-<NUM> can be used to reach MT <NUM>.

At step <NUM>, donor-CU <NUM> may send DL data to donor-DU <NUM>. Donor-DU <NUM> may select a different route, for example, via IAB12 <NUM>-<NUM>, for MT1 <NUM>. DL data may be sent to MT1 <NUM>-<NUM> (for example, via IAB12 <NUM>-<NUM> - MT1 <NUM>-<NUM>).

At step <NUM>, for example at a later time, IAB22 <NUM>-<NUM> may detect the radio link to IAB32 <NUM>-<NUM> has resumed. IAB22 <NUM>-<NUM> may inform its upstreaming IAB node <NUM>, for example, IAB11 <NUM>-<NUM>, that IAB22 <NUM>-<NUM> can be used for MT1 <NUM>-<NUM>.

At step <NUM>, since IAB11 <NUM>-<NUM> does not have any active route for MT1 <NUM>-<NUM>, IAB11 <NUM>-<NUM> may inform its upstreaming node, for example, donor-DU, that IAB11 <NUM>-<NUM> may be used for MT1 <NUM>-<NUM>. Since IAB11 <NUM>-<NUM> is preferred based on previous configuration received in step <NUM>, donor-DU <NUM> may use IAB11 <NUM>-<NUM> for further DL data delivery to MT1 <NUM>.

Donor-CU <NUM> may send DL data to donor-DU <NUM>. Donor-DU <NUM> may send the DL data to MT1 <NUM>-<NUM> via the route of, IAB11 <NUM>-<NUM> - IAB22 <NUM>-<NUM> - IAB32 <NUM>-<NUM> - MT1 <NUM>-<NUM>.

The link event notification used in steps <NUM>/<NUM>/<NUM> may have the following characteristics. The link event notification may indicate to upstream IAB nodes <NUM> that an outage has occurred or of a poor quality of a radio link, or that the node <NUM> has recovered from the outage, that a change of the link quality of a radio link with downstream IAB nodes <NUM>, or that an access MT <NUM> has been detected. The link event notification may also be related to the upstream node. This may be used by a downstream IAB node <NUM> to select an upstream IAB node <NUM> in case of UL radio link issue or recovery with current upstream IAB node <NUM> (not shown in the call flow of <FIG>). The detection may be based on the pre-configured or pre-specified conditions mentioned above (for example, throughput drop, number of HARQ or ARQ retransmissions, signal strength, etc.). The IAB node implementation may determine how/when the link event notification is detected, based on the configuration received from donor-CU.

The notification may be delivered in the following way: Within the adaptation layer header of the F1-U (or data) packet of the IAB MT sent to donor-CU <NUM>. In instances in which the link event notification is placed on adaptation layer, not only donor-CU <NUM>, but all the intermediate nodes may read and interpret this information as well and act upon the information included in the link event notification immediately.

Alternatively, the notification may be delivered within RRC message between IAB MT and Donor-CU. In this case, the information may not be interpreted by the intermediate nodes and would traverse them transparently. In these instances, the intermediate nodes just relay the message and do not examine the content of the message. Upon receiving link event notification from a certain IAB MTs, donor-CU <NUM> would be required to propagate this information to all affected IAB nodes either via RRC signalling to IAB MTs or via F1-AP signalling to IAB DUs.

Providing the notification in the adaptation layer header may result in less signalling delay and overhead. <FIG> illustrates messaging within the adaptation layer header.

<FIG> is an example flow diagram <NUM> illustrating a method in accordance with example embodiments which may be performed by an apparatus.

At block <NUM>, a donor-CU <NUM> device (for example, an apparatus, module or component) may configure a donor-DU <NUM> device and IAB nodes <NUM> with routing information. In some instances, the donor-CU <NUM> device may configure the devices directly with the routing information. Alternatively, donor-CU <NUM> device may configure with topology information from which routing information can be derived for the next node to reach MT <NUM> and the donor.

At block <NUM>, donor-CU <NUM> device configures donor-DU <NUM> device and IAB nodes <NUM> with preferences. Preference information may indicate a preferred route (for example, via route ID or via the identifier of the next hop / next IAB node), and may additionally indicate circumstances when a branching point should switch to the less preferred route/branch or start duplicating packets and send them on both branches. The preference information may also include circumstances when the link event notification needs to be sent to upstream or downstream nodes (for example, when throughput is below or above a threshold, or when number of HARQ or ARQ retransmissions exceed or less than a threshold, or when signal strength is below or above a threshold, etc.).

When configuring preferences, donor-CU <NUM> may take into account the overall knowledge of the IAB topology as well as characteristics of the particular bearer, QoS flow or knowledge of the MTs <NUM> service or utilized network slice information. Network slices are defined in TS23. Network slices are used to allocated resources in the network according to: <NUM> - A Slice/Service type (SST), which refers to the expected network Slice behavior in terms of features and services; and <NUM> A Slice Differentiator (SD), which is optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices of the same Slice/Service type. The SST may differentiate between, for example, ultra-low latency from mobile broadband from Internet of Things (IoT). The SD may example separate service between two customers (for example, between Citibank and Wells Fargo [tm]).

At block <NUM>, donor-CU <NUM> may send the routes and preferences to branching nodes. The donor-CU <NUM> may send the information via C-plane signalling using RRC or F1AP, or U-plane signalling by adding the preference information in the adaptation header, or both. Donor-CU <NUM> may also send the routes and preference information to all related IAB nodes via C-plane signalling using RRC or F1AP, or U-plane signalling by adding the preference information in the adaptation header, or both.

<FIG> is an example flow diagram <NUM> illustrating a method in accordance with the claimed invention.

At block <NUM>, branching IAB node <NUM> or donor-DU <NUM> receives the routes and preference information from donor-CU <NUM>. The branching IAB node <NUM> or donor-DU <NUM> receives the routes and preference information from the CU <NUM> via C-plane or U-plane. The other IAB node <NUM> may also receive the preference information from the CU <NUM> via C-plane or U-plane.

At block <NUM>, the IAB node <NUM> or donor-DU <NUM> may generate link event notifications based on the configured preference information received from the donor-CU <NUM>. In case the donor-CU <NUM> does not provide the preference information regarding when the link event should be generated, the IAB node <NUM> may generate link event notification based on its implementation. The IAB node <NUM> or donor-DU <NUM> may transmit the link event notification to a downstream node, or a upstream node. The link event notification may be propagated by the intermediate IAB node until it reaches a branching node (for example, an IAB node <NUM>, or a donor-DU <NUM>).

At block <NUM>, branching node (for example, IAB node <NUM> or donor-DU <NUM>) may receive the link event notification from the downstream and/or upstream IAB nodes <NUM> or donor. A link event notification may occur under several circumstances, which may be configurable or pre-specified, for example, when the throughput characteristics of a link changes significantly, when number of HARQ retransmissions on a link reaches a certain number, when number of RLC ARQ retransmissions reaches a certain number, etc..

At block <NUM>, branching IAB node <NUM> or donor-DU <NUM> may adapt the uplink and/or downlink routes based on the route preference and the link event notifications.

At block <NUM>, the IAB node <NUM> or donor-DU <NUM> may propagate the link event notification to all next-hop routes.

Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that routes can be adapted to the current radio conditions much quicker than with RRC signalling. In some instances, for example, sudden blockage of the radio path may result in very poor radio conditions. In these instances, the usage of RRC signalling may not be possible (or advisable) due to a high likelihood that the required RRC messages would not be delivered to the target node (for example, measurement report from MT <NUM> to donor-CU <NUM>). Another technical effect is that less signalling is required. For example, donor-CU may be unaware of the route selection, but CU still have the control by providing configuration of preference information. The example embodiments may be applied to either access UEs or MT part of the IAB node (in both cases, UE/MT is connected to two separate upstream IAB nodes using Dual-Connectivity).

Configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with routing information may further comprise at least one of: configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node directly with routing information; and configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with topology information from which the routing information is derivable.

Sending the routing information and the preference information may further comprise: sending the routing information and the preferences via at least one of: C-plane signalling using at least one of radio resource control and front haul application protocol, and U-plane signalling by adding the preference information in at least one adaptation header.

The preference information may indicates a preferred route via at least one of route identifier and an identifier of a next hop.

The preference information may further indicates at least one of a circumstance at which a branching point is to switch to a less preferred route, a circumstance at which the branching point is to start duplicating packets and sending the duplicated packets on each of at least two branches at the branching point, and a circumstance at which an integrated access and backhaul node send a link event notification.

Configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with the preference information may further comprise: configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node based on at least one of an overall knowledge of an integrated access and backhaul node topology; at least one characteristic of at least one particular bearer; at least one quality of service flow; and utilized network slice information.

The preference information may indicate a preferred route via at least one of route identifier and an identifier of a next hop.

The received preference information may further indicate at least one of: a circumstance at which a branching point is to switch to a less preferred route, a circumstance at which the branching point is to start duplicating packets and sending the duplicated packets on each of at least two branches at the branching point, and a circumstance at which an integrated access and backhaul node send a link event notification.

At least one link event notification may be transmitted when at least one of: throughput characteristics of a link changes significantly; a number of hybrid automatic repeat request retransmissions on a link reaches a particular number; a number of radio link control automatic repeat request retransmissions reaches a particular number, and the radio link availability or route availability is changed.

Transmitting the at least one link event notification may further comprise: transmitting 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.

Receiving the at least one link event notification may further comprise: receiving 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 donor.

At least one link event notification may further comprise at least one of: a binary indication of a radio link availability, or a route availability, or a link is resumed after declaring no route available; and several levels indicating radio link quality.

Means for configuring the at least one of at least one donor distributed unit and the at least one intermediate integrated access and backhaul node with routing information may further comprise at least one of: means for configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node directly with routing information; and means for configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with topology information from which the routing information is derivable.

Means for sending the routing information and the preference information may further comprise: means for sending the routing information and the preferences via at least one of: C-plane signalling using at least one of radio resource control and front haul application protocol, and U-plane signalling by adding the preference information in at least one adaptation header.

The preference information may further indicate at least one of a circumstance at which a branching point is to switch to a less preferred route, a circumstance at which the branching point is to start duplicating packets and sending the duplicated packets on each of at least two branches at the branching point, and a circumstance at which an integrated access and backhaul node send a link event notification.

Means for receiving the at least one link event notification may further comprise: means for receiving 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 a donor.

When configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with routing information, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to at least one of: configure the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node directly with routing information; and configure the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with topology information from which the routing information is derivable.

When sending the routing information and the preference information, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to send the routing information and the preferences via at least one of: C-plane signalling using at least one of radio resource control and front haul application protocol, and U-plane signalling by adding the preference information in at least one adaptation header.

When configuring the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node with the preference information, the at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to configure the at least one of at least one donor distributed unit and the at least one integrated access and backhaul node based on at least one of an overall knowledge of an integrated access and backhaul node topology; at least one characteristic of at least one particular bearer; at least one quality of service flow; and utilized network slice information.

Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware. In an example embodiment, the software (e.g., application logic, an instruction set) is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in <FIG>. A computer-readable medium may comprise a computer-readable storage medium (e.g., memories <NUM>, <NUM>, <NUM> or other device) that may be any media or means that can contain, store, and/or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. A computer-readable storage medium does not comprise propagating signals.

Although various aspects are set out above, other aspects comprise other combinations of features from the described embodiments, and not solely the combinations described above.

It is also noted herein that while the above describes example embodiments, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof.

Embodiments may be practiced in various components such as integrated circuit modules.

The foregoing description has provided by way of example and non-limiting examples a full and informative description of the best method and apparatus presently contemplated by the inventors for carrying out the invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention.

It should be noted that the terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and/or printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as several non-limiting and non-exhaustive examples.

Claim 1:
A branching node (<NUM>, <NUM>), in an integrated access and backhaul topology, the branching node providing a branching point to integrated access and backhaul nodes (<NUM>) in the integrated access and backhaul topology, the branching node (<NUM>, <NUM>) comprising:
means for receiving (<NUM>) information indicating at least a more preferred integrated access and backhaul next node and a less preferred integrated access and backhaul next node for reaching at least one mobile terminal and/or at least one donor distributed unit in the integrated access and backhaul node topology, wherein the information indicates the more preferred integrated access and backhaul next node via at least a route identifier;
means for transmitting (<NUM>) and/or receiving (<NUM>) at least one link event notification; and
means for selecting an integrated access and backhaul next node for reaching the at least one mobile terminal or the at least one donor distributed unit, based on the information and the at least one link event notification.