Patent Description:
Currently the fifth generation ("<NUM>") of cellular systems, also referred to as New Radio (NR), is being standardized within the Third-Generation Partnership Project (3GPP). NR is developed for maximum flexibility to support multiple and substantially different use cases. These include enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device-to-device (D2D), and several other use cases.

<FIG> illustrates a high-level view of the <NUM> network architecture, consisting of a Next Generation RAN (NG-RAN) <NUM> and a <NUM> Core (5GC) <NUM>. NG-RAN <NUM> can include one or more gNodeB's (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs <NUM>, <NUM> connected via interfaces <NUM>, <NUM>, respectively. More specifically, gNBs <NUM>, <NUM> can be connected to one or more Access and Mobility Management Functions (AMFs) in the 5GC <NUM> via respective NG-C interfaces. Similarly, gNBs <NUM>, <NUM> can be connected to one or more User Plane Functions (UPFs) in 5GC <NUM> via respective NG-U interfaces. Various other network functions (NFs) can be included in the 5GC <NUM>, including Session Management Function(s) (SMF).

Although not shown, in some deployments 5GC <NUM> can be replaced by an Evolved Packet Core (EPC), which conventionally has been used together with a Long-Term Evolution (LTE) Evolved UMTS RAN (E-UTRAN). In such deployments, gNBs <NUM>, <NUM> can connect to one or more Mobility Management Entities (MMEs) in EPC <NUM> via respective S1-C interfaces. Similarly, gNBs <NUM>, <NUM> can connect to one or more Serving Gateways (SGWs) in EPC via respective NG-U interfaces.

In addition, the gNBs can be connected to each other via one or more Xn interfaces, such as Xn interface <NUM> between gNBs <NUM> and <NUM>. The radio technology for the NG-RAN is often referred to as NR. With respect to the NR interface to UEs, each of the gNBs can support frequency division duplexing (FDD), time division duplexing (TDD), or a combination thereof.

NG-RAN <NUM> is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, F1) the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and signaling transport.

The NG RAN logical nodes shown in <FIG> include a Central Unit (CU or gNB-CU) and one or more Distributed Units (DU or gNB-DU). For example, gNB <NUM> includes gNB-CU <NUM> and gNB-DUs <NUM> and <NUM>. CUs (e.g., gNB-CU <NUM>) are logical nodes that host higher-layer protocols and perform various gNB functions such as controlling the operation of DUs. A DU (e.g., gNB-DUs <NUM>, <NUM>) is a decentralized logical node that hosts lower layer protocols and can include, depending on the functional split option, various subsets of the gNB functions. As such, each of the CUs and DUs can include various circuitry needed to perform their respective functions, including processing circuitry, transceiver circuitry (e.g., for communication), and power supply circuitry. Moreover, the terms "central unit" and "centralized unit" are used interchangeably herein, as are the terms "distributed unit" and "decentralized unit.

A gNB-CU connects to one or more gNB-DUs over respective F1 logical interfaces, such as interfaces <NUM> and <NUM> shown in <FIG>. F1 supports control plane (CP) and user plane (UP) separation into respective FLAP protocol and F1-U protocol, such that a gNB-CU may also be separated in CP and UP (discussed below). However, a gNB-DU can be connected to only a single gNB-CU. The gNB-CU and connected gNB-DU(s) are only visible to other gNBs and the 5GC as a gNB, i.e., the F1 interface is not visible beyond gNB-CU.

A CU can host protocols such as RRC and PDCP, while a DU can host protocols such as RLC, MAC and PHY. In other variants, the RLC protocol can be split between CU and DU, with Automatic Retransmission Request (ARQ) functionality in CU. In other variants, a CU can host RRC and PDCP, including for both UP (e.g., PDCP-U) and CP (e.g., PDCP-C) traffic.

Centralized control plane protocols (e.g., PDCP-C and RRC) can be hosted in a different CU than centralized user plane protocols (e.g., PDCP-U). In particular, a CU can be logically divided into a CU-CP function (including RRC and PDCP for signaling radio bearers) and CU-UP function (including PDCP for user plane). <FIG> shows an exemplary gNB architecture that includes two DUs, a CU-CP, and one or more CU-UPs. As shown in <FIG>, a single CU-CP can be associated with multiple CU-UPs in a gNB. The CU-CP and CU-UP communicate with each other using the E1-AP protocol over the E1 interface, as specified in 3GPP TS <NUM> (v15. Furthermore, the F1 interface between CU and DU is functionally split into F1-C between DU and CU-CP and F1-U between DU and CU-UP. In any deployment scenario, at least one of the CU-CP and the CU-UP functions is centralized.

Densification via deployment of more and more base stations (e.g., macro or micro base stations) is one mechanism to satisfy the increasing demand for bandwidth and/or capacity in mobile networks, which is mainly driven by the increasing use of video streaming services. Due to the availability of more spectrum in the millimeter wave band, deploying small cells that operate in this band is an attractive deployment option for these purposes. However, the normal approach of connecting the small cells to the operator's backhaul network with optical fiber can be very expensive and impractical. Employing wireless links for connecting the small cells to the operator's network is a cheaper and more practical alternative.

One such approach is an Integrated Access and Backhaul (IAB) network where the operator can repurpose radio resources conventionally used for network access (e.g., by wireless devices or UEs) for use to wirelessly connect small cells to the operator's backhaul network. Wireless relaying was studied earlier in 3GPP in the scope of LTE Rel-<NUM> based on a Relay Node (RN) with the functionality of an LTE eNB and UE modem. The RN is connected to a donor eNB which has a S1/X2 proxy functionality hiding the RN from the rest of the network.

Similar IAB options can also be considered for <NUM>/NR networks. One difference compared to LTE is the gNB-CU/DU split architecture described above, which separates time critical RLC/MAC/PHY protocols from less time critical RRC/PDCP protocols. In general, the 3GPP NR IAB specifications reuse existing functions and interfaces defined in NR. Each IAB node can include the functionality of a gNB-DU (also referred to as "IAB-DU") that terminates the radio interface layers of access links towards served UEs and backhaul links towards immediately downstream (or "child") IAB nodes.

Each IAB node can also include a Mobile-Termination function (referred to as MT or "IAB-MT") that terminates the radio interface layers of a backhaul link towards an immediately upstream (or "parent") DU, i.e., either an IAB-DU or a donor DU. The MT functionality is similar to functionality that enables UEs to access the IAB network and has been specified as part of the Mobile Equipment (ME). In addition to the connection to downstream (or "descendant") IAB-MTs and/or UEs, each IAB-DU also has an upstream F1 connection to the CU part of a donor gNB, also referred to as an "IAB-donor CU". This connection is via a particular DU of the donor gNB, also referred to as an "IAB-donor DU". Each IAB-donor CU may be associated with multiple IAB-donor DUs, as illustrated in <FIG>.

IAB topology also allows one IAB node to connect to multiple parent nodes. Currently, it is used for back-up or redundancy purposes, e.g., in case of radio link failure of one parent node. It is desirable to use the redundant routes concurrently to achieve load balancing, reliability, etc. However, current solutions do not adequately support this arrangement.

Document <CIT> discloses a network management function of a relay network that may identify relay node support of multi-mobile terminal (MT) operation, and that may coordinate configuration of multiple backhaul links supported by the relay node via the multi -MT functionality of the relay node. In some cases, a relay node may transmit MT capabilities to the management function over a first established backhaul link, and the management function may configure a second backhaul link using a second MT function of the relay node. In other cases, the relay node may autonomously establish multi-MT connectivity based on preconfigured parent-selection policies, and the network management function may identify the relay node is dual-connected to the network management function. In either case, the network management function may configure backhaul routes (e.g., backhaul links) and resource configuration across the redundant topology.

Document D4 constitutes prior art under Article <NUM>(<NUM>) EPC and discloses a distributed unit, DU, of a radio access node configured to operate in a scenario where the DU is one of multiple DUs serving links to a multi-connected entity. The DU acquires a first DU radio resource configuration for the DU, acquires a first link radio resource configuration corresponding to a first link of a multi-connectivity link of a multi -connected entity, wherein the first link is served by the DU, acquires a multiplexing configuration of the multi-connectivity link, and determines availability of at least one radio resource for the multi-connectivity link based on the first DU radio resource configuration, the first link radio resource configuration, and the multiplexing configuration.

Accordingly, embodiments of the present disclosure address these and other difficulties in integrating IAB nodes into a wireless network, thereby facilitating the otherwise-advantageous deployment of IAB solutions.

Embodiments of the present disclosure include methods (e.g., procedures) for IAB node configured to communicate with first and second parent nodes in a wireless network.

According to the present disclosure, there are provided methods, an IAB node, an IAB donor CU, a first parent node and a computer-readable medium according to the independent claims. Developments are set forth in the dependent claims.

These exemplary methods can include determining the IAB node's multiplexing capability between a first parent link with the first parent node and a second parent link with the second parent node; and sending an indication of the multiplexing capability to one or more ancestor nodes in the wireless network. In various embodiments, the one or more ancestor nodes can include any of the following: the first parent node, the second parent node, and an IAB donor CU that is an ancestor node of at least one of the first and second parent nodes.

Other embodiments include methods (e.g., procedures) for a first parent node of an IAB node in a wireless network. These exemplary methods can be performed by an IAB node (e.g., IAB-DU and IAB-MT).

These exemplary methods can include receiving, from the IAB node, an indication of multiplexing capability between a first parent link with the first parent node and a second parent link with a second parent node of the IAB node; receiving a second resource configuration for the second parent link; and determining availability of resources for the first parent link based on the indication of multiplexing capability and on the second resource configuration.

Other embodiments include IAB nodes (e.g., IAB-MT and IAB-DU) or IAB donor CUs configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments also include non-transitory, computer-readable media storing computer-executable instructions that, when executed by processing circuitry, configure such IAB nodes or IAB donor CUs to perform operations corresponding to any of the exemplary methods described herein.

These and other embodiments described herein can reduce and/or minimize difficulties with resource coordination on respective links between multiple IAB parent nodes and a common IAB (child) node. By operating in this manner, embodiments can facilitate concurrent use of the multiple links, thereby improving data throughput, reliability, and/or load balancing in IAB networks.

These and other objects, features, and advantages of the present disclosure will become apparent upon reading the following Detailed Description in view of the Drawings briefly described below.

Embodiments briefly summarized above will now be described more fully with reference to the accompanying drawings. These descriptions are provided by way of example to explain the subject matter to those skilled in the art and should not be construed as limiting the scope of the subject matter to only the embodiments described herein. More specifically, examples are provided below that illustrate the operation of various embodiments according to the advantages discussed above.

The steps of any methods and/or procedures disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein can be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments can apply to any other embodiments, and vice versa.

Furthermore, the following terms are used throughout the description given below:.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is generally used. Other wireless systems, including without limitation Wide Band Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB) and Global System for Mobile Communications (GSM), may also benefit from the concepts, principles, and/or embodiments described herein.

<FIG> shows a reference diagram for an IAB network in standalone mode, as further explained in 3GPP TR <NUM> (version <NUM>. The IAB network shown in <FIG> includes one IAB-donor <NUM> and multiple IAB-nodes <NUM>-<NUM>, all of which can be part of a radio access network (RAN <NUM>) such as an NG-RAN. IAB donor <NUM> includes DUs <NUM>, <NUM> connected to a CU <NUM>, which is represented by functions CU-CP <NUM> and CU-UP <NUM>. IAB donor <NUM> can communicate with core network (CN) <NUM> via the CU functionality shown.

Each of the IAB nodes <NUM>-<NUM> connects to the IAB-donor via one or more wireless backhaul links (also referred to herein as "hops"). More specifically, the MT function of each IAB-node <NUM>-<NUM> terminates the radio interface layers of a wireless backhaul link towards a corresponding ancestor DU function. This MT functionality is similar to functionality that enables UEs to access the IAB network and, in fact, has been specified by 3GPP as part of the Mobile Equipment (ME). However, IAB functionality is transparent to UEs, such that UEs are unaware if they are being served by a conventional gNB or an IAB-donor node or IAB nodes.

In the context of <FIG>, ancestor DUs can include either DU <NUM> or <NUM> of IAB donor <NUM> and, in some cases, a DU function of an intermediate IAB node that is descendant from IAB donor <NUM>. As a more specific example, IAB-node <NUM> is descendant from IAB-node <NUM> and DU <NUM>, IAB-node <NUM> is an ancestor of IAB-node <NUM> but a descendant of DU <NUM>, and DU <NUM> is an ancestor of IAB-nodes <NUM> and <NUM>. The DU functionality of IAB nodes <NUM>-<NUM> also terminates the radio interface layers of wireless access links towards UEs (e.g., for network access via the DU) and wireless backhaul links towards other descendant IAB nodes. Accordingly, IAB-nodes <NUM>, <NUM>, and <NUM> can be considered "access IAB nodes" for UEs <NUM>, <NUM>, and <NUM>, respectively, and that term will be used in the same manner hereinafter.

As shown in <FIG>, IAB-donor <NUM> can be treated as a single logical node that comprises a set of functions such as gNB-DUs <NUM>-<NUM>, gNB-CU-CP <NUM>, gNB-CU-UP <NUM>, and possibly other functions. In some deployments, the IAB-donor can be split according to these functions, which can all be either co-located or non-co-located as allowed by the 3GPP NG-RAN architecture. Also, some of the functions presently associated with the IAB-donor can be moved outside of the IAB-donor if such functions do not perform IAB-specific tasks.

In general, the existing MT, gNB-DU, gNB-CU, UPF, AMF, and SMF as well as the corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2 and N4 are used as baseline for the IAB architectures. For example, each IAB-node DU connects to the IAB-donor CU using a modified form of F1, which is referred to as F1*. The user-plane portion of F1* (referred to as "F1*-U") runs over RLC channels on the wireless backhaul between the MT on the serving IAB-node and the DU on the IAB donor.

<FIG> illustrates parent and child relationships with respect to a particular IAB node. Furthermore, the backhaul (BH) link between the parent node and the IAB node is referred to as parent BH link, whereas the backhaul link between the IAB node and the child node is referred to as child BH link. Each of these BH links include uplink (UL) and downlink (DL). <FIG> also shows UL and DL access links from the intermediate IAB node to a UE.

As mentioned above, the IAB architecture also adopts the CU/DU split of gNBs in which more time-critical functionality is placed closer to the radio in the DU and less time-critical functionality is placed in the CU. In general, an IAB donor CU contains all gNB-CU functions of all descendant IAB nodes relative to that IAB donor and connects to the 5GC via the NG interface. Each IAB node then hosts the gNB-DU function that handles downstream communications as well as an MT function that handles upstream communication. The MT is a logical unit that provides UE-like functions. Each IAB-DU establishes RLC channels to UEs and/or to MTs of connected IAB-node. Each IAB-MT establishes BH radio interface towards the parent IAB-node or IAB-donor. <FIG> shows an exemplary arrangement of CU, DU, and MT functionality in an IAB network.

Wireless BH links - including IAB - are vulnerable to blockage, e.g., due to moving objects such as vehicles, seasonal changes (foliage), severe weather conditions (rain, snow or hail), or infrastructure changes (new buildings). Traffic variations can also create uneven load distribution on wireless BH links, leading to link- or node-level congestion. In view of those concerns, IAB topology supports redundant paths as another difference from Rel-<NUM> LTE relay.

<FIG> shows two exemplary IAB network topologies. More specifically, the left side of <FIG> shows a spanning tree (ST) topology, in which there is only one route between each IAB-node and IAB-donor. In other words, each IAB node has only a single parent node but can have one or more child nodes. Additionally, the right side of <FIG> shows a directed acyclic graph (DAG) topology that supports redundant routes between IAB-nodes and the IAB donor CU. In other words, each IAB node can have one or more parent nodes and one or more child nodes.

<FIG> shows an exemplary IAB network (<NUM>) that includes various multi-parent arrangements. In particular, IAB-<NUM> (<NUM>) connects to IAB-donor <NUM> (<NUM>) via two parent nodes IAB-<NUM> (<NUM>) and IAB-<NUM> (<NUM>), which connect to the same parent node IAB-<NUM> (<NUM>). Also, IAB-<NUM> (<NUM>) connects to IAB-donor <NUM> (<NUM>) via two parent nodes IAB-<NUM> (<NUM>) and IAB-<NUM> (<NUM>), which have different parent nodes IAB-<NUM> (<NUM>) and IAB-<NUM> (<NUM>). In addition, IAB-<NUM> (<NUM>) connects to two parent nodes IAB-<NUM> (<NUM>) and IAB-<NUM> (<NUM>), which connect to different IAB-donors (<NUM> and <NUM>). These arrangements are exemplary various other multi-parent arrangements. Each of the IAB donors includes a CU (<NUM> and <NUM>) and one or more DUs.

The multi-connectivity or route redundancy shown in <FIG> and <FIG> may be used for back-up purposes. It is also desirable to use redundant routes concurrently to achieve load balancing, improve reliability, etc. To do so, however, resource coordination is required.

In case of in-band operation, an IAB node is typically subject to a half-duplex constraint, whereby it can only be in transmission or reception mode at any given time. Rel-<NUM> IAB mainly considers the TDM case where the MT and DU resources of the same IAB-node are separated in time. Based on this consideration, various resource types have been defined for IAB-MT and DU.

For an IAB-MT, as defined in Rel-<NUM>, the link to the parent node can include DL time resources, UL time resources, and flexible (F) time resources. Likewise, for an IAB-DU, the link to the child node can include DL time resources, UL time resources, F time resources, and unavailable (NA) time resources (i.e., resources not to be used for communication on the DU child links). Each of the DL, UL, and F time resources of the DU child link can belong to one of the following two categories:.

The IAB DU resources are configured per cell, and the H/S/NA attributes for the DU resource configuration are explicitly indicated per-resource type (D/U/F) in each slot. As a result, the semi-static time-domain resources of the IAB-DU can be of seven different types: DL-H, DL-S, UL-H, UL-S, F-H, F-S, and NA. <FIG> shows exemplary coordination relationships between IAB-MT and IAB-DU time resources in tabular form.

Furthermore, an IAB-DU may correspond to multiple cells, including cells operating on different carrier frequencies. Similarly, an MT function may correspond to multiple carrier frequencies. This can either be implemented by one MT unit operating on multiple carrier frequencies or by multiple MT units, each operating on a different carrier frequency. The H/S/NA attributes for the per-cell DU resource configuration should take into account the associated MT carrier frequency(ies).

A configured Soft DU resource is by default unavailable if it is not indicated as available. The parent node can indicate availability implicitly or explicitly. In case of implicit indication, the IAB-node knows, via indirect means (e.g., lack of scheduling grant, no data available at MT, capability of simultaneous DU and MT, etc.) that the DU resource can be used without impacting the MTs ability to transmit and/or receive.

An IAB-node may also receive an explicit indication from the parent node about resource availability. The purpose of having the explicit indication is to allow for more dynamic utilization of the MT and DU resources. A new downlink control information (DCI) format, Format 2_5, and a new radio network temporary identifier, IA-RNTI, are defined to indicate DU-IA (DU indicated as available) to an IAB node. This DCI contains one or multiple fields, with each field value used as the index to an entry in an RRC-configured availability indicator (AI) AvailabilityCombination table. Each entry in the AI AvailabilityCombination table indicates the resource availability for a set of consecutive slots. Each element of each entry in the AI AvailabilityCombination table indicates the resource availability in a slot. Table <NUM> below shows an exemplary table with eight entries, each corresponding to a different combination of availabilities of D, U, and F resources.

However, the above-described resource coordination mechanisms are insufficient for concurrent use of redundant paths from a single IAB node to multiple parent nodes.

Embodiments of the present disclosure address these and other problems, difficulties, and/or issues by providing mechanisms for an IAB node, when connecting to multiple parent nodes, to provide one or more ancestor nodes information about the IAB node's capability to use multiple parent links concurrently. The ancestor nodes receiving such information can include the parent IAB nodes that provide the concurrent links, and/or a network function unit (e.g., IAB donor CU) that is responsible for resource configuration of the involved IAB nodes. Each of the parent nodes may be provided with the resource configuration of the other parent node(s) that provide the concurrent links to the IAB node.

In some embodiments, a prioritization order can be defined for the respective parent nodes when competing for a particular resource. In some embodiments, one or more of the parent nodes can also receive dynamic indication of the resource usage/allocation of one or more other parent nodes. Based on the received information, the network function unit can coordinate resource usage by the respective parent nodes, e.g., by assigning respective coordinated DU resource configurations. Based on the received information, the respective parent nodes can determine whether they can schedule transmission on particular radio resources on the respective links to the common IAB (child) node.

By operating in this manner, embodiments of the present disclosure can reduce and/or minimize difficulties with resource coordination on respective links between multiple IAB parent nodes and a common IAB (child) node. By operating in this manner, embodiments facilitate concurrent use of the multiple links, thereby improving data throughput, reliability, and/or load balancing in the IAB network.

In the following description, the term "resource" refers generally to both time and frequency resources, unless explicitly noted to the contrary.

At a high level, embodiments can be divided into three categories or groups: operations performed by the IAB (child) node having multiple parent nodes; operations performed by the respective parent nodes; and operations performed by a network function unit that is responsible for resource configuration of the involved IAB nodes (referred to hereinafter as "IAB donor CU" for brevity). Although the categories are described individually below, embodiments from the categories can be used cooperatively.

In some embodiments, when connecting to more than one parent node, an IAB node can determine its multiplexing capability between the respective links to the respective parent nodes (also referred to as "parent links"). For example, the multiplexing capability can be based on certain component carrier (CC) pairs and/or certain resource block (RB) group combinations. Furthermore, the multiplexing capability can include any of the following:.

After determining the multiplexing capability, the IAB node can send this information (or a representation of it, such as one or more indices) to the IAB donor CU and/or the respective parent nodes. In some embodiments, the IAB node can receive explicit DU soft resource availability indications (e.g., DCI Format 2_5) from more than one of the parent nodes. In this case, the IAB node determines whether it can use the DU resource based on the union of the received availability indications. For example, if the IAB node receives a first indication from a first parent node that the DU soft resource is available and receives a second indication from a second parent node that the DU soft resource is unavailable, the IAB node can determine that it cannot use the DU resource. In other words, the IAB node determines that it can use the DU soft resource only when both the first and second indications indicate availability.

In some embodiments, upon obtaining resource usage/allocation from a first parent node, the IAB node can provide such information to at least the second parent node. In some embodiments, parent nodes may have a prioritization order (e.g., assigned by IAB donor CU or negotiated among parent nodes) such that a higher-priority parent node can allocate certain resources before a lower-priority parent node can allocate these resources. The prioritization can be on a node basis, resource basis, UE basis, etc. For example, if the first parent node serves a master cell group (MCG) for the IAB (child) node and the second parent node serves a secondary cell group (SCG) for the IAB node, the first parent node can have higher priority. In some scenarios, the second parent node serving the SCG can have higher priority instead.

As mentioned above, the IAB donor CU is responsible for resource configuration of the descendant nodes in the IAB network, including the IAB (child) node and one or more of IAB node's parent nodes. When the IAB node connects to multiple parent nodes, the IAB donor CU can receive information about the IAB node's multiplexing capability between the respective parent links. The multiple capability information can include any of the information discussed above in relation to the IAB node operations.

In some embodiments, when one of the parent nodes belongs to another IAB donor CU, the two IAB donor CUs (e.g., first and second IAB donor CUs) can exchange information concerning the parent node(s) for which they are responsible. This information can include DU resource configurations - including D/U/F patterns, Hard/Soft/NA information, etc. - for the respective parent nodes. By doing so, the IAB donor CUs can avoid configuring conflicting resources to the respective parent nodes under their responsibility. For example, exchanging information can avoid configuring UL to a first parent IAB-DU while configuring DL to a second parent IAB-DU, or configuring resources that cannot be used simultaneously by the parent nodes as Hard (i.e., for both parent nodes).

In some embodiments, IAB donor CUs may have an assigned prioritization order such that a higher-priority IAB donor CU can allocate certain resources before a lower-priority IAB donor CU can allocate these resources. The prioritization can be on a node basis, resource basis, UE basis, etc. For example, if a first IAB donor CU is responsible for a first parent IAB node that serves an MCG for the IAB (child) node and a second IAB donor CU is responsible for a second parent IAB node that serves a SCG for the IAB node, the first IAB donor CU can have higher priority. In some scenarios, the second parent node serving the SCG can have higher priority instead.

After receiving the multiplexing capability information discussed above, the IAB donor CU can determine resource configurations for the respective parent nodes for which it is responsible. In case the IAB donor CU is responsible for all parent nodes of the IAB (child) node, it determines resource configuration for all of the parent nodes. Subsequently, the IAB donor CU can send the determined resource configurations to the respective parent nodes (i.e., for which it is responsible). In some embodiments, the IAB donor CU can send the resource configuration determined for one of the parent nodes (e.g., first parent node) to the other parent nodes (e.g., second parent node). More generally, the IAB donor CU can distribute the determined resource configurations among the parent nodes for the IAB (child) node as necessary, desirable, and/or practical.

Other embodiments involve operations by a first parent node of an IAB node that has parent links to the first parent node and at least a second parent node. In such embodiments, the first parent node may receive information on the multiplexing capability of the IAB node between the respective parent links. In some embodiments, the first parent node can receive DU resource configuration of the second parent node for the IAB (child) node. This information can be received from the second parent node or from a IAB donor CU that is responsible for both the first and second parent nodes.

Certain rules and/or procedures can be defined between the first and second parent nodes when competing for certain resources on the respective parent links towards the IAB (child) node. In some embodiments, the first and second parent nodes can determine a resource priority among them. For example, the higher-priority parent node can be the one serving an MCG for the IAB (child) node. In some embodiments, the first parent node can identify a resource-related condition with respect to one or more other parent nodes for the IAB (child) node (e.g., the second parent node), such as a resource collision condition, a resource starvation condition, etc..

In some embodiments, the first parent node can transmit and/or receive messages to/from other parent nodes (e.g., the second parent node) having links to the common IAB (child) node. For example, these messages can be exchanged directly between the nodes, via the common IAB (child) node (e.g., via MAC- or BAP-layer forwarding), or via an ancestor node (e.g., IAB node or IAB donor CU) that is common to all parent nodes.

The following non-limiting example illustrates principles of the various embodiments discussed above. Assume the first parent node (P1) has a higher priority than a second parent node (P2), and P1 and P2 cannot use a particular DU resource concurrently (as reported from the IAB node). For that DU resource:.

When both P1 and P2 have configured a DU resource as Soft, P1 and/or P2 may take various actions. In some embodiments, by knowing P1's DU resource configuration, P2 can determine that the DU resource is not available for its use. In other embodiments, P2 can obtain information about P1's actual usage of the DU resource. P2 may use the resource for a particular direction (e.g., UL or DL) when the information indicates that P1 cannot or will not use the resource on that direction.

P1's actual usage of the DU resource can be indicated by a DCI format 2_5. In various embodiments, P2 can obtain such information in one of the following ways:.

These embodiments described above can be further illustrated with reference to <FIG>, which depict exemplary methods (e.g., procedures) for an IAB node, an IAB donor CU, and a parent node, respectively. Put differently, various features of the operations described below correspond to various embodiments described above. The exemplary methods shown in <FIG> can be complementary to each other such that they can be used cooperatively to provide benefits, advantages, and/or solutions to problems described herein. Although the exemplary methods are illustrated in <FIG> by specific blocks in particular orders, the operations corresponding to the blocks can be performed in different orders than shown and can be combined and/or divided into blocks and/or operations having different functionality than shown. Optional blocks and/or operations are indicated by dashed lines.

More specifically, <FIG> illustrates an exemplary method (e.g., procedure) for an IAB node configured to communicate with first and second parent nodes in a wireless network, according to various embodiments of the present disclosure. The exemplary method shown in <FIG> can be performed by an IAB node (e.g., IAB-DU and IAB-MT) configured as described elsewhere herein.

The exemplary method can include the operations of block <NUM>, where the IAB node can determine its (i.e., the IAB node's) multiplexing capability between a first parent link with the first parent node and a second parent link with the second parent node. The exemplary method can also include the operations of block <NUM>, where the IAB node can send an indication of the multiplexing capability to one or more ancestor nodes in the wireless network. In various embodiments, the one or more ancestor nodes can include any of the following: the first parent node, the second parent node, and an IAB donor CU that is an ancestor node of at least one of the first and second parent nodes.

In some embodiments, the exemplary method can also include the operations of blocks <NUM>-<NUM>. In block <NUM>, the IAB node can receive, from the first parent node, a first indication of availability of resources for the first parent link. In block <NUM>, the IAB node can receive, from the second parent node, a second indication of availability of resources for the second parent link. In some embodiments, the exemplary method can also include the operations of block <NUM>, where the IAB node can forward the first indication to the second parent node, and/or block <NUM>, where the IAB node can forward the second indication to the first parent node. In some embodiments, the first and second indications can be respective DCI format 2_5 messages. In general, the first and second indications can be various explicit or implicit indications, such as discussed above.

In some embodiments, the first and second indications relate to a first resource (e.g., of Soft type) that is configured for both the first and second parent links. In such embodiments, the exemplary method can also include the operations of block <NUM>, where the IAB node can determine that the first resource is available for use by the IAB node only when both the first and second indications indicate that the first resource is available.

In some embodiments, one of the first and second parent nodes serves a master cell group for the IAB node, and the other of the first and second parent node serves a secondary cell group for the IAB node. In some embodiments, the determined multiplexing capability (e.g., in block <NUM>) can include one or more of the following: capability for time-division multiplexing; capability for frequency-division multiple; and capability for spatial multiplexing.

In addition, <FIG> illustrates an exemplary method (e.g., procedure) for an IAB donor CU configured to communicate with an IAB node in a wireless network via at least an intermediate first parent node of the IAB node, according to various embodiments of the present disclosure. The exemplary method shown in <FIG> can be performed by an IAB donor CU configured as described elsewhere herein.

The exemplary method can include the operations of block <NUM>, where the IAB donor CU can receive, from the IAB node, an indication of multiplexing capability between a first parent link with the first parent node and a second parent link with a second parent node of the IAB node. The exemplary method can also include the operations of block <NUM>, where the IAB donor CU can determine a first resource configuration for the first parent link based on the IAB node's indicated multiplexing capability. The exemplary method can also include the operations of block <NUM>, where the IAB donor CU can send the first resource configuration to at least the first parent node. For example, the first resource configuration can indicate Hard/Soft/NA, etc. such as described above.

In some embodiments, the IAB donor CU also communicates with the IAB node via the second parent node. In such embodiments, the exemplary method can also include the operations of blocks <NUM> and <NUM>. In block <NUM>, the IAB donor CU can determine a second resource configuration for a second parent link based on the IAB node's indicated multiplexing capability. In block <NUM>, the IAB donor CU can send the second resource configuration to the second parent node. For example, the second resource configuration can indicate Hard/Soft/NA, etc. such as described above.

In other embodiments, a second IAB donor CU can be responsible for (e.g., an ancestor of) the second parent node (i.e., instead of the first IAB donor CU). In such embodiments, the exemplary method can also include the operations of blocks <NUM>-<NUM>. In block <NUM>, the IAB donor CU can receive, from the second IAB donor CU, a second resource configuration for the second parent link. In block <NUM>, the IAB donor CU can adapt the first resource configuration based on the second resource configuration. For example, this adaptation can be performed before sending the first resource configuration to the first parent node (e.g., in block <NUM>).

In some embodiments, sending the first resource configuration to at least the first parent node in block <NUM> can include the operations of sub-block <NUM>, where the IAB donor CU can send the first resource configuration to the second parent node (e.g., when the IAB donor CU is an ancestor node of the second parent node) or to a second donor CU that is an ancestor node of the second parent node. In some embodiments, the exemplary method can also include the operations of block <NUM>, where the IAB donor CU can send the second resource configuration to the first parent node.

In some embodiments, one of the first and second parent nodes serves a master cell group for the IAB node, and the other of the first and second parent node serves a secondary cell group for the IAB node. In some embodiments, the IAB node's indicated multiplexing capability (e.g., received in block <NUM>) can include one or more of the following: capability for time-division multiplexing; capability for frequency-division multiple; and capability for spatial multiplexing.

In addition, <FIG> illustrates an exemplary method (e.g., procedure) for a first parent node of an IAB node in a wireless network, according to various embodiments of the present disclosure. The exemplary method shown in <FIG> can be performed by an IAB node (e.g., IAB-DU and IAB-MT) configured as described elsewhere herein.

The exemplary method can include the operations of block <NUM>, where the first parent node can receive, from the IAB node, an indication of the IAB node's multiplexing capability between a first parent link with the first parent node and a second parent link with a second parent node of the IAB node. The exemplary method can also include the operations of block <NUM>, where the first parent node can receive a second resource configuration for the second parent link. The exemplary method can also include the operations of block <NUM>, where the first parent node can determine availability of resources for the first parent link based on the IAB node's indicated multiplexing capability and on the second resource configuration. For example, the second resource configuration can indicate Hard/Soft/NA, etc. such as described above.

In some embodiments, the exemplary method can also include the operations of block <NUM>, where the first parent node can send a first indication of availability of resources for the first parent link to the IAB node and/or to the second parent node.

In some embodiments, the second resource configuration can be received (e.g., in block <NUM>) from one of the following: the second parent node; the IAB node; or an IAB donor CU that is an ancestor node of at least the first parent node.

In some embodiments, the determining operations of block <NUM> can include the operations of sub-block <NUM>, where the first parent node can determine that a first resource is unavailable for the first parent link if the second resource configuration indicates that the first resource is configured as available for the second parent link (e.g., Hard type).

In some embodiments, the second resource configuration (e.g., received in block <NUM>) can indicate that availability of resources for the second parent link is indicated by the second parent node (e.g., Soft type). The indication can be explicit or implicit, as discussed above. In such embodiments, the exemplary method can also include the operations of block <NUM>, where the first parent node can receive a second indication of availability of the resources for the second parent link. In various embodiments, the second indication can be received directly from the second parent node or indirectly via the IAB node or a parent node to both the first and second parent nodes.

In some of these embodiments, the first parent link can be associated with a first resource configuration, which indicates that availability of resources for the first parent link is indicated by the first parent node (e.g., Soft type). The indication can be explicit or implicit, as discussed above. In such embodiments, determining availability of resources for the first parent link (e.g., in block <NUM>) can be further based on the second indication. An example of these embodiments was discussed above, in which a DU resource was configured as Soft type on both the first and second parent links.

In some embodiments, determining availability of resources for the first parent link in block <NUM> can be further based on a prioritization between the first and second parent nodes for scheduling resources configured for both the first and second parent links. In some of these embodiments, the prioritization is one of the following:.

In some embodiments, the indicated multiplexing capability (e.g., received in block <NUM>) can include one or more of the following: capability for time-division multiplexing; capability for frequency-division multiple; and capability for spatial multiplexing.

Although the subject matter described herein can be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 1260b, and WDs <NUM>, 1210b, and 1210c. In practice, a wireless network can further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network can provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

The wireless network can comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the wireless network can be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network can implement communication standards, such as GSM, UMTS, LTE, and/or other suitable <NUM>, <NUM>, <NUM>, or <NUM> standards; wireless local area network (WLAN) standards, such as the IEEE <NUM> standards; and/or any other appropriate wireless communication standard, such as the WiMax, Bluetooth, Z-Wave and/or ZigBee standards.

Network <NUM> can comprise one or more backhaul networks, core networks, IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide-area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

In different embodiments, the wireless network can comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components or systems that can facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.

Examples of network nodes are provided above. Base stations can be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and can then also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station can be a relay node or a relay donor node controlling a relay. A network node can also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or RRUs, sometimes referred to as Remote Radio Heads (RRHs). Parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

As another example, a network node can be a virtual network node as described in more detail below. More generally, however, network nodes can represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network.

Although network node <NUM> illustrated in the example wireless network of <FIG> can represent a device that includes the illustrated combination of hardware components, other embodiments can comprise network nodes with different combinations of components. It is to be understood that a network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods and/or procedures disclosed herein. Moreover, while the components of network node <NUM> are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, a network node can comprise multiple different physical components that make up a single illustrated component (e.g., device readable medium <NUM> can comprise multiple separate hard drives as well as multiple RAM modules).

Processing circuitry <NUM> can comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide various functionality of network node <NUM>, either alone or in conjunction with other network node <NUM> components (e.g., device readable medium <NUM>). Such functionality can include any of the various wireless features, functions, or benefits discussed herein.

For example, processing circuitry <NUM> can execute instructions stored in device readable medium <NUM> or in memory within processing circuitry <NUM>. In some embodiments, processing circuitry <NUM> can include a system on a chip (SOC). As a more specific example, instructions (also referred to as a computer program product) stored in medium <NUM> can include instructions that, when executed by processing circuitry <NUM>, can configure network node <NUM> to perform operations corresponding to various exemplary methods (e.g., procedures) described herein.

In some embodiments, processing circuitry <NUM> can include one or more of radio frequency (RF) transceiver circuitry <NUM> and baseband processing circuitry <NUM>. In some embodiments, radio frequency (RF) transceiver circuitry <NUM> and baseband processing circuitry <NUM> can be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry <NUM> and baseband processing circuitry <NUM> can be on the same chip or set of chips, boards, or units.

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device can be performed by processing circuitry <NUM> executing instructions stored on device readable medium <NUM> or memory within processing circuitry <NUM>. In alternative embodiments, some or all of the functionality can be provided by processing circuitry <NUM> without executing instructions stored on a separate or discrete device readable medium, such as in a hard-wired manner.

Device readable medium <NUM> can comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device readable and/or computer-executable memory devices that store information, data, and/or instructions that can be used by processing circuitry <NUM>. Device readable medium <NUM> can store any suitable instructions, data or information, including a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry <NUM> and, utilized by network node <NUM>. Device readable medium <NUM> can be used to store any calculations made by processing circuitry <NUM> and/or any data received via interface <NUM>. In some embodiments, processing circuitry <NUM> and device readable medium <NUM> can be considered to be integrated.

Interface <NUM> is used in the wired or wireless communication of signaling and/or data between network node <NUM>, network <NUM>, and/or WDs <NUM>. Interface <NUM> also includes radio front end circuitry <NUM> that can be coupled to, or in certain embodiments a part of, antenna <NUM>. Radio front end circuitry <NUM> can be connected to antenna <NUM> and processing circuitry <NUM>. Radio front end circuitry can be configured to condition signals communicated between antenna <NUM> and processing circuitry <NUM>. Radio front end circuitry <NUM> can receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry <NUM> can convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters <NUM> and/or amplifiers <NUM>. The radio signal can then be transmitted via antenna <NUM>. Similarly, when receiving data, antenna <NUM> can collect radio signals which are then converted into digital data by radio front end circuitry <NUM>. The digital data can be passed to processing circuitry <NUM>. In other embodiments, the interface can comprise different components and/or different combinations of components.

In certain alternative embodiments, network node <NUM> may not include separate radio front end circuitry <NUM>, instead, processing circuitry <NUM> can comprise radio front end circuitry and can be connected to antenna <NUM> without separate radio front end circuitry <NUM>. Similarly, in some embodiments, all or some of RF transceiver circuitry <NUM> can be considered a part of interface <NUM>. In still other embodiments, interface <NUM> can include one or more ports or terminals <NUM>, radio front end circuitry <NUM>, and RF transceiver circuitry <NUM>, as part of a radio unit (not shown), and interface <NUM> can communicate with baseband processing circuitry <NUM>, which is part of a digital unit (not shown).

Antenna <NUM> can include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. Antenna <NUM> can be coupled to radio front end circuitry <NUM> and can be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna <NUM> can comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between, for example, <NUM> and <NUM>. An omni-directional antenna can be used to transmit/receive radio signals in any direction, a sector antenna can be used to transmit/receive radio signals from devices within a particular area, and a panel antenna can be a line of sight antenna used to transmit/receive radio signals in a relatively straight line. In some instances, the use of more than one antenna can be referred to as MIMO. In certain embodiments, antenna <NUM> can be separate from network node <NUM> and can be connectable to network node <NUM> through an interface or port.

Antenna <NUM>, interface <NUM>, and/or processing circuitry <NUM> can be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by a network node. Any information, data and/or signals can be received from a wireless device, another network node and/or any other network equipment. Similarly, antenna <NUM>, interface <NUM>, and/or processing circuitry <NUM> can be configured to perform any transmitting operations described herein as being performed by a network node. Any information, data and/or signals can be transmitted to a wireless device, another network node and/or any other network equipment.

Power circuitry <NUM> can comprise, or be coupled to, power management circuitry and can be configured to supply the components of network node <NUM> with power for performing the functionality described herein. Power circuitry <NUM> can receive power from power source <NUM>. Power source <NUM> and/or power circuitry <NUM> can be configured to provide power to the various components of network node <NUM> in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source <NUM> can either be included in, or external to, power circuitry <NUM> and/or network node <NUM>. For example, network node <NUM> can be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry <NUM>. As a further example, power source <NUM> can comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry <NUM>. The battery can provide backup power should the external power source fail. Other types of power sources, such as photovoltaic devices, can also be used.

Alternative embodiments of network node <NUM> can include additional components beyond those shown in <FIG> that can be responsible for providing certain aspects of the network node's functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, network node <NUM> can include user interface equipment to allow and/or facilitate input of information into network node <NUM> and to allow and/or facilitate output of information from network node <NUM>. This can allow and/or facilitate a user to perform diagnostic, maintenance, repair, and other administrative functions for network node <NUM>.

WD <NUM> can include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD <NUM>, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies can be integrated into the same or different chips or set of chips as other components within WD <NUM>.

Antenna <NUM> can include one or more antennas or antenna arrays, configured to send and/or receive wireless signals, and is connected to interface <NUM>. In certain alternative embodiments, antenna <NUM> can be separate from WD <NUM> and be connectable to WD <NUM> through an interface or port. Antenna <NUM>, interface <NUM>, and/or processing circuitry <NUM> can be configured to perform any receiving or transmitting operations described herein as being performed by a WD. Any information, data and/or signals can be received from a network node and/or another WD. In some embodiments, radio front end circuitry and/or antenna <NUM> can be considered an interface.

Radio front end circuitry <NUM> is connected to antenna <NUM> and processing circuitry <NUM> and can be configured to condition signals communicated between antenna <NUM> and processing circuitry <NUM>. Radio front end circuitry <NUM> can be coupled to or a part of antenna <NUM>. In some embodiments, WD <NUM> may not include separate radio front end circuitry <NUM>; rather, processing circuitry <NUM> can comprise radio front end circuitry and can be connected to antenna <NUM>. Similarly, in some embodiments, some or all of RF transceiver circuitry <NUM> can be considered a part of interface <NUM>. Radio front end circuitry <NUM> can receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry <NUM> can convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters <NUM> and/or amplifiers <NUM>. The radio signal can then be transmitted via antenna <NUM>. Similarly, when receiving data, antenna <NUM> can collect radio signals which are then converted into digital data by radio front end circuitry <NUM>. The digital data can be passed to processing circuitry <NUM>. In other embodiments, the interface can comprise different components and/or different combinations of components.

Processing circuitry <NUM> can comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide WD <NUM> functionality either alone or in combination with other WD <NUM> components, such as device readable medium <NUM>. Such functionality can include any of the various wireless features or benefits discussed herein.

For example, processing circuitry <NUM> can execute instructions stored in device readable medium <NUM> or in memory within processing circuitry <NUM> to provide the functionality disclosed herein. More specifically, instructions (also referred to as a computer program product) stored in medium <NUM> can include instructions that, when executed by processor <NUM>, can configure wireless device <NUM> to perform operations corresponding to various exemplary methods (e.g., procedures) described herein.

In other embodiments, the processing circuitry can comprise different components and/or different combinations of components. In certain embodiments processing circuitry <NUM> of WD <NUM> can comprise a SOC. In some embodiments, RF transceiver circuitry <NUM>, baseband processing circuitry <NUM>, and application processing circuitry <NUM> can be on separate chips or sets of chips. In alternative embodiments, part or all of baseband processing circuitry <NUM> and application processing circuitry <NUM> can be combined into one chip or set of chips, and RF transceiver circuitry <NUM> can be on a separate chip or set of chips. In still alternative embodiments, part or all of RF transceiver circuitry <NUM> and baseband processing circuitry <NUM> can be on the same chip or set of chips, and application processing circuitry <NUM> can be on a separate chip or set of chips. In yet other alternative embodiments, part or all of RF transceiver circuitry <NUM>, baseband processing circuitry <NUM>, and application processing circuitry <NUM> can be combined in the same chip or set of chips. In some embodiments, RF transceiver circuitry <NUM> can be a part of interface <NUM>. RF transceiver circuitry <NUM> can condition RF signals for processing circuitry <NUM>.

In certain embodiments, some or all of the functionality described herein as being performed by a WD can be provided by processing circuitry <NUM> executing instructions stored on device readable medium <NUM>, which in certain embodiments can be a computer-readable storage medium. In alternative embodiments, some or all of the functionality can be provided by processing circuitry <NUM> without executing instructions stored on a separate or discrete device readable storage medium, such as in a hard-wired manner.

Device readable medium <NUM> can be operable to store a computer program, software, an application including one or more of logic, rules, code, tables, etc. and/or other instructions capable of being executed by processing circuitry <NUM>. Device readable medium <NUM> can include computer memory (e.g., Random Access Memory (RAM) or Read Only Memory (ROM)), mass storage media (e.g., a hard disk), removable storage media (e.g., a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device readable and/or computer executable memory devices that store information, data, and/or instructions that can be used by processing circuitry <NUM>. In some embodiments, processing circuitry <NUM> and device readable medium <NUM> can be considered to be integrated.

User interface equipment <NUM> can include components that allow and/or facilitate a human user to interact with WD <NUM>. Such interaction can be of many forms, such as visual, audial, tactile, etc. User interface equipment <NUM> can be operable to produce output to the user and to allow and/or facilitate the user to provide input to WD <NUM>. The type of interaction can vary depending on the type of user interface equipment <NUM> installed in WD <NUM>. For example, if WD <NUM> is a smart phone, the interaction can be via a touch screen; if WD <NUM> is a smart meter, the interaction can be through a screen that provides usage (e.g., the number of gallons used) or a speaker that provides an audible alert (e.g., if smoke is detected).

This can comprise specialized sensors for doing measurements for various purposes, interfaces for additional types of communication such as wired communications etc. The inclusion and type of components of auxiliary equipment <NUM> can vary depending on the embodiment and/or scenario.

Power source <NUM> can, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, can also be used. WD <NUM> can further comprise power circuitry <NUM> for delivering power from power source <NUM> to the various parts of WD <NUM> which need power from power source <NUM> to carry out any functionality described or indicated herein. Power circuitry <NUM> can in certain embodiments comprise power management circuitry. Power circuitry <NUM> can additionally or alternatively be operable to receive power from an external power source; in which case WD <NUM> can be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry <NUM> can also in certain embodiments be operable to deliver power from an external power source to power source <NUM>. This can be, for example, for the charging of power source <NUM>. Power circuitry <NUM> can perform any converting or other modification to the power from power source <NUM> to make it suitable for supply to the respective components of WD <NUM>.

<FIG> is a schematic block diagram illustrating a virtualization environment <NUM> in which functions implemented by some embodiments can be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which can include virtualizing hardware platforms, storage devices and networking resources.

In some embodiments, some or all of the functions described herein can be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments <NUM> hosted by one or more of hardware nodes <NUM>. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), then the network node can be entirely virtualized.

The functions can be implemented by one or more applications <NUM> (which can alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) operative to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Virtualization environment <NUM> can include general-purpose or special-purpose network hardware devices (or nodes) <NUM> comprising a set of one or more processors or processing circuitry <NUM>, which can be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device can comprise memory <NUM>-<NUM> which can be non-persistent memory for temporarily storing instructions <NUM> or software executed by processing circuitry <NUM>. For example, instructions <NUM> can include program instructions (also referred to as a computer program product) that, when executed by processing circuitry <NUM>, can configure hardware node <NUM> to perform operations corresponding to various exemplary methods (e.g., procedures) described herein. Such operations can also be attributed to virtual node(s) <NUM> that is/are hosted by hardware node <NUM>.

Each hardware device can comprise one or more network interface controllers (NICs) <NUM>, also known as network interface cards, which include physical network interface <NUM>. Each hardware device can also include non-transitory, persistent, machine-readable storage media <NUM>-<NUM> having stored therein software <NUM> and/or instructions executable by processing circuitry <NUM>. Software <NUM> can include any type of software including software for instantiating one or more virtualization layers <NUM> (also referred to as hypervisors), software to execute virtual machines <NUM> as well as software allowing it to execute functions, features and/or benefits described in relation with some embodiments described herein.

Virtual machines <NUM>, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and can be run by a corresponding virtualization layer <NUM> or hypervisor. Different embodiments of the instance of virtual appliance <NUM> can be implemented on one or more of virtual machines <NUM>, and the implementations can be made in different ways.

During operation, processing circuitry <NUM> executes software <NUM> to instantiate the hypervisor or virtualization layer <NUM>, which can sometimes be referred to as a virtual machine monitor (VMM). Virtualization layer <NUM> can present a virtual operating platform that appears like networking hardware to virtual machine <NUM>.

As shown in <FIG>, hardware <NUM> can be a standalone network node with generic or specific components. Hardware <NUM> can comprise antenna <NUM> and can implement some functions via virtualization. Alternatively, hardware <NUM> can be part of a larger cluster of hardware (e.g., such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) <NUM>, which, among others, oversees lifecycle management of applications <NUM>.

NFV can 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.

In the context of NFV, virtual machine <NUM> can be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine.

In some embodiments, one or more radio units <NUM> that each include one or more transmitters <NUM> and one or more receivers <NUM> can be coupled to one or more antennas <NUM>. Radio units <NUM> can communicate directly with hardware nodes <NUM> via one or more appropriate network interfaces and can be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. Nodes arranged in this manner can also communicate with one or more UEs, such as described elsewhere herein.

In some embodiments, some signaling can be performed via control system <NUM>, which can alternatively be used for communication between the hardware nodes <NUM> and radio units <NUM>.

The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, fall within the scope of the invention as claimed. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claim 1:
A method for an integrated access backhaul, IAB, node configured to communicate with first and second parent nodes in a wireless network, the method comprising:
determining (<NUM>) the IAB node's multiplexing capability between a first parent link with the first parent node and a second parent link with the second parent node;
sending (<NUM>) an indication of the multiplexing capability to one or more ancestor nodes in the wireless network;
receiving (<NUM>), from the first parent node, a first indication of availability of resources for the first parent link;
receiving (<NUM>), from the second parent node, a second indication of availability of resources for the second parent link, wherein the first and second indications relate to a first resource that is configured for both the first and second parent links; and
determining (<NUM>) that the first resource is available for use by the IAB node only when both the first and second indications indicate that the first resource is available.