RELATED APPLICATIONS

[0001] This application claims the benefits of priority of U.S. Provisional Patent Application No. 63/111,310, entitled “Methods for informing lAB-Donor-CU about the local decisions” and filed at the United States Patent and Trademark Office on November 9, 2020, the content of which is incorporated herein by reference.

TECHNICAL FIELD

[0002] The present description generally relates to wireless communication systems and more specifically to Integrated Access and Backhaul (IAB) networks that support local decisions.

BACKGROUND

[0003] Integrated Access Backhaul Networks

[0004] Protocol and Architecture overview

[0005] Third Generation Partnership Project (3GPP) is currently standardizing integrated access and wireless access backhaul (IAB) in New Radio (NR) in Release-17.

[0006] The usage of short range mmWave spectrum in NR creates a need for densified deployment with multi-hop backhauling. However, optical fiber to every base station will be too costly and sometimes not even possible (e.g. historical sites). The main IAB principle is the use of wireless links for the backhaul (instead of fiber) to enable flexible and very dense deployment of cells without the need for densifying the transport network. Use case scenarios for IAB can include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA) (e.g. to residential/office buildings). The larger bandwidth available for NR in mmWave spectrum provides opportunity for self-backhauling, without limiting the spectrum to be used for the access links. On top of that, the inherent multi-beam and Multiple Input Multiple Output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.

[0007] During the study item phase of the IAB work (summary of the study item can be found in the technical report TR 38.874), it has been agreed to adopt a solution that leverages the Central Unit (CU)/Distributed Unit (DU) split architecture of NR, where the IAB node will be hosting a DU part that is controlled by a central unit. The IAB nodes also have a Mobile Termination (MT) part that they use to communicate with their parent nodes. [0008] The specifications for IAB strive to reuse existing functions and interfaces defined in NR. In particular, MT, gNB-DU, gNB-CU, User Plane Function (UPF), Access and Mobility Management Function (AMF) and Session Management Function (SMF) as well as the corresponding interfaces NR Uu (between MT and gNB), F 1 , NG, X2 and N4 are used as baseline for the IAB architectures. Modifications or enhancements to these functions and interfaces for the support of IAB will be explained in the context of the architecture discussion. Additional functionality such as multi-hop forwarding is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.

[0009] The Mobile-Termination (MT) function has been defined as a component of the IAB node. In the context of this study, MT is referred to as a function residing on an lAB-node that terminates the radio interface layers of the backhaul Uu interface toward the lAB-donor or other lAB-nodes. [0010] FIG. 1 shows a reference diagram for the IAB architecture in standalone mode, which contains one lAB-donor and multiple lAB-nodes. For example, FIG. 1 shows a high-level architectural view of an IAB network. The lAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP (Control Plane), gNB-CU-UP (User Plane) and potentially other functions. In a deployment, the lAB-donor can be split according to these functions, which can all be either collocated or non-collocated as allowed by 3 GPP Next Generation- Radio Access Network (NG-RAN) architecture. lAB-related aspects may arise when such split is exercised. Also, some of the functions presently associated with the lAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform lAB-specific tasks.

[0011] The baseline user plane and control plane protocol stacks for IAB are shown in FIGs. 2-3. [0012] As shown in FIGs. 2 and 3, the chosen protocol stacks reuse the current CU-DU split specification in Release- 15, where the full user plane Fl-U (GPRS Tunneling Protocol (GTP)- U/User Datagram Protocol (UDP)/ Internet Protocol (IP)) is terminated at the IAB node (like a normal DU) and the full control plane Fl-C (Fl -Access Point (AP)/Stream Control Transmission Protocol (SCTP)/IP) is also terminated at the IAB node (like a normal DU). In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic (Internet Protocol Security (IPsec) in the case of UP, and Datagram Transport Layer Security (DTLS) in the case of CP). IPsec could also be used for the CP protection instead of DTLS (in this case no DTLS layer would be used). [0013] A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is used for routing packets to the appropriate downstream/upstream node and also mapping the User Equipment (UE) bearer data to the proper backhaul Radio Link Control (RLC) channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end Quality of Service (QoS) requirements of bearers.

[0014] BAP entities

[0015] On the lAB-node, the BAP sublayer contains one BAP entity at the MT function and a separate collocated BAP entity at the DU function as shown in FIGs. 2 and 3, in which the Adapt layer corresponds to the BAP layer. On the lAB-donor-DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of a BAP entity at the lAB-node or lAB-donor- DU across the backhaul link.

[0016] BAP routing

[0017] Donor IAB nodes and access IAB nodes decide on the destination and route packets based on the routing tables which the network configures for each of the IAB nodes. FIG. 4 illustrates a BAP data Protocol Data Unit (PDU) format, which comprises fields for a BAP header and data. The BAP header contains two fields, “Destination” and “BAP path identity”, which will be used by intermediate nodes to route the packets to the next IAB node. Intermediate nodes do not change the destination, or the path identity contained in the BAP header. The only exception is when the IAB node experiences a Radio Link Failure (RLF). In this situation, the transmitter (of the intermediate node) may update the BAP header to re-route packets via a new path to reach its destination.

SUMMARY

[0018] There are some challenges with the existing solutions. 3GPP Rel-16 specifications for IAB network support the rerouting of traffic for uplink (only for intra-DU) and downlink (DL) performed by the intermediate IAB nodes under the condition of experiencing a RLF. For rerouting the traffic, the intermediate IAB nodes will use the destination BAP address carried in the packets’ headers to find an appropriate alternative egress BackHaul (BH) link for forwarding the packets when the actual/intended egress BH link is no longer available (due to RLF). However, for Rel-17 IAB enhancements, companies are discussing the extension of local rerouting to scenarios other than RLF (e.g., load balancing, link congestion, etc.) as well as for inter-DU case for Uplink (UL) traffic. The local decisions made by an intermediate IAB node either to avoid link congestion or create load balance are made on limited/local information and these decisions might have implications on the other links or part of the network. Thus, to avoid a situation where local decisions lead the overall IAB network to a suboptimal level, the lAB-Donor-CU should be informed of why and which intermediate IAB nodes made a local decision.

[0019] The present disclosure proposes a mechanism used by the intermediate IAB nodes and lAB-Donor-DUs to inform the lAB-Donor-CU about which IAB node and for what purpose the IAB node made local decisions, thus enabling the lAB-Donor-CU to take appropriate actions for keeping the overall IAB network in an optimal state.

[0020] According to an aspect, some embodiments include methods performed by a network node. A method may comprise: determining that a received data packet needs to change a routing path from a first routing path to a second routing path; and sending the data packet to a next IAB node based at least on the second routing path, wherein the data packet includes an indication of the change of routing path.

[0021] According to another aspect, some embodiments include a network node configured, or operable, to perform one or more functionalities (e.g. actions, operations, steps, etc.) as described herein, such as the above method.

[0022] In some embodiments, the network node may comprise one or more communication interfaces configured to communicate with one or more other radio nodes and/or with one or more network nodes, and processing circuitry operatively connected to the communication interface, the processing circuitry being configured to perform one or more functionalities as described herein. In some embodiments, the processing circuitry may comprise at least one processor and at least one memory storing instructions which, upon being executed by the processor, configure the at least one processor to perform one or more functionalities as described herein.

[0023] In some embodiments, the network node may comprise one or more functional modules configured to perform one or more functionalities as described herein.

[0024] According to yet another aspect, some embodiments include a non-transitory computer- readable medium storing a computer program product comprising instructions which, upon being executed by processing circuitry (e.g., at least one processor) of the network node, configure the processing circuitry to perform one or more functionalities as described herein.

[0025] The advantages/technical benefits of the embodiments of the present disclosure are: [0026] - The embodiments enable the network to monitor the IAB nodes which are re-routing packets, which allows the CU to trigger reconfigurations and adapt routing tables. [0027] - They enable the network to know which IAB nodes may be experiencing overload or having other issues, e.g. RLF, congestion, buffer overflow, lack of mapping rules, etc.

[0028] This summary is not an extensive overview of all contemplated embodiments and is not intended to identify key or critical aspects or features of any or all embodiments or to delineate the scope of any or all embodiments. In that sense, other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Exemplary embodiments will be described in more detail with reference to the following figures, in which:

[0030] FIG. 1 illustrates a reference diagram for lAB-architectures (see for example 3 GPP TR 38.874).

[0031] FIG. 2 illustrates a baseline User Plane (UP) Protocol stack for IAB in rel-16.

[0032] FIG. 3 illustrates a baseline Control Plane (CP) Protocol stack for IAB in rel-16.

[0033] FIG. 4 illustrates an example of a BAP data PDU format.

[0034] FIG. 5 illustrates an example of an IAB network.

[0035] FIG. 6 is an example of data packet rerouting in the IAB network of FIG. 5.

[0036] FIG. 7 illustrates an example of a BAP packet header according to some embodiments.

[0037] FIG. 8 illustrates a signaling diagram for data packet rerouting in an IAB network, according to some embodiments.

[0038] FIGs. 9-10 are flow charts of a method in a network node, in accordance with an embodiment.

[0039] FIG. 11 illustrates one example of a wireless communications system in which embodiments of the present disclosure may be implemented.

[0040] FIGs. 12 and 13 are block diagrams that illustrate a wireless device according to some embodiments of the present disclosure.

[0041] FIGs. 14 and 15 are block diagrams that illustrate a network node according to some embodiments of the present disclosure.

[0042] FIG. 16 illustrates a virtualized environment of a network node, according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0043] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

[0044] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

[0045] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0046] As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

[0047] As a note, the terms “lAB-Donor-CU” and “Donor-CU” can be used interchangeably. The terms “lAB-Donor-DU”, “Donor-DU”, and “DU” can be used interchangeably. The terms “BAP destination address” and “BAP address” can be used interchangeably. The term “intermediate IAB node” can be used to address/refer to an IAB node which receives data from an ingress BH Radio Link Control (RLC) channel from another IAB node or IAB donor DU, and which transmits data on an egress channel to another IAB node or to the IAB donor DU.

[0048] This disclosure uses the methods presented in the application with application number US63/0944977 that provided mechanisms to enhance uplink (UL) traffic rerouting for the inter- DU case and indicate to the lAB-Donor-DU that a packet had been rerouted. In other words, the IAB nodes uses the BAP protocol to route the packets. The present disclosure covers the following additional methods to indicate:

[0049] - The identity/identifier (ID) of an intermediate IAB node that made a local decision.

[0050] - The type of local decision (e.g., rerouting, link congestion, load balancing, etc.).

[0051] - Whether the decision is made for the UL or DL traffic.

[0052] - All the information received by lAB-Donor-DU to lAB-Donor-CU.

[0053] FIG. 5 illustrates an example of an IAB network, in which different paths are configured. For example, 3 uplink paths from IAB4 to Donor CU are provided as follows:

[0054] - Path 1 : IAB4-IAB1-DU1;

[0055] - Path 2: IAB4-IAB3-IAB1-DU1;

[0056] - path 3: IAB4-IAB3-IAB2-DU2.

[0057] Also, two uplink paths from IAB5 to Donor CU are configured as follows:

[0058] - Path 1 : 1 AB 5 -IAB 3 -I AB 1 -DU 1;

[0059] - Path 2: IAB5-IAB3-IAB2-DU2.

[0060] The present disclosure provides embodiments/methods for situations where an IAB node decides, locally, to change or modify the route configured for a BAP packet. For example, the route can be derived from the fields “BAP address” and “BAP path ID” in the BAP header (see FIG. 4) and the mapping rules configured by the network. To indicate the local decisions to a network node (such as the Donor CU), the IAB node can utilize/incorporate to the BAP header one or more fields. More specifically, different examples are given below to illustrate indications of different information.

[0061] How an intermediate IAB node will indicate to lAB-Donor-CU the type of local decision

[0062] In an example, the BAP header can include a new field to indicate the “type of local decision”. This field may have 2 to 4 bits. An IAB node will add this field in the BAP header of a packet to indicate the type of local decisions being made by the IAB node. For instance, the intermediate IAB node can set the bits to 001 for rerouting due to RLF, 010 for rerouting due to link congestion, 011 for creating load balancing, etc. The IAB node can get this information, i.e., how to set the bits for reporting different types of local decisions via F 1 signaling or via Operation Administration and Management (0AM). Alternatively, the codepoints could be specified in a standard specification, such as 3GPP. An example of this field is shown in FIG. 7. This field is referred to as the “type field”. [0063] How an intermediate IAB node will indicate to lAB-Donor-CU whether the local decision is made for the UL or DL traffic

[0064] In an example, the BAP header can include a new field to indicate whether the decision is related to DL or UL traffic. The intermediate nodes can employ a bit flag to indicate whether the node made a decision for DL or UL traffic. For instance, the bit flag can be set to 0 for UL traffic and 1 for DL traffic, or vice versa. For the UL traffic, this bit can be set (to 0 or 1) directly in packets/traffic for which the decision is made. However, for the decision made for the DL traffic, this bit can be used implicitly to convey an indication to the lAB-Donor-CU, i.e., will be set (to 1 or 0) in the UL packets originated from the IAB node to the lAB-Donor-CU. The intermediate IAB nodes can get this information, i.e., how to indicate to lAB-Donor-CU whether the decision is made for UL or DL traffic via Fl signaling or via 0AM. An example of this field is shown in FIG. 7. This field is referred to as the “UL” field.

[0065] How an intermediate IAB node and lAB-Donor-DU that made a local decision will indicate its identity (ID) to lAB-Donor-CU

[0066] In an example, the BAP header can include a new field to indicate the “IAB ID”. An IAB node can employ 3 to 4 bits (or more bits) in the BAP header for indicating its ID, when making a local decision, such as packet rerouting. The lAB-Donor-CU can first assign a node ID per path (via Fl -signaling or the IAB node can get this information from 0AM) to each IAB node. The assigned node ID can be used by the IAB nodes to indicate their identities when making the local decisions. For example, for the network topology shown in FIG. 5, the lAB-Donor-CU can assign node ID 1, 2, 3 to IAB4, IAB1, lAB-Donor-DUl, respectively, for Path 1 from IAB4 to Donor- CU. The Donor-CU can assign node ID 1, 2, 3, 4 to IAB4, IAB3, IAB1, lAB-Donor-DUl, respectively, for Path 2 from IAB4 to Donor-CU. Thus, when IAB4 makes a local decision (e.g., reroute the UL traffic originally intended for Path 1 towards Path 2), IAB4 can set the bits in the BAP header to 001. Similarly, if IAB3 reroutes the UL traffic intended for Path 2 towards Path 1, it can set the bits in the BAP header to 010.

[0067] In another example, the intermediate IAB nodes can implicitly indicate their node ID per path rather than being assigned by lAB-Donor-CU. For instance, when IAB4 (of the network shown in FIG. 5, which is redrawn in FIG. 6) sends a packet using Path 2, it can use the Type of local decision field set to “000” (i.e., default value indicating normal packet), Traffic type flag set to “0” (to indicate UL traffic) and Node ID field set to “001” of the BAP header.

[0068] Let’s suppose that a packet is received by IAB3, and because of the unavailability of the BH link towards IAB1 (due to RLF as illustrated in FIG. 6), IAB3 decides to reroute the packet on Path 3 (i.e., on egress link toward IAB2). In this case, IAB3 sets the Type field to 001 (indication for rerouting due to RLF), Traffic type flag to 0 (indication for UL traffic) and increments the Node ID field value to 010. IAB3 then forwards the packet on the egress link toward IAB2. The IAB2, when receiving the packet, notices the Type field value (i.e., 001), which is different from the default value (i.e., 000). It will just forward the packet on its egress link towards IAB-Donor-DU2 without incrementing the Node ID field value. Thus, when lAB-Donor- DU2 finally receives the packet, from the Node ID field value (i.e., 010) it will know that the second node on Path 2 (IAB4-IAB3-IABl-IAB-Donor-DUl) has an RLF in one of its egress and because of this RLF, the packet is rerouted. FIG. 7 illustrates an example of a BAP header 20 (or a packet header) with different fields. The BAP header 20 comprises an example of a field for indicating the Node ID. For example, this field is referred to as the “ID” field 22 as shown in FIG. 7.

[0069] As an alternative, the node ID could be the BAP address of the node that made the decision to re-route the packet. The BAP address can be indicated in the BAP address field 28 in the BAP header 20, for example.

[0070] The above examples can be independent from each other, e.g. implemented separately from each other, or, they could be implemented as a combination.

[0071] As shown, FIG. 7 illustrates a BAP header, which includes all the above examples, e.g. the BAP header includes a Type field 24, an ID field 22 and a traffic type (UL/DL) field 26. The BAP header 20 can comprise also other fields, such as reserved (R) bits/fields.

[0072] How the information received by lAB-Donor-DU from intermediate IAB nodes will be conveyed to lAB-Donor-CU

[0073] In another example, the lAB-Donor-DU can employ the Fl signaling to report the information it has received in the BAP header (of a received packet) about the local decisions to lAB-Donor-CU. For this purpose, either the existing Fl-C message can be enhanced with some new Information Elements (IES) or a new Fl-C message can be specified. The Fl-C message (whether new or an enhanced version of the existing message) will indicate the following information: the intermediate node ID, the type of decision and the direction (i.e., UL or DL); this information is acquired from the BAP header of the received packets, for example.

[0074] A related issue is how frequent the lAB-Donor-DU will send this information to the IAB- Donor-CU. For example, if the Donor-DU receives continuous packets from an intermediate IAB node with the same information (i.e., same node ID, decision type, and direction of traffic), the lAB-Donor DU can inform or send an Fl-C message to Donor-CU once or after every T seconds. To do so, the lAB-Donor-CU can configure a value (that will be reconfigurable) using the Fl-C message. Furthermore, the Donor-CU can send an acknowledgment message to Donor-DU that it (lAB-Donor-CU) has properly received the Fl-C message (carrying the information that Donor- DU got from the IAB node via a BAP header).

[0075] All the examples described above are applicable to situations where one or more intermediate IAB nodes make local decisions for a given packet, along the path from the source node (i.e., Access node or Donor-DU) to the destination node (i.e., Donor-DU or Access node). If an intermediate node receives a packet that is already rerouted by a descendant node, and the intermediate node has to reroute this packet again, then the intermediate node can reroute the packet but will not change the values in the Type field, Traffic type flag, and Node ID field of the packet header. Another possible option is to update the values of these fields to reflect the decision made by the most recent intermediate IAB node. Alternatively, a second IAB node that performs a re-routing could add an additional second set of fields in the header as described above. With the information in the additional fields, the CU will know each of the IAB nodes that made a rerouting and the reasons for the rerouting.

[0076] Turning to FIG. 8, a signaling diagram between different IAB nodes (in a chain of connected IAB nodes) for indicating routing changes will be described. For example, in block 50, an intermediate IAB node determines that there is a need to change routing paths (in response to determining a problem in a link, for example). As such, when the IAB node receives a data packet, it checks that its configured routing path for the next IAB node has a problem (e.g. link failure). Then, the IAB node determines a new routing path. Then, the IAB node sends the data packet to the next IAB node in the new routing path (block 52). The data packet includes an indication of the change of routing paths, for example. The next IAB node could send the data packet and the indication to the lAB-Donor-DU (block 54), which transmits the indication to the lAB-Donor-CU (block 56). The lAB-donor-DU can send the data packet to the lAB-donor-CU as well. By receiving all the indications of routing path changes from different intermediate IAB nodes, the lAB-Donor-CU can perform some operational tasks or make decisions or take actions to keep the network in an optimal state (block 58). In one alternative, the lAB-Donor-CU receives only the indication of change of routing paths from the most recent IAB node that made the determination of changing routing path.

[0077] Now turning to FIG. 9, a method 100 in an IAB node in a chain of connected lABs will be described. This method is implemented in the intermediate IAB node of FIG. 8, for example. The IAB node can be the network node 320 of FIG. 14 and IAB3 of FIG. 6, for example. Method 100 comprises:

[0078] Step 110: determining that a received data packet needs to change a routing path from a first routing path to a second routing path; and

[0079] Step 120: sending the data packet to a next IAB node based at least on the second routing path, wherein the data packet includes an indication of the change of routing path.

[0080] For example, when the IAB node receives a data packet, it checks if the data packet needs to be rerouted. If the IAB node detects or determines that there is a problem in a link, then, it decides that there is a need to reroute the data packets from a configured (or pre-defined) routing path to a new routing path. The configured routing path can be the first routing path and the new path can be the second routing path. The first routing path is different from the second routing path, for example.

[0081] As such, in some examples, determining the need of a change of routing paths is in response to determining a problem in a link of the configured/first routing path. For example, the problem in the link can include a radio link failure, a congestion in the link, a need to balance traffic in the link, low capacity of the link, slow link, etc.

[0082] In some examples, the indication of the change of routing paths can include one or more of: an indication of a reason for the change, an indication of an identity (ID) of the IAB node that determined the change, and an indication of a traffic type. The reason for the change can be a radio link failure, a congestion in a link or a need to balance in the link, etc. The traffic type can be UL or DL traffic.

[0083] In some examples, the indication of the reason for a change of routing path can be given by a first field in a backhaul adaptation protocol (BAP) header of the data packet. For example, the first field can have 2 to 4 bits.

[0084] In some examples, the indication of the identity (ID) of the IAB node can be given by a second field in a BAP header of the data packet. For example, the second field can have 3 to 4 bits.

[0085] In some examples, the ID of the IAB node can be assigned by a network node or the ID of the IAB node can be the BAP address of the IAB node.

[0086] In some examples, the indication of the traffic type can be given by a third field in a BAP header of the data packet. For example, the indication of the traffic type can be downlink or uplink traffic and the third field can have one bit (e.g. a flag). [0087] FIG. 10 illustrates a method 200 for a first network node, such as an IAB donor-DU connected to an lAB-Donor-CU (or second network node), both of them being in a chain of connected IAB nodes (see FIGs. 5 and 6 for an example of a chain of connected IAB nodes). For example, the first network node can be network node 320 of FIG. 14. Method 200 comprises: [0088] Step 210: sending, to the second IAB node, an indication of a change of a routing path from a first routing path to a second routing path for one or more data packets; and [0089] Step 220: receiving a response from the second IAB node.

[0090] In some examples, the indication of the change can be an indication of a reason for the change, an indication of an identity (ID) of an IAB node that determined the change or an indication of a traffic type, or a combination thereof. The reason can be a radio link failure in a link, a congestion in a link or a need to balance traffic in a link, etc. The type of traffic can be UL or DL traffic.

[0091] In some examples, the indication can be sent to the second IAB node via Fl signaling, using an enhanced Fl-C message or a new Fl -C message.

[0092] In some examples, the information can be sent to the second IAB node, once during a period of time or after each period of time.

[0093] In some examples, the sent indication is derived from a Backhaul Adaptation Protocol (BAP) header of data packets received at the first IAB node.

[0094] In some examples, the indication is from a most recent IAB node that made a local decision of changing routing paths.

[0095] In some examples, the indication is from each IAB node from the chain of connected IAB nodes that made a local decision of changing routing paths, e.g. changing from a configured/pre- defined/first routing path to a new/second routing path.

[0096] In some examples, the second IAB node can take some actions to keep the network in an optimal state based on the received indication.

[0097] In some examples, the first IAB node can be an IAB donor-DU and the second IAB node can be an lAB-Donor-CU.

[0098] There may be provided another method at the lAB-donor-CU of FIG. 8, for example. In this case, the method may comprise: receiving, from a second IAB node (e.g. an IAB -donor-DU), an indication of a change of a routing path from a first routing path to a second routing path for one or more data packets; and performing an operational task based at least on the indication. [0099] In some examples, the indication of a change of a routing path can comprise one or more indications of change of routing paths from one or more IAB nodes in the chain of connected IAB nodes.

[0100] In some examples, performing an operational task may comprise keeping a network in an optimal state, based at least on the indication. For example, the lAB-donor-CU can do some load balancing.

[0101] In some examples, the indication of change can comprise one or more of: an indication of a reason for the change, an indication of an identity (ID) of an IAB node that determined the change, and an indication of a traffic type.

[0102] FIG. 11 illustrates an example of a wireless network 300 that may be used for wireless communications. Wireless network 300 includes UEs 310 and a plurality of radio network nodes 320 (e.g., Node Bs (NBs) Radio Network Controllers (RNCs), evolved NBs (eNBs), next generation NB (gNBs), etc.) directly or indirectly connected to a core network 330 which may comprise various core network nodes. The network 300 may use any suitable radio access network (RAN) deployment scenarios, including Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UMTS Terrestrial Radio Access Network (EUTRAN). UEs 310 may be capable of communicating directly with radio network nodes 320 over a wireless interface. In certain embodiments, UEs may also be capable of communicating with each other via device-to-device (D2D) communication. In certain embodiments, network nodes 320 may also be capable of communicating with each other, e.g. via an interface (e.g. X2 in LTE or other suitable interface).

[0103] As an example, UE 310 may communicate with radio network node 320 over a wireless interface. That is, UE 310 may transmit wireless signals to and/or receive wireless signals from radio network node 320. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a radio network node 320 may be referred to as a cell.

[0104] It should be noted that a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine-to-machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc.

[0105] In some embodiments, the “network node” can be any kind of network node which may comprise of a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB, NR BS, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), a multistandard BS (also known as MSR BS), etc.), a core network node (e.g., MME, SON node, a coordinating node, positioning node, MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc. The network node may also comprise a test equipment. The network node 320 may be an IAB node, an IAB donor, an IAB donor-DU or an IAB donor-CU. Furthermore, the IAB node 320 may have components as a MT and/or DU.

[0106] In certain embodiments, network nodes 320 may interface with a radio network controller (not shown). The radio network controller may control network nodes 320 and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be included in the network node 320. The radio network controller may interface with the core network node 340. In certain embodiments, the radio network controller may interface with the core network node 340 via the interconnecting network 330.

[0107] The interconnecting network 330 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. The interconnecting network 330 may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

[0108] In some embodiments, the core network node 340 may manage the establishment of communication sessions and various other functionalities for wireless devices 310. Examples of core network node 340 may include MSC, MME, SGW, PGW, O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT node, etc. Wireless devices 110 may exchange certain signals with the core network node 340 using the non-access stratum layer. In non-access stratum signaling, signals between wireless devices 310 and the core network node 340 may be transparently passed through the radio access network. In certain embodiments, network nodes 320 may interface with one or more other network nodes over an internode interface. For example, network nodes 320 may interface each other over an X2 interface.

[0109] Although FIG.11 illustrates a particular arrangement of network 300, the present disclosure contemplates that the various embodiments described herein may be applied to a variety of networks having any suitable configuration. For example, network 300 may include any suitable number of wireless devices 310 and network nodes 320, as well as any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone). The embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards and using any suitable components and are applicable to any radio access technology (RAT) or multi-RAT systems in which the wireless device receives and/or transmits signals (e.g., data). While certain embodiments are described for NR and/or LTE, the embodiments may be applicable to any RAT, such as UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR, NX), 4G, 5G, LTE FDD/TDD, etc. The network 300 (with the wireless devices 310 and network nodes 320) may be able to operate in LAA or unlicensed spectrum.

[0110] FIG. 12 is a schematic block diagram of the wireless device 310 according to some embodiments of the present disclosure. As illustrated, the wireless device 310 includes circuitry 400 comprising one or more processors 410 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like) and memory 420. The wireless device 310 also includes one or more transceivers 430 each including one or more transmitters 440 and one or more receivers 450 coupled to one or more antennas 460. Furthermore, the processing circuitry 400 may be connected to an input interface 480 and an output interface 485. The input interface 480 and the output interface 485 may be referred to as communication interfaces. The wireless device 310 may further comprise power source 490.

[OHl] In some embodiments, the functionality of the wireless device 310 described above may be fully or partially implemented in software that is, e.g., stored in the memory 420 and executed by the processor(s) 410. For example, the processor 410 is configured to perform all the functionalities performed by the wireless device 310.

[0112] In some embodiments, a computer program including instructions which, when executed by the at least one processor 410, causes the at least one processor 410 to carry out the functionality of the wireless device 310 according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). [0113] FIG. 13 is a schematic block diagram of the wireless device 310 according to some other embodiments of the present disclosure. The wireless device 310 includes one or more modules 495, each of which is implemented in software. The module(s) 495 provide the functionality of the wireless device 310 described herein.

[0114] FIG. 14 is a schematic block diagram of a network node 320 according to some embodiments of the present disclosure. As illustrated, the network node 320 includes a processing circuitry 500 comprising one or more processors 510 (e.g., CPUs, ASICs, FPGAs, and/or the like) and memory 520. The network node also comprises a network interface 530. The network node 320 also includes one or more transceivers 540 that each include one or more transmitters 550 and one or more receivers 560 coupled to one or more antennas 570. In some embodiments, the functionality of the network node 320 described above may be fully or partially implemented in software that is, e.g., stored in the memory 520 and executed by the processor(s) 510. For example, the processor 510 can be configured to perform any steps of the methods 100 and 200 of FIG. s 9 to 10 respectively, when the network node 320 is an IAB node or an IAB donor-DU.

[0115] FIG. 15 is a schematic block diagram of the network node 320 according to some other embodiments of the present disclosure. The network node 320 includes one or more modules 580, each of which is implemented in software. The module(s) 580 provide the functionality of the network node 320 described herein, such as performing methods 100 and 200 of FIG. 9 and 10 respectively.

[0116] FIG. 16 is a schematic block diagram that illustrates a virtualized embodiment of the wireless device 310 or network node 320, according to some embodiments of the present disclosure. As used herein, a “virtualized” node 1200 is a network node 320 or wireless device 310 in which at least a portion of the functionality of the network node 320 or wireless device 310 is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). For example, in FIG. 16, there is provided an instance or a virtual appliance 1220 implementing the methods or parts of the methods of some embodiments. The one or more instance(s) runs in a cloud computing environment 1200. The cloud computing environment provides processing circuits 1230 and memory 1290-1 for the one or more instance(s) or virtual applications 1220. The memory 1290-1 contains instructions 1295 executable by the processing circuit 1260 whereby the instance 1220 is operative to execute the methods or part of the methods described herein in relation to some embodiments.

[0117] The cloud computing environment 1200 comprises one or more general-purpose network devices including hardware 1230 comprising a set of one or more processor(s) or processing circuits 1260, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors, and network interface controller(s) (NICs) 1270, also known as network interface cards, which include physical Network Interface 1280. The general-purpose network device also includes non-transitory machine readable storage media 1290-2 having stored therein software and/or instructions 1295 executable by the processor 1260. During operation, the processor(s)/processing circuits 1260 execute the software/instructions 1295 to instantiate a hypervisor 1250, sometimes referred to as a virtual machine monitor (VMM), and one or more virtual machines 1240 that are run by the hypervisor 1250.

[0118] A virtual machine 1240 is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes. Each of the virtual machines 1240, and that part of the hardware 1230 that executes that virtual machine 1240, be it hardware 1230 dedicated to that virtual machine 1240 and/or time slices of hardware 1230 temporally shared by that virtual machine 1240 with others of the virtual machine(s) 1240, forms a separate virtual network element(s) (VNE).

[0119] The hypervisor 1250 may present a virtual operating platform that appears like networking hardware to virtual machine 1240, and the virtual machine 1240 may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtualization of the hardware is sometimes referred to as network function virtualization (NFV). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in Data centers, and customer premise equipment (CPE). Different embodiments of the instance or virtual application 1220 may be implemented on one or more of the virtual machine(s) 1240, and the implementations may be made differently.

[0120] In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory). [0121] Some embodiments may be represented as a non-transitory software product stored in a machine-readable medium (also referred to as a computer-readable medium, a processor-readable medium, or a computer usable medium having a computer readable program code embodied therein). The machine-readable medium may be any suitable tangible medium including a magnetic, optical, or electrical storage medium including a diskette, compact disk read only memory (CD-ROM), digital versatile disc read only memory (DVD-ROM) memory device (volatile or non-volatile), or similar storage mechanism. The machine-readable medium may contain various sets of instructions, code sequences, configuration information, or other data, which, when executed, cause a processor to perform steps in a method according to one or more of the described embodiments. Those of ordinary skill in the art will appreciate that other instructions and operations necessary to implement the described embodiments may also be stored on the machine-readable medium. Software running from the machine-readable medium may interface with circuitry to perform the described tasks.

[0122] The above-described embodiments are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description, which is defined solely by the appended claims.