Power Control for IAB Node Forwarding

Abstract

The present invention discloses a node of an integrated access and backhaul (IAB) network, the node comprising a processor circuit and an interface circuit. The processor circuit is configured to: make a determination about cross link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node; and generate a command according to the determination, the command being configured to modify the characteristics of the beam transmitted from the parent node to the IAB node. The interface circuit is configured to transmit the command to a beam controller of the parent node.

Description

Technical Field

[0001] The present technology relates to wireless communications, and in particular to radio architecture and operations for resolving problematic conditions of wireless backhaul links. Background Art

[0002] The radio access network typically resides between a wireless device (such as a user equipment (UE), a mobile phone, a mobile station, or any other device with a wireless terminal) and the core network. Examples of radio access network types include: GRAN, which is the GSM radio access network; GERAN, which includes EDGE packet radio service; UTRAN, which is the UMTS radio access network; E-UTRAN, which includes long term evolution; and g-UTRAN, which is new radio (NR).

[0003] The radio access network may include one or more access nodes, such as base station nodes, which facilitate wireless communications or otherwise provide an interface between a wireless terminal and a telecommunications system. Non-limiting examples of base stations may include Node B ("NB"), enhanced Node B ("eNB"), Home eNB ("HeNB"), gNB (for New Radio ["NR"] technology systems), or some other similar terminology, depending on the radio access technology type.

[0004] The 3rd Generation Partnership Project ("3GPP") is a group that develops collaborative agreements, such as 3GPP standards, that are intended to establish globally applicable technical specifications and technical reports for wireless communication systems. Various 3GPP documents may describe certain aspects of radio access networks. The overall architecture of fifth generation systems (e.g., 5G systems, also referred to as "NR" or "new radio", and "NG" or "next generation") is described in Fig.34 , and is also described in 3GPP TS 38.300. The 5G NR network consists of NGRAN (Next Generation Radio Access Network) and 5GC (5G Core Network). As shown in the figure, NGRAN consists of gNB (e.g., 5G base station) and ng-eNB (i.e., LTE base station). The Xn interface exists between gNB-gNB, between (gNB)-(ng-eNB), and between (ng-eNB)-(ng-eNB). Xn is a network interface between NG-RAN nodes. Xn-U represents the Xn user plane interface, and Xn-C represents the Xn control plane interface. The NG interface exists between 5GC and base stations (i.e., gNB and ng-eNB). The gNB node provides NR user plane and control plane protocol terminals to the UE and is connected to the 5GC via the NG interface. The 5G NR (New Radio) gNB is connected to the AMF (Access and Mobility Management Function) and UPF (User Plane Function) in the 5GC (5G Core Network).

[0005] In some cellular mobile communication systems and networks such as Long Term Evolution (LTE) and New Radio (NR), the service area is covered by one or more base stations, each of which can be connected to the core network via a fixed line backhaul link (e.g., fiber optic cable). In some cases, due to the weak signal from the base station at the edge of the service area, users often encounter performance problems such as: reduced data rate, high probability of link failure, etc. The concept of relay nodes has been introduced to extend the coverage area and improve signal quality. Relay nodes are connected to base stations using wireless backhaul links, and base stations are connected to relay nodes using wireless fronthaul links.

[0006] In the 3rd Generation Partnership Project (3GPP), the concept of relay nodes ("IAB nodes") as a fifth generation (5G or NR) cellular system has been discussed and standardized based on the RAN slicing technology introduced for new radio, such as different levels of isolation and functional segmentation and placement of functions shared across the control plane (CP), user plane (UP) and control logic (CL), where the IAB node utilizes the same 5G radio access technology (i.e., new radio (NR)) to simultaneously operate services to user equipment (UE) (access links) and connections to the core network (backhaul links). These radio links can be multiplexed in time, frequency and / or space. The system is called integrated access and backhaul (IAB).

[0007] Fig.33 is a diagram showing an example of a radio protocol architecture for a control plane and a user plane in a mobile communication network. The radio protocol architecture of a UE and / or a gNodeB can be shown in three layers: Layer 1, Layer 2, and Layer 3. Layer 1 (L1 layer) is the lowest layer and implements various physical layer signal processing functions. Layer 2 (L2 layer) is above the physical layer and is responsible for the link between the UE and / or gNodeB above the physical layer. In the user plane, the L2 layer may include a media access control (MAC) sublayer, a radio link control (RLC) sublayer, and a packet data convergence protocol (PDCP) sublayer, which terminate at the gNodeB on the network side. Although not shown, the UE may have several upper layers above the L2 layer, including a network layer (e.g., an IP layer) that terminates at a PDN gateway on the network side, and an application layer that terminates at the other end of the connection (e.g., a remote UE, a server, etc.). The control plane also includes a radio resource control (RRC) sublayer in Layer 3 (L3 layer). The RRC sublayer is responsible for obtaining radio resources (ie, radio bearers) and for configuring lower layers between the IAB node and / or UE and the IAB bearer using RRC signaling.

[0008] Various nomenclatures may be used to describe the IAB system and the relationship of nodes in the network topology of the IAB system. As used herein:

[0009] A node connected to the IAB node and topologically located between the IAB node and the core network is a parent node of the LAB node.

[0010] • The parent node may be an IAB node, or it may be a carrier node.

[0011] • The carrier node is the node that is topologically closest to the core network.

[0012] A node that is connected to an IAB node and is neither a parent node nor a carrier node is a child node.

[0013] • The child node can be a UE or another IAB node.

[0014] The integrated access and backhaul (IAB) system should be reliable and robust to various possible failures. However, as explained in more detail below, in some cases, a problem called cross-link interference (CLI) may occur, such as in a topology where the parent node and the IAB node use a "frequency reuse factor = 1".

[0015] For 3GPP Rel-16, the Tx and Rx configuration of the IAB node is limited to using TDM half-duplex services, for example, the IAB node can only perform one of the following operations at a time: receive from the parent node, transmit to the parent node, receive from the child node, transmit to the child node. For Rel-17, an enhanced configuration is proposed to achieve full-duplex in the context of IAB, for example, the IAB node can receive from the parent node on its MT side and transmit to the child node on its DU side at the same time. However, if the IAB node uses the same time and frequency resources as the parent node uses to communicate with the IAB node to communicate with the child node, for example, the frequency reuse is 1, then the downlink transmission of the parent node to the IAB node may interfere with the child node's reception of the downlink transmission of the IAB.

[0016] The coexistence of different link directions on the same frequency resources in neighboring cells leads to potential cross-link interference (CLI), i.e., user-to-user (UE-UE) and base station-to-base station (BS-BS) interference, as well as nodes of the IAB topology.

[0017] LTE has supported a feature called "3D beamforming" since 3GPP Rel-9. This technology enables the energy radiated by the antenna to be focused into a beam instead of being omnidirectional, e.g. not spherical. Such energy beams are referred to in this article as "Tx beams". This technology has been implemented for the MIMO feature and has been continuously improved with each subsequent release so that a single "beam" can be created and directed, e.g. pointing in a specific direction and location to serve a specific UE. In NR, the concept of beamforming is used to provide connectivity not only from gNB to UE, but also between gNBs.

[0018] What are needed are methods, apparatus and / or techniques to mitigate cross-link interference (CLI) in an integrated access and backhaul (IAB) system. Summary of the invention

[0019] In one embodiment, a node of an integrated access and backhaul (IAB) network is provided, the node comprising: a processor circuit, the processor circuit being configured to: make a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IAB node to a child node of the IAB node; and generate a command based on the determination, the command being configured to modify characteristics of the beam transmitted from the parent node to the IAB node; and an interface circuit, the interface circuit being configured to transmit the command to a beam controller of the parent node.

[0020] In one embodiment, a method in a node of an integrated access and backhaul (IAB) network is provided, the node comprising: using a processor circuit: making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node; and generating a command based on the determination, the command being configured to modify characteristics of the beam transmitted from the parent node to the IAB node; and transmitting the command to a beam controller of the parent node.

[0021] In one embodiment, a node of an integrated access and backhaul (IAB) network is provided, comprising: an interface configured to obtain a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; and a beam transmission circuit configured to modify characteristics of the beam transmitted from the node to the wireless relay node using the command.

[0022] In one embodiment, a method in a node of an integrated access and backhaul (IAB) network is provided, comprising: obtaining a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; and modifying characteristics of the beam transmitted from the node to the wireless relay node based on the command. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The foregoing and other objects, features, and advantages of the technology disclosed herein will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings, in which reference numerals refer to the same parts in the various views. The accompanying drawings are not necessarily drawn to scale, emphasis instead being placed on illustrating the principles of the technology disclosed herein.

[0024] [ Figure 1A ] Figure 1A is a diagrammatic view of a mobile network infrastructure using 5G signals and 5G base stations, where Figure 1A A beam management processor (BMP) located at a non-carrier IAB node is shown, where Figure 1B A beam management processor (BMP) located at the carrier IAB node is shown, and Figure 1C An IAB network power management controller in an IAB node that is not a carrier node is shown.

[0025] [ Figure 1B ] Figure 1B is a diagrammatic view of a mobile network infrastructure using 5G signals and 5G base stations, where Figure 1A A beam management processor (BMP) located at a non-carrier IAB node is shown, where Figure 1B A beam management processor (BMP) located at the carrier IAB node is shown, and Figure 1C An IAB network power management controller in an IAB node that is not a carrier node is shown.

[0026] [ Figure 1C ] Figure 1C is a diagrammatic view of a mobile network infrastructure using 5G signals and 5G base stations, where Figure 1A A beam management processor (BMP) located at a non-carrier IAB node is shown, where Figure 1B A beam management processor (BMP) located at the carrier IAB node is shown, and Figure 1C An IAB network power management controller in an IAB node that is not a carrier node is shown.

[0027] [ Figure 2A ] Figure 2A Describe separately Figure 1A , Figure 1B and Figure 1C Diagrammatic views of examples of functional block diagrams of exemplary embodiments and modes.

[0028] [ Figure 2B ] Figure 2B Describe separately Figure 1A , Figure 1B and Figure 1C Diagrammatic views of examples of functional block diagrams of exemplary embodiments and modes.

[0029] [ Figure 2C ] Figure 2C Describe separately Figure 1A , Figure 1B and Figure 1C Diagrammatic views of examples of functional block diagrams of exemplary embodiments and modes.

[0030] [ Figure 3 ] Figure 3 is a diagrammatic view showing the control plane (C-plane) and user plane (U-plane) protocols between the UE, IAB node and IAB bearer.

[0031] [ Figure 4 ] Figure 4 is a functional block diagram of an exemplary protocol stack configuration of the U-plane.

[0032] [ Figure 5A ] Figure 5A A functional block diagram depicts an exemplary protocol stack configuration for a C-plane between IAB nodes connected to an IAB bearer.

[0033] [ Figure 5B ] Figure 5B Depicted is a functional block diagram of an exemplary C-plane protocol stack configuration of an IAB node connected to another IAB node connected to an IAB bearer.

[0034] [ Figure 5C ] Figure 5C A functional block diagram depicts an exemplary C-plane protocol stack configuration for RRC signaling of a UE.

[0035] [ Fig. 6A ] Fig. 6A Depicted is an exemplary message sequence for an IAB node to establish an RRC connection followed by an F1-AP* connection.

[0036] [ Figure 6B ] Figure 6B An exemplary message sequence for an IAB node to establish an RRC connection with an IAB bearer followed by an F1 setup procedure is depicted.

[0037] [ Fig. 7A ] Fig. 7A are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0038] [ Figure 7B ] Figure 7B are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0039] [ Figure 7C ] Figure 7Care diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0040] [ Fig.7D ] Fig.7D are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0041] [ Fig. 7E ] Fig. 7E are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0042] [ Figure 7F ] Figure 7F are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0043] [ Figure 7G ] Figure 7G are diagrammatic views depicting various examples of beam transmission in a communication network with wireless backhaul.

[0044] [ Fig. 8A ] Fig. 8A They include Figure 2A , Figure 2B and Figure 2C A schematic diagram of an exemplary general communication system of nodes showing greater details.

[0045] [ Figure 8B ] Figure 8B They include Figure 2A , Figure 2B and Figure 2C A schematic diagram of an exemplary general communication system of nodes showing greater details.

[0046] [ Figure 8C ] Figure 8C They include Figure 2A , Figure 2B and Figure 2C A schematic diagram of an exemplary general communication system of nodes showing greater details.

[0047] [ Fig. 9 ] Fig. 9 is a flow chart illustrating exemplary, non-limiting, basic actions or steps that may be performed by a node executing a beam management process according to exemplary embodiments and modes.

[0048] [ Fig.10 ] Fig.10 is a flow chart illustrating exemplary, non-limiting, basic actions or steps that may be performed by a node to modify characteristics of a beam transmitted therefrom according to a beam management procedure according to exemplary embodiments and modes.

[0049] [ Fig.11 ] Fig.11 is a diagram showing states involved in performing a beam management process.

[0050] [ Fig.12 ] Fig.12 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0051] [ Fig.13 ] Fig.13 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0052] [ Fig.14 ] Fig.14 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0053] [ Fig.15 ] Fig.15 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0054] [ Fig.16 ] Fig.16 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0055] [ Fig.17 ] Fig.17 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0056] [ Fig.18 ] Fig.18 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0057] [ Fig.19 ] Fig.19 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0058] [ Fig. 20 ] Fig. 20 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0059] [ Fig.21 ] Fig.21is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0060] [ Fig. 22 ] Fig. 22 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0061] [ Fig.23 ] Fig.23 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0062] [ Fig.24 ] Fig.24 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0063] [ Fig.25 ] Fig.25 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0064] [ Fig.26 ] Fig.26 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0065] [ Fig. 27 ] Fig. 27 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0066] [ Fig.28 ] Fig.28 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0067] [ Fig.29 ] Fig.29 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0068] [ Fig.30 ] Fig.30 is a flow chart illustrating exemplary logical acts or steps comprising a beam management process that may be performed by a beam management processor (BMP).

[0069] [ Fig.31 ] Fig.31is a diagram showing an example architecture of a carrier IAB node configured in a segmented or distributed manner to host CU functionality.

[0070] [ Fig.32 ] Fig.32 is a diagrammatic view showing exemplary elements comprising an electronic machine that may include a wireless terminal, a radio access node, and a core network node according to exemplary embodiments and modes.

[0071] [ Fig.33 ] Fig.33 is a diagrammatic view showing an example of a radio protocol architecture for a control plane and a user plane in a mobile communication network.

[0072] [ Fig.34 ] Fig.34 A diagrammatic view of the overall architecture of the 5G New Radio system. DETAILED DESCRIPTION

[0073] In one of its exemplary aspects, the technology disclosed herein relates to methods and apparatus for detecting / mitigating / managing situations in which downlink transmissions from a parent node to an IAB node cause cross-link interference (CLI) on a downlink from the IAB node to a child node, as received by the child node. Specifically, situations in which the parent node communicates with the IAB node using the same frequency band (e.g., time and frequency resources) and at least some overlapping spatial resources, where the IAB node is communicating with the child node using these overlapping spatial resources.

[0074] In one of their exemplary aspects, these apparatus and methods detect that a child node (e.g., UE) connected to an IAB node is located at a location covered by or nearly covered by a Tx beam, and a parent node of the IAB node is communicating with the IAB node using the Tx beam, and detect whether the child node is affected by a CLI from the Tx beam of the parent node.

[0075] In one of its exemplary aspects, these apparatus and methods determine whether a reduction in transmit power of a backhaul link between a parent node and one or more of its IAB child nodes can be achieved that can reduce interference to access links used by the IAB node and the child nodes and still maintain acceptable throughput and QoS on the backhaul link used by the parent node and the IAB node, and if such a determination is made, the processor requests the parent node to reduce its transmit power on the backhaul link between the parent node and the IAB node.

[0076] In one of its exemplary aspects, these apparatus and methods determine whether an increase in transmit power of a backhaul link between a parent node and an IAB node can be implemented, which increase can provide a benefit to the IAB node via an increase in throughput of the parent node, and the increase in transmit power of the backhaul link between the parent node and the IAB node will not subject child nodes of the IAB node to an unacceptable level of CLI from transmissions of the parent node, and if such a determination is made, the process requests the parent node to increase its transmit power on the backhaul link between the parent node and the IAB node.

[0077] In one of its exemplary aspects, these apparatus and methods determine a power transmission threshold for a backhaul link that finds a balance between the above two aspects, such as minimizing the parent node transmit power to reduce interference to the child node, and maximizing the parent node transmit power to increase the DL throughput from the parent node to the IAB node.

[0078] For ease of explanation and not limitation, specific details such as specific architectures, interfaces, technologies, etc. are proposed in the following description so as to thoroughly understand the technology disclosed herein. However, it is obvious to those skilled in the art that the technology disclosed herein can also be implemented in other embodiments different from these specific details. That is, those skilled in the art can conceive of various arrangements, although these arrangements are not explicitly described or shown in this article, they still embody the principles of the technology disclosed herein and are included in its spirit and scope. In some cases, detailed descriptions of well-known devices, circuits, and methods are omitted so that the description of the technology disclosed herein will not be obscure due to unnecessary details. All statements of the principles, aspects, and embodiments of the technology disclosed herein and their specific examples are described herein and are intended to cover their structural and functional equivalents. In addition, it is intended that such equivalents include currently known equivalents and equivalents developed in the future, that is, any element developed to perform the same function, regardless of the structure.

[0079] Thus, for example, those skilled in the art will appreciate that the block diagrams herein can represent conceptual views of exemplary circuits or other functional units that embody technical principles. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudo codes, etc. represent various processes that can be substantially represented in a computer-readable medium and thus executed by a computer or processor, regardless of whether such a computer or processor is explicitly shown.

[0080] As used herein, the term "core network" may refer to a device, a group of devices, or a subsystem in a telecommunications network that provides services to telecommunications network users. Examples of services provided by the core network include aggregation, authentication, call switching, service invocation, gateways to other networks, etc.

[0081] As used herein, the term "wireless terminal" may refer to any electronic device used to transmit voice and / or data via a telecommunication system, such as, but not limited to, a cellular network. Other terms used to refer to a wireless terminal and non-limiting examples of such devices may include a user equipment terminal, UE, mobile station, mobile device, access terminal, subscriber station, mobile terminal, remote station, user terminal, terminal, subscriber unit, cellular phone, smart phone, personal digital assistant ("PDA"), laptop computer, tablet computer, netbook, e-reader, wireless modem, etc.

[0082] As used herein, the term "access node," "node," or "base station" may refer to any device or group of devices that facilitates wireless communication or, in other words, provides an interface between a wireless terminal and a telecommunications system. In the 3GPP specifications, non-limiting examples of a base station may include a Node B ("NB"), an enhanced Node B ("eNB"), a Home eNB ("HeNB"), a gNB (for New Radio ["NR"] technology systems), or some other similar terminology.

[0083] As used herein, the term "telecommunication system" or "communication system" may refer to any network of devices used to transmit information. Non-limiting examples of telecommunication systems are cellular networks or other wireless communication systems.

[0084] As used herein, the term "cellular network" or "cellular radio access network" may refer to a network distributed over cells, each cell being served by at least one fixed-position transceiver such as a base station. A "cell" may be any communication channel specified by a standardization or regulatory body for advanced international mobile telecommunications ("IMTAdvanced"). All or a portion of a cell may be adopted by 3GPP as a licensed frequency band (e.g., frequency band) to be used for communication between a base station (such as a Node B) and a UE terminal. A cellular network using a licensed frequency band may include configured cells. A configured cell may include a cell that a UE terminal is aware of and is permitted by a base station to transmit or receive information. Examples of cellular radio access networks include E-UTRAN and any successor networks thereof (e.g., NUTRAN).

[0085] Any reference to "resources" herein refers to "radio resources" unless it is clear from the context that another meaning is intended. Generally speaking, as used herein, a radio resource ("resource") is a time-frequency unit that can carry information (e.g., signal information or data information) over a radio interface.

[0086] An example of radio resources occurs in the context of a "frame" of information that is typically formatted and written by a node, for example. In Long Term Evolution (LTE), a frame that may have one or more downlink parts and one or more uplink parts is transmitted between a base station and a wireless terminal. Each LTE frame may include multiple subframes. For example, in the time domain, a 10ms frame consists of ten one-millisecond subframes. An LTE subframe is divided into two time slots (thus making 20 time slots in a frame). The signal transmitted in each time slot is described by a resource grid consisting of resource elements (REs). Each column of the two-dimensional grid represents a symbol (e.g., an OFDM symbol on a downlink (DL) from a node to a wireless terminal; an SC-FDMA symbol in an uplink (UL) frame from a wireless terminal to a node). Each row of the grid represents a subcarrier. A resource element (RE) is the smallest time-frequency unit used for downlink transmission in a subframe. That is, a symbol on a subcarrier in a subframe includes a resource element (RE) uniquely defined by an index pair (k, 1) in the time slot (where k and 1 are indices in the frequency domain and time domain, respectively). In other words, one symbol on one subcarrier is a resource element (RE). Each symbol includes multiple subcarriers in the frequency domain, and the specific number depends on the channel bandwidth and configuration. The minimum frequency resource supported by today's standards is a collection of multiple subcarriers and multiple symbols (e.g., multiple resource elements (RE)), and is called a resource block (RB). In the case of a canonical cyclic prefix, a resource block may include, for example, 84 resource elements, i.e., 12 subcarriers and 7 symbols.

[0087] In 5G New Radio ("NR"), a frame consists of 10ms duration. A frame consists of 10 subframes, each with 1ms duration, similar to LTE. Each subframe consists of 2μ slots. Each slot can have 14 (normal CP) or 12 (extended CP) OFDM symbols. A slot is a typical unit used for transmission by a scheduling mechanism. NR allows transmission to start at any OFDM symbol and only lasts for the number of symbols required for communication. This is called "microslot" transmission. This facilitates very low latency for critical data communications and minimizes interference to other RF links. Microslots help achieve lower latency in the 5G NR architecture. Unlike slots, microslots are not associated with a frame structure. It helps to truncate existing frames without waiting for scheduling. See, for example, https: / / www.rfwireless-world.com / 5G / 5G-NR-Mini-Slot.html, which is incorporated herein by reference.

[0088] In a mobile network used in a wireless network, the source and destination may be interconnected through multiple nodes. In such a network, the source and destination may not be able to communicate directly with each other because the distance between the source and the destination is greater than the transmission range of the node. That is, an intermediate node is required to relay the communication and provide information transmission. Therefore, an intermediate node can be used to relay information signals in a relay network with a network topology, in which the source and the destination are interconnected through such intermediate nodes. In a hierarchical telecommunication network, the backhaul portion of the network may include an intermediate link between the core network of the entire hierarchical network and a small subnetwork. The integrated access and backhaul (IAB) next generation NodeB uses 5G new radio communications, such as sending and receiving NR user plane (U plane) data traffic and NR control plane (C plane) data. Both UE and gNB may include an addressable memory that communicates electronically with a processor. In one embodiment, instructions may be stored in a memory and executable instructions to process received packets and / or send packets according to different protocols (e.g., a media access control (MAC) protocol and / or a radio link control (RLC) protocol).

[0089] In a mobile network, an IAB child node may establish a connection with an IAB node / carrier or parent using the same initial access process (discovery) as an access UE, thereby attaching to a network or pre-occupying a cell. In one embodiment, a radio resource control (RRC) protocol may be used to send signaling notifications between a 5G radio network and a UE, wherein the RRC may have at least two states (e.g., RRC_IDLE and RRC_CONNECTED) and state transitions. The RRC sublayer may enable a connection to be established based on broadcast system information, and may also include security procedures. The U-plane may include PHY, MAC, RLC, and PDCP layers.

[0090] Embodiments of the present system disclose methods and apparatus for an IAB node to notify a child node and / or a UE of upstream radio conditions, and therefore, the term "IAB node" may be used to represent a parent IAB node or a child IAB node, depending on the location of the IAB node in network communications with an IAB carrier responsible for making a physical connection with a core network. The present invention discloses embodiments in which an IAB node (child IAB node) may follow the same initial access process as a UE, including cell search, system information acquisition, and random access, in order to initially establish a connection with a parent IAB node or an IAB carrier. That is, when an IAB base station (eNB / gNB) needs to establish a backhaul connection to a parent IAB node or an IAB carrier or to pre-occupy a parent IAB node or an IAB carrier, the IAB node may perform the same process and steps as a UE, wherein the IAB node may be regarded as a UE, but the parent IAB node or IAB carrier distinguishes the IAB node from the UE.

[0091] A. Overview of General Architecture Description

[0092] Figure 1A An exemplary telecommunications system 20 is shown, which includes: a core network 21; and a plurality of wireless access nodes, including a carrier or parent IAB node 22 and other IAB nodes 24 that are not carrier IAB nodes, such as IAB nodes 24A, 24B, and 24C; and a plurality of user equipment (UE) 30, which are served by one or more of these access nodes. The IAB nodes 24 are not carrier IAB nodes, but are considered access nodes because they provide connectivity to the UE and therefore provide access to the core network of the UE. Figure 1A It is also shown that the carrier IAB node 22 may be connected to the core network 21 , for example, via a wired 31 or other suitable connection; and a wireless backhaul link may connect the carrier IAB node 22 , the IAB node 24 , and a user equipment (UE) 30 . Figure 1A Specifically shown is, for example, a carrier IAB node 22 connected to one or more IAB nodes 24 via a downlink carrier backhaul link 32 and an uplink carrier backhaul link 33 . Figure 1A It is also shown that the IAB node 24 may be connected to one or more child nodes, such as to a user equipment (UE) 30 or another IAB node 24, via a downlink backhaul link 34 and an uplink backhaul link 35. It should be understood that some portions of the operations and behaviors performed by a carrier IAB node may be capable of being performed by a parent IAB node.

[0093] Figure 1A Indication Exemplary embodiments in the present embodiment may include a mobile network infrastructure using 5G signals and 5G base stations (or cell sites). A system diagram of a radio access network utilizing an IAB node is depicted, wherein the radio access network may include, for example, an IAB carrier 22 and multiple IAB nodes 24. Different embodiments may include different numbers of IAB carriers and IAB node ratios. In this article, the IAB node 24 may be referred to as an IAB relay node. The IAB node 24 may be a radio access network (RAN) node that supports wireless access to UE and wireless backhaul of access traffic. The IAB carrier 22 may be a RAN node that may provide an interface to the core network 21 to the UE 30 and provide wireless backhaul functionality to the IAB node. The IAB node / carrier 22 may use a wireless backhaul link to serve one or more IAB nodes 24 and simultaneously use a wireless access link to serve the UE. Therefore, a network backhaul traffic state may be achieved based on a wireless communication system connected to multiple IAB nodes and UEs.

[0094] Further references Figure 1A, multiple UEs 30 are depicted as communicating with IAB nodes (e.g., IAB nodes 24 and IAB carrier nodes 22) via wireless access links. Additionally, an IAB node, which is considered a child node, may communicate with other IAB nodes and / or IAB carriers via wireless backhaul links, all of which may be considered IAB parent nodes. For example, a UE may connect to an IAB node, which itself may connect to a parent IAB node in communication with an IAB carrier, thereby extending backhaul resources to allow backhaul traffic to be transmitted within the network and between parent and child for integrated access.

[0095] Figure 2A The carrier IAB node 22 and the IAB node 24 are shown (see Figure 1A ). The carrier IAB node 22 may include at least one carrier IAB node centralized unit (CU) 40 and at least one carrier IAB node distributed unit (DU) 42. The centralized unit (CU) 40 is a logical entity that manages the carrier IAB node distributed unit (DU) 42 configured in the carrier IAB node 22 and the remote DU residing in one or more IAB nodes. The centralized unit (CU) 40 may also be an interface connected to the core network 21, which is manifested as a RAN base station (e.g., eNB or gNB).

[0096] In some embodiments, the carrier IAB node distributed unit (DU) 42 is a logical entity that hosts the radio interface (backhaul / access) for other child IAB nodes and / or UEs. In one configuration, under the control of the centralized unit (CU) 40, the distributed unit (DU) 42 can provide physical layer and layer 2 (L2) protocols (e.g., media access control (MAC), radio link control (RLC), etc.), while the centralized unit (CU) 40 can manage upper layer protocols (such as packet data convergence protocol (PDCP), radio resource control (RRC), etc.). Figure 2A As shown, the carrier IAB node centralized unit (CU) 40 may host or include an IAB network power management controller 45. The IAB network power management controller 45 may also be referred to as a "beam controller" 45 herein.

[0097] Likewise Figure 2A As shown, the IAB node 24 may include a mobile terminal (MT) 50 and a distributed unit (DU) 52. In some exemplary embodiments, the distributed unit (DU) 52 may have the same functions as the distributed unit (DU) 42 in the IAB bearer, and the mobile terminal (MT) 50 may be a UE-like function that terminates the radio interface layer. For example, the mobile terminal (MT) 50 may be used to perform at least one of the following: radio transmission and reception, encoding and decoding, error detection and correction, signaling, and access to the SIM.

[0098] DU can have Figure 1A In other words, the access node or gNodeB can be rewritten as CU and DU, and the UE can be rewritten as MT.

[0099] B. IAB network power management / beam steering

[0100] In one of its exemplary aspects, the technology disclosed herein relates to controlling cross-link interference (CLI) that may occur between beams from different IAB nodes of an IAB network. FIG. 7A to FIG. 7G Understanding cross-link interference (CLI) example. In an exemplary embodiment and mode, the control or management of cross-link interference (CLI) is implemented using a cross-link interference controller 44, which may also be referred to as a beam management processor (BMP) 44. The beam management processor (BMP) 44 is used to make a determination about cross-link interference (CLI) and generate a command based on the determination, which is configured to modify the characteristics of the beam transmitted from the parent node to the IAB node. For example, the beam management processor (BMP) 44 can make a determination about the cross-link interference (CLI) between (a) a beam transmitted from the parent node to the IAB node and (b) a beam transmitted from the IBA node to the child node of the IAB node. The command is then transmitted to the IAB network power management controller 45 (e.g., beam controller) of the parent node (e.g., carrier or parent IAB node 22) via an interface circuit. In an exemplary embodiment and mode, a command is generated to modify the signal strength of the beam transmitted from the parent node to the IAB node.

[0101] In Figure IA and Figure 2A In the exemplary embodiment and mode of the present invention, the IAB network power management controller 45 includes a carrier IAB node centralized unit (CU) 40 and is therefore located at a carrier or parent IAB node 22. On the other hand, the beam management processor (BMP) 44 may be located at or include an IAB node that is a child node relative to the carrier IAB node 22 or any other parent node hosting the IAB network power management controller 45. For example, Figure 1A A beam management processor (BMP) 44 is shown located in or included in the IAB nodes 24A, 24B, and 24C. Thus, the IAB node 24 may have a beam management processor (BMP) 44 even if its parent IAB node also has a beam management processor (BMP) 44. Figure 1A and Figure 2AIn the exemplary embodiment and mode, the mobile terminal (MT) 50 of the IAB node 24 acts as an interface circuit that transmits the command to the parent node, and specifically transmits the command to the carrier IAB node 22 via a wireless interface (e.g., uplink carrier backhaul link 33) for use by the IAB network power management controller 45. The command (e.g., beam modification command) configured to modify the beam of the carrier IAB node 22 is shown as Figure 2A Command 72A of .

[0102] Figure 2A and Figure 2B Exemplary embodiments and modes of Figure 1A and Figure 1B The exemplary embodiment and mode of FIG. 4 is the same, except for the fact that the beam management processor (BMP) 44 is located in or includes the carrier IAB node 22 (i.e., the IAB node that hosts the IAB network power management controller 45). Figure 2A and Figure 2B In the embodiment, the internal circuit or bus even includes the processor circuit of one or both of the IAB network power management controller 45 and the beam management processor (BMP) 44 as an interface circuit, which is represented as Figure 2B The interface circuit 74 in the carrier IAB node 22 transmits the beam modification command 72B from the beam management processor (BMP) 44 to the IAB network power management controller 45 in the carrier IAB node 22.

[0103] Figure 1C and Figure 2C Exemplary embodiments and modes of Figure 1A The exemplary embodiment and mode of FIG. 4 is the same as that of FIG. 4 , except that an IAB node 24 other than the carrier or parent IAB node 22 is shown to host the IAB network power management controller 45. For example, Figure 1C and Figure 2C It is shown that the IAB node 24B can host the IAB network power management controller 45B, which can receive beam modification commands from the IAB node 24C. Therefore, the IAB network power management controller 45B is in the IAB node 24b, which is the parent node of the IAB node 24C. Figure 1C As shown in FIG. 2 , the IAB node 24A may also optionally include its own beam management processor (BMP) 44 that communicates with an IAB network power management controller 45 in the carrier or parent IAB node 22 .

[0104] Unless otherwise indicated or understood from the context, references below to the beam management processor (BMP) 44 and / or beam modification commands 72 are intended to include all (1) Figure 1A , Figure 2AExemplary embodiments and modes; (2) Figure 1B / Figure 2B Exemplary embodiments and modes, and (3) Figure 1C In addition, Figure 1A and Figure 2A The beam management processor (BMP) 44 performs the beam management process 70A; Figure 1B and Figure 2B The beam management processor (BMP) 44 performs the beam management process 70B. Figure 1C and Figure 2C The beam management processor (BMP) 44 in the IAB node 24C also performs operations similar to Figure 1A and Figure 1B Unless otherwise indicated or understood from the context, as used herein, "beam management process 70" generally refers to beam management processes 70A, 70B, and 70C. In addition, beam management process 70 executes or cycles between various states, such as those described herein. Fig.11 Those states shown in .

[0105] Various exemplary implementations of the beam modification command 72 are described herein. In one exemplary implementation, the beam modification command 72 may take the form of or include a binary indication, e.g., 1 bit of a power headroom (PHR) medium access control (MAC) control element (CE) sent by the IAB node to the parent node to reduce or increase the Tx power of the parent node by a predetermined amount. Alternatively, the IAB node may calculate and send a specific value to the parent node, e.g., requiring multiple bits, by which the IAB node requests the parent node to increase or decrease its Tx power by the sent value. In this alternative approach, the PHR MAC CE may again be used as a transmission mechanism, but instead of using unused reserved bits, it may send a value in the PH (Type 1, Pcell) field and allocate one of the reserved bits (bits 1 or 2) of the octet to indicate to the parent node that the value in the PH (Type 1, Pcell) field is a target value for the Tx power of the parent node serving the IAB node and that it is not a PHR report from the UE.

[0106] C. Protocol stack configuration and signaling

[0107] The embodiments include a mobile network infrastructure in which multiple UEs are connected to a set of IAB nodes, and the IAB nodes communicate with each other for relaying and / or communicating with the IAB carrier using different aspects of the embodiments of the present invention. In some embodiments, the UE may communicate with the CU of the IAB carrier on the C plane using the RRC protocol; and in other embodiments, the UE may use the Service Data Adaptation Protocol (SDAP) and / or the Packet Data Convergence Protocol (PDCP) radio protocol architecture for data transmission (U plane) through the NR gNB. In some embodiments, the DU of the IAB node may communicate with the CU of the IAB carrier using the 5G radio network layer signaling protocol: F1 Application Protocol (F1-AP*), which is a wireless backhaul protocol that provides signaling services between the DU of the IAB node and the CU of the IAB carrier. That is, as further described below, the protocol stack configuration may be interchangeable and different mechanisms may be used.

[0108] like Figure 3 As shown in the diagram shown, the protocols between the UE, IAB node and IAB bearer are grouped into a control plane (C-plane) and a user plane (U-plane). The C-plane carries control signals (signaling data) while the U-plane carries user data. Figure 3 An example of an implementation is shown where there are two IAB nodes, IAB Node 1 and IAB Node 2 (two hops) between the UE and the IAB bearer. Other implementations may include networks with a single hop or multiple hops where there may be more than two IAB nodes.

[0109] Figure 4 A functional block diagram of an exemplary protocol stack configuration for the U-plane is depicted, the stack including a service data protocol (e.g., SDAP, 3GPP TS 38.324) that can carry user data (e.g., via IP packets). In one embodiment, SDAP runs on top of PDCP (3GPP TS 38.323) and the L2 / physical layer. In one embodiment, an adaptation layer is introduced between the IAB node and the IAB node / bearer, where the adaptation layer carries relay-specific information such as the IAB node / bearer address, QoS information, UE identifier, and potentially other information. In this embodiment, RLC (3GPP TS 38.322) can provide reliable transport in a hop-by-hop manner, while PDCP can perform end-to-end (UE-CU) error recovery. GTP-U (GPRS Tunneling Protocol User Plane) can be used to route user data between CU and DU within the IAB bearer.

[0110] Figure 5Ais a functional block diagram of an exemplary protocol stack configuration of the C-plane between an IAB node (IAB node 1) directly connected to an IAB carrier (via a single hop). In this embodiment, the MT component of the IAB node 1 may establish an RRC connection with the CU component of the IAB carrier. In parallel, the RRC may be used to carry another signaling protocol so that the CU / IAB carrier controls the DU component residing in the IAB node 1. In one embodiment, such a signaling protocol may be referred to as the F1 Application Protocol * (F1-AP*), which is a protocol called F1-AP specified in 3GPPTS 38.473, or a protocol based on F1-AP with potential extension features to accommodate wireless backhaul (the original F1-AP is designed for wired lines). In other embodiments, F1-AP may be used for CU-DU connections within the IAB carrier. It is assumed that below the RLC, the MAC / PHY layer is shared with the U-plane.

[0111] Figure 5B A functional block diagram of an exemplary C-plane protocol stack configuration of an IAB node 2 is depicted, which is connected to the aforementioned IAB node 1 (2 hops). In one embodiment, it can be assumed that the IAB node 1 has established an RRC / F1-AP* connection with the IAB bearer, such as Figure 5A As shown. In IAB node 1, the RRC / PDCP signaling bearer for IAB node 2 can be carried by the adaptation layer to the IAB bearer. Figure 5A , the RRC of IAB node 2 carries the F1-AP* signaling.

[0112] Figure 5C Depicted in Figure 5B Another functional block diagram of an exemplary C-plane protocol stack configuration for RRC signaling of a UE in a 2-hop relay configuration as shown. Thus, a UE with MT components and functions can be connected to a CU of an IAB bearer via a C-plane. As shown, although traffic is routed through IAB Node 2 and IAB Node 1, these two nodes are passive nodes because the data is passed to the next node without manipulation. That is, the UE transmits data to a node connected to, for example, IAB Node 2, which then transmits data to a node connected to, for example, IAB Node 1, which then transmits the data (without manipulation) to the IAB bearer.

[0113] Figure 5A , Figure 5B and Figure 5C It is shown that each IAB node or UE's MT itself has an end-to-end RRC connection with the CU of the IAB bearer. Similarly, each IAB node's DU has an end-to-end F1-AP* connection with the CU of the IAB bearer. Any IAB node present between such endpoints transparently transmits RRC or F1-AP signaling traffic.

[0114] Fig. 6A and Figure 6B is a diagram of an exemplary flow of information transmission / reception and / or processing performed by an IAB node and an IAB bearer according to aspects of an embodiment of the present invention.

[0115] Fig. 6A An exemplary message sequence is depicted regarding the IAB node 1 establishing an RRC connection and then establishing an F1-AP* connection. It is assumed that the IAB node 1 has been pre-configured with (or has been configured by the network) information indicating how to select a cell served by the IAB bearer. As shown in the figure, the IAB node 1 in an idle state (RRC_IDLE) can initiate an RRC connection establishment process by sending a random access preamble to the IAB bearer, which can be received and processed by the DU of the IAB bearer. Upon successful receipt of a random access response from the IAB bearer, the IAB node 1 can send an RRCSetupRequest, then receive an RRCSetup and transmit an RRCSetupComplete. At this point in the message sequence, the IAB node 1 can enter a connected state (RRC_CONNECTED) with the IAB bearer, and can continue with security procedures to configure encryption / integrity protection features. The CU of the IAB bearer can also send an RRCReconfiguration to the IAB node 1, which may include configuration parameters for configuring radio bearers (e.g., data radio bearers (DRBs) and signaling radio bearers (SRBs)). In some embodiments, RRCReconfiguration is sent to modify the RRC connection and establish a radio connection between the UE and the network, however, in this embodiment, RRCReconfiguration may also be sent to configure a connection between the IAB node and the network. The RRC connection reconfiguration message may be used, for example, to establish / modify / release a radio bearer and / or perform a handover, etc. In one embodiment, any RRC message transmitted from the IAB node 1 may include information identifying the IAB node 1 as an IAB node (rather than a UE). For example, a carrier CU may be configured with a list of node identifiers (e.g., IMSI or S-TMSI) that are allowed to use services from the carrier. This information may be used by the CU in subsequence operations, for example, to distinguish a UE from an IAB node.

[0116] As described above, after the RRC connection establishment process, the DU of the IAB node 1 and the IAB bearer may proceed to the F1 setup process using the F1-AP* protocol, which may activate one or more cells served by the DU of the IAB node 1, thereby allowing other IAB nodes and / or UEs to camp on the cells. In this process, the adaptation layer for the IAB node 1 and the IAB bearer may also be configured and activated.

[0117] Figure 6B An exemplary message sequence or information flow for establishing an RRC connection between an IAB node 2 and an IAB bearer and then performing an F1 setup procedure is depicted. In this embodiment, it is assumed that the IAB node 1 has already executed Fig. 6A The procedures for establishing RRC and F1-AP* connections disclosed in . Figure 3 According to aspects of embodiments of the present invention, an IAB node 2 is shown communicating with an IAB node 1 via a radio interface. Figure 6B Node 1 can also be depicted as a child node of IAB Node 1.

[0118] As mentioned above, for example, reference Figure 2A , Figure 2B and Figure 2C ,Each IAB node hosts two New Radio (NR) functions: (i) a mobile terminal (MT) for maintaining a wireless backhaul connection towards an upstream IAB node or IAB carrier, and (ii) a distributed unit (DU) for providing access connectivity to downstream UEs of other IAB nodes. The DU connects to the CU hosted by the IAB carrier via the NRF1-AP* protocol running over the wireless backhaul link.

[0119] The carrier IAB node centralized unit (CU) 40 at the IAB carrier 22 holds all control and upper layer functions, while lower layer operations are delegated to the DU located at the IAB node 24. The split occurs at the radio link control (RLC) layer, so the radio resource control (RRC), service data adaptation protocol (SDAP) and packet data convergence protocol (PDCP) layers reside in the CU, while the RLC, MAC and PHY are hosted by the DU. The adaptation layer is added on top of the RLC, which routes data across the IAB network topology, thus achieving end-to-end connectivity between the DU and the CU.

[0120] For 3GPP Rel-16 intra-band IAB operation, the need to multiplex both access and backhaul traffic within the same frequency band (i.e., access and backhaul traffic carried on the same frequency band) with minimal impact on existing specifications led to the specification of using half-duplex operation. Half-duplex means that the IAB node cannot support simultaneous Tx / Rx. Therefore, the radio resources are divided between access and backhaul in time orthogonal manner (time division multiplexing (TDM)).

[0121] However, for Rel-17, multiplexing of access and backhaul links in frequency (frequency division multiplexing (FDM)) or space (spatial division multiplexing (SDM)) is considered, because in the case of SDM / FDM Tx, they will allow the IAB node to transmit to the access UE and / or child node in DL and to the parent node in UL simultaneously, and in the case of SDM / FDMRx, the IAB node can receive from the parent node in DL and from the access UE and / or child node in UL simultaneously.

[0122] In addition, Rel-17 will consider full duplex of FDM or SDM, which means that the IAB node can simultaneously transmit to the access UE and / or child node in DL and receive from the parent node in DL for backhaul, or the IAB node can simultaneously transmit to the parent node in UL for backhaul and receive in UL for access UE and / or child node, thereby providing enhanced throughput.

[0123] Whether half-duplex or full-duplex, a centralized or decentralized scheduling coordination mechanism is required between the IAB node and the IAB bearer.

[0124] D. Signal beam and signal beam angle

[0125] Millimeter wave (mmWave) frequencies, also known as frequency range 2 or “FR2” in 3GPP terminology, offer the availability of huge bandwidth. However, mmWave links are extremely susceptible to rapid channel variations and suffer from severe free-space path loss and atmospheric absorption. To address these challenges, NR networks provide a set of mechanisms by which the UE and gNB establish highly directional transmit links, also known as transmit beams or Tx beams, typically using high-dimensional phased arrays to benefit from the resulting beamforming gain and maintain acceptable communication quality. However, directional links require fine alignment of the transmitter beams through a set of operations called beam management. Beam management is critical for initial access (e.g., establishing a UE connection with a gNB) and beam tracking (e.g., beam adaptation schemes).

[0126] The details of how the gNB and UE select and maintain specific Tx beams are not covered in detail here, but general beam management during the connected state includes the following:

[0127] The gNB transmits a specific reference signal for each of the multiple beams.

[0128] • Each beam of the plurality of beams has different spatial and temporal aspects.

[0129] For beams where the UE can detect a signal, it performs some measurements on the beamed signal and sends feedback to the gNB, including information about a reference signal specific to each beam.

[0130] The gNB evaluates the quality of the reference signal from each of the multiple beams received by the UE and selects the best one.

[0131] Fig. 7A The gNB is shown using a specific Tx beam among N potential Tx beams as the access link (i.e., beam 3) at the UE.

[0132] As described above, Rel-17 will consider full-duplex Tx and Rx schemes, which means that the IAB node can simultaneously transmit in DL to the access UE and / or child node and receive in DL from the parent node for backhaul, or the IAB node can simultaneously transmit in UL to the parent node for backhaul and receive in UL for the access UE and / or child node. Such simultaneous transmissions may cause cross-link interference (CLI) between the parent node and the child node.

[0133] Due to the nature of wireless communications, wireless links may degrade or fail at any time. Therefore, a process is needed to monitor the status of the Tx beam and manage its resources. According to one of its exemplary aspects, the technology disclosed herein provides a beam management processor (BMP) 44 that is configured and employed to detect and mitigate and manage situations when the Tx beam alignment of the parent node and the IAB node (frequency reuse = 1) is such that a CLI condition may exist. Specifically, the beam management processor (BMP) 44 can perform a beam management process 70 that:

[0134] 1. Detect that the child node connected to the IAB node is in a position covered by or almost covered by the Tx beam that the parent node of the IAB node is using to communicate with the IAB node.

[0135] 2. When determining CLI impact, determine whether the child node is affected by the CLI of the Tx beam from the parent node, while considering the RP parameters specific to the child node type, such as a child node in an IAB network or a UE in an access network.

[0136] 3. Determine whether a reduction in transmit power of a downlink backhaul link between the parent node and the IAB node can be achieved that reduces interference to an access link used by the IAB node and the child node and still maintains acceptable throughput and QoS on the backhaul link used by the parent node and the IAB node. And, if such a determination is made, the processor requests the parent node to reduce its transmit power on the backhaul link between the parent node and the IAB node.

[0137] 4. Determine whether an increase in the transmit power of the downlink backhaul link between the parent node and the IAB node can be achieved, which can provide benefits to the IAB node or its cell via an increase in the throughput of the parent node, and the increase in the transmit power of the backhaul link between the parent node and the IAB node will not cause the child node or its cell to be significantly affected by the CLI transmitted from the parent node. And, if such a determination is made, the processor requests the parent node to increase its transmit power on the backhaul link between the parent node and the IAB node.

[0138] 5. Find the power transmission threshold of the backhaul link that balances the above two aspects (minimizing the parent node transmit power to reduce interference to the child node, and maximizing the parent node transmit power to increase the DL throughput from the parent node to the IAB node).

[0139] Figure 7B The use of a Tx beam as an access link to a UE (ie, a beam Z ) of the IAB node, and using the Tx beam as the backhaul link to the IAB node (i.e., beam N The access network belonging to the IAB node is not shown, but from the above, those skilled in the art should understand the behavior well.

[0140] Figure 7C The use of a Tx beam as an access link to a child node MT (ie, beam c ), and a parent node that uses a Tx beam as a backhaul link to the IAB node (i.e., beam 3), and the Tx beam of the parent node is aligned with the Tx beam of the IAB node, and the Tx beam of the parent node is strong enough to cover some area in the same area as the Tx beam of the IAB node, i.e., beam c and beam 3 is aligned within its coverage area.

[0141] Fig.7D The use of a Tx beam as an access link to a child node MT (ie, beam c ), and a parent node using a Tx beam as a backhaul link to the IAB node (i.e., beam 3), and the Tx beam of the parent node is aligned with the Tx beam of the IAB node, and the Tx beam of the parent node is strong enough to provide coverage to some areas in the same area as the Tx beam of the IAB node, and both links cover the UE, and therefore the UE may experience beam 3 as its receive beam c In fact, due to the beam 3 and beam c The basic overlap, in Fig.7D The beam cannot be seen c Mark.

[0142] Fig. 7E The result of one step of the beam management process is shown, which reduces the coverage area of ​​the parent node's Tx beam 3, for example, reducing the beam 3 Tx power so that Tx beam 3 is aligned with the beam of the IAB node. c The alignment is reduced to the point where beam 3 no longer causes the receive beam to be aligned with the first child node. c However, the signal strength of beam 3 may remain strong enough that child node 2 may still experience beam 3 as its receiving beam. c CLI. Similar to Fig.7D ,exist Fig. 7E In the case of beam 3 and beam c The basic overlap of beam c makes it impossible to see the marking of beam c.

[0143] Figure 7F The result of the subsequent steps of the beam management process is shown, which further reduces the coverage area of ​​the parent node's Tx beam 3, for example, reducing the beam 3 Tx power so that Tx beam 3 is aligned with the beam of the IAB node. c The alignment is reduced to the point where beam 3 no longer causes the second child node to receive beam c However, the signal strength of beam 3 can remain strong enough so that the IAB node can still maintain the necessary DL bandwidth with the parent node. Fig.7D and Fig. 7E ,exist Figure 7F In the case of beam 3 and beam c The basic overlap of beam c makes it impossible to see the marking of beam c.

[0144] Figure 7G The result of the subsequent steps of the beam management process is shown, which increases the coverage area of ​​the parent node's Tx beam 3 (i.e., increases the beam 3 Tx power) compared to the previous figure, so that Tx beam 3 provides a stronger signal to the IAB node (i.e., increased throughput), but does not cause the child node to receive the beam c CLI.

[0145] E. Node Architecture for Beam Management

[0146] Fig. 8A , Figure 8B and Figure 8C General exemplary embodiments and modes of arrangement and composition of certain functions and components of the carrier IAB node 22, the exemplary representative IAB node 24, and the exemplary representative user equipment (UE) 30 are shown in greater detail. Fig. 8A The implementation scheme and mode correspond to Figure 1A and Figure 2AAn arrangement in which the IAB node 24 includes a beam management processor (BMP) 44. Figure 8B The implementation scheme and mode correspond to Figure 1B and Figure 2B An arrangement in which the carrier IAB 24 includes a beam management processor (BMP) 44. Figure 8C The implementation scheme and mode correspond to Figure 1C and Figure 2C An arrangement in which the carrier IAB 24B includes an IAB network power management controller 45B. It should be understood that Fig. 8A , Figure 8B and Figure 8C Each of the nodes includes additional components and functionalities known to those skilled in the art, and for simplicity, mainly those components and functionalities related to the technology disclosed herein are shown.

[0147] From the foregoing, it can be understood that Fig. 8A , Figure 8B and Figure 8C The carrier IAB node 22 is shown to include a centralized unit (CU) 40 and a distributed unit (DU) 42. The centralized unit (CU) 40 and the distributed unit (DU) 42 may be implemented (e.g., composed of) or include one or more processor circuits (e.g., a carrier node processor 46), for example. The centralized unit (CU) 40 and the distributed unit (DU) 42 may share one or more node processors 46, or each of the centralized unit (CU) 40 and the distributed unit (DU) 42 may include one or more node processors 46. The IAB network power management controller 45 may be constituted or implemented by the carrier node processor 46. The centralized unit (CU) 40 and the distributed unit (DU) 42 may be co-located at the same node site, or alternatively, one or more distributed units may be located at a site away from the centralized unit (CU) 40 and connected to it via a packet network. The distributed unit (DU) 42 of the carrier IAB node 22 may include a transceiver circuit 47, which in turn may include a transmitter circuit 48 and a receiver circuit 49. Transceiver circuit 47 includes an antenna for wireless transmission. Transmitter circuit 48 includes, for example, amplifiers, modulation circuits, and other conventional transmission equipment. Receiver circuit 49 includes, for example, amplifiers, demodulation circuits, and other conventional receiver equipment.

[0148] like Fig. 8A , Figure 8B and Figure 8CAs shown, in an exemplary embodiment and mode, the IAB node 24 (also referred to as the wireless relay node 24) includes an IAB node mobile terminal (MT) unit 50 and an IAB node distributed unit (DU) 52. The IAB node mobile terminal (MT) unit 50 and the IAB node distributed unit (DU) 52 may be implemented (e.g., composed of) or include one or more processor circuits (e.g., IAB node processor 54), for example. The IAB node mobile terminal (MT) unit 50 and the IAB node distributed unit (DU) 52 may share one or more IAB node processors 54, or each of the IAB node mobile terminal (MT) unit 50 and the IAB node distributed unit (DU) 52 may include one or more IAB node processors 54. The IAB node distributed unit (DU) 52 may include an IAB node transceiver circuit 57, which in turn may include an IAB node transmitter circuit 58 and an IAB node receiver circuit 59. The IAB node transceiver circuit 57 includes an antenna for wireless transmission. IAB node transmitter circuitry 58 may include, for example, amplifiers, modulation circuitry, and other conventional transmission equipment. IAB node receiver circuitry 59 may include, for example, amplifiers, demodulation circuitry, and other conventional receiver equipment.

[0149] Fig. 8A , Figure 8B and Figure 8C The subnode 30 is shown by way of example as a user equipment (UE) 30, which in an exemplary, non-limiting embodiment and mode includes a transceiver circuit 60. The transceiver circuit 60 may in turn include a transmitter circuit 62 and a receiver circuit 64. The transceiver circuit 60 includes an antenna for wireless transmission. The transmitter circuit 62 may include, for example, an amplifier, a modulation circuit, and other conventional transmission equipment. The receiver circuit 64 may include, for example, an amplifier, a demodulation circuit, and other conventional receiver equipment. Fig. 8A and Figure 8B Also shown is a subnode 30, which (as previously noted) may be a user equipment or an integrated access and backhaul (IAB) node, and also includes node processor circuitry such as one or more node processors 66 and an interface 68 including one or more user interfaces. Such user interfaces may be used for user input and output operations, and may include, for example, a screen such as a touch screen that may display information to a user and receive information input by a user. For example, the user interface 68 may also include other types of devices such as a speaker, a microphone, or a tactile feedback device.

[0150] exist Fig. 8A , Figure 8B and Figure 8CIn the exemplary, non-limiting embodiments and modes shown, the child node 30 may include a frame / message generator / processor 69. As will be appreciated by those skilled in the art, in some telecommunication systems, messages, signals and / or data are transmitted over a radio or air interface using one or more "resources" (e.g., "radio resources"). The frame / message generator / processor 69 is used to process messages, signals and data received from other nodes.

[0151] As compared to Figure 1A and Figure 2A As understood, Fig. 8A In the exemplary embodiment and mode of the invention, the beam management processor (BMP) 44 is located at the IAB node 24, for example, the IAB node 24 includes the beam management processor (BMP) 44. For example, the beam management processor (BMP) 44 can be implemented by the IAB node processor 54. On the other hand, in Fig. 8A In the exemplary embodiment and mode of the present invention, the IAB network power management controller 45 is located at the carrier or parent IAB node 22, for example, the carrier or parent IAB node 22 includes the IAB network power management controller 45. For example, the carrier node processor 46 providing the carrier IAB node centralized unit (CU) 40 may include a processor for forming the IAB network power management controller 45.

[0152] As compared to Figure 1B and Figure 2B As understood, Figure 8B In the exemplary embodiment and mode of the embodiment, the beam management processor (BMP) 44 and the IAB network power management controller 45 are located at the carrier or parent IAB node 22, for example, the carrier or parent IAB node 22 includes both the beam management processor (BMP) 44 and the IAB network power management controller 45. The beam management processor (BMP) 44 can and the IAB network power management controller 45 can include or be included in the carrier node processor 46. Preferably, the beam management processor (BMP) 44 and the IAB network power management controller 45 include or are included in the carrier IAB node centralized unit (CU) 40.

[0153] As compared to Figure 1C and Figure 2C As understood, Figure 8C In an exemplary embodiment and mode of the IAB node 24b, the IAB node 24b may host an IAB network power management controller 45B and optionally also host its own beam management processor (BMP) 44.

[0154] Thus, a beam management processor (BMP) 44 may be included in the IAB node 24, such as Figure 1A , Figure 2A and Fig. 8AThe situation and Figure 1C , Figure 2C Alternatively, the beam management processor (BMP) 44 can Figure 1B , Figure 2B and Figure 8B Wherever included, for example, whether in the carrier IAB node 22 or in the IAB node 24, in an exemplary embodiment and mode, a beam management processor (BMP) 44 may include a processor circuit configured to make a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to an IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node; and based on the determination. Figure 1A / Figure 2A / Fig. 8A In the case of Figure 1C / Figure 2C / Figure 8C In the case of, such processor circuits may include IAB node processor 54; Figure 1B / Figure 2B / Figure 8B In the case of , such processor circuitry may include carrier node processor 46.

[0155] A node including a beam management processor (BMP) 44 also includes an interface circuit configured to transmit commands to a beam controller of a parent node (e.g., an IAB network power management controller 45). Figure 2A and Figure 8B In an exemplary embodiment and mode of the invention, the interface circuit includes a mobile terminal circuit of the IAB node, and the mobile terminal circuit of the IAB node is configured to transmit the command to the beam controller via the wireless backhaul interface. Figure 1B , Figure 2B and Figure 8B In an exemplary embodiment and mode, the interface circuit includes a circuit or bus that connects the beam management processor (BMP) 44 to the IAB network power management controller 45, or a circuit that transmits the beam modification command 72 through a function or data channel, etc.

[0156] Fig. 9Exemplary, non-limiting, basic actions or steps that may be performed by a node performing a beam management process according to exemplary embodiments and modes are shown. Action 9-1 includes making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to an IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node. Action 9-2 includes generating a command based on the determination, the command being configured to modify a characteristic of a beam transmitted from the parent node to the IAB node. Action 9-1 and action 9-2 may be performed using a processor circuit, such as Fig. 8A The IAB node processor 54 of the IAB node 24 in the embodiment and mode, Fig. 8A The IAB node processor 54 of the IAB node 24C in the embodiment and mode, or Figure 8B The carrier node processor 46 of the carrier or parent IAB node 22 of the embodiment and mode. Action 9-3 includes transmitting a command (e.g., a beam modification command 72) to the beam controller of the parent node, for example, in FIG. 1A / Figure 2A / Fig. 8A In the case of Figure 2B / Figure 8B In the case of a transmission to the IAB network power management controller 45 of the carrier or parent IAB node 22, or in Figure 1C / Figure 2C / Figure 8C In the case of , it is transmitted to the IAB network power management controller 45B of the IAB node 24B.

[0157] Fig.10 Exemplary, non-limiting, basic actions or steps that may be performed by a node to modify the characteristics of a beam transmitted therefrom in accordance with a beam management procedure are shown. Fig.10 The node of the action is Figure 1A / Figure 2A and Figure 1B / Figure 2B In both cases it can be a carrier node or a parent node 22. Figure 1C / Figure 2C In this case, it may be the IAB node 24B, for example, the node hosting the IAB network power management controller 45B, which may receive the beam modification command from the IAB node 24C.

[0158] Action 10-1 includes obtaining commands configured based on a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node. Action 10-1 may be performed by a receiver circuit of a node that receives the beam steering command 72. Thus, the receiver circuit may be viewed as an interface configured to obtain commands configured based on a determination regarding cross-link interference. Figure 1A / Figure 2A In the case of Figure 1B / Figure 2B In the case of , the receiver circuit may be the receiver circuit 49 of the distributed unit (DU) 42 of the carrier IAB node 22. Figure 1C / Figure 2C In the case of , the receiver circuit may be the IAB node receiver circuitry 59 of the IAB node distributed unit (DU) 52 of the IAB node 24B.

[0159] Action 10-2 comprises modifying a characteristic of a beam transmitted from the node to the wireless relay node in accordance with the command. Preferably, the characteristic is the transmit power of the carrier or parent IAB node 22. Optionally, as action 10-3, the carrier or parent IAB node 22 may generate configuration data for use by the wireless relay node in its determination of cross link interference (CLI). Action 10-2 and optional action 10-3 are described in detail below. Figure 1A / Figure 2A and Figure 1B / Figure 2B In the case of Figure 1C / Figure 2C In the case of , it is performed by the IAB network power management controller 45B of the IAB node 24B. The IAB network power management controller 45 can therefore be regarded as a beam transmission circuit that is configured to modify the characteristics of the beam transmitted from the node to the wireless relay node using the command. The beam itself is transmitted by an appropriate transmitter of the node, for example, in Figure 1A / Figure 2A In the case of Figure 1B / Figure 2B In the case of, it is transmitted by the transmission circuit 48 of the distributed unit (DU) 42 of the carrier IAB node 22, and Figure 1C / Figure 2C In the case of , it is transmitted by the IAB node transmitter circuit system 58 of the distributed unit (DU) 52 of the IAB node 24.

[0160] As described above, in exemplary embodiments and modes, the characteristic of the beam transmitted from the node to the wireless relay node is the transmit power of the beam. However, in other exemplary embodiments and modes, different characteristics of the beam may be modified. For example, in exemplary embodiments and modes, the modified characteristic of the beam may be the beam frequency, which may be particularly relevant in the case where the frequency reuse is not 1.

[0161] F. Beam Management Process: Overview

[0162] Fig.11 Exemplary states involved in executing the beam management process 70 are shown. Figure 1A and Figure 2A As described above, in one configuration, the RLC layer of the DU portion of the IAB node may host a beam management processor (BMP) 44 that performs beam management procedures. Figure 1B and Figure 2B In another configuration depicted, a carrier IAB node centralized unit (CU) 40 of the carrier IAB node 22 may host a beam management processor (BMP) 44 that performs the beam management process 70 .

[0163] The beam management process 70 may determine that the IAB node is using "in-band" resources and "full-duplex" signaling on the access and backhaul links, and therefore there is a possibility of cross-link interference (CLI) of the parent node Tx beam to the Tx beam of the child node receiving IAB node.

[0164] The beam management process 70 may monitor the positions of the child nodes relative to their IAB nodes and the parent nodes of the IAB nodes, and determine that such positions will cause the Tx beam of the access link of the IAB node serving the child node to be aligned with the Tx beam of the backhaul link of the parent node serving the IAB node. The beam management process 70 may then further determine that the signal strength of the backhaul link of the parent node is sufficient to cause cross link interference (CLI) when the IAB node sends an access link signal to the child node.

[0165] The beam management process 70 may then further determine that the signal strength of the parent node's backhaul link may be reduced and may still provide sufficient throughput to the IAB node, and thus the beam management process 70 may send an indication to the parent node requesting the parent node to reduce its transmit power on the backhaul link to the IAB node.

[0166] The beam management process 70 may then further determine that an increase in the signal strength of the parent node's backhaul link may improve throughput to the IAB node, and that such an increase in the signal strength of the parent node's backhaul link may not cause CLI when the IAB node sends an access link signal to the child node, such that the beam management process 70 may send an indication to the parent node, requesting the parent node to increase its transmit power on the backhaul link to the IAB node.

[0167] Therefore, as one of the exemplary aspects of the technology disclosed herein, a beam management process 70 is provided to detect, mitigate and manage cross-link interference (CLI) that a parent node may cause to a child node of an IAB node. In an exemplary embodiment and mode, the beam management process 70 may include, for example, Fig.11 Five separate states are visualized in .

[0168] In state 70-1, the beam management process 70 executed by the beam management processor (BMP) 44 evaluates whether there are child nodes of the IAB node being interfered by the parent node serving the IAB node (i.e., CLI). If the result of 70-1 is true, the beam management process 70 transitions to state 70-2. If the result of state 70-1 is false, the beam management process 70 transitions to state 70-4.

[0169] In state 70-2, the beam management process 70 evaluates whether the transmit power of the parent node on the backhaul link to the IAB node can be reduced and still provide service to the IAB node. If the result of state 70-2 is true, the beam management process 70 transitions to state 70-3. If the result of state 70-2 is false, the beam management process 70 transitions to state 70-1.

[0170] In state 70-3, the beam management process 70 sends a signal (e.g., a beam modification command 72) to the parent node to request a reduction in transmit power on the backhaul link serving the IAB node, and initializes a local timer PCTimer to a value associated with the parent node, which provides a period of time that elapses before the BMP can issue another request to change the transmit power of the parent node on the backhaul link serving the IAB node and before the BMP transitions back to state 70-1.

[0171] In state 70-4, the beam management process 70 evaluates whether an increase in the transmit power of the parent node on the backhaul link will provide an increase in throughput to the IAB node and will not cause interference to the child nodes of the IAB node. If the result of state 70-4 is true, the BMP transitions to state 70-5. If the result of state 70-4 is false, the beam management process 70 transitions to state 70-1

[0172] In state 70-5, the beam management process 70 sends a signal (e.g., a beam modification command 72) to the parent node to request an increase in the transmit power on the backhaul link serving the IAB node, and initializes the local timer PCTimer to a value associated with the parent node, which provides a period of time that elapses before the beam management process 70 can issue another request to change the transmit power of the parent node on the backhaul link serving the IAB node and before the beam management process 70 transitions back to state 70-1.

[0173] Although Fig.11 The various states of the beam management process 70 are shown, but Figures 12 to 30 Exemplary logical acts or steps comprising a beam management process 70 that may be performed by the beam management processor (BMP) 44 are shown. Figures 12 to 30 Each of the BMPs is associated with a page of logic flow for the beam management process 70. The first text block of the BMP is associated with the topmost level of the flow chart, is considered the start of the beam management process 70, and is identified by "BMP() 1.0". Fig.30 Each page in the logic flow diagram of can be viewed as a subroutine or program call or similar structured coding method. The beam management process 70 operates from the perspective of the IAB node and considers the IAB nodes attached to it (eg, child nodes) and the parent node serving it.

[0174] The beam management process 70 (i.e., BMP() of Figure BMP) determines, mitigates, and manages cross-link interference (CLI) caused by a parent node to a child node, where the parent node serves an IAB node that serves the child node. Referring to the actions of Figure BMP, in summary:

[0175] • As action 12-0, the beam management process 70 determines whether the time and frequency resources used by the parent node to serve the IAB node are the same as the time and frequency resources used by the IAB node to serve its child nodes, and if not, the BMP terminates.

[0176] Otherwise, as shown in action 12-1, the beam management process 70 uses the DecreaseTxPower() function 80 to reduce the Tx beam power of the parent node as much as possible.

[0177] Then, as action 12-2, the beam management process 70 may use the IncreaseTxPower() function 220 to increase the Tx beam power of the parent node as much as possible,

[0178] The beam management process 70 then resumes execution at action 12-0.

[0179] F.1 BMP: DecreaseTxPower() function

[0180] The DecreaseTxPower() function 80 determines whether any of the child nodes of the IAB node served by the parent node are likely to experience CLI from the parent node's Tx beam, and if so, it further determines whether a reduction in the parent node's Tx beam signal strength will result in an acceptable service level provided by the parent node to the IAB node. Fig.13 Exemplary actions are shown for the steps of the DecreaseTxPower() function 80. The DecreaseTxPower() function 80 is a top-level function for determining whether the power of the Tx beam of a parent node may be reduced, and requesting such a reduction from the parent node.

[0181] Fig.13 The basic, representative actions or steps of the exemplary implementation of the DecreaseTxPower() function 80 shown include, but are not necessarily limited to, the following:

[0182] As action 13-1, use the GetNodeData() function 90 to obtain all necessary data of the BMP to perform its functions, such as ChildNodeInfoTable, ParentNodeInfo, IABNodeInfo.

[0183] As action 13-2, a loop index "i" is initialized.

[0184] As actions 13-3 to 13-5, for each child node in ChildNodeInfoTable, for example, the information of each child node is copied to ChildNodeInfo in turn (action 13-3) for processing, and the BeamInterference() function 100 with an input parameter set to zero is used (action 13-5) to estimate whether the signal of the Tx beam used by the parent node to serve the IAB node may cause interference to the child node,

[0185] Then, if the BeamInterference() function returns true as determined in act 13-6, the PowerControlMitification() function 190 is used in act 13-7 to determine whether the IAB node can tolerate the reduction of the parent node's Tx beam,

[0186] Then, if it is determined as action 13-8 that the PowerControlMitigation() function of action 13-7 returns a true value, then as action 13-11, a ReqTxPowerDecrease() function 210 is called to request the parent node to reduce the Tx power of the beam serving the IAB node,

[0187] Then as action 13-12, wait until the power control timer expires,

[0188] • Then continue with the first step 13 - 1 of the DecreaseTxPower() function 80 .

[0189] As shown in actions 13-9 to 13-10, if the DecreaseTxPower() function 80 sequentially steps through all child nodes in the ChildNodeInfoTable without executing the ReqTxPowerDecrease() function 210, it returns (action 13-10).

[0190] F.2 BMP: GetNodeData() function

[0191] The GetNodeData() function 90 obtains all necessary data related to the parent node, IAB node and child node for which the BMP is to be executed. The basic actions or steps of the exemplary implementation and mode of the GetNodeData() function 90 are as follows: Fig.14 , and in summary includes constructing data objects related to parent nodes, IAB nodes and child nodes into three information tables accessible to all functions of the BMP, for example, these tables are global data.

[0192] The first table ChildNodeInfoTbl is a 2-dimensional table of all child nodes served by the IAB node and necessary information associated with each child node. Non-limiting examples of a child node table may include information about the location of the child node, minimum receiver threshold, interference level offset, aspects of the IAB node beam serving the child node, such as Horz_Angle, Horz_Width, Vert_Angle, Vert_Width, TxPower,

[0193] The second table IABNodeInfo is a 1-dimensional table of information about IAB nodes. Non-limiting examples of the IAB node table may include information about the location of the IAB node, the minimum receiver threshold, the service level offset, and the maximum offset.

[0194] The third table ParentNodeTable is a 1-dimensional table of parent nodes serving the IAB node and information associated with the parent node. Non-limiting examples of ParentNodeTable may include information about the location of the parent node, aspects of the beam of the parent node serving the IAB node, and the step value that the parent node will use to increase or decrease the parent node Tx beam.

[0195] For each child node [1..n] of the IAB node, action 14-1 of the GetNodeData() function 90 includes adding the following child node information elements [1..m] to the table ChildNodeInfoTbl[0..n-1, 0..m-1]: InterferenceOffset, MinRxThreshold, Location[X, Y, Z], RxDiffValue, PathLossModel, etc.

[0196] For each child node [1..n] of the IAB node, action 14-2 of the GetNodeData() function 90 includes adding the following child node service Tx beam information elements [1..z] to the table ChildNodeInfoTbl[0..n-1, m..m+z-1]: Horz_Angle, Horz_Width, Vert_Angle, Vert_Width, IAB TxPower, etc.

[0197] For an IAB node serving one or more child nodes, action 14 - 3 of the GetNodeData() function 90 includes obtaining the following IAB node information elements [1..q] into IABNodeInfo[0..q-1]: ServiceOffset, location[X, Y, Z], MinRxThreshold, MaxOffset, PathLossModel, etc.

[0198] For a parent node serving an IAB node that serves one or more child nodes, action 14-4 of the GetNodeData() function 90 includes obtaining the following parent node information elements [1..r] into ParentNodeInfo[0..r-1]: Horz_Angle, Horz_Width, Vert_Angle, Vert_Width, TxPower, Tx Antenna location[X, Y, Z], TxPowerStep, PCStepTimer, etc. Action 14-5 includes the return of the GetNodeData() function 90.

[0199] F.3 BMP: BeamInterference(parameters) function

[0200] Fig.15Basic, exemplary representative actions or steps of an exemplary implementation of the BeamInterference(parameter) function 100 are shown. The BeamInterference(parameter) function 100 takes 1 parameter as input: the value passed to the CheckBeamStrength() function. The function will determine whether the Tx beam of the parent node serving the IAB node is strong enough to cause interference to the child node given the relative position of the child node with respect to the parent node. The BeamInterference(parameter) function 100 checks the interference of the parent node Tx beam of the IAB node serving the IAB node to the child node of the IAB node. If the input parameter is zero, a check on the signal strength is calculated for the current conditions. If the parameter is non-zero, a check on the received signal of the parent node at the IAB node is calculated for a potential increase in the Tx signal of the parent node, such as an increase in the parameter value.

[0201] Fig.15 The basic, representative actions or steps of the illustrated exemplary implementation of the BeamInterference (parameters) function 100 include, but are not necessarily limited to, the following:

[0202] As action 15-1, using the CheckBeamStrength() function 110 with 1 input parameter to estimate whether the parent node's Tx beam signal strength will interfere with the child node receiving a signal from the IAB node, and if determined as action 15-2, then there is interference,

[0203] As action 15-3, use the CheckBeamAlignment() function 180 to determine if the child node's position is aligned with both the parent node's Tx beam and the IAB node's Tx beam.

[0204] If the CheckBeamStrength() check of act 15-1, and if the CheckBeamAligment() check of act 15-3 is determined to be true as act 15-4, then the BeamInterference() function 100 returns true as act 15-5, otherwise returns false as act 15-6.

[0205] F.4 BMP: CheckBeamStrength(parameters) function

[0206] Fig.16The basic, exemplary representative actions or steps of an exemplary implementation of the CheckBeamStrength(parameters) function 110 are shown. The CheckBeamStrength(parameters) function 110 takes as input 1 parameter: the value passed to the CheckRxThreshold() function. The CheckBeamStrength(parameters) function 110 determines whether the parent node's Tx power, which is adjusted according to the offset, is sufficient to interfere with the child node's reception of the IAB node's signal.

[0207] Based on the given adjustment, the CheckBeamStrength (parameter) function 110 checks whether the signal strength of the parent node's Tx beam will interfere with the child node's reception of the IAB node's signal. Determining whether there is interference takes two aspects into consideration: first, checking whether the parent node's signal (estimated at the child node) exceeds the minimum threshold of the child node's receiver. Second, checking whether the received signal of the IAB node (estimated at the child node) is strong enough than the parent node's received signal (estimated at the child node) so that the parent node's signal does not cause excessive interference to the child node's received signal of the IAB node. If the input parameter is zero, a check on the parent node's received signal strength is calculated for the current conditions. If the input parameter is non-zero, a check on the parent node's received signal at the child node is calculated for a potential increase in the parent node's Tx signal (i.e., increasing the parameter value).

[0208] Basic, exemplary, representative actions or steps of the CheckBeamStrength(parameters) function 110 include:

[0209] As action 16-1, use the CheckRxThreshold() function 120 with 1 input parameter to estimate whether the Tx beam signal strength of the parent node is stronger than the minimum received signal of the child node. If it is determined as action 16-2 that the signal strength of the Tx beam of the parent node is greater than the Rx signal strength of the child node, perform action 16-3.

[0210] As action 16-3, use the CheckDiffRxPower() function 160 to determine if the difference between the Rx signal strength of the IAB node at the child node and the Rx signal strength of the parent node at the child node is greater than a system-provided value.

[0211] If CheckRxThresholdQ returns true as determined as act 16-3, and if CheckDiffRxPowerQ returns false as determined as act 16-4, then CheckBeamStrength(parameter) function 110 returns true as act 16-5, otherwise returns false as act 16-6.

[0212] F.5 BMP: CheckRxThreshold(parameters) function

[0213] Fig.17 The basic, exemplary representative actions or steps of an exemplary implementation of the CheckRxThreshold(parameter) function 120 are shown. The CheckRxThreshold(parameter) function 120 takes as input 1 parameter: an offset to apply to the minimum receiver threshold of the child node. The CheckRxThreshold(parameter) function 120 determines whether the Tx power of the parent node is greater than the minimum receive threshold of the child node, which Tx power is adjusted according to the offset.

[0214] Fig.17 The basic, representative actions or steps of the illustrated exemplary implementation of the CheckRxThreshold(parameters) function 120 include, but are not necessarily limited to, the following:

[0215] As action 17-1, obtain an RF propagation model from the ChildNodeInfo table for use in determining a path loss between the transmitting node and the receiving node,

[0216] Then as action 17-2, the RF signal strength loss from the transmitter to the receiver is estimated using the CalculatePathLoss() function 130 with 3 input parameters, e.g., from the parent node to the child node for a given path loss model, e.g., obtaining the path loss between the parent node and the child node for a given RF propagation model. For example, the Friis equation can solve for the path loss given the distance between the Tx and Rx antennas, the Tx power, the Tx frequency, and other antenna configuration parameters. Other path loss models are: Walfish-Ikegami, / / Okumura-Hata, Longley-Rice, Lee, and Young.

[0217] Then as action 17-3, the InterferenceOffset() function 140 with 1 input parameter is used to obtain an offset for determining whether the receiver of the child node is interfered by the parent node Tx beam, so action 17-3 includes obtaining the interference offset between the parent node and the child node. The system can provide an interference offset used when evaluating whether the parent node Tx beam interferes with the receiver of the child node. The offset can be a positive or negative value.

[0218] • Then as action 17-4, the MinRxThresholdQ function 150 is used to obtain the minimum received signal for determining whether the child node's receiver is interfered by the parent node Tx beam.

[0219] As action 17-5, obtain the current transmit power of the parent node's Tx beam from the ParentNodeInfo table,

[0220] determining as action 17-6 the transmit power of the parent node estimated as action 17-6,

[0221] After determining the TargetRxSignal as action 17-7, determining as action 17-8 that the estimated transmit power of the parent node minus the path loss to the child node, plus the parameter provided by the BMP is greater than the minimum receiver threshold of the child node minus the interference offset provided by the system,

[0222] If the determination of action 17-8 is true, then true is returned as action 17-9, otherwise false is returned as action 17-10.

[0223] F.6 BMP: CalculatePathLoss() function 60

[0224] Fig.18 Basic, representative, exemplary actions or steps of an exemplary implementation of the CalculatePathLoss() function 60 are shown. The CalculatePathLoss(ParentNodeInfo, IABNodeInfo, Model) function 130 takes as input three parameters: information about the transmitting node, information about the receiving node, and the path loss model to be used. The function provides an estimate of the RF signal strength loss from a transmitter to a receiver (e.g., a parent node to a child node) given information about the transmitter power, the transmitter antenna, the distance between the transmitter and the receiver, and the expected propagation environment (e.g., free space or non-free space), and a propagation model (e.g., Walshis-Ikegami, Okumura-Hata, Longley-Rice, Lee, and Young).

[0225] Fig.18 The basic, representative actions or steps of the exemplary implementation of the CalculatePathLoss() function 60 shown include, but are not necessarily limited to, the following:

[0226] as action 18-1, determining whether an input parameter of the receiver node is a UE type,

[0227] then if yes, using as action 18-2 a set of parameters used by a path loss model for a receiver node of the UE type,

[0228] • Otherwise, use as action 18-3 a set of parameters used by the path loss model for non-UE type receiver nodes.

[0229] • As depicted by act 18-4 and act 18-6, select the propagation model to be used based on the input parameters (if provided), as shown by corresponding acts 18-5 and 18-6, otherwise use a default model as act 18-9.

[0230] ·As action 18-8, calculate the path loss from the transmitting node to the receiving node via the selected RF propagation model and node type parameters, and return the result as action 18-9. The CalculatePathLoss() function 60 calculates the estimated path loss between the nodes based on the path loss model and based on the Rx node type parameters. The present disclosure contemplates which model is used, but the details about the operation of the model selected by the function are not the focus of the present disclosure. Any number of different models can determine the path loss. For example, the Friis equation can solve for the path loss given the distance between the Tx and Rx antennas, the Tx power, the Tx frequency, and other antenna configuration parameters. Other path loss models are: Walfish-Ikegami, Okumura-Hata, Longley-Rice, Lee, and Young.

[0231] F.7 BMP: InterferenceOffset(NodeInfo) function

[0232] The InterferenceOffset(NodeInfo) function 140 takes as input 1 parameter: information about the node to be considered. The function returns a value that is used as a signal strength offset for that node when considering the relative strength between the transmitted signal and the receiver sensitivity when determining whether a child node may be interfered with by the parent node transmission. This value can be a default, generic, and provided by the system for UEs or non-UEs, or it can be specific to the input node.

[0233] The InterferenceOffset(NodeInfo) function 140 returns the interference level offset of the node passed as its parameter. This interference level offset is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node. This offset provides the system with the ability to fine-tune the evaluation criteria when determining interference. The offset can be a positive or negative value.

[0234] The basic, representative actions or steps of an exemplary implementation of the InterferenceOffset(NodeInfo) function 140 are as follows: Fig.19 are shown in, and include but are not necessarily limited to the following:

[0235] As action 19-1, presetting the output of InterferenceOffset(NodeInfo) function 140 to 0 db, under the condition that neither system-general nor node-specific interference level offset values ​​are expected to be provided by the system for use by beam management process 70,

[0236] Then, as action 19-2, if a system-provided interference level offset is provided,

[0237] As action 19-3, further determine whether the node is of UE type, and in this case, as action 19-4, obtain the system provided interference level offset for the node of UE type, and according to the result of action 19-6, return it as action 19-8. For example, such system provided interference level offset for the node of UE type can be obtained from the RRC configuration message.

[0238] Otherwise, as action 19-5, a system-provided interference level offset for non-UE type nodes may be obtained and, depending on the result of action 19-6, returned as action 19-8. For example, such a system-provided interference level offset may be obtained from a system information block (SIB).

[0239] • Finally, if it is determined as action 19-6 that a node specific interference level offset is available from the Nodeinfo table parameter, then the interference level offset is obtained as action 19-7 and then returned as action 19-8.

[0240] F.8 BMP: MinRxThreshold(NodeInfo) function

[0241] Fig. 20 The basic, representative actions or steps of an exemplary implementation of the MinRxThreshold(NodeInfo) function 150 are shown. The MinRxThreshold(NodeInfo) function 150 takes as input 1 parameter: information about the node to be considered. The function returns a value that is the minimum signal strength at which the node can receive and reliably decode the data in the signal. The value can be a default, generic, and provided by the system for UEs or non-UEs, or it can be specific to the input node.

[0242] The MinRxThreshold(NodeInfo) function 150 returns the minimum receive threshold of the node (e.g., ChildNode or IABNode) passed to it as a parameter. This minimum receive threshold is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node. Alternatively, this minimum receive threshold is used when evaluating whether the Tx beam of the parent node is strong enough at the IAB node.

[0243] Fig. 20 The basic, representative actions or steps of the exemplary implementation of the MinRxThreshold(NodeInfo) function 150 shown include, but are not necessarily limited to, the following:

[0244] As action 20-1, in the expectation that neither system-general nor node-specific minimum receiver thresholds are provided by the system for use by the beam management process 70, preset its output to -123 dBm,

[0245] Then as action 20-2, if it is determined that the system-provided minimum receiver threshold is provided, then

[0246] Then as action 20-3, further determine whether the node is of UE type, and in this case, as action 20-4, obtain the system-provided minimum receiver threshold for nodes of UE type, and return it as action 20-8 according to the result of action 20-6,

[0247] • Otherwise, as action 20-5, a system-provided minimum receiver threshold for non-UE type nodes may be obtained and, depending on the result of action 20-6, returned as action 20-8.

[0248] • Finally, if it is determined as action 20-6 that a node specific minimum receiver threshold is available from the Nodeinfo table parameters, such minimum receiver threshold is obtained as action 20-7 and returned as action 20-8.

[0249] F.9 BMP: CheckDiffRxPower() function

[0250] Fig.21 The basic, representative actions or steps of an exemplary implementation of CheckDiffRxPower() 160 are shown. CheckDiffRxPower() 160 determines whether the signal transmitted by the parent node, adjusted for the path loss to the child node, is greater than the signal sent by the IAB node (adjusted for the path loss to the child node), and if so, it returns true. Otherwise, it returns false. CheckDiffRxPower() 160 determines whether the received signal of the IAB node is sufficiently greater than the received signal of the parent node so that the parent node's signal will not cause excessive interference to the child node.

[0251] Fig.21 The basic, representative actions or steps of the illustrated exemplary implementation of CheckDiffRxPower() 160 include, but are not necessarily limited to, the following:

[0252] As action 21-1, obtain an RF propagation model from the ChildNodeInfo table for use in determining a path loss between a transmitting node and a receiving node,

[0253] As action 21-2, use the CalculatePathLoss() function 130 with 3 input parameters to estimate the loss of RF signal strength from the parent node to the child node for a given path loss model,

[0254] Then as action 21-3, use the CalculatePathLoss() function 130 with 3 input parameters to estimate the loss of RF signal strength from the IAB node to the child node for a given path loss model,

[0255] Then as action 21-4, obtain the current transmit power of the parent node's Tx beam from the ParentNodeInfo table,

[0256] Then as action 21-5, obtain the current transmit power of the Tx beam of the IAB node from the IABNodeInfo table,

[0257] Then as action 21-6, the parent node received signal strength at the child node is calculated,

[0258] Then as action 21-7, the IAB received signal strength at the child node is calculated,

[0259] As action 21-8, calculating the difference between the received signal of the parent node and the received signal of the IAB node,

[0260] • Then as action 21-9, the RxDiffValue() function 80 is used to obtain a value representing the difference between the received signal of the parent node and the received signal of the IAB node.

[0261] Then as action 21-10, determine whether the signal of the IAB node received at the child node is sufficiently stronger than the signal of the parent node received at the child node (determined according to the difference value) so that the interference caused by the parent node signal will not prevent the child node from decoding the IAB node signal, and return true as action 21-11, otherwise return false as action 21-12.

[0262] F.10 BMP: RxDiffValue(NodeInfo) function

[0263] Fig. 22The basic, representative actions or steps of an exemplary implementation of the RxDiffValue(NodeInfo) function 170 are shown. The RxDiffValue(NodeInfo) function 170 takes as input 1 parameter: information about the node to be considered. The function returns a value, namely the difference in signal strength between two transmitting nodes. This value can be a default, generic, and provided by the system for UEs or non-UEs, or it can be specific to the input nodes. The RxDiffValue(NodeInfo) function 170 returns a value representing the difference in strength between two signals perceived by the node through the parameter. This value is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node. This value provides the system with the ability to fine-tune the evaluation criteria when determining interference.

[0264] Fig. 22 The basic, representative actions or steps of the illustrated exemplary implementation of the RxDiffValue(NodeInfo) function 170 include, but are not necessarily limited to, the following:

[0265] as action 22-1, under the condition that neither system-general nor node-specific difference values ​​are expected to be provided by the system for use by the BMP, presetting its output to 0,

[0266] Action 22-2 includes determining whether a system-provided difference value is provided. In the case of an Rx difference value that is common to nodes other than the UE, the system-provided difference value may be provided, and in the case of a common value provided for the UE, the Rx difference value may be obtained from a system information block (SIB). If it is determined at action 22-2 that such a system-provided difference value is provided, then

[0267] Action 22-3 further determines whether the node is of UE type, and in this case, as action 22-4, a system-provided interference level offset for a node of UE type may be obtained and, depending on the result of action 22-6, returned as action 22-8,

[0268] Otherwise, action 22-5 comprises obtaining a system-provided difference value for a node of non-UE type and, depending on the result of action 22-6, returning such a system-provided difference value for a node of non-UE type as action 22-8. Such Rx difference value specific to such a node may be obtained from an RRC configuration message.

[0269] • Finally, if it is determined as act 22-6 that a node specific difference value is available from the Nodeinfo table parameter, then that difference value is obtained as act 22-7 and then returned as act 22-8.

[0270] F.11 BMP: CheckBeamAlignment() function

[0271] Fig.23 The basic, representative actions or steps of an exemplary implementation of the CheckBeamAlignment() function 180 are shown. The CheckBeamAlignment() function 180 determines whether the parent node Tx beam serving the IAB node is aligned with the IAB node Tx beam serving the child node so that the two Tx beams can cover the position of the child node. The CheckBeamAligment() function 180 determines whether there is an alignment of the parent node's Tx beam with the IAB node's Tx beam and the child node's Tx beam.

[0272] Fig.23 The basic, representative actions or steps of the illustrated exemplary implementation of the CheckBeamAlignment() function 180 include, but are not necessarily limited to, the following:

[0273] As action 23-1, use the AngleBetweenPoint() function with 3 input parameters (e.g., ParentNodeInfo, IABNodeInfo, and ChildNodeInfo) to calculate the angle between the two lines of interest at the location of the parent node, and terminate each line at the location of the IAB node and the child node. Two exemplary non-limiting equations for the AngleBetweenPoint() function are shown below, and it can be understood that there are many other ways to derive the angle between two lines in two dimensions.

[0274] Equation 1: p1 is the intersection of the two lines and the result is in degrees.

[0275] AngleBetween (p0, p1, p2)

[0276] a=Math.pow(p1.x-p0.x, 2)+Math.pow(p1.y-p0.y, 2),

[0277] b=Math.pow(p1.x-p2.x, 2)+Math.pow(p1.y-p2.y, 2),

[0278] c=Math.pow(p2.x-p0.x, 2)+Math.pow(p2.y-p0.y, 2);

[0279] Returns Rad2Deg(Math.acos((a+bc) / Math.sqrt(4*a*b)))

[0280] Equation 2: p1 is the starting point of the two lines and the result is in degrees.

[0281] AngleBetween(p0, p1, p2)

[0282] v1=Vector(p0[Location], p1[Location])

[0283] v2=Vector(p0[Location], p2[Location])

[0284] Returns Rad2Deg(arcCos(v1 dot v2) / (magnitude(v1)*magnitude(v2)))

[0285] Then as action 23-2, the width (in degrees) of the parent node's Tx beam is obtained from the ParentNodeInfo table and then multiplied by 0.5.

[0286] As action 23-3, determine whether the angle of 1 / 2 parent node's Tx beam width is greater than the angle between the two lines. If so, as action 23-4, CheckBeamAlignment() function 180 returns true, indicating that the parent node Tx beam and the IAB node Tx beam are aligned so that the child node can be covered by these two beams, otherwise returns false as action 23-5.

[0287] F.12 ​​BMP: PowerControlMitigation() function

[0288] Fig.24 The basic, representative actions or steps of an exemplary implementation of the PowerControlMitigation() function 190 are shown. The PowerControlMitigation() function 190 estimates whether a predetermined reduction in the parent node's Tx beam signal strength can be reliably received by the IAB node, e.g., given the reduced signal strength, the parent node can still provide an acceptable service level to the IAB node, and if so, PowerControlMitigation() will return true, otherwise false. Assuming that the parent node's signal is also adjusted for path loss and the IAB node's receiver sensitivity is also adjusted according to the service offset provided by the system, if the parent node's signal is reduced by the TxPowerStep value, the PowerControlMitigation() function 190 determines whether the IAB node can be able to maintain an acceptable service level from the parent node.

[0289] Fig.24The basic, representative actions or steps of the illustrated exemplary implementation of the CheckBeamAlignment() function 180 include, but are not necessarily limited to, the following:

[0290] as action 24-1, obtaining from the IABNodeInfo table a model to be used for determining a path loss between a transmitting node and a receiving node,

[0291] As action 24-2, use the CalculatePathLoss() function 130 with 3 input parameters to estimate the loss of RF signal strength from the transmitter to the receiver, e.g., the parent node to the IAB node for a given path loss model. As described above, techniques such as Friis equation, Walfish-Ikegami, Okumra-Hata, Longley-Rice, Lee and Young, etc. may be employed.

[0292] As action 24-3, use the ServiceOffset() function 200 with 1 input parameter to obtain an offset for determining whether the IAB node's receiver can reliably receive the parent node's Tx beam,

[0293] As action 24-4, using the MinRxThreshold() function 150 with 1 input parameter to obtain a minimum received signal for determining whether the receiver of the IAB node can reliably receive the parent node Tx beam,

[0294] As action 24-5, obtain the current transmit power of the Tx beam of the parent node from the ParentNodeInfo table,

[0295] As action 24-6, obtain the stepwise change of the transmit power of the Tx beam of the parent node from the ParentNodeInfo table.

[0296] As actions 24-7 to 24-9, determine whether the estimated parent node transmit power minus the path loss to the IAB node minus the system-provided step change in the parent node Tx power is greater than the child node's minimum receiver threshold plus the system-provided offset, and if so, return true as action 24-12, otherwise return false as action 12-11.

[0297] If the estimated signal strength of the parent node's Tx beam at the IAB node (e.g., Tx power minus the path loss to the IAB node and minus the expected change in Tx power) is greater than the IAB node target / / Rx signal strength (i.e., the minimum receive threshold of the IAB node plus the system offset value), the IAB node may still be able to receive the parent node transmission if the parent node reduces its Tx beam power by the TxPowerStep value.

[0298] F.13 BMP: ServiceOffset(NodeInfo) function

[0299] Fig.25 The basic, representative actions or steps of an exemplary implementation of the ServiceOffset(NodeInfo) function 200 are shown. The ServiceOffset(NodeInfo) function 200 takes as input 1 parameter: information about the node to be considered. When determining whether the IAB node may still be able to receive the parent node transmission, the function returns a value that is the signal strength offset for the node when considering the relative strength between the transmitted signal and the receiver sensitivity. The value can be a default, generic, and provided by the system for UEs or non-UEs, or it can be specific to the input node.

[0300] Fig.25 The basic, representative actions or steps of the exemplary implementation of the ServiceOffset(NodeInfo) function 200 shown include, but are not necessarily limited to, the following:

[0301] as action 25-1, in the event that neither system-generic nor node-specific service level offset values ​​are expected to be provided by the system for use by the BMP, presetting its output to 0 dB,

[0302] then if it is determined as action 25-2 that a system provided service level offset is provided, then as action 25-3, such system provided service level offset is obtained, for example, from a system information block (SIB), and finally based on the result of action 25-4, the system provided service level offset for a node of type IAB is returned as action 25-6,

[0303] If it is determined as action 25-4 that a node specific interference level offset is available from a Nodeinfo table parameter, then as action 25-5 such a node specific interference level offset is obtained, for example, from an RRC configuration message, and depending on the result of action 22-6, the node specific interference level offset is returned as action 25-6.

[0304] F.14 BMP: ReqTxPowerDecrease() function

[0305] Fig.26 The basic, representative actions or steps of an exemplary implementation of the ReqTxPowerDecrease() function 210 are shown. The ReqTxPowerDecrease() function 210 issues a request to the parent node to reduce the Tx power of the beam serving the IAB node by a pre-agreed step amount, for example, the TxPowerStep value associated with the parent node is the pre-agreed amount. The ReqTxPowerDecrease() function 210 requests the parent node to reduce the power of its Tx beam serving the IAB node by a power control step value and initializes PCTimer to the value provided by the parent node.

[0306] Fig.26 The basic, representative actions or steps of the illustrated exemplary implementation of the ReqTxPowerDecrease() function 210 include, but are not necessarily limited to, the following:

[0307] As action 26-1, a request is sent to the parent node using the PwrHeadroomRpt() function, requesting the parent node to reduce its Tx beam signal by a stepwise predetermined amount,

[0308] Then additionally as action 26-1, a value is obtained from ParentnodeInfo indicating how long the BMP should wait before attempting to issue a request to change the parent node Tx beam signal. The value obtained from action 26-1 indicates how long the BMP should wait between attempting to request to modify the parent node's Tx beam and initializing the timer PCTimer().

[0309] • Then as action 26-3, the timer PCTimer() is initialized using the value obtained from action 26-1, which is returned as action 26-3.

[0310] F.15 BMP: IncreaseTxPower() function

[0311] Fig. 27 The basic, representative actions or steps of an exemplary implementation of the IncreaseTxPower() function 220 are shown. The IncreaseTxPower() function 220 determines whether any of the child nodes of the IAB node served by the parent node will experience CLI due to an increase in the Tx beam signal of the parent node, and whether such an increase will also result in an increase in the throughput of the child node, and whether such an increase will also not exceed the Tx power limit of the parent node. The IncreaseTxPower() function 220 is a top-level function for determining whether the power of the Tx beam of the parent node may be increased, and requesting such an increase from the parent node.

[0312] Fig. 27 The basic, representative actions or steps of the illustrated exemplary implementation of the IncreaseTxPower() function 220 include, but are not necessarily limited to, the following:

[0313] As in action 27-1, wait until the power control timer expires. The power control timer is a system programmable time before the next possible request to change the parent node's transmit power. The timer wait loop is placed so that if the last request was to increase Tx power and the immediately subsequent request is to decrease Tx power, the timer does not cause a delay.

[0314] As action 27-2, use the GetNodeData() function 90 to obtain all necessary data for the BMP to perform its function,

[0315] Then, after initializing the loop index corresponding to the child node as action 27-3, for each child node in ChildNodeInfoTable, for example, the information of each child node is respectively copied into ChildNodeInfo in turn for processing, and actions 27-4 to 27-8 are performed.

[0316] Action 27-4 and Action 27-5 include obtaining the expected step-wise change in the parent node Tx beam signal from the ParentNodeInfo table. Specifically, Action 27-4 includes obtaining information about the child node from the ChildNodeInfoTable using an index. Action 27-5 includes obtaining an input parameter of the expected change in the parent node's Tx power to assess the potential interference of the parent node to the child node.

[0317] • Action 27-6 includes using the BeamlInterference() function 100 (whose input parameters are set to stepwise change) to estimate whether a stepwise increase of the parent node Tx beam signal will cause CLI to the child node.

[0318] Action 27-7 comprises determining whether the BeamlInterference() function 100 returns true, for example indicating interference, with the result that the function of action 27-11 returns to the beginning of the beam management process 70 (see Fig.12 ) without requesting an increase in the parent node's Tx beam signal.

[0319] Otherwise if it is determined as action 27-8 that the IncreaseTxPower() function 220 has sequentially traversed all child nodes in the ChildNodeInfoTable, then as action 27-9 the PowerControlRestoration() function 230 is used to determine whether an increase in the parent node Tx power will not exceed the parent node's Tx limit and may also result in an increase in the IAB node throughput.

[0320] If the PowerControlRestoration() function 230 returns true as determined in action 27-10, then the TxPower() function will request the parent node to increase the Tx power of the beam serving the IAB node using the ReqTxPowerIncrease() function as action 27-12. After action 27-12, the IncreaseTxPower() function 220 will perform action 27-11, which is to Fig.12 Return to the start of the beam management process 70.

[0321] F.16 BMP: PowerControlRestoration() function

[0322] Fig.28 The basic, representative actions or steps of an exemplary implementation of the PowerControlRestoration() function 230 are shown. The PowerControlRestoration() function 230 considers two aspects that an increase in the parent node Tx beam signal will have: first, it determines whether the parent node is already at maximum Tx power, and then it will determine whether an increase in the parent node Tx beam signal will cause the signal received at the child node to exceed a certain maximum value (i.e., more signal will not provide any increase in IAB node throughput). If either aspect is true, the function returns false, otherwise it returns true.

[0323] The PowerControlRestoration() function 230 determines whether the transmit power of the parent node can be increased. The function checks two aspects: (1) If the parent node is already at the maximum Tx power, the PowerControlRestoration() function 230 determines not to issue a request because such a request would simply waste signaling; (2) If a request to increase the power of the parent node's Tx beam would cause the signal received at the child node to exceed a certain maximum value, the PowerControlRestoration() function 230 would not issue a request because any increase in the signal received by the child node would not result in any improvement in the throughput of the IAB node.

[0324] Fig.28 The basic, representative actions or steps of the exemplary implementation of the PowerControlRestoration() function 230 shown include, but are not necessarily limited to, the following:

[0325] As action 28-1, obtain from the ParentNodeInfo table the current power level of the Tx beam that the parent node is using to serve the IAB node,

[0326] Then as action 28-2, obtain from the ParentNodeInfo table the maximum power level of the Tx beam that the parent node can use to serve the IAB node,

[0327] • Then as action 28-3, it is determined whether the current power level of the parent node's Tx beam is greater than or equal to the maximum level of the parent node's Tx beam, and if so, then as action 28-4, the PowerControlRestoration() function returns false.

[0328] Otherwise, as action 28-5, obtain the path loss model to be used from the IABNodeInfo table,

[0329] Then as action 28-6, use the CalculatePathLoss() function 130 with 3 input parameters to estimate the loss of RF signal strength from the parent node to the IAB node, for example, for a given path loss model,

[0330] Then as act 28-7, using the MaxOffset() function 240 with 1 input parameter to obtain an offset for determining whether the signal received at the IAB node from the parent node has exceeded a level that provides no additional benefit to the IAB node,

[0331] Then as action 28-8, use the MinRxThreshold() function 150 with 1 input parameter to obtain the minimum receive signal of the IAB node receiver,

[0332] As action 28-9, obtain the stepwise change of the transmit power of the Tx beam of the parent node from the ParentNodeInfo table.

[0333] As actions 28-10 to 28-12, determine whether the estimated current transmit power of the parent node minus the path loss to the IAB node plus the system-provided step change in the parent node Tx power is greater than the minimum receiver threshold of the child node plus the system-provided offset. If the determination of action 28-12 is affirmative, then as action 28-13, the PowerControlRestoration() function 230 returns true, otherwise as action 28-14, the PowerControlRestoration() function 230 returns false.

[0334] If the estimated signal strength of the parent node Tx beam at the IAB node (e.g., Tx power minus the path loss to the IAB node and plus the expected change in Tx power) is less than the IAB node target Rx maximum signal strength, such as the minimum receive threshold of the IAB node plus a certain system offset value, then if the parent node increases its Tx beam power by the TxPowerStep value, the IAB node may be able to increase its received parent node transmit throughput. Otherwise, the request to increase the parent node Tx power may not benefit the IAB node.

[0335] F.17 BMP: MaxOffset(NodeInfo) function

[0336] Fig.29 The basic, representative actions or steps of an exemplary implementation of the MaxOffset(NodeInfo) function 240 are shown. The MaxOffset(NodeInfo) function 240 takes 1 parameter as input: information about the node, and the function returns a value that, when combined with the minimum received signal strength (i.e., the level at which the node can receive and reliably decode the data in the signal), produces a value representing a signal strength threshold above which the receiver cannot derive any increase in data throughput (i.e., the maximum Rx signal strength). This value can be a default and provided by the system, or it can be specific to the IAB node. The MaxOffset(NodeInfo) function 240 returns the maximum offset passed by the node to the MaxOffset(NodeInfo) function 240 via an independent variable. This maximum offset is used when evaluating whether the signal received by the IAB node has exceeded a level above which the IAB node cannot obtain additional benefits. This offset provides the system with the ability to fine-tune the evaluation criteria when determining whether an increase in the parent node Tx beam power will provide any benefit to the IAB node (i.e., more signals will provide an increase in the throughput of the IAB node).

[0337] Fig.29The basic, representative actions or steps of the exemplary implementation of the MaxOffset(NodeInfo) function 240 shown include, but are not necessarily limited to, the following:

[0338] as action 29-1, in the event that neither system-generic nor node-specific minimum receiver thresholds are expected to be provided by the system for use by the BMP, preset its output to 0 dBm,

[0339] then if it is determined as action 29-2 whether a system-provided maximum offset is provided (e.g., provided by a system information block (SIB)), then based on the result of action 29-4, obtaining the system-provided maximum offset as action 29-3, returning the system-provided maximum offset for a node of type IAB as action 29-6,

[0340] If it is determined as action 29-4 that a node specific maximum offset is available from the Nodeinfo table parameters, such node specific maximum offset is obtained as action 29-5, for example via RRC, and returned as action 29-6.

[0341] F.18 BMP: ReqTxPowerIncrease() function

[0342] Fig.30 The basic, representative actions or steps of an exemplary implementation of the ReqTxPowerIncrease() function 250 are shown. The ReqTxPowerIncrease() function 250 requests the parent node to increase the Tx power of the beam serving the IAB node by a step amount. The ReqTxPowerIncrease() function 250 requests the parent node to increase the power of its Tx beam serving the IAB node by a power control step value and initializes PCTimer to the value provided by the parent node.

[0343] Fig.30 The basic, representative actions or steps of the illustrated exemplary implementation of the ReqTxPowerIncrease() function 250 include, but are not necessarily limited to, the following:

[0344] As action 30-1, a request is sent to the parent node using the PwrHeadroomRpt() function, requesting the parent node to increase its Tx beam signal by a step-wise predetermined amount, and obtaining from the parent node information a value indicating how long the BMP should wait before attempting to issue a request to change the parent node Tx beam signal. A Power Headroom Report (PHR) (MAC CE type (MAC Control Element)) is used to report that the margin between the estimated received signal strength of the parent node at the IAB node and the IAB node minimum received signal threshold is sufficient to support the parent node Tx power increase TxPowerStep and still benefit from the bandwidth increase with the IAB node.

[0345] Then as action 30-2, the timer PCTimer() is initialized with this value and then returned as action 30-3. After each request to change the Tx beam power of the parent node, the BMP will initialize the timer with the value associated with the parent node. When the timer expires, the beam management process 70 will re-evaluate the parent node Tx beam power to determine whether the Tx beam power can be changed.

[0346] G: Signaling to increase / decrease the parent node's Tx power

[0347] The previously mentioned beam modification command 72 (see Figure 2A and Figure 2B ) is an example of signaling that can be used to request an increase or decrease in the transmit power of the parent node. In exemplary embodiments and modes, the beam modification command 72 can take the form of a medium access control (MAC) control element (CE), such as a power headroom (PHR) MAC CE, a PHR MAC CE. Table 1 below shows an exemplary format of a single-entry PHR MAC CE (LCID 57), for example, how to modify the PHR MAC CE defined in TS 38.321 to adapt to the technology disclosed herein, and in particular, the beam modification command 72. A multi-entry type of PHR MAC CE (LCID 56 or LCID 54) can also be used in a similar manner.

[0348] Table 1: Modified single-entry PHR MAC CE

[0349]

[0350]

[0351] H: System information to facilitate beam management

[0352] Table 2 provides an ASN.1 description of a new system information block SIBx that may be added to TS 36.331 and provides a set of common system values ​​provided by the system so that the IAB node may be able to increase or decrease the signal of the parent node Tx beam via a request to the parent node, detect and mitigate and manage interference caused by the parent node serving the IAB node to the child node served by the IAB node.

[0353] Table 2: SIBx information elements

[0354]

[0355]

[0356] I: RRC messages to facilitate beam management

[0357] Table 3 provides an ASN.1 description of new elements in the RRCConnectionReconfiguration message, which may be added to 3GPP TS 36.331 and provides a set of common system values ​​and a set of node-specific values ​​provided by the system, so that the IAB node may be able to increase or decrease the signal of the parent node Tx beam via a request to the parent node, detect and mitigate and manage interference caused by the parent node serving the IAB node to the child node served by the IAB node.

[0358] Table 3: RRCConnectionReconfiguration message

[0359] Information Elements

[0360]

[0361]

[0362]

[0363]

[0364] J: Action of the IAB node upon receiving beam management promotion information

[0365] The actions taken by a device (eg, an IAB node) upon receiving an RRCConnectionReconfiguration (including the information element backHaulPCNodeDataToAddMod) may be captured in TS 36.331 as shown in Table 4.

[0366] Table 4

[0367] If the UE is able to comply with the configuration included in the RRCConnectionReconfiguration message, the UE shall:

[0368] 1> If the RRCConnectionReconfiguration message does not include fullConfig and the UE is connected to a 5GC (i.e., incremental signaling during intra-5GC handover):

[0369] 2> Multiplex the source SDAP and PDCP configuration (i.e., the current SDAP / PDCP configuration for all RBs from the source RAT before receiving the inter-RAT handover RRCConnectionReconfiguration message);

[0370] 1> If the RRCConnectionReconfiguration message includes fullConfig and the source RAT is E-UTRA (i.e., intra-RAT inter-system handover):

[0371] / / For brevity, the text that already exists in this section of the TS is not shown here / /

[0372] 1> If the received RRCConnectionReconfiguration includes backHaulPCNodeDataToAddMod′.

[0373] 2>Configure parameters for BMP, as shown in backHaulPCNodeDataToAddMod;

[0374] / / For brevity, the text that already exists in this section of the TS is not shown here / /

[0375] The actions taken by a device (eg, an IAB node) upon receiving SystemInformationBlockTypeX (including the information element backHaulPCInfo) may be captured in TS 36.331 as shown in Table 5.

[0376] Table 5

[0377] After receiving SystemInformationBlockTypex, the UE shall:

[0378] 1> If configured to run as an IAB node:

[0379] 2>Configure parameters for BMP, as shown in backHaulPCInfo;

[0380] K: Parameter description / instructions

[0381] The following information may provide descriptions and explanations for various terms and / or phrases used herein.

[0382] Interferenceoffset

[0383] This parameter is the offset between the estimated signal strength of the parent node at the child node and the minimum Rx threshold of the child node. This parameter is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node. This parameter provides the system with the ability to fine-tune the evaluation criteria when determining interference.

[0384] The system may or may not provide an interference offset parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the parameter may be a value common to all UE type nodes, and a different value common to all non-UE type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the offset may be specific to each child node of the IAB node.

[0385] MinRxThresholdChildNode

[0386] This parameter is the minimum Rx threshold of the child node. This parameter is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node.

[0387] The system may or may not provide a minimum RX threshold parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the threshold may be a value common to all UE type nodes, and a different threshold common to all non-UE type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the threshold may be specific to each child node of the IAB node.

[0388] MinRxThresholdlABNode

[0389] This parameter is the minimum Rx threshold of the IAB node. This parameter is used when evaluating whether the parent node's Tx beam is sufficient at the IAB node receiver.

[0390] The system may or may not provide a minimum RX threshold parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the threshold may be a value common to all UE type nodes, and a different threshold common to all non-UE type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the threshold may be specific to each child node of the IAB node.

[0391] RxDiffValue

[0392] This parameter is the difference between the estimated signal strength of the IAB node at the child node and the estimated signal strength of the parent node at the child node. This parameter is used when evaluating whether the Tx beam of the parent node interferes with the receiver of the child node. This difference parameter provides the system with the ability to fine-tune the evaluation criteria when determining interference.

[0393] The system may or may not provide a differential parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the parameter may be a value common to all UE-type nodes, and a different value common to all non-UE-type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the value may be specific to each child node of the IAB node.

[0394] PathLossModel

[0395] The present disclosure contemplates which model is used, but the details regarding the operation of the model selected by this function are not central to the present disclosure. Any number of different models can determine the path loss. For example, the Friis equation can solve for the path loss given the distance between the Tx and Rx antennas, the Tx power, the Tx frequency, and other antenna configuration parameters. Other path loss models are: Walfish-Ikegami, Okumura-Hata, Longley-Rice, Lee, and Young.

[0396] The system may or may not provide a PathLossModel parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the parameter may be a value common to all UE-type nodes, and a different value common to all non-UE-type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the parameter may be specific to each child node of the IAB node.

[0397] ServiceOffset

[0398] This parameter is the offset between the estimated signal strength of the parent node at the IAB node and the minimum Rx threshold of the IAB node. This parameter is used when evaluating whether the signal strength of the Tx beam of the parent node estimated at the IAB node is sufficient to serve the receiver of the IAB node. This parameter provides the system with the ability to fine-tune the evaluation criteria when determining the level of service to the parent node of the IAB node and the interference it may cause to the child nodes of the IAB node.

[0399] The system may or may not provide a service offset parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the parameter may be a value common to all non-UE type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the service offset may be specific to the IAB node.

[0400] The offset can be positive or negative.

[0401] MaxOffset

[0402] This parameter is an offset representing the difference between the minimum Rx threshold of an IAB node and its maximum Rx threshold. This parameter is used when evaluating whether the signal strength of the parent node's Tx beam estimated at the IAB node is so great that any further increase will not benefit the IAB node. This parameter provides the system with the ability to fine-tune the evaluation criteria when determining the parent node service level to the IAB node and the interference it may cause to the child nodes of the IAB node.

[0403] The system may or may not provide the maximum offset parameter. If provided, the parameter may be sent by the system via a SIB message, and thus the parameter may be a value common to all non-UE type nodes. Alternatively, if provided, the parameter may be sent to the IAB node via an RRC configuration message, and the service offset may be specific to the IAB node.

[0404] The offset can be positive or negative.

[0405] TxPowerStep

[0406] • This parameter is a value (in dBm) representing the agreed incremental change in the Tx power of the parent node each time the parent node receives a PHR MAC CE with LCID 57 or 56 or 54 and the Di or Dd bit field is set to non-zero.

[0407] The system may or may not provide the TXPowerStep parameter. If provided, it may be sent by the system via a SIB message. Alternatively, if provided, it may be sent to the IAB node via an RRC configuration message. If not provided, the default value used by the IAB node is 1.

[0408] PCStepTimer

[0409] • This parameter is a value representing the agreed amount of time between each attempt by the PBM to send a PHR MAC CE with LCID 57 or 56 or 54 and with the Di or Dd bit field set to non-zero to the parent node.

[0410] The system may or may not provide a PCStepTimer parameter. If provided, it may be sent by the system via a SIB message. Alternatively, if provided, it may be sent to the IAB node via an RRC configuration message. If not provided, the default value used by the IAB node is 1 ms.

[0411] The basic parameters included in the uplink PC equation for LTE UE are:

[0412] https: / / www.researchgate.net / publication / 224242015How_to_Set_the_Fractional_Power_Control_Compensation_Factor_in_LTE

[0413] PUSCH power = min{Pmax, 10log(M)+P0+αPL+ΔTF+f}, where:

[0414] Pmax is the maximum transmit power of the UE;

[0415] M is the number of radio blocks (RBs) allocated to the UE;

[0416] P0 is the target received power at the eNode-B;

[0417] a is called the compensation factor;

[0418] PL is the UE-eNode-B path loss;

[0419] ΔTF is a correction factor depending on the transport format;

[0420] f is the loop closing command issued by the eNode-B

[0421] IAB Architecture for Rel-16

[0422] https: / / arxiv.org / pdf / 1906.01099.pdf

[0423] Sequence frame number / frequency reuse factor

[0424] Benefits of the present invention: For SFN, the frequency reuse factor = 1 (i.e., all cells use the same frequency band and rely on OFDMA and SC-FDMA to mitigate intra-cell interference). However, if the IAB node performs its own scheduling independent of its parent node, there may be intra-cell interference, so PC needs to be applied to the parent node (note that "parent" here covers the parent node ("DN") of both carrier nodes and non-carrier nodes) DL. On the other hand, if the carrier controls the resource scheduling of the IAB node (and thereby ensures that IAB and carrier resources are orthogonal), resource efficiency gains can be obtained by applying PC to the carrier DL and then allowing the link between the UE and the IAB to have a frequency reuse of 1.

[0425] Cross Link Interference (CLI)

[0426] http s: / / arxiv.org / pdf / 1902.02980.pdf

[0427] Cross-link interference (CLI) covers the coexistence of different link directions on the same frequency resources in neighboring cells, which leads to potential cross-link interference (CLI), i.e. user-to-user (UE-UE) and base station-to-base station (BS-BS) interference.

[0428] L. Circuit and Hardware Implementation

[0429] Certain units and functions of system 20 may be implemented by electronic machinery. For example, electronic machinery may refer to processor circuits described herein, such as carrier node processor 46, IAB node processor 54, and node processor 66. In addition, the term "processor circuit" is not limited to meaning one processor, but may include multiple processors, where multiple processors operate at one or more sites. In addition, as used herein, the term "server" is not limited to one server unit, but may cover multiple servers and / or other electronic equipment, and may be located at one site or distributed to different sites. Based on these understandings, Fig.32An example of an electronic machine such as a processor circuit is shown, which includes one or more processors 290, a program instruction memory 292; other memory 294 (e.g., RAM, cache, etc.); input / output interfaces 296 and 297, a peripheral device interface 298; support circuits 299; and a bus 300 for communication between the aforementioned units. The processor 290 may include the processor circuits described herein, such as the carrier node processor 46, the IAB node processor 54, and the node processor 66.

[0430] The memory or registers described herein may be depicted as memory 294 or any computer readable medium, which may be one or more of readily available memory such as random access memory (RAM), read-only memory (ROM), floppy disk, hard disk, flash memory, or any other form of digital storage (local or remote), and preferably has non-volatile properties, and thus may include memory. Support circuits 299 are coupled to processor 290 to support the processor in a conventional manner. These circuits include caches, power supplies, clock circuits, input / output circuits and subsystems, etc.

[0431] Although the processes and methods of the disclosed embodiments may be discussed as being implemented as software routines, some of the method steps disclosed therein may be performed in hardware and by a processor running the software. Thus, the embodiments may be implemented in software executed on a computer system, in hardware such as an application specific integrated circuit or other type of hardware, or in a combination of software and hardware. The software routines of the disclosed embodiments can be executed on any computer operating system and can be executed using any CPU architecture.

[0432] The functions of the various elements including functional blocks (including but not limited to those labeled or described as "computers", "processors" or "controllers") may be provided through the use of hardware such as circuit hardware and / or hardware capable of executing software in the form of programming instructions stored on computer-readable media. Therefore, such functions and illustrated functional blocks should be understood to be hardware-implemented and / or computer-implemented, and therefore machine-implemented.

[0433] In terms of hardware implementation, the functional blocks may include or encompass, but are not limited to, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuits, including but not limited to one or more application specific integrated circuits [ASICs] and / or one or more field programmable gate arrays (FPGAs), and (where appropriate) state machines capable of performing such functions.

[0434] In terms of computer implementation, a computer is generally understood to include one or more processors or one or more controllers, and the terms computer and processor and controller are used interchangeably herein. When provided by a computer or processor or controller, these functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by multiple separate computers or processors or controllers (some of which may be shared or distributed). In addition, the use of the term "processor" or "controller" may also be interpreted to refer to other hardware capable of performing such functions and / or executing software, such as the exemplary hardware described above.

[0435] Nodes that communicate using the air interface also have suitable radio communication circuits.In addition, the technology disclosed herein may be further considered to be fully embodied in any form of computer-readable memory, such as a solid-state memory, a magnetic disk, or an optical disk containing a suitable set of computer instructions that will cause a processor to perform the technology described herein.

[0436] In addition, each functional block or various features of the wireless terminal 30 and IAB node used in each of the above-mentioned embodiments can be implemented or executed by a circuit (usually an integrated circuit or multiple integrated circuits). The circuit designed to perform the functions described in this specification may include a general-purpose processor, a digital signal processor (DSP), a dedicated or general-purpose integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices or discrete hardware components or a combination thereof. The general-purpose processor can be a microprocessor, or alternatively, the processor can be a conventional processor, a controller, a microcontroller or a state machine. The general-purpose processor or each of the above-mentioned circuits can be configured by a digital circuit, or can be configured by an analog circuit. In addition, when the technology of making an integrated circuit that replaces the current integrated circuit appears due to the progress of semiconductor technology, the integrated circuit produced by the technology can also be used.

[0437] It should be understood that the technology disclosed herein is intended to solve problems centered on radio communications and is necessarily rooted in computer technology and overcomes problems that occur specifically in radio communications. In addition, the technology disclosed herein improves the basic functions of radio access networks, for example, methods and processes for handling problem conditions such as radio link failures (RLFs) on backhaul links.

[0438] Fig.31Various details of an exemplary architecture of a carrier IAB node 22 are shown, wherein a carrier IAB node centralized unit (CU) 40 may be configured in a segmented or distributed manner to host CU-control plane functions, such as an IAB network power management controller 45, CU-user plane functions, and other functions. Functions and / or processors comprising the carrier IAB node centralized unit (CU) 40 may be co-located or comprise separate communication networks extending over multiple processors and / or nodes and connected by a packet communication network.

[0439] M: Additional Exemplary Embodiments and Modes

[0440] The technology disclosed herein also encompasses one or more of the following non-limiting, non-exclusive exemplary embodiments and modes:

[0441] Exemplary embodiment 1: A node of an integrated access and backhaul (IAB) network, the node comprising: a processor circuit, the processor circuit being configured to: make a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IAB node to a child node of the IAB node; and generate a command based on the determination, the command being configured to modify the characteristics of the beam transmitted from the parent node to the IAB node; an interface circuit, the interface circuit being configured to transmit the command to a beam controller of the parent node.

[0442] Example embodiment 2: A node according to example embodiment 1: wherein the command is configured to modify the signal strength of the beam transmitted from the parent node to the IAB node.

[0443] Example embodiment 3: A node according to example embodiment 1, wherein the processor circuit is configured to make the determination based at least in part on the relative positions of: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0444] Example embodiment 4: A node according to example embodiment 1, wherein the processor circuit is configured to make the determination based at least in part on radio frequency (RF) conditions for: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0445] Exemplary embodiment 5: A node according to exemplary embodiment 1, wherein the node is a carrier node; the processor circuit includes a centralized unit circuit of the carrier node; and the interface circuit is configured to transmit the command from the centralized unit circuit to the beam controller.

[0446] Exemplary embodiment 6: A node according to exemplary embodiment 1, wherein the node is the IAB node; and the interface circuit includes a mobile terminal circuit of the IAB node, and the mobile terminal circuit of the IAB node is configured to transmit the command to the beam controller via a wireless backhaul interface.

[0447] Example embodiment 7: The node of example embodiment 6, wherein the processor circuit comprises a distributed unit circuit of the IAB node.

[0448] Example embodiment 8: A node according to example embodiment 1, wherein the processor circuit is configured to use configuration data to make the determination regarding the cross-link interference (CLI).

[0449] Example embodiment 9: The node according to example embodiment 8 further includes a receiver circuit configured to receive the configuration data from the parent IAB node via a wireless interface.

[0450] Example embodiment 10: The node of example embodiment 9, wherein the processor circuit is configured to obtain the configuration data from a system information block (SIB) received by the receiver circuit.

[0451] Example embodiment 11: The node of example embodiment 9, wherein the processor circuit is configured to obtain the configuration data from a radio resource control (RRC) reconfiguration message received by the receiver circuit.

[0452] Exemplary embodiment 12: A node according to exemplary embodiment 8, wherein the configuration data includes: first reconfiguration data, the first reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the parent node to the IAB node, and second reconfiguration data, the second reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the IAB node to the child node.

[0453] Exemplary embodiment 13: A method in a node of an integrated access and backhaul (IAB) network, the node comprising: using a processor circuit: making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node; and generating a command based on the determination, the command being configured to modify the characteristics of the beam transmitted from the parent node to the IAB node; and transmitting the command to a beam controller of the parent node.

[0454] Example embodiment 14: A method according to example embodiment 13, wherein the command is configured to modify the signal strength of the beam transmitted from the parent node to the IAB node.

[0455] Exemplary embodiment 15: The method according to exemplary embodiment 13 also includes using the processor circuit to make the determination based at least in part on the relative positions of: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0456] Exemplary embodiment 16: The method according to exemplary embodiment 13 also includes using the processor circuit to make the determination based at least in part on radio frequency (RF) conditions for the following: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0457] Exemplary embodiment 17: A method according to exemplary embodiment 13, wherein the node is a carrier node; the processor circuit includes a centralized unit circuit of the carrier node; and the command is transmitted from the centralized unit circuit to the beam controller.

[0458] Example 18: A method according to Example 13, wherein the node is the IAB node, and the method further comprises using a mobile terminal circuit of the IAB node to transmit the command to the beam controller via a wireless backhaul interface.

[0459] Example 19: The method according to Example 13 also includes using configuration data to make the determination regarding the cross-link interference (CLI).

[0460] Example 20: The method according to Example 19 also includes receiving the configuration data from the parent IAB node via a wireless interface.

[0461] Example 21: The method according to Example 20 also includes obtaining the configuration data from a system information block (SIB).

[0462] Example 22: The method according to Example 20 also includes obtaining the configuration data from a radio resource control (RRC) reconfiguration message.

[0463] Exemplary embodiment 23: A method according to exemplary embodiment 19, wherein the configuration data includes: first reconfiguration data, the first reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the parent node to the IAB node, and second reconfiguration data, the second reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the IAB node to the child node.

[0464] Exemplary embodiment 24: A node of an integrated access and backhaul (IAB) network, comprising: an interface configured to obtain a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; and a beam transmission circuit configured to modify the characteristics of the beam transmitted from the node to the wireless relay node using the command.

[0465] Example embodiment 25: A node according to example embodiment 24, wherein the node is a carrier node.

[0466] Example 26: A node according to Example 24, wherein the node is an IAB node carrier node.

[0467] Example 27: The node according to Example 24, wherein the command is received from the wireless relay node.

[0468] Exemplary embodiment 28: According to the node described in exemplary embodiment 27, it also includes: a data generation circuit, which is configured to generate configuration data for use by the processor that makes the determination about the cross-link interference (CLI); a transmitter circuit, which is configured to transmit the configuration data to the wireless relay node via a radio interface; and a receiver circuit, which is configured to receive the beam modification command from the wireless relay node via the radio interface.

[0469] Example 29: The node of Example 24, wherein the processor circuit that performs the determination includes the node.

[0470] Example embodiment 30: The node according to example embodiment 24 further includes: a data generation circuit, which is configured to generate configuration data for use by the processor that makes the determination regarding the cross-link interference (CLI).

[0471] Exemplary embodiment 31: A method in a node of an integrated access and backhaul (IAB) network, comprising: obtaining a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a subnode of the wireless relay node; and modifying characteristics of the beam transmitted from the node to the wireless relay node based on the command.

[0472] Example 32: The method according to Example 31 also includes receiving the command from the wireless relay node.

[0473] Example 33: A method according to Example 31, wherein the node is a carrier node.

[0474] Example 34: A method according to Example 31, wherein the node is an IAB node carrier node.

[0475] Exemplary embodiment 35: The method according to exemplary embodiment 31 also includes generating configuration data for making the determination regarding the cross-link interference (CLI); transmitting the configuration data to the wireless relay node via a radio interface; and receiving the beam modification command from the wireless relay node via the radio interface.

[0476] Example 36: The method according to Example 31 also includes generating configuration data for the determination regarding the cross-link interference (CLI).

[0477] Exemplary embodiment 37: A wireless terminal used as a wireless relay node, the wireless terminal communicating with an access node of a radio access network (RAN) via a radio interface, the wireless terminal comprising: a transceiver circuit, the transceiver circuit being configured to receive configuration data related to an estimate of the strength of an RF signal received by the wireless terminal, such as transmitted by the RAN; receiving configuration data related to the estimate of the strength of an RF signal received by a node, such as transmitted by the RAN, from the wireless access node, the node being using the relay capability of the wireless terminal to communicate with the wireless access node via a radio interface; wherein; the configuration data may be specific to the type of node that is using the relay capability of the wireless terminal; wherein; the node type may be a user equipment; the node type may be a wireless access node type, the wireless access node transmitting to the wireless access node A wireless access node transmits a command related to the modification of the RF signal strength transmitted by the wireless access node; a processor circuit, the processor circuit being configured to determine whether to request modification of the transmitted RF signal strength of the wireless access node; wherein; the determination of whether to request modification is based on the relative position of the wireless access node, the wireless terminal acting as a relay and the node using the relay capability of the wireless terminal; the determination of whether to request modification is based on the estimated RF conditions at the wireless terminal acting as a relay node and the estimated RF conditions at the node using the relay capability of the wireless terminal; the determination of whether to request modification is based on the node type using the relay capability of the wireless terminal; wherein; the node using the relay capability of the wireless terminal may be a user equipment type; the node using the relay capability of the wireless terminal may be a wireless access node type.

[0478] Example implementation 38: A wireless terminal according to example implementation 37, wherein the configuration data is sent via SIBx.

[0479] Example 39: A wireless terminal according to Example 37, wherein the configuration data is sent via an RRCReconfiguration message.

[0480] Example embodiment 40: A wireless terminal according to example embodiment 37, wherein the configuration data is sent via a single-entry PHR MAC CE.

[0481] Example embodiment 41: A wireless terminal according to example embodiment 37, wherein the configuration data is sent via a multi-entry PHR MAC CE.

[0482] N: Other documents

[0483] One or more of the following documents may be relevant to the technology disclosed herein (all of which are incorporated herein by reference in their entirety):

[0484]

[0485]

[0486]

[0487] 3GPP RAN draft email discussion, week 4 of October 2019:

[0488]

[0489]

[0490]

[0491] Although the above description contains many specific instructions, these should not be interpreted as limiting the scope of the technology disclosed herein, but only provide illustrations for some current preferred embodiments of the technology disclosed herein. Therefore, the scope of the technology disclosed herein should be determined by the attached claims and their legal equivalents. Therefore, it should be understood that the scope of the technology disclosed herein fully covers other embodiments that may become obvious to those skilled in the art, and therefore the scope of the technology disclosed herein is limited only by the attached claims, where the reference element in the singular form does not mean "only one" (unless explicitly stated as such), but refers to "one or more". The above embodiments can be combined with each other. All structural, chemical and functional equivalents of the elements of the above preferred embodiments known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the present claims. In addition, a device or method does not necessarily solve every problem that the technology disclosed herein seeks to solve, because it will be covered by the present claims. In addition, the elements, components or method steps of the present disclosure are not intended to be dedicated to the public, regardless of whether the elements, components or method steps are explicitly stated in the claims.

[0492] In one embodiment, a node of an integrated access and backhaul (IAB) network is provided, the node comprising: a processor circuit, the processor circuit being configured to: make a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IAB node to a child node of the IAB node; and generate a command based on the determination, the command being configured to modify characteristics of the beam transmitted from the parent node to the IAB node; and an interface circuit, the interface circuit being configured to transmit the command to a beam controller of the parent node.

[0493] In one embodiment, the node is provided wherein commands are configured to modify the signal strength of the beam transmitted from the parent node to the IAB node.

[0494] In one embodiment, the node is provided wherein the processor circuit is configured to make the determination based at least in part on the relative positions of: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0495] In one embodiment, the node is provided wherein the processor circuit is configured to make the determination based at least in part on radio frequency (RF) conditions for: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0496] In one embodiment, the node is provided, wherein the node is a carrier node; the processor circuit comprises a centralized unit circuit of the carrier node; and the interface circuit is configured to transmit the command from the centralized unit circuit to the beam controller.

[0497] In one embodiment, the node is provided, wherein the node is the IAB node; and the interface circuit includes a mobile terminal circuit of the IAB node, the mobile terminal circuit of the IAB node being configured to transmit the command to the beam controller via a wireless backhaul interface.

[0498] In one embodiment, the node is provided wherein the processor circuit comprises a distributed unit circuit of the IAB node.

[0499] In one embodiment, the node is provided wherein the processor circuit is configured to use configuration data to make the determination regarding the cross-link interference (CLI).

[0500] In one embodiment, the node is provided, further comprising a receiver circuit configured to receive the configuration data from the parent IAB node over a wireless interface.

[0501] In one embodiment, the node is provided, wherein the processor circuit is configured to obtain the configuration data from a system information block (SIB) received by the receiver circuit.

[0502] In one embodiment, the node is provided, wherein the processor circuit is configured to obtain the configuration data from a Radio Resource Control (RRC) reconfiguration message received by the receiver circuit.

[0503] In one embodiment, the node is provided, wherein the configuration data includes: first reconfiguration data, the first reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the parent node to the IAB node, and second reconfiguration data, the second reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the IAB node to the child node.

[0504] In one embodiment, a method in a node of an integrated access and backhaul (IAB) network is provided, the node comprising: using a processor circuit: making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the IAB node and (b) a beam transmitted from the IBA node to a child node of the IAB node; and generating a command based on the determination, the command being configured to modify characteristics of the beam transmitted from the parent node to the IAB node; and transmitting the command to a beam controller of the parent node.

[0505] In one embodiment, the method is provided wherein the command is configured to modify the signal strength of the beam transmitted from the parent node to the IAB node.

[0506] In one embodiment, the method is provided further comprising using the processor circuit to make the determination based at least in part on the relative positions of: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0507] In one embodiment, the method is provided, further comprising making the determination, using the processor circuit, based at least in part on radio frequency (RF) conditions for: the parent node; the IAB node; and other nodes for which the IAB node acts as a relay node.

[0508] In one embodiment, the method is provided wherein the node is a carrier node; the processor circuit comprises a centralized unit circuit of the carrier node; and the command is transmitted from the centralized unit circuit to the beam controller.

[0509] In one embodiment, the method is provided wherein the node is the IAB node and the method further comprises using mobile terminal circuitry of the IAB node to transmit the command to the beam controller over a wireless backhaul interface.

[0510] In one embodiment, the method is provided, further comprising using configuration data to make the determination regarding the cross-link interference (CLI).

[0511] In one embodiment, the method is provided, further comprising receiving the configuration data from the parent IAB node via a wireless interface.

[0512] In one embodiment, the method is provided, further comprising obtaining the configuration data from a system information block (SIB).

[0513] In one embodiment, the method is provided, further comprising obtaining the configuration data from a Radio Resource Control (RRC) reconfiguration message.

[0514] In one embodiment, the method is provided, wherein the configuration data includes: first reconfiguration data, the first reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the parent node to the IAB node, and second reconfiguration data, the second reconfiguration data is related to an estimation of the radio frequency (RF) signal strength of the beam transmitted by the IAB node to the child node.

[0515] In one embodiment, a node of an integrated access and backhaul (IAB) network is provided, comprising: an interface configured to obtain a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; and a beam transmission circuit configured to modify characteristics of the beam transmitted from the node to the wireless relay node using the command.

[0516] In one embodiment, the node is provided, wherein the node is a carrier node.

[0517] In one embodiment, the node is provided, wherein the node is an IAB node carrier node.

[0518] In one embodiment, the node is provided, wherein the command is received from the wireless relay node.

[0519] In one embodiment, the node is provided, further comprising a data generation circuit configured to generate configuration data for use by the processor that makes the determination regarding the cross-link interference (CLI); a transmitter circuit configured to transmit the configuration data to the wireless relay node via a radio interface; and a receiver circuit configured to receive the beam modification command from the wireless relay node via the radio interface.

[0520] In one embodiment, a node is provided wherein the processor circuit making the determination comprises the node.

[0521] In one embodiment, the node is provided further comprising data generation circuitry configured to generate configuration data for use by the processor making the determination regarding the cross-link interference (CLI).

[0522] In one embodiment, a method in a node of an integrated access and backhaul (IAB) network is provided, comprising: obtaining a command configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; and modifying characteristics of the beam transmitted from the node to the wireless relay node based on the command.

[0523] In one embodiment, the method is provided, further comprising receiving the command from the wireless relay node.

[0524] In one embodiment, the method is provided wherein the node is a carrier node.

[0525] In one embodiment, the method is provided wherein the node is an IAB node carrier node.

[0526] In one embodiment, the method is provided, further comprising: generating configuration data for making the determination regarding the cross-link interference (CLI); transmitting the configuration data to the wireless relay node via a radio interface; and receiving the beam modification command from the wireless relay node via the radio interface.

[0527] In one embodiment, the method is provided, further comprising generating configuration data for use in said determination regarding said cross-link interference (CLI).

[0528] <Cross Reference>

[0529] This nonprovisional patent application claims priority under 35 U.S.C. §119 to Provisional Patent Application No. 62,966,741, filed on January 28, 2020, the entire contents of which are hereby incorporated by reference.

Claims

1. A node of an integrated access and backhaul (IAB) network, the node comprising: A processor circuit, the processor circuit being configured to: making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the node and (b) a beam transmitted from the node to a child node of the node; as well as generating a command based on the determination, the command configured to modify a characteristic of the beam transmitted from the parent node to the node; An interface circuit is configured to transmit the command to a beam controller of the parent node.

2. The node of claim 1, wherein the command is configured to modify the signal strength of the beam transmitted from the parent node to the node.

3. The node of claim 1 , wherein the processor circuit is configured to make the determination based at least in part on the relative positions of: the parent node; the node; and The node acts as a relay node for other nodes.

4. The node of claim 1 , wherein the processor circuit is configured to make the determination based at least in part on radio frequency (RF) conditions for: the parent node; the node; and The node acts as a relay node for other nodes.

5. The node of claim 1, wherein the processor circuit is configured to use configuration data to make the determination regarding the cross-link interference (CLI).

6. The node according to claim 5, wherein the configuration data comprises: first reconfiguration data relating to an estimate of a radio frequency (RF) signal strength of the beam transmitted by the parent node to the node, and Second reconfiguration data relating to an estimate of a radio frequency (RF) signal strength of the beam transmitted by the node to the child node.

7. A method in a node of an integrated access and backhaul (IAB) network, the node comprising: Using the processor circuit: making a determination regarding cross-link interference (CLI) between (a) a beam transmitted from a parent node to the node and (b) a beam transmitted from the node to a child node of the node; as well as generating a command according to the determination, The command is configured to modify a characteristic of the beam transmitted from the parent node to the node; The command is transmitted to the beam controller of the parent node.

8. The method of claim 7, wherein the command is configured to modify the signal strength of the beam transmitted from the parent node to the node.

9. The method of claim 7, further comprising using the processor circuit to make the determination based at least in part on the relative positions of: the parent node; the node; and The node acts as a relay node for other nodes.

10. The method of claim 7, further comprising using the processor circuit to make the determination based at least in part on radio frequency (RF) conditions for: the parent node; the node; and The node acts as a relay node for other nodes.

11. The method of claim 7, further comprising using configuration data to make the determination regarding the cross-link interference (CLI).

12. The method of claim 11, wherein the configuration data comprises: first reconfiguration data relating to an estimate of a radio frequency (RF) signal strength of the beam transmitted by the parent node to the node, and Second reconfiguration data relating to an estimate of a radio frequency (RF) signal strength of the beam transmitted by the node to the child node.

13. A node of an integrated access and backhaul (IAB) network, comprising: an interface configured to obtain commands configured according to a determination regarding cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; Beam transmission circuitry is configured to use the command to modify characteristics of the beam transmitted from the node to the wireless relay node.

14. The node of claim 13, wherein the command is received from the wireless relay node.

15. The node according to claim 13, further comprising: data generation circuitry configured to generate configuration data for use by a processor making said determination regarding said cross-link interference (CLI); a transmitter circuit configured to transmit the configuration data to the wireless relay node over a radio interface; and A receiver circuit is configured to receive the beam modification command from the wireless relay node over the radio interface.

16. The node of claim 13, wherein a processor circuit that makes the determination comprises the node.

17. The node of claim 13, further comprising data generation circuitry configured to generate configuration data for use by a processor that makes the determination regarding the cross-link interference (CLI).

18. A method in a node of an integrated access and backhaul (IAB) network, comprising: obtaining commands configured based on a determination of cross-link interference (CLI) between (a) a beam transmitted from the node to a wireless relay node and (b) a beam transmitted from the wireless relay node to a child node of the wireless relay node; A characteristic of the beam transmitted from the node to the wireless relay node is modified according to the command.

19. The method of claim 18, further comprising receiving the command from the wireless relay node.

20. The method of claim 18, further comprising: generating configuration data for making said determination regarding said cross-link interference (CLI); transmitting the configuration data to the wireless relay node via a radio interface; as well as The beam modification command is received from the wireless relay node over the radio interface.

Images