Patent Publication Number: US-2023164658-A1

Title: Enhanced conditional handover procedures in iab networks

Description:
CROSS REFERENCE 
     This Nonprovisional application claims priority under 35 U.S.C. § 119 on provisional Application No. 63/019,148 on May 1, 2020, the entire contents of which are hereby incorporated by reference. 
    
    
     TECHNICAL FIELD 
     The technology relates to wireless communications, and particularly to radio architecture and operation of wireless relay networks. 
     BACKGROUND ART 
     A radio access network typically resides between wireless devices, such as user equipment (UEs), mobile phones, mobile stations, or any other device having wireless termination, and a core network. Example of radio access network types includes the GRAN, GSM radio access network; the GERAN, which includes EDGE packet radio services; UTRAN, the UMTS radio access network; E-UTRAN, which includes Long-Term Evolution; and g-UTRAN, the New Radio (NR). 
     A radio access network may comprise one or more access nodes, such as base station nodes, which facilitate wireless communication or otherwise provides an interface between a wireless terminal and a telecommunications system. A non-limiting example of a base station can include, depending on radio access technology type, a Node B (“NB”), an enhanced Node B (“eNB”), a home eNB (“HeNB”), a gNB (for a New Radio [“NR”] technology system), or some other similar terminology. 
     The 3rd Generation Partnership Project (“3GPP”) is a group that, e.g., develops collaboration agreements such as 3GPP standards that aim to define globally applicable technical specifications and technical reports for wireless communication systems. Various 3GPP documents may describe certain aspects of radio access networks. Overall architecture for a fifth generation system, e.g., the 5G System, also called “NR” or “New Radio”, as well as “NG” or “Next Generation”, is shown in  FIG.  66   , and is also described in 3GPP TS 38.300. The 5G NR network is comprised of NG RAN (Next Generation Radio Access Network) and 5GC (5G Core Network). As shown, NGRAN is comprised of gNBs (e.g., 5G Base stations) and ng-eNBs (i.e. LTE base stations). An Xn interface exists between gNB-gNB, between (gNB)-(ng-eNB) and between (ng-eNB)-(ng-eNB). The Xn is the network interface between NG-RAN nodes. Xn-U stands for Xn User Plane interface and Xn-C stands for Xn Control Plane interface. A NG interface exists between 5GC and the base stations (i.e. gNB &amp; ng-eNB). A gNB node provides NR user plane and control plane protocol terminations towards the UE, and is connected via the NG interface to the 5GC. The 5G NR (New Radio) gNB is connected to AMF (Access and Mobility Management Function) and UPF (User Plane Function) in 5GC (5G Core Network). 
     In some cellular mobile communication systems and networks, such as Long-Term Evolution (LTE) and New Radio (NR), a service area is covered by one or more base stations, where each of such base stations may be connected to a core network by fixed-line backhaul links, e.g., optical fiber cables. In some instances, due to weak signals from the base station at the edge of the service area, users tend to experience performance issues, such as: reduced data rates, high probability of link failures, etc. A relay node concept has been introduced to expand the coverage area and increase the signal quality. As implemented, the relay node may be connected to the base station using a wireless backhaul link. 
     In 3rd Generation Partnership Project (3GPP), the relay node concept for the fifth generation (5G) cellular system has been discussed and standardized, where the relay nodes may utilize the same 5G radio access technologies (e.g., New Radio (NR)) for the operation of services to User Equipment (UE) (access link) and connections to the core network (backhaul link) simultaneously. These radio links may be multiplexed in time, frequency, and/or space. This system may be referred to as Integrated Access and Backhaul (IAB). 
     Some such cellular mobile communication systems and networks may comprise IAB-donors and IAB-nodes, where an IAB-donor may provide interface to a core network to UEs and wireless backhauling functionality to IAB-nodes. Additionally, an IAB-node may provide IAB functionality combined with wireless self-backhauling capabilities. IAB-nodes may need to periodically perform inter-IAB-node discovery to detect new IAB-nodes in their vicinity based on cell-specific reference signals, e.g., Synchronization Signal and PBCH block SSB). The cell-specific reference signals may be broadcasted on a Physical Broadcast Channel (PBCH) where packets may be carried or broadcasted on the Master Information Block (MIB) section. 
     Demand for wireless traffic has increased significantly over time and IAB systems are expected to be reliable and robust against various kinds of possible failures. Considerations have been given for IAB backhaul design. In particular, to provide methods and procedures to address radio link failures on the backhaul link. 
     What is needed are methods, apparatus, and/or techniques to cope with unfavorable conditions or problems on a wireless backhaul link, and particularly involving conditional handovers. 
     SUMMARY OF INVENTION 
     In one example, a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the wireless terminal comprising: receiver circuitry configured to receive: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional re-configuration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; processor circuitry configured, upon receiving the BH radio link condition indication, to determine whether to trigger a conditional handover configured by the conditional reconfiguration based on the node serving cell information. 
     In one example, an integrated access and backhaul (IAB) node which communicates over at least two radio interfaces including a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the IAB node comprising: processor circuitry configured to detect a radio link condition on the first interface, and; transmitter circuitry configured to transmit, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine whether to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the IAB donor comprising: processor circuitry configured to generate a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitter circuitry configured to transmit the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     In one example, a method for a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the method comprising: receiving: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; upon receiving the BH radio link condition indication, using the node serving cell information to make a determination whether to trigger a conditional handover configured by the conditional reconfiguration. 
     In one example, a method for an integrated access and backhaul (IAB) node which communicates across at least two radio interfaces comprising a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the method comprising: detecting a radio link condition on the first interface, and; transmitting, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, a method for an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the method comprising: generating a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitting the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       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 characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the technology disclosed herein. 
         FIG.  1    is a diagrammatic view illustrating a mobile network infrastructure using 5G signals and 5G base stations. 
         FIG.  2    is a diagrammatic view depicting an example of functional block diagrams for the IAB-donor and the IAB-node. 
         FIG.  3    is a diagrammatic view illustrating Control Plane (C-Plane) and User Plane (U-Plane) protocols among the UE, IAB-nodes, and IAB-donor. 
         FIG.  4    is a functional block diagram of an example protocol stack configuration for the U-Plane. 
         FIG.  5 A  depicts a functional block diagram of an example protocol stack configuration for the C-Plane between an IAB-node connected to an IAB-donor. 
         FIG.  5 B  depicts a functional block diagram of an example configuration of the C-Plane protocol stack for an IAB-node connected to another IAB-node which is connected to an IAB-donor. 
         FIG.  5 C  depicts a functional block diagram of an example configuration of the C-Plane protocol stack for a UE&#39;s RRC signaling. 
         FIG.  6 A  depicts an example message sequence for an IAB-node to establish an RRC connection, followed by F1-AP* connection. 
         FIG.  6 B  depicts an example message sequence for IAB-node to establish an RRC connection with an IAB-donor, followed by the F1 setup procedure. 
         FIG.  7    is a diagrammatic view of an example scenario where an IAB-node detects a Radio Link Failure (RLF) on the upstream link to its parent node. 
         FIG.  8    illustrates an example flow of information transmit/receive and/or processing by a UE and/or IAB-node connected to a set of IAB-nodes in communication with an IAB-donor, for processing a notification of an RLF. 
         FIG.  9 A  illustrates an example flow of information transmit/receive and/or processing by a UE and/or IAB-node connected to a set of IAB-nodes in communication with an IAB-donor, based on receiving an Upstream RLF notification. 
         FIG.  9 B  illustrates another example flow of information transmit/receive and/or processing by a UE and/or IAB-node connected to a set of IAB-nodes in communication with an IAB-donor, based on not having received an Upstream RLF notification. 
         FIG.  10    is a diagrammatic view illustrating an example of a radio protocol architecture for the control and user planes in a mobile communications network. 
         FIG.  11    is a diagrammatic view showing another example telecommunications system in which a conditional autonomous handover may be performed for resolving a wireless link backhaul condition. 
         FIG.  12    is a diagrammatic view showing an example, non-limiting more detailed implementation of at least portions of the system of  FIG.  11   . 
         FIG.  13    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a wireless access node of  FIG.  11   . 
         FIG.  14    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a child node of  FIG.  11   . 
         FIG.  15    depicts example, basic, representative acts or steps of a message flow for the system scenario shown in  FIG.  11   . 
         FIG.  16    is a diagrammatic view showing another example telecommunications system in wherein a wireless link backhaul condition may be resolved when redundant links are utilized. 
         FIG.  17    is a diagrammatic view showing an example, non-limiting more detailed implementation of at least portions of the system of  FIG.  16   . 
         FIG.  18    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a wireless access node of  FIG.  16   . 
         FIG.  19    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a child node of  FIG.  16   . 
         FIG.  20 A  depicts example, basic, representative acts or steps of a message flow for a first example system scenario shown in  FIG.  16   . 
         FIG.  20 B  depicts example, basic, representative acts or steps of a message flow for a first example system scenario shown in  FIG.  16   . 
         FIG.  21    is a diagrammatic view showing another example telecommunications system wherein a routing loop may occur upon cell selection. 
         FIG.  22 A  depicts example, basic, representative acts or steps of a message flow in a situation in which an IAB node of  FIG.  21    may recover from a broken upstream link by an RRC reestablishment procedure with a first parent IAB node. 
         FIG.  22 A  depicts example, basic, representative acts or steps of a message flow in a situation in which an IAB node of  FIG.  21    may recover from a broken upstream link by an RRC reestablishment procedure with a second parent IAB node. 
         FIG.  23    is a diagrammatic view showing another example telecommunications system, and particularly an example telecommunications system wherein generic routing loop prevention information is used to address a potential routing loop problem. 
         FIG.  24    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a wireless access donor node of  FIG.  23   . 
         FIG.  25    is a flowchart showing example, non-limiting, basic acts or steps that may be performed by a non-donor Integrated Access and Backhaul (IAB) node of  FIG.  23   . 
         FIG.  26 A  is a diagrammatic view showing an example implementation of the generic telecommunications system of  FIG.  23    wherein the routing loop prevention information comprises configuration information, e.g., configuration parameter(s), generated by a donor Integrated Access and Backhaul (IAB) node. 
         FIG.  26 B  is a diagrammatic view showing an example implementation of the generic telecommunications system of  FIG.  23    wherein the routing loop prevention information comprises configuration information, e.g., configuration parameter(s), generated by a network server entity. 
         FIG.  27    is a diagrammatic view of an example message flow including a RRCReconfiguration message for sending a whitelist or blacklist of configuration parameter(s). 
         FIG.  28    is a flowchart showing example, representative acts or steps which may be performed by the IAB node of  FIG.  26 A . 
         FIG.  29    is a flowchart showing example, representative acts or steps which may be performed by the wireless access donor node of  FIG.  26 A . 
         FIG.  30    is a flowchart showing example, representative acts or steps which may be performed by the wireless access donor node of  FIG.  26 B . 
         FIG.  31    is a flowchart showing example, representative acts or steps which may be performed by the network entity  FIG.  26 B . 
         FIG.  32    is a schematic view of an IAB node which further comprises a configuration parameter(s) validity timer. 
         FIG.  33    is a diagrammatic view showing an example implementation of the generic telecommunications system of  FIG.  23    wherein, as routing loop prevention information, an Integrated Access and Backhaul (IAB) node broadcasts system information which announces parent nodes. 
         FIG.  34    is a diagrammatic view illustrating a mode of operation of a telecommunications network that includes Integrated Access and Backhaul (IAB) nodes that broadcasts system information which announces parent nodes in the manner of  FIG.  33   . 
         FIG.  35    is a diagrammatic view showing an example implementation of the generic telecommunications system of  FIG.  23    wherein, as routing loop prevention information, an Integrated Access and Backhaul (IAB) node broadcasts system information which announces parent nodes, and wherein a routing loop prevention information generator takes the form of a parent node identifications generator. 
         FIG.  36    is a flowchart showing example, representative acts or steps which may be performed by the wireless access donor node of  FIG.  33   - FIG.  35   . 
         FIG.  37    is a flowchart showing example, representative acts or steps which may be performed by the wireless access donor node of  FIG.  33   - FIG.  35   . 
         FIG.  38    is a diagrammatic view showing another example and generic telecommunications system in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. 
         FIG.  39    is a flowchart showing example, representative, acts or steps performed by a generic IAB node of the system of  FIG.  38   . 
         FIG.  40    is a flowchart showing example, representative, acts or steps performed by a generic child node of the system of  FIG.  38   . 
         FIG.  41 A  is a schematic view showing details of respective example implementations telecommunications system of the generic system of  FIG.  38    in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. 
         FIG.  41 B  is a schematic view showing details of respective example implementations telecommunications system of the generic system of  FIG.  38    in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. 
         FIG.  41 C  is a schematic view showing details of respective example implementations telecommunications system of the generic system of  FIG.  38    in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. 
         FIG.  42    is an example message flow of the generic scenario shown in  FIG.  38   . 
         FIG.  43 A  is a flowchart showing example, representative acts or steps performed by an IAB node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  43 B  is a flowchart showing example, representative acts or steps performed by an IAB node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  43 C  is a flowchart showing example, representative acts or steps performed by an IAB node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  44 A  is a flowchart showing example, representative acts or steps performed by a child node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  44 B  is a flowchart showing example, representative acts or steps performed by a child node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  44 C  is a flowchart showing example, representative acts or steps performed by a child node of the implementations of  FIGS.  41 A,  41 B, and  41 C , respectively. 
         FIG.  45    is a diagrammatic view showing another example and generic telecommunications system in which an IAB node may update an RRC connection and thereby require a child node to perform a re-establishment procedure with respect to a new donor IAB node. 
         FIG.  46 A  is an example diagrammatic view of message flow which illustrates a need for the system of  FIG.  45   . 
         FIG.  46 B  is an example diagrammatic view of message flow which illustrates context transfer of grandchild nodes between donor IAB nodes for the system of  FIG.  45   . 
         FIG.  46 C  is an example diagrammatic view of message flow which illustrates an inter-CU handover for the system of  FIG.  45   . 
         FIG.  47    is a flowchart showing example, representative, acts or steps performed by a generic IAB node of the system of  FIG.  45   . 
         FIG.  48    is a flowchart showing example, representative, acts or steps performed by a generic child node of the system of  FIG.  45   . 
         FIG.  49    is a schematic views showing details of an example implementation telecommunications system of the generic system of  FIG.  45    wherein an IAB node performs a RRC Connection Re-establishment. 
         FIG.  50    is a diagrammatic view of message flow showing another implementation of how the system of  FIG.  45    and  FIG.  49    may perform context transfer. 
         FIG.  51 A  is a diagrammatic view depicting message flow of example RRC re-establishment procedure for a child node and an example inter-CU handover, respectively. 
         FIG.  51 B  is a diagrammatic view depicting message flow of example RRC re-establishment procedure for a child node and an example inter-CU handover, respectively. 
         FIG.  52    is a schematic view showing details of an example implementation telecommunications system of the generic system of  FIG.  45    wherein an IAB-node  24 A performs an inter-CU, e.g., an inter-donor, handover. 
         FIG.  53    is a flowchart showing example, representative, acts or steps performed by an IAB node of the system of  FIG.  52   . 
         FIG.  54    is a flowchart showing example, representative, acts or steps performed by a child node of the system of  FIG.  52   . 
         FIG.  55    is a flowchart showing example, representative, acts or steps performed by a donor IAB node that performs context transfer such as in the system of  FIG.  49    and the system of  FIG.  52   . 
         FIG.  56    is a diagrammatic view showing an example and generic telecommunications system in which a Child Node has been configured by Donor IAB node with an RRCReconfiguration message that facilitates conditional handover. 
         FIG.  57    is a diagrammatic view of information elements of an example RRCRe-configuration message for the embodiment and mode of  FIG.  56   . 
         FIG.  58 A  is a diagrammatic view including signaling and showing an example of a successful scenario for Child Node of the embodiment and mode  FIG.  56    performing CHO. 
         FIG.  58 B  is a diagrammatic view including signaling and showing an example of a problematic scenario due to a conditional handover triggered by a backhaul (BH) RLF indication in the embodiment and mode of  FIG.  56   . 
         FIG.  59    is a diagrammatic view showing an example and generic telecommunications system in which a Child Node comprises a node serving cell information-based conditional handover controller. 
         FIG.  60    is a schematic view showing in more detail nodes of the example and generic telecommunications system of  FIG.  59    according to an example embodiment and mode. 
         FIG.  61    is a diagrammatic view including signaling and showing an example scenario wherein node serving cell information is provided to the child node provided with a node serving cell information-based conditional handover controller which declines to perform a conditional handover to a cell based on node serving cell information. 
         FIG.  62    is a flow chart showing example, representative acts or steps or acts performed by a child node of the example embodiment and mode of  FIG.  59   . 
         FIG.  63    is a flow chart showing example, representative acts or steps or acts performed by a donor IAB node of the example embodiment and mode of  FIG.  59   . 
         FIG.  64    is a flow chart showing example, representative acts or steps or acts performed by an IAB node of the example embodiment and mode of  FIG.  59   . 
         FIG.  65    is a diagrammatic view showing example elements comprising electronic machinery which may comprise a wireless terminal, a radio access node, and a core network node according to an example embodiment and mode. 
         FIG.  66    is a diagrammatic view of overall architecture for a 5G New Radio system. 
     
    
    
     DESCRIPTION OF EMBODIMENTS 
     In one of its example aspects the technology disclosed herein concerns a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node. In an example embodiment and mode the wireless terminal comprises receptacle and processor circuitry. The receiver circuitry is configured to receive: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication. The processor circuitry is configured, upon receiving the BH radio link condition indication, to determine whether to trigger a conditional handover configured by the conditional reconfiguration based on the node serving cell information. Methods of operating such wireless terminals are also provided. 
     In another of its example aspects the technology disclosed herein concerns an integrated access and backhaul (IAB) node which communicates over at least two radio interfaces including a first interface and a second interface. The first interface is configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface is configured to serve one or more cells to communicate with a wireless terminal. In an example embodiment and mode the IAB node comprises processor circuitry and transmitter circuitry. The processor circuitry is configured to detect a radio link condition on the first interface. The transmitter circuitry is configured to transmit, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells. The BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine whether to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. Methods of operating such integrated access and backhaul (IAB) nodes are also provided. 
     In yet another of its example aspects the technology disclosed herein concerns an Integrated access and backhaul (IAB) donor node that communicates with a wireless terminal via an IAB node. In an example embodiment and mode the IAB donor comprises processor circuitry and transmitter circuitry. The processor circuitry is configured to generate a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell. The transmitter circuitry is configured to transmit the reconfiguration message to the wireless terminal. The conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. Methods of operating such Integrated access and backhaul (IAB) donor nodes are also provided. 
     In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the technology disclosed herein. However, it will be apparent to those skilled in the art that the technology disclosed herein may be practiced in other embodiments that depart from these specific details. That is, those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the technology disclosed herein and are included within its spirit and scope. In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the technology disclosed herein with unnecessary detail. All statements herein reciting principles, aspects, and embodiments of the technology disclosed herein, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure. 
     Thus, for example, it will be appreciated by those skilled in the art that block diagrams herein can represent conceptual views of illustrative circuitry or other functional units embodying the principles of the technology. Similarly, it will be appreciated that any flow charts, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown. 
     As used herein, the term “core network” can refer to a device, group of devices, or sub-system in a telecommunication network that provides services to users of the telecommunications network. Examples of services provided by a core network include aggregation, authentication, call switching, service invocation, gateways to other networks, etc. 
     As used herein, the term “wireless terminal” can refer to any electronic device used to communicate voice and/or data via a telecommunications system, such as (but not limited to) a cellular network. Other terminology used to refer to wireless terminals and non-limiting examples of such devices can include user equipment terminal, UE, mobile station, mobile device, access terminal, subscriber station, mobile terminal, remote station, user terminal, terminal, subscriber unit, cellular phones, smart phones, personal digital assistants (“PDAs”), laptop computers, tablets, netbooks, e-readers, wireless modems, etc. 
     As used herein, the term “access node”, “node”, or “base station” can refer to any device or group of devices that facilitates wireless communication or otherwise provides an interface between a wireless terminal and a telecommunications system. A non-limiting example of a base station can include, in the 3GPP specification, a Node B (“NB”), an enhanced Node B (“eNB”), a home eNB (“HeNB”), a gNB (for a New Radio [“NR”] technology system), or some other similar terminology. 
     As used herein, the term “telecommunication system” or “communications system” can refer to any network of devices used to transmit information. A non-limiting example of a telecommunication system is a cellular network or other wireless communication system. 
     As used herein, the term “cellular network” or “cellular radio access network” can refer to a network distributed over cells, each cell served by at least one fixed-location transceiver, such as a base station. A “cell” may be any communication channel that is specified by standardization or regulatory bodies to be used for International Mobile Telecommunications-Advanced (“IMTAdvanced”). All or a subset of the cell may be adopted by 3GPP as licensed bands (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 licensed frequency bands can include configured cells. Configured cells can include cells of which a UE terminal is aware and in which it is allowed by a base station to transmit or receive information. Examples of cellular radio access networks include E-UTRAN, and any successors thereof (e.g., NUTRAN). 
     Any reference to a “resource” herein means “radio resource” unless otherwise clear from the context that another meaning is intended. In general, as used herein a radio resource (“resource”) is a time-frequency unit that can carry information across a radio interface, e.g., either signal information or data information. 
     An example of a radio resource occurs in the context of a “frame” of information that is typically formatted and prepared, e.g., by a node. In Long Term Evolution (LTE) a frame, which may have both downlink portion(s) and uplink portion(s), is communicated between the base station and the wireless terminal. Each LTE frame may comprise plural subframes. For example, in the time domain, a 10 ms frame consists of ten one millisecond subframes. An LTE subframe is divided into two slots (so that there are thus 20 slots in a frame). The transmitted signal in each slot is described by a resource grid comprised of resource elements (RE). Each column of the two dimensional grid represents a symbol (e.g., an OFDM symbol on downlink (DL) from node to wireless terminal; an SC-FDMA symbol in an uplink (UL) frame from wireless terminal to node). Each row of the grid represents a subcarrier. A resource element (RE) is the smallest time-frequency unit for downlink transmission in the subframe. That is, one symbol on one sub-carrier in the sub-frame comprises a resource element (RE) which is uniquely defined by an index pair (k,l) in a slot (where k and l are the indices in the frequency and time domain, respectively). In other words, one symbol on one sub-carrier is a resource element (RE). Each symbol comprises a number of sub-carriers in the frequency domain, depending on the channel bandwidth and configuration. The smallest time-frequency resource supported by the standard today is a set of plural subcarriers and plural symbols (e.g., plural resource elements (RE)) and is called a resource block (RB). A resource block may comprise, for example, 84 resource elements, i.e., 12 subcarriers and 7 symbols, in case of normal cyclic prefix 
     In 5G New Radio (“NR”), a frame consists of 10 ms duration. A frame consists of 10 subframes with each having 1 ms duration similar to LTE. Each subframe consists of 2 μ  slots. Each slot can have either 14 (normal CP) or 12 (extended CP) OFDM symbols. A Slot is typical unit for transmission used by scheduling mechanism. NR allows transmission to start at any OFDM symbol and to last only as many symbols as required for communication. This is known as “mini-slot” transmission. This facilitates very low latency for critical data communication as well as minimizes interference to other RF links. Mini-slot helps to achieve lower latency in 5G NR architecture. Unlike slot, mini-slots are not tied to the frame structure. It helps in puncturing the existing frame without waiting to be scheduled. See, for example, https://www.rfwireless-world.com/5G/5G-NR-Mini-Slot.html, which is incorporated herein by reference. 
     A mobile network used in wireless networks may be where the source and destination are interconnected by way of a plurality of nodes. In such a network, the source and destination may not be able to communicate with each other directly due to the distance between the source and destination being greater than the transmission range of the nodes. That is, a need exists for intermediate node(s) to relay communications and provide transmission of information. Accordingly, intermediate node(s) may be used to relay information signals in a relay network, having a network topology where the source and destination are interconnected by means of such intermediate nodes. In a hierarchical telecommunications network, the backhaul portion of the network may comprise the intermediate links between the core network and the small subnetworks of the entire hierarchical network. Integrated Access and Backhaul (IAB) Next generation NodeB use 5G New Radio communications such as transmitting and receiving NR User Plane (U-Plane) data traffic and NR Control Plane (C-Plane) data. Both, the UE and gNB may include addressable memory in electronic communication with a processor. In one embodiment, instructions may be stored in the memory and are executable to process received packets and/or transmit packets according to different protocols, for example, Medium Access Control (MAC) Protocol and/or Radio Link Control (RLC) Protocol. 
     In some aspects of the embodiments for handling of radio link failures in wireless relay networks, disclosed is a Mobile Termination (MT) functionality-typically provided by the User Equipment (UE) terminals-that may be implemented by Base Transceiver Stations (BTSs or BSs) nodes, for example, IAB nodes. In one embodiment, the MT functions may comprise common functions such as: radio transmission and reception, encoding and decoding, error detection and correction, signaling, and access to a SIM. 
     In a mobile network, an IAB child node may use the same initial access procedure (discovery) as an access UE to establish a connection with an IAB node/donor or parent-thereby attaching to the network or camping on a cell. In one embodiment, Radio Resource Control (RRC) protocol may be used for signaling between 5G radio network and UE, where RRC may have at least two states (e.g., RRC_IDLE and RRC_CONNECTED) and state transitions. The RRC sublayer may enable establishing of connections based on the broadcasted system information and may also include a security procedure. The U-Plane may comprise of PHY, MAC, RLC and PDCP layers. 
     At least some example embodiments herein disclose methods and devices for an IAB-node to inform child nodes and/or UEs of upstream radio conditions and accordingly, the term IAB-node may be used to represent either a parent IAB-node or a child IAB-node, depending on where the IAB-node is in the network communication with the IAB-donor which is responsible for the physical connection with the core network. Embodiments are disclosed where an IAB-node, e.g., child IAB-node, may follow the same initial access procedure as a UE, including cell search, system information acquisition, and random access, in order to initially set up a connection to a parent IAB-node or an IAB-donor. That is, when an IAB base station (eNB/gNB) needs to establish a backhaul connection to, or camp on, a parent IAB-node or an IAB-donor, the IAB-node may perform the same procedures and steps as a UE, where the IAB-node may be treated as a UE but distinguished from a UE by the parent IAB-node or the IAB-donor. 
     In at least some example embodiments for handling radio link failures in wireless relay networks, MT functionality-typically offered by a UE-may be implemented on an IAB-node. In some examples of the disclosed systems, methods, and device embodiments, consideration may be made in order for a child IAB-node to monitor a radio condition on a radio link to a parent IAB-node-where the parent IAB-node may itself be a child IAB-node in communication with an IAB-donor. 
     With reference to  FIG.  1   , the present embodiments include a mobile network infrastructure using 5G signals and 5G base stations (or cell stations). Depicted is a system diagram of a radio access network utilizing IAB nodes, where the radio access network may comprise, for example, one IAB-donor and multiple IAB-nodes. Different embodiments may comprise different number of IAB-donor and IAB-node ratios. Herein, the IAB nodes may be referred to as IAB relay nodes. The IAB-node may be a Radio Access Network (RAN) node that supports wireless access to UEs and wirelessly backhauls the access traffic. The IAB-donor may be a RAN node which may provide an interface to the core network to UEs and wireless backhauling functionality to IAB nodes. An IAB-node/donor may serve one or more IAB nodes using wireless backhaul links as well as UEs using wireless access links simultaneously. Accordingly, network backhaul traffic conditions may be implemented based on the wireless communication system to a plurality of IAB nodes and UEs. 
     With further reference to  FIG.  1   , a number of UEs are depicted as in communication with IAB nodes, for example, IAB nodes and IAB donor node, via wireless access link. Additionally, the IAB-nodes (child nodes) may be in communication with other IAB-nodes and/or an IAB-donor (all of which may be considered IAB parent nodes) via wireless backhaul link. For example, a UE may be connected to an IAB-node which itself may be connected to a parent IAB-node in communication with an IAB-donor, thereby extending the backhaul resources to allow for the transmission of backhaul traffic within the network and between parent and child for integrated access. The embodiments of the system provide for capabilities needed to use the broadcast channel for carrying information bit(s) (on the physical channels) and provide access to the core network. 
       FIG.  2    depicts an example of functional block diagrams for the IAB-donor and the IAB-node (see  FIG.  1   ). The IAB-donor may comprise at least one Central Unit (CU) and at least one Distributed Unit (DU). The CU is a logical entity managing the DU collocated in the IAB-donor as well as the remote DUs resident in the IAB-nodes. The CU may also be an interface to the core network, behaving as a RAN base station (e.g., eNB or gNB). In some embodiments, the DU is a logical entity hosting a radio interface (backhaul/access) for other child IAB-nodes and/or UEs. In one configuration, under the control of CU, the DU may offer a physical layer and Layer-2 (L2) protocols (e.g., Medium Access Control (MAC), Radio Link Control (RLC), etc.) while the CU may manage upper layer protocols (such as Packet Data Convergence Protocol (PDCP), Radio Resource Control (RRC), etc.). An IAB-node may comprise DU and Mobile-Termination (MT) functions, where in some embodiments the DU may have the same functionality as the DU in the IAB-donor, whereas MT may be a UE-like function that terminates the radio interface layers. As an example, the MT may function to perform at least one of: radio transmission and reception, encoding and decoding, error detection and correction, signaling, and access to a SIM. 
     Embodiments include a mobile network infrastructure where a number of UEs are connected to a set of IAB-nodes and the IAB-nodes are in communication with each other for relay and/or an IAB-donor using the different aspects of the present embodiments. In some embodiments, the UE may communicate with the CU of the IAB-donor on the C-Plane using RRC protocol and in other embodiments, using Service Data Adaptation Protocol (SDAP) and/or Packet Data Convergence Protocol (PDCP) radio protocol architecture for data transport (U-Plane) through NR gNB. In some embodiments, the DU of the IAB-node may communicate with the CU of the IAB-donor using 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 an IAB-node and the CU of an IAB-donor. That is, as further described below, the protocol stack configuration may be interchangeable, and different mechanism may be used. 
     As illustrated by the diagram shown in  FIG.  3   , the protocols among the UE, IAB-nodes, and IAB donor are grouped into Control Plane (C-Plane) and User Plane (U-Plane). C-Plane carries control signals (signaling data), whereas the U-Plane carries user data.  FIG.  3    shows an example of the embodiment where there are two IAB-nodes, IAB-node  1  and IAB-node  2 , between the UE and the IAB-donor (two hops). Other embodiments may comprise a network with a single hop or multiple hops where there may be more than two IAB-nodes present. 
       FIG.  4    depicts a functional block diagram of an example protocol stack configuration for the U-Plane, the stack comprising Service Data Protocol (e.g., SDAP, 3GPP TS 38.324) which may carry user data (e.g., via IP packets). In one embodiment, the SDAP runs on top of PDCP (3GPP TS 38.323) and the L2/Physical layers. In one embodiment, an Adaptation Layer is introduced between the IAB-node and the IAB-node/donor, where the Adaptation Layer carries relay-specific information, such as IAB-node/donor addresses, QoS information, UE identifiers, and potentially other information. In this embodiment, RLC (3GPP TS 38.322) may provide reliable transmission in a hop-by-hop manner while PDCP may perform end-to-end (UE-CU) error recovery. GTP-U (GPRS Tunneling Protocol User Plane) may be used for routing user data between CU and DU inside the IAB-donor. 
       FIG.  5 A  is a functional block diagram of an example protocol stack configuration for the C-Plane between an IAB-node (IAB-node  1 ) directly connected to the IAB-donor (via a single hop). In this embodiment, the MT component of IAB-node  1  may establish an RRC connection with the CU component of the IAB-donor. In parallel, RRC may be used for carrying another signaling protocol in order for CU/IAB-donor to control the DU component resident in the IAB-node  1 . In one embodiment, such a signaling protocol may be referred to as F1 Application Protocol* (F1-AP*), either the protocol referred as F1-AP specified in 3GPP TS 38.473 or a protocol based on the F1-AP with potential extended features to accommodate wireless backhauls (the original F1-AP is designed for wirelines). In other embodiments, F1-AP may be used for CU-DU connection inside the IAB-donor. It is assumed that below RLC, MAC/PHY layers are shared with the U-Plane. 
       FIG.  5 B  depicts a functional block diagram of an example configuration of the C-Plane protocol stack for IAB-node  2 , an IAB-node connected to the aforementioned IAB-node  1  (2 hops). In one embodiment, it may be assumed that the IAB-node  1  has already established RRC/F1-AP* connections with the IAB-donor as shown in  FIG.  5 A . In IAB-node  1  the signaling bearer for IAB-node  2  RRC/PDCP may be carried by the Adaptation Layer to the IAB-donor. Similar to  FIG.  5 A , the F1-AP* signaling is carried by the RRC of IAB-node  2 . 
       FIG.  5 C  depicts yet another functional block diagram of an example configuration of the C-Plane protocol stack for UE&#39;s RRC signaling under the 2-hop relay configuration shown in  FIG.  5 B . Accordingly, the UE having an MT component and functionality, via the C-Plane, may be connected to the CU of the IAB-donor. Though traffic is routed through IAB-node  2  and IAB-node  1 , as depicted, the two nodes are passive nodes in that the data is passed to the next node(s) without manipulation. That is, data is transmitted by the UE to the node it is connected to, e.g., IAB-node  2 , and then IAB-node  2  transmits the data to the node that is connected to, e.g., IAB-node  1 , and then IAB-node  1  transmits the data (without manipulation) to the IAB-donor. 
       FIGS.  5 A,  5 B, and  5 C  illustrate that the MT of each IAB-node or UE has its own end-to-end RRC connection with the CU of the IAB-donor. Likewise, the DU of each IAB-node has an end-to-end F1-AP* connection with the CU of the IAB-donor. Any IAB nodes present between such end points transparently convey RRC or F1-AP signaling traffic. 
       FIGS.  6 A and  6 B  are diagrams of an example flow of information transmit/receive and/or processing by IAB-node(s) and an IAB-donor according to aspects of the present embodiments. 
       FIG.  6 A  depicts an example message sequence for IAB-node  1  to establish an RRC connection, followed by F1-AP* connection. It is assumed that IAB-node  1  has been pre-configured (or configured by the network) with information that instructs how to select a cell served by the IAB-donor. As shown in the figure, IAB-node  1 -in an idle state (RRC_IDLE)-may initiate an RRC connection establishment procedure by sending Random Access Preamble to the IAB-donor, which may be received and processed by the DU of the IAB-donor. Upon successful reception of Random Access Response from the IAB-donor, IAB-node  1  may send a RRCSetupRequest, followed by reception of an RRCSetup and transmission of RRCSetupComplete. At this point of the message sequence, the IAB-node  1  may enter a connected state (RRC_CONNECTED) with the IAB-donor, and may proceed with a security procedure to configure encryption/integrity protection features. The CU of the IAB-donor may further send an RRCReconfiguration to IAB-node  1 , which may comprise configuration parameters to configure radio bearers (e.g., data radio bearers (DRBs) and signaling radio bearers (SRB_s)). In some embodiments, the RRCReconfiguration is sent to modify an RRC connection and establish Radio Connection between a UE and the network, however, in the present embodiment, the RRCReconfiguration may also be sent to configure a connection between an IAB-node and the network. RRC Connection Reconfiguration messages may be used to, for example, establish/modify/release Radio Bearers, and/or perform handover, etc. In one embodiment, any of the RRC messages transmitted from IAB-node  1  may include information identifying the IAB-node  1  as an IAB-node (not as a UE). For example, the Donor CU may be configured with a list of node identities (e.g., IMSI or S-TMSI) that may be allowed to use the service from the donor. The information may be used by the CU in the subsequence operations, for example, to distinguish a UE from an IAB-node. 
     As described above, following the RRC connection establishment procedure, the DU of IAB-node  1  and IAB-donor may proceed with F1 setup procedure using the F1-AP* protocol, which may activate one or more cells served by the DU of IAB-node  1 -thereby allowing other IAB nodes and/or UEs to camp on the cell. In this procedure, the Adaptation Layer for IAB-node  1  and IAB-donor may be configured and activated as well. 
       FIG.  6 B  depicts an example message sequence or flow of information for IAB-node  2  to establish an RRC connection with IAB-donor, followed by the F1 setup procedure. It is assumed in this embodiment that IAB-node  1  has already performed the process disclosed in  FIG.  6 A  to establish an RRC and F1-AP* connection. Referring back to  FIG.  3   , the IAB-node  2  shown in communication via the radio interface with IAB-node  1 , may be also depicted in  FIG.  6 B  as a child node of IAB-node  1  according to aspects of the present embodiments. 
     It should be understood that upon or after establishing the RRC/F1-AP connection the IAB-donor may acquire knowledge of the IAB-node location within the relay network topology. In one configuration, this may be achieved by intermediate IAB-nodes relaying identifications of nodes located in its downstream to its upstream nodes. 
     Due to the nature of wireless communications, the wireless backhaul links are susceptible to be deteriorated or broken at any time. In aspects of the present embodiments, the MT part of an IAB-node may constantly monitor the quality of the radio link and/or signal quality on the upstream of the IAB-node, where the radio link may be to a parent IAB node/donor of the IAB-node. If radio problems cannot be recovered in a designated duration, the MT may declare Radio Link Failure (RLF), meaning a loss of communication link may have occurred or signal strength is weak to continue (e.g., below a threshold). 
       FIG.  7    shows an example diagram of a scenario where an IAB-node (Node A) detects RLF on the upstream link to its parent node (Parent node  1 ). In some embodiments, the MT component of Node A may need to find another parent that is visible from the node. In this case, the MT component may perform a cell selection procedure, and if a suitable cell, such as Parent node  2 , is successfully found, the Node A may then proceed with an RRC reestablishment procedure with the suitable cell, e.g., Parent node  2 . It should be noted that Node A in this scenario needs to find a cell served by either an IAB-node or an IAB-donor, e.g., non-IAB-capable cells are not suitable. In one embodiment, a cell served by either an IAB-node or an IAB-donor may broadcast a state, e.g., via a flag, as an indication indicating the IAB capability, which may further comprise an indication of the IAB functionality, a node type (IAB-node or IAB-donor), a hop count and/or the current state of the connectivity to the parent node. Such broadcast may occur using system information, such as MIB, system information block type 1 (SIB1) or any of the other SIBs. Alternatively, or in parallel, Node A may have been pre-configured or configured by the network with a list of IAB-capable cell identifications. 
     While Node A is trying to find a new suitable IAB-capable serving cell, the child IAB nodes, e.g., Child node  1  and Child node  2 , and/or UEs, e.g., UE 1  and UE 2 , may still be in connected mode with Node A. If Node A successfully recovers from the RLF before expiration of a pre-configured or network-configured period of time, the child nodes and/or the UEs may not be aware of the RLF. However, in the scenario where Node A fails or has failed to recover from the RLF in a timely manner, e.g., before expiration of a pre-configured/network-configured period of time, not only may these child nodes/UEs suffer discontinuity of service, but also all the nodes/UEs in the downstream may also suffer discontinuity of service. 
     Some example embodiments herein disclose systems, methods, and device where an IAB-node may inform connected nodes, e.g., child nodes, or UEs, of the upstream radio conditions. In some embodiments, the upstream radio condition information may enable the child nodes or UEs to decide to stay connected with the IAB-node or to look for another node to connect to. 
       FIG.  8    shows an example scenario for Upstream RLF notification, a notification of an RLF, sent from a node (Node A) and detected on the node&#39;s upstream, to the child nodes and/or the directly connected UEs. In one embodiment, upon receiving the notification, each of the child nodes and/or UEs may perform cell selection and, if successful, proceed to RRC reestablishment. As shown in  FIG.  8   , each of the child nodes and/or UEs, after a successful selection to a new node (Node B), may start the reestablishment procedure through Node B. That is, once a successful selection is made, the child nodes and/or UEs may transmit Random Access Preamble/Response messages, followed by RRCReestablishmentRequest and subsequent messages as illustrated in  FIG.  8   . 
     In one embodiment, Upstream RLF notification may be carried by the Adaptation Layer, e.g., a header part or a message body of the Adaptation Layer protocol. In an alternate embodiment, or in addition to, the notifications may be carried by the RLC sublayer, MAC, or a physical layer signaling, e.g., PDCCH. Additionally or alternatively, the notifications may be broadcasted via system information, e.g., MIB, SIB1 or any of the other SIBs, or transmitted in a dedicated manner. 
     Accordingly, in one embodiment, RRC resident in each of the child nodes and/or UEs may perform cell selection upon receiving a notification indicating the reception of the Upstream RLF notification from lower layers. In at least some of the example embodiments herein, this may be performed even if the radio link to the parent node remains in good condition. The node and/or UE may then start a timer, timer Txxx, e.g., T311 specified in 3GPP TS 38.331, based on the received notification, and upon selecting a suitable cell while timer Txxx is running, the node and/or UE may stop timer Txxx and initiate transmission of RRCReestablishmentRequest to the IAB-donor. 
     Once the RRC connection is reestablished, the CU of the IAB-donor may update the F1-AP* configurations in Node B as well as the child IAB-node that initiated the RRC reestablishment. In the scenario where the connecting device is a UE, F1-AP* configuration updates are not needed as they do not have the F1-AP* interface. Accordingly, the updated configuration from the IAB-donor may be used to reconfigure the routing topology which was modified or changed due to the RLF. 
       FIG.  9 A  shows another scenario where the child nodes and/or UEs may start a timer, for example, timer Tyyy, based on receiving an Upstream RLF notification. While the timer Tyyy is running, Node A may attempt to recover the upstream link by performing cell selection. In the scenario depicted in  FIG.  9   , Node A has successfully found a new parent node (Parent node  2 ) and may initiate the RRC reestablishment procedure. Node A, based on receiving F1-AP* configuration update from the CU of the IAB-donor, may transmit/send Upstream Recovery notification-a notification indicating that the upstream is recovered-to the child IAB-node and/or the UEs. If timer Tyyy has not expired yet, the child IAB-node and/or the UEs that receive the notification may stop timer Tyyy and stay connected with Node A. If the timer expires before receiving Upstream Recovery notification, the child IAB-node and/or the UEs may perform cell selection/RRC reestablishment as shown in  FIG.  8   . In one embodiment, the timer value/configuration may be pre-configured. In another embodiment, the timer value/configuration may be configured by the parent node (e.g., Parent node  1 ) via a dedicated signaling or via a broadcast signaling (e.g., system information, such as MIB, SIB1 or any of the other SIBs). 
     Similar to the previous scenario, in one embodiment, the Upstream RLF notification may be carried by the Adaptation Layer, RLC, MAC, or a physical layer signaling. Additionally, the notifications may be broadcasted via system information (e.g., MIB, SIB1 or any of the other SIBs) or transmitted in a dedicated manner. 
     In yet another embodiment for this scenario, RRC resident in each of the child nodes and/or UEs may start timer Tyyy upon receiving Upstream RLF notification from the lower layers. If the node and/or UE receive a notification indicating the reception of the Upstream RLF notification from lower layers while timer Tyyy is running, the node and/or UE may stop timer Tyyy. If timer Tyyy expires, the node and/or UE may then start timer Txxx and upon selecting a suitable cell while the timer is running, the node and/or UE may stop the timer and initiate transmission of RRCReestablishmentRequest. 
       FIG.  9 B  shows yet another scenario where Node A may start a timer Tzzz upon detecting an RLF. In this scenario, Node A may or may not send the aforementioned Upstream RLF notification to the child IAB-nodes and/or UEs. While the timer Tzzz is running, Node A may attempt to recover the upstream link by performing cell selection. In the scenario depicted in  FIG.  9 B , at the timer Tzzz expiry (cell selection failure), Node A may send a notification (e.g. Upstream Disconnect notification) to the child IAB-nodes/UEs notifying the unsuccessful RLF recovery. In this case, the child IAB-nodes/UEs that receive the notification may start the aforementioned timer Txxx and initiate the cell selection procedure as shown in  FIG.  8   . The notification may be carried by the Adaptation Layer, RLC, MAC, or a physical layer signaling, in a broadcast or a dedicated manner. In one embodiment, the timers Txxx and Tzzz may be the same timer or share same configurations. In another embodiment, the timers Txxx and Tzzz may be different timers or differently configured. 
     Additionally, notifications that an IAB-node provides to its downstream (children/UEs) may not be limited to RLF or RLF recovery. In some embodiments, the IAB-node may inform child nodes and/or UEs of the signal quality (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ)), error rates, and/or any other types of measurements that indicate the radio condition of the upstream. In this case, IAB-nodes and/or UEs may be pre-configured or configured by the network with conditions for initiating cell selection/reestablishment. The notifications may be carried by the Adaptation Layer, RLC, MAC, or a physical layer signaling, in a broadcast or a dedicated manner. 
     In one embodiment, upon receiving one of the notifications from the parent node, the IAB-node and/or UE may send back or respond with an acknowledgement to the parent node, as shown in  FIG.  8   ,  FIGS.  9 A and  9 B . 
       FIG.  10    is a diagram illustrating an example of a radio protocol architecture for the control and user planes in a mobile communications network. The radio protocol architecture for the UE and/or the gNodeB may be shown with 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 responsible for the link between the UE and/or gNodeB over 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 are terminated 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., IP layer) that is terminated at the PDN gateway on the network side, and an application layer that is terminated at the other end of the connection (e.g., far end UE, 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 (i.e., radio bearers) and for configuring the lower layers using RRC signaling between the IAB-nodes and/or the UE and an IAB-donor. 
     Addressing Backhaul Conditions with Autonomous Handover 
       FIG.  11    shows yet another example diagram of a telecommunications system  20  comprising wireless access node  22 - 1 , also known as Donor node  1 ; wireless access node  22 - 2 , also known as Donor node  2 ; IAB-node  24 A, also known as Node A or relay node A; IAB-node  24 B, also known as Node B or relay node B; and child node  1 , also known as child node  30 . The child node  30  may be, for example, a user equipment, UE, or Integrated Access and Backhaul (IAB) node, as previously described. The wireless access node  22 - 1  and wireless access node  22 - 2  may be connected by a wired backhaul link  32 . The other elements of  FIG.  11    may be connected by wireless backhaul links, e.g., the wireless access node  22 - 1  may be connected by wireless backhaul link  34 A to IAB-node  24 A; the wireless access node  22 - 2  may be connected by wireless backhaul link  34 B to IAB-node  24 B; the IAB-node  24 A may be connected by wireless backhaul link  36 A to child node  30 ; and the IAB-node  24 B may be connected by  36 B to child node  30 . 
     The example embodiments and modes of  FIG.  11   - FIG.  15    concern addressing problematic conditions on a wireless backhaul link using an autonomous handover. In general terms, the wireless access node  22 - 1  generates and sends to child node  30  a message which comprises information configured to facilitate a conditional handover of the wireless terminal. As used herein, the terms “handover” and “handoff” may be used interchangeably, and generally involve transfer of a connection or communication, at least partially, from one node or set of nodes to another node. Although the message may be of any appropriate type and bear any suitable name, in an example embodiment and mode described herein the message is a reconfiguration message and, for sake of illustration, is arbitrarily and not exclusively known, and shown in  FIG.  11   , as the conditional handover preparation message  40 . The information comprising such message, e.g., the conditional handover preparation message  40 , includes at least one identity of a target cell and one or more conditions which at least partially enable the wireless terminal to perform a conditional handover autonomously. In some configurations, the identity of a target cell may comprise one of or a combination of: a physical cell identity (PCI), CellIdentity (a cell identifier to unambiguously identify a cell within a PLMN), a PLMN-identity, a tracking area identity, and a RAN area code. As understood herein, the one or more conditions include a reception of a notification from the wireless relay node, e.g., from IAB-node  24 A. Such notification is also known herein and shown in  FIG.  11    as condition notification  42 , and may be notification of a problematic condition on a wireless backhaul link. Upon reception of the condition notification  42 , the child node  30  may perform an autonomous handover, depicted as event  44  in  FIG.  11   . The performance of the autonomous handover  44  is based on, e.g., enabled by using at least, the information provided in the conditional handover preparation message  40 . 
     Various components and functionalities of the nodes shown in  FIG.  11    are further shown in  FIG.  12   .  FIG.  12    shows wireless access node  22 - 1  as comprising central unit  50 - 1  and distributed unit  52 - 1 . The central unit  50 - 1  and distributed unit  52 - 1  may be realized by, e.g., be comprised of or include, one or more processor circuits, e.g., node processor(s)  54 - 1 . The one or more node processor(s)  54 - 1  may be shared by central unit  50 - 1  and distributed unit  52 - 1 , or each of central unit  50 - 1  and distributed unit  52 - 1  may comprise one or more node processor(s)  54 - 1 . Moreover, central unit  50 - 1  and distributed unit  52 - 1  may be co-located at a same node site, or alternatively one or more distributed units  52 - 2  may be located at sites remote from central unit  50 - 1  and connected thereto by a packet network. The distributed unit  52 - 1  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  12   , node processor(s)  54 - 1  of wireless access node  22 - 1  may comprise message generator  60  and handover coordinator  62 . The message generator  60  serves to generate, e.g., the conditional handover preparation message  40  as described herein. As mentioned above, the conditional handover preparation message  40  includes information comprising at least one identity of a target cell and one or more conditions for the wireless terminal performing the conditional handover autonomously. The handover coordinator  62  serves to communicate with the target cell, e.g., with another node which may be involved in the handover, so that suitable information and preparation can be obtained for the handover. In the example scenario described herein, the target cell will be a cell served by wireless access node  22 - 2 . 
     As shown in  FIG.  12    the IAB-node  24 A, also known as wireless relay node  24 A, in an example embodiment and mode comprises relay node mobile termination unit  70 A and relay node distributed unit  72 A. The relay node mobile termination unit  70 A and relay node distributed unit  72 A may be realized by, e.g., by comprised of or include, one or more processor circuits, e.g., relay node processor(s)  74 A. The one or more relay node processor(s)  74 A may be shared by relay node mobile termination unit  70 A and relay node distributed unit  72 A, or each of relay node mobile termination unit  70 A and relay node distributed unit  72 A may comprise one or more relay node processor(s)  74 A. The relay node distributed unit  72 A may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, de-modulation circuitry, and other conventional receiver equipment. 
       FIG.  12    further shows that IAB-node  24 A may comprise radio condition detector  80  and notification generator  82 . Both condition detector  80  and notification generator  82  may be realized or comprised by relay node processor(s)  74 . The notification generator  82  serves to generate the condition notification  42 , based on a condition detected by condition detector  80 . 
     It should be understood that, although not illustrated in  FIG.  12   , the wireless access node  22 - 2  and IAB-node  24 B of  FIG.  11    and of  FIG.  15    may have similar components and functionalities as the wireless access node  22 - 1  and IAB-node  24 A, respectively, but with differently numbered/alphabetized suffixes denoting comparable components. 
       FIG.  12    shows child node  30  as comprising, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment.  FIG.  12    further shows child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, as also comprising node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  48  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. 
     In an example, non-limiting embodiment and mode shown in  FIG.  12   , the child node  30  may include frame/message generator/handler  94  and handover controller  96 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes, including but not limited to the conditional handover preparation message  40  and condition notification  42  described herein. 
     In a most basic example embodiment and mode, a wireless access node of the technology disclosed herein transmits a message which comprises information configured to facilitate a conditional handover of the wireless terminal, the information comprising at least one identity of a target cell and one or more conditions for the wireless terminal performing the conditional handover autonomously, the conditions including a reception of a notification from the wireless relay node. In a most basic example embodiment and mode of the technology disclosed herein, the wireless terminal, e.g., child node  30 , receives such message. Beyond the basic example embodiment and mode mentioned above,  FIG.  13    shows further example, optional, non-limiting, basic acts or steps that may be performed by the wireless access node  22 - 1  of  FIG.  11    and  FIG.  12   . Act  13 - 1  comprises initiating a handover coordination with another node upon occurrence of a predetermined event. In the example scenario described herein, the other node to be involved in the handover is wireless access node  22 - 2 . The handover coordination of act  13 - 1  may be performed by handover coordinator  62 , which works through a wired backhaul link interface to wireless access node  22 - 2 . The predetermined event may be, for example, receipt of a measurement report from the wireless terminal, e.g., from child node  30 , including a measurement regarding a signal received by the wireless terminal from another node, such as wireless access node  22 - 2 . Act  13 - 2  comprises generating the conditional handover preparation message  40  to include the information facilitating the conditional handover  44 . The conditional handover preparation message  40  may be generated, e.g., by message generator  60  of node processor(s)  54 - 1 . Act  13 - 3  comprises sending or transmitting the conditional handover preparation message to child node  30 , e.g., over the wireless backhaul links  34 A and  36 A and thus via IAB-node  24 A. 
     Beyond the basic example embodiment and mode mentioned above,  FIG.  14    shows further example, optional, non-limiting, basic acts or steps that may be performed by child node  30  of  FIG.  11    and  FIG.  12   . Act  14 - 1  comprises receiving a message which comprises information configured to facilitate a conditional handover of the wireless terminal. Such message may be, for example, the conditional handover preparation message  40  described herein, which comprises at least one identity of a target cell and one or more conditions for the wireless terminal performing the conditional handover autonomously. Act  14 - 2  comprises receiving the condition notification  42  from an appropriate node, such as IAB-node  24 A, which advises of the possible need of an autonomous handover. Act  14 - 3  comprises, upon receipt of the condition notification  42 , performing an autonomous handover  44  to another node, e.g., to wireless access node  22 - 2  through IAB-node  24 B. 
     In an example scenario shown in  FIG.  11   , IAB-node  24 A, also known as Node A or wireless access node  24 A, may detect a radio condition, such as a radio link failure, RLF, on the upstream link to its parent node, e.g. wireless access node  22 - 1  or Donor  1 . In the example scenario of  FIG.  11   , the Child Node  30 , which may be an IAB-node or an UE, was configured by the donor-node wireless access node  22 - 1  with a conditional handover, e.g., conditional handover preparation message  40  which may be a reconfiguration with sync, in advance, which allows the child node  30  to autonomously perform a handover to a designated cell when one or more conditions configured by the RRC of the Donor  1  are satisfied. In some configurations, the conditions may include reception of some of the aforementioned notifications from a parent node, such as Upstream RLF notification. When such conditions are met, the Child Node  1 , e.g., child node  30 , may start accessing the designated cell, e.g. Node B/Donor  2 , also called IAB-node  24 B/wireless access node  22 - 2 , and perform a handover procedure. In one example embodiment and mode, the Donor nodes  1  and  2  may be physically collocated or even the same entity. In another example embodiment and mode, these two donor nodes, e.g., wireless access node  22 - 1  and wireless access node  22 - 2 , may be separate nodes, mutually connected by a wired backhaul link, as shown in  FIG.  11   . It is assumed that prior to providing the configuration for the conditional handover to Child node  30 , the two donor nodes wireless access node  22 - 1  and wireless access node  22 - 2  may perform negotiations/coordination with regard to the handover, e.g., act  11 - 3 , described above. 
       FIG.  15    depicts an example message flow for the scenario shown in  FIG.  11   . In the situation of  FIG.  15   , the child node  30  is in connected mode as shown by act  15 - 1 . As act  15 - 3  the currently serving donor node, Donor  1  or wireless access node  22 - 1 , may start a handover coordination with a node serving a potential target cell, e.g., Donor  2  or wireless access node  22 - 2 . The coordination of act  15 - 3  may comprise sharing of identifications of the Child Node  1 , e.g., child node  30 ; security parameters; and radio link configurations. As shown in  FIG.  15   , the coordination of act  15 - 3  may be triggered by act  15 - 2 , e.g., receipt of a measurement report(s) transmitted by the Child Node  1 , wherein the child node  30  reports sufficient signal quality observed from the Node B, e.g., from IAB-node  24 B. 
     After the coordination of act  15 - 3  is completed, as act  15 - 4  the Child Node  30  (in the RRC_CONNECTED state, as indicated by act  15 - 1 ) may receive the conditional handover preparation message  40 . In an example embodiment and mode, the conditional handover preparation message  40  may be a RRCReconfiguration message comprising potential target cells, e.g. the cell served by Node B or IAB-node  24 B, and one or more conditions for an autonomous handover. In the example flow of  FIG.  15   , the conditions may include a reception of the Upstream RLF notification. The other non-limiting examples of conditions may include or comprise signal quality thresholds for the downlink signals from the currently serving node, e.g., Node A=IAB-node  24 A), as well as some of the other aforementioned notifications, such as Upstream Disconnect notification. 
     In the example flow shown in  FIG.  15   , as act  15 - 5  the Node A, e.g., IAB-node  24 A, may detect an RLF on the upstream link, e.g., on wireless backhaul link  32 . The condition on the wireless backhaul link  32  may be detected by the condition detector  80  of IAB-node  24 A. The Node A may then send the Upstream RLF notification  42  to its child nodes/UEs, including the Child node  30 . The condition notification  42  may be generated by notification generator  82 . As optional act  15 - 7 , Child node  30  may send back an acknowledgement. Moreover, due to the configured conditions, as act  15 - 8  the child node  30  may initiate a conditional handover to the configured target cell, e.g., in the example scenario, the cell served by IAB-node  24 B, by performing a random access procedure. The random access procedure in which child node  30  participates comprises, as act  15 - 8 , sending a Random Access Preamble message to IAB-node  24 B and, as act  15 - 9 , receiving a Random Access Response message from IAB-node  24 B. Act  15 - 10  comprises the child node  30  sending a RRCReconfigurationComplete message to the donor of the target cell, e.g., Donor  2  =wireless access node  22 - 2  via Node B =IAB-node  24 B. As act  15 - 11  wireless access node  22 - 2  may use F1-AP* to update the routing configurations at the Node B for the Child Node  1 , e.g., at IAB-node  24 B for child node  30 , and as act  15 - 12  may interact with wireless access node  22 - 1  to report the completion of the conditional handover. The wireless access node  22 - 1  may then release the resources saved for child node  30 . 
     Accordingly, in the example embodiment and mode of  FIG.  11   - FIG.  15   , an IAB-node or a UE may be configured with a conditional handover with conditions, comprising a reception of a notification representing the radio condition of the upstream radio link of the parent node and at least one identification of a target node. Upon receiving such a notification, the IAB-node or the UE may then perform an autonomous handover to the cell served by the target node. 
     Addressing Backhaul Conditions Involving Redundant Connections 
       FIG.  16    shows yet another example diagram of a telecommunications system  20  which, like the telecommunications system  20  of  FIG.  15   , comprises wireless access node  22 - 1 , also known as Donor node  1 ; wireless access node  22 - 2 , also known as Donor node  2 ; IAB-node  24 A, also known as Node A or relay node A; IAB-node  24 B, also known as Node B or relay node B; and child node  1 , also known as child node  30 . The child node  30  may be, for example, a user equipment, UE, or Integrated Access and Backhaul (IAB) node, as previously described. The wireless access node  22 - 1  and wireless access node  22 - 2  may be connected by a wired backhaul link  32 . The other elements of  FIG.  16    may be connected by wireless backhaul links, e.g., the wireless access node  22 - 1  may be connected by wireless backhaul link  34 A to IAB-node  24 A; the wireless access node  22 - 2  may be connected by wireless backhaul link  34 B to IAB-node  24 B; the IAB-node  24 A may be connected by wireless backhaul link  36 A to child node  30 ; and the IAB-node  24 B may be connected by  36 B to child node  30 . 
     The example embodiments and modes of  FIG.  16   - FIG.  20 A ,  FIG.  20 B  concern addressing problematic conditions on a wireless backhaul link using redundant links. In general terms, the wireless access node  22 - 1  generates and sends to child node  30  at message which comprises information configured to activate plural signaling data path, such as first signaling data path SRB_f and second signaling data path SRB_s shown in  FIG.  16   . The first signaling data path SRB_f is established between wireless access node  22 - 1  and the wireless terminal also known as child node  30 , and has its signaling data routed via wireless access node  22 - 1  and IAB-node  24 A. In one configuration, the second signaling data path SRB_s may be established between wireless access node  22 - 2  and child node  30  and has its signaling data relayed by IAB-node  24 B. In another configuration (not shown in  FIG.  16   ), the second signaling data path SRB_s may be established directly established between wireless access node  22 - 2  and child node  30  without being relayed by an IAB-node. It should be noted that either of the first or second signaling data path may be a master signaling radio bearer, e.g., the signaling data bearer that is established first, and the other signaling data path may be a secondary signaling radio bearer that may be added after the master signaling radio bearer is established. 
     Although the message(s) configured to activate the plural signaling data paths may be of any appropriate type and bear any suitable name, in an example embodiment and mode described herein the message is a reconfiguration message and, for sake of illustration, is arbitrarily and not exclusively known, and shown in  FIG.  16   , as the plural path activation message  140 . The plural path activation message  140  is received by the child node  30 , after which both the first signaling data path SRB_f and the second signaling data path SRB_s are activated. Should the child node  30  thereafter receive a notification from the IAB-node  24 A, the child node  30  may generate a report message (also referred as a failure information message) and transmit the message through the second signaling path SRB_s. The report message may include information based on the notification, and the notification may be based on a radio condition detected on the first signaling data path. 
     Various components and functionalities of the nodes shown in  FIG.  16    are further shown in  FIG.  17   . Components of  FIG.  17    which have similar names to the components of  FIG.  12    also have comparable function.  FIG.  17    shows wireless access node  22 - 1  as comprising central unit  50 - 1  and distributed unit  52 - 1 . The central unit  50 - 1  and distributed unit  52 - 1  may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., node processor(s)  54 - 1 . The one or more node processor(s)  54 - 1  may be shared by central unit  50 - 1  and distributed unit  52 - 1  or each of central unit  50 - 1  and distributed unit  52 - 1  may comprise one or more node processor(s)  54 - 1 . Moreover, central unit  50 - 1  and distributed unit  52 - 1  maybe co-located at a same node site, or alternatively one or more distributed units  52 - 2  may be located at sites remote from central unit  50 - 1  and connected thereto by a packet network. The distributed unit  52 - 1  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  17   , node processor(s)  54 - 1  of wireless access node  22 - 1  may comprise message generator  60 ; plural path controller  162 ; and report handler  163 . The message generator  60  serves to generate, e.g., plural path activation message  140  as described herein. The plural path controller  162  serves, e.g., to activate the plural paths, including first signaling data path SRB_f and second signaling data path SRB_s. The report handler  163  is configured to receive and process a report from child node  30  which is based on a notification representing a radio condition detected on one of the signaling data paths. 
     As shown in  FIG.  17    the IAB-node  24 A, also known as wireless relay node  24 A, in an example embodiment and mode comprises relay mobile termination unit  70 A and relay distributed unit  72 A. The relay mobile termination unit  70 A and relay distributed unit  72 A may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., relay node processor(s)  74 A. The one or more relay node processor(s)  74 A may be shared by relay mobile termination unit  70 A and relay distributed unit  72 A, or each of mobile termination unit  70 A and distributed unit  72 A may comprise one or more relay node processor(s)  74 A. The relay node distributed unit  72 A may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
       FIG.  17    further shows that IAB-node  24 A may comprise radio condition detector  80  and notification generator  82 . Both condition detector  80  and notification generator  82  may be realized or comprised by relay node processor(s)  74 . The notification generator  82  serves to generate the condition notification  42 , based on a condition detected by condition detector  80 . 
     It should be understood that, although not illustrated in  FIG.  17   , the wireless access node  22 - 2  and IAB-node  24 B of  FIG.  16    and of  FIG.  17    may have similar components and functionalities as the wireless access node  22 - 1  and IAB-node  24 A, respectively, but with differently numbered/alphabetized suffixes denoting comparable components. 
       FIG.  17    shows child node  30  as comprising, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment.  FIG.  17    further shows child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, as also comprising node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  48  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. 
     In an example, non-limiting embodiment and mode shown in  FIG.  17   , the child node  30  may include frame/message generator/handler  94 ; path controller  196 ; and report generator  198 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes, including but not limited to incoming messages such as the plural path activation message  140  and condition notification  42  described herein, as well as outgoing messages such as a report message  199  generated by report generator  198 . The path controller  196  works in conjunction with establishing, activating, and deactivating signaling data paths in which child node  30  participates, such as first signaling data path SRB_f and second signaling data path SRB_s. 
     In a most basic example embodiment and mode, a wireless access node of the technology disclosed herein transmits at least one message which activates a first signaling data path and a second signaling data path. The first signaling data path, e.g., first signaling data path SRB_f, and the second signaling data path, e.g., second signaling data path SRB_s, are both established between the wireless access node, e.g., wireless access node  22 - 1 , and the wireless terminal, e.g., child node  30 . Signaling data on the first signaling data path is relayed by a wireless relay node, e.g., IAB-node  24 A. In a most basic example embodiment and mode of the technology disclosed herein, the wireless terminal, e.g., child node  30 , receives such message. Further, the child node  30  may, as a condition on the first signaling data path SRB_f arises, processes a notification received from the wireless relay node and, upon reception of the notification, transmit a report message to the wireless access node on the second signaling data path. The report message comprises information based on the notification, and the notification is based on a radio condition detected on the first signaling data path. 
     Beyond the basic example embodiment and mode mentioned above,  FIG.  18    shows further example, non-limiting, basic acts or steps that may be performed by the wireless access node  22 - 1  of  FIG.  16    and  FIG.  17   . Act  18 - 1  comprises generating the at least one message, e.g., the message(s) being configured to activate a first signaling data path and a second signaling data path. As mentioned above, the first signaling data path and the second signaling data path are established between the wireless access node and the wireless terminal, and the signaling data on the second signaling data path is relayed by a wireless relay node. The message(s) of act  18 - 1 , which may be termed as the plural path activation message(s)  140 , may be generated by message generator  60 . Act  18 - 2  comprises transmitting the at least one message(s), e.g., the plural path activation message  140 , to the child node  30 . The plural path activation message  140  may be transmitted by the transmitter circuitry  57  of wireless access node  22 - 1 . 
     A problematic condition may thereafter arise, and for sake of example is illustrated herein as a radio link failure occurring on first signaling data path SRB_f. Act  18 - 3  comprises the wireless access node  22 - 1  receiving a report from child node  30 , and in particular receiving a report message comprising information based on a notification received by child node  30 . The notification is preferably based on a radio condition detected on the first signaling data path. Such notification may be the condition notification  42  described herein. The report message, e.g., report message  199 , may be received by receiver circuitry  58  and handled by report handler  163 . Act  18 - 4  comprises determining and/or performing an action based on the report message. An example of such an action for act  18 - 4  may be, for example, deactivating the first signaling data path SRB_f. 
     Beyond the basic example embodiment and mode mentioned above,  FIG.  19    shows further example, non-limiting, basic acts or steps that may be performed by child node  30  of  FIG.  16    and  FIG.  17   . Act  19 - 1  comprises receiving a message which activates a first signaling data path and a second signaling data path, e.g., the first signaling data path SRB_f and the second signaling data path SRB_s. Act  19 - 2  comprises receiving a notification of a condition detected on the first signaling data path SRB_f. The message of act  19 - 1  may be the plural path activation message  140  described herein, generated by wireless access node  22 - 1 ; the message of act  19 - 2  may be the condition notification  42  described herein, generated by IAB-node  24 A. The messages of both act  19 - 1  and act  19 - 2  may be received through receiver circuitry  88  and processed by frame/message generator/handler  94 . Act  19 - 3  comprises, upon reception of the notification of act  19 - 2 , transmitting a report message to the wireless access node. The report message comprises information based on the notification; the notification is based on a radio condition detected on the first signaling data path. 
     In an example scenario shown in  FIG.  16   , child node  30 , e.g., Child Node  1 , which may be an IAB-node or a UE, establishes redundant connections, i.e., multiple connections or simultaneous connections, such as Dual Connectivity (DC), for at least the signaling radio bearer (SRB), and possibly the data radio bearers (DRBs) as well. In the scenario of  FIG.  16   , the SRB may be carried by two or more separate paths: (1) signaling data path SRB_f which includes wireless access node  22 - 1 , IAB-node  24 A, and child node  30 , e.g., Donor  1 -Node A-Child Node  1 (SRB_f) and (2) signaling data path SRB_s which involves wireless access node  22 - 1 , wireless access node  22 - 2 , IAB-node  24 B, and  30 , e.g., Donor 1 -Donor 2 -Node B-Child Node  1 (SRB_s). In one configuration, the wireless access node  22 - 1 , e.g., Donor  1 , may act as a master node while wireless access node  22 - 2 , e.g., Donor  2 , may behave as a secondary or slave node. In another configuration, the wireless access node  22 - 1 , e.g., Donor  1 , may act as a secondary or slave node while wireless access node  22 - 2 , e.g., Donor  2 , may behave as a master node. In one configuration, signaling data may duplicated and transmitted on the multiple paths, e.g., on first signaling data path SRB_f and second signaling data path SRB_s. In another configuration, packets for signaling data are split into the two paths, e.g., first signaling data path SRB_f and second signaling data path SRB_s, for increased throughput. 
     After establishing an RRC connection to wireless access node  22 - 1 , e.g., to Donor  1 , the Child Node  30  may be provisioned with a configuration with a secondary cell served by the wireless access node  22 - 2  and IAB-node  24 B. Following the configuration, the Child Node  30  may use the multiple paths for transmitting/receiving signaling bearer (and possibly data bearers). In the present example embodiment and mode, at least one of the parent nodes of the Child node  30  may send some of the aforementioned notifications representing the radio condition of its upstream radio link. That is, either IAB-node  24 A or IAB-node  24 B may send such notifications, as and when the radio condition(s) occur. For example, similar to the previously disclosed embodiments, when detecting a radio link failure (RLF) on the upstream radio link of IAB-node  24 A, the IAB-node  24 A may send the Upstream RLF notification to its child nodes including the Child Node  30 . In this case, the Child Node  30  may attempt to report this event to at least one of the serving donors using a path not affected by the RLF. In the scenario shown in the  FIG.  16   , the Child Node  30  may use the path SRB_s to send the report to the wireless access node  22 - 2  through the IAB-node  24 B. In some example configurations, the report may be also conveyed to the wireless access node  22 - 1 , e.g., to Donor  1 , which may decide to reconfigure updated redundant connections to the Child Node  30 . 
       FIG.  20 A  shows an example message flow for the scenario shown in  FIG.  16   , where the Child Node  30  may first establish an RRC connection with the Donor  1 , which results in setting up the SRB_f. While the Child node  30  is in RRC_CONNECTED (depicted as act  20 - 1  in  FIG.  20 A ), the wireless access node  22 - 1  may decide to configure an additional connection and, as represented by act  20 - 2 , start a coordination with wireless access node  22 - 2 . It should be noted that, similar to the previously disclosed embodiment, the wireless access node  22 - 1  and the wireless access node  22 - 2  may be physically collocated or separated entities, or even the same entity. As act  10 - 3  wireless access node  22 - 1  may send to the Child Node  30  RRCReconfiguration comprising a configuration to add a new SRB (SRB_s) and an identity of the cell to serve SRB_s, the identity of the cell served by IAB-node  24 B. As act  20 - 4  Child Node  30  may then acknowledge to RRCReconfiguration by sending a RRCReconfigurationComplete message. As act  20 - 5  wireless access node  22 - 2  may use F1-AP* to update the routing configurations at the Node B, e.g., at IAB-node  24 B, for the Child Node  30 . 
     As act  20 - 6  the child node  30  may initiate a random access procedure by sending a Random Access Preamble message, and as act  20 - 7  may receive a Random Access Response message. The random access procedure of act  20 - 6  and act  207  serves to synchronize child node  30  to the IAB-node  24 B. 
     Eventually, as act  20 - 8 , IAB-node  24 A may detect a specified radio condition on its upstream link. In the example scenario shown in  FIG.  20 A , the specified upstream condition may be a radio link failure (RLF), but could be other radio link condition(s) as well. Act  20 - 9  comprises IAB-node  24 A sending a notification, e.g., condition notification  42 , to child node  30 . In the example scenario shown in  FIG.  20 A , in which the specified upstream condition may be a radio link failure (RLF), the condition notification  42  may be an Upstream RLF notification which may be sent to child nodes/UEs of IAB-node  24 A, including but not necessarily limited to Child Node  30 . As act  20 - 10  Child Node  30  may send back an acknowledgement of the condition notification  42  to IAB-node  24 A. Further, upon receipt of the notification of act  20 - 9 , e.g., upon receipt of condition notification  42 , as act  20 - 11  the child node  30  may generate and transmit a report message reporting the RLF occurring on the path for SRB_f. The report message  199  may be generated by report generator  198  upon receipt of the condition notification  42 . 
     In one example embodiment and mode shown in  FIG.  20 A , the report message of act  20 - 11  is an RRC message of act  20 - 11  directed to the Donor  1 , e.g., to wireless access node  22 - 1 . As Act  20 A- 12 , the Donor  2 , e.g., wireless access node  22 - 2 , may transfer the report message to the Donor  1  using an inter-node message on the wired backhaul link  32 . Upon receipt of the report message, the Donor  1  may coordinate with the Donor  2  to deactivate the problematic signaling data path (e.g. the first signaling data path SRB_f), as shown in Act  20 A- 13 . In one implementation, the wireless access node  22 - 1  aka Donor  1 , now recognizing that SRB_f is torn down, may reconfigure the Child Node  30  with a new SRB configuration, e.g. releasing SRB_f. by sending another RRCReconfiguration. In parallel, wireless access node  22 - 1  may also use the F1-AP* to update the routing configuration of the Child Node  30 , if the Child Node  30  is an IAB-node. 
     In another example embodiment and mode shown in  FIG.  20 B , the report message  42  of act  20 B- 11  is addressed to the parent node, e.g., IAB-node  24 B using the Adaptation Layer, the RLC Layer, the MAC Layer or the physical layer signaling. Then, as act  20 B- 12 , the parent node IAB-node  24 B may convey the report message using a protocol, e.g., F1-AP*, to the Donor  2 , e.g., to wireless access node  22 - 2 . As act  20 B- 13  the wireless access node  22 - 2  may redirect the report message to the Donor  1 , e.g., wireless access node  22 - 1 , using an inter-node message on the wired backhaul link  32 . Similar to the previous embodiment and mode shown in  FIG.  20 A , in one implementation, the wireless access node  22 - 1  aka Donor  1 , now recognizing that SRB_f is torn down, may reconfigure the Child Node  30  with a new SRB configuration, e.g. releasing SRB_f. by sending another RRCReconfiguration. In parallel, wireless access node  22 - 1  may also use the F1-AP* to update the routing configuration of the Child Node  30 , if the Child Node  30  is an IAB-node. 
     In either the example embodiment and mode of  FIG.  20 A  or the example embodiment and mode of  FIG.  20 B , upon receipt of the report message  199  the wireless access node  22 - 1  may take appropriate action, such as for example, deactivating the first signaling data path SRB_f. 
     In one example embodiment and mode, the Child Node is preconfigured to send the report message upon receiving one of designated notifications from the parent node, e.g., from IAB-node  24 A. In another example embodiment and mode, the Child Node is configured by an IAB-donor node to send the report message upon receiving one of designated notifications. In this latter case, RRCReconfiguration may be used to configure the designated notifications for sending report message. 
     Accordingly, in the example embodiment and mode of  FIG.  16   - FIG.  20 A  and  FIG.  20 B , an IAB-node or a UE configured with multiple radio paths for the signaling radio bearer(s) may receive from one parent node a notification representing the radio condition of the upstream radio link of one of the parent nodes. The IAB-node or the UE may use one or more other radio paths to send a report message reporting the radio condition to at least one IAB-donor node. The IAB-donor node that receives the report message may initiate reconfiguration for updated topology and/or routing of the relay network accordingly. 
     Preventing Routing Loops in Cell Selection 
     As disclosed in the aforementioned embodiments and modes, the MT part of an IAB-node may perform a cell selection procedure upon detecting a Radio Link Failure, RLF, on its upstream radio link.  FIG.  21    illustrates an example scenario, where Node  24 -A- 21 , an IAB-node, detects an RLF on the backhaul radio link to the current parent node (Parent node  22 -P 1 - 21 ). Eventually Node  24 -A- 21  may start to perform the cell selection procedure, attempting to find a suitable cell with sufficient signal quality. As a result of the cell selection, the MT part of Node  24 -A- 21  may be able to find the original parent node (Parent node  24 -P 1 - 21 ) that served before the RLF (Cell Selection A in  FIG.  21   ). In this case, Node  24 -A- 21  may initiate the RRC reestablishment procedure shown in  FIG.  22 A  by sending RRCReestablishmentRequest to the IAB-donor  22 -D- 21  via Parent node  22 -P 1 - 21 , in order to recover the broken upstream link. Upon receiving the RRCReestablishmentRequest, the IAB-donor  22 -D- 21  may retrieve the connection context (e.g. security keys, etc.) for the MT part of Node  24 -A- 21 , and then may respond to Node  24 -A- 21  with RRCReestablishment, Node  24 -A- 21  may complete the RRC reestablishment procedure by sending RRCReestablishmentComplete. 
     If Node  24 -A- 21  fails to find the original parent and selects another parent node (e.g. Cell selection B to Parent node  24 -P 2 - 21  in  FIG.  21   ), the MT part of Node  24 -A- 21  may initiate the RRC reestablishment procedure, similar to the cell selection case of  FIG.  22 A . In this case, if Parent node  24 -P 2 - 21  is connected to the same IAB-donor  22 -D- 21 , or if Parent node  24 -P 2 - 21  is connected to a different IAB-donor (not illustrated) and the different IAB-donor is able to retrieve the connection context for the MT part of Node  24 -A- 21 , the RRC establishment procedure may be successfully performed in a way similar to the flow shown in  FIG.  22 A . If the different IAB-donor fails to retrieve the connection context, the different IAB-donor and Node  24 -A- 21  may follow the message flow shown in  FIG.  22 B  where the IAB-donor may respond back to Node  24 -A- 21  with RRCSetup, to setup a brand-new RRC connection, and in turn, Node  24 -A- 21  may send RRCSetupComplete, followed by the security procedure, similar to the flow shown in  FIG.  6 B . 
     It should be noted that, upon detecting the RLF, Node  24 -A- 21  may or may not immediately transmit the aforementioned upstream RLF notification to its child nodes (e.g. Child node  30 - 1 - 21  in  FIG.  21   ). Transmission of the upstream RLF notification may be determined based on the previously disclosed embodiments. 
       FIG.  21    also serves to illustrate a potential problematic situation wherein, during the cell selection procedure, Node  24 -A- 21  ends up with discovering downlink broadcast transmission (synchronization signals, system information, etc.) from the DU parts of its child nodes (e.g., Child node  30 - 1 - 21 , as shown by the arrow labeled “Cell selection C”) or from the DU parts of its grandchild nodes (Child node  30 - 2 - 21 , as shown by the arrow labeled “Cell selection D”). In such a situation, without proper configurations, Node  24 -A- 21  may not be able to recognize that the downlink broadcast transmission is indeed from a (grand)child IAB-node in its own downstream path. As a result, if the signal quality is sufficient, Node  24 -A- 21  may choose to camp on the (grand)child node, and eventually any signaling (e.g. RRC, F1AP, etc.) addressed to the IAB-donor would be circulated in a closed loop. A closed loop in a relay network may be referred as a “routing loop”, and the network topology that forms a routing loop may be referred as loop topology. 
     Various embodiments and modes described herein are configured to address and/or combat the routing loop problem.  FIG.  23    shows a telecommunication system  20 - 23  which generically addresses a potential routing loop situation using routing loop prevention information that may be utilized by an Integrated Access and Backhaul (IAB) node in order to prevent the node from selecting a cell of one of its children or grandchildren nodes. Components of  FIG.  23    which have similar names to the components of  FIG.  12    and/or  FIG.  17    also have comparable function, unless otherwise noted or clear from the context. 
       FIG.  23    shows wireless access node  22 - 23 , also known as IAB-donor node  22 - 23 , as comprising central unit  50  and distributed unit  52 . The central unit  50  and distributed unit  52  may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., node processor(s)  54 - 1 . The one or more node processor(s)  54 - 1  may be shared by central unit  50  and distributed unit  52  or each of central unit  50  and distributed unit  52  may comprise one or more node processor(s)  54 . Moreover, central unit  50  and distributed unit  52  maybe co-located at a same node site, or alternatively one or more distributed units  52  may be located at sites remote from central unit  50  and connected thereto by a packet network. The distributed unit  52  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  23   , node processor(s)  54  of wireless access node  22 - 23  may comprise routing loop prevention information generator  200 . The routing loop prevention information generator  200  generates routing loop prevention information that, when received by an Integrated Access and Backhaul (IAB) node, may be used by the Integrated Access and Backhaul (IAB) node to avoid selecting any of its children or grandchildren nodes in a cell selection procedure. Differing types of routing loop prevention information are described herein in differing embodiments and modes. For example, in the example embodiment and mode of  FIG.  23 C  the routing loop prevention information is configuration information, whereas in the example embodiment and mode of  FIG.  33   - FIG.  37    the routing loop prevention information is carried by system information.  FIG.  23    further shows that the transmitter circuitry  57  of wireless access node  22 - 23  may transit a signal or message  202  comprising the routing loop prevention information, e.g., routing loop prevention information message  202 , over a radio interface to other Integrated Access and Backhaul (IAB) nodes. 
     As shown in  FIG.  23    the IAB-node  24 - 23 , also known as wireless relay node  24 - 23 , in an example embodiment and mode comprises relay mobile termination unit  70  and relay distributed unit  72 . The relay mobile termination unit  70  and relay distributed unit  72  may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., relay node processor(s)  74 . The one or more relay node processor(s)  74  may be shared by relay mobile termination unit  70  and relay distributed unit  72 , or each of mobile termination unit  70  and distributed unit  72  may comprise one or more relay node processor(s)  74 . The relay node distributed unit  72  may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
       FIG.  23    further shows that IAB-node  24 - 23  may comprise cell selection procedure controller  204 . The cell selection procedure controller  204  serves to initiate and perform a cell selection procedure when the IAB node  24 - 23  has detected or experienced, e.g., a radio link failure (RLF), and therefore needs to select another cell or, if the RLF is temporary, attempt to re-select the same cell if able to do so. In addition, the IAB node  24 - 23  comprises cell selection routing loop prevention controller  206 . The cell selection routing loop prevention controller  206  may comprise or be included in cell selection procedure controller  204 , which may in turn be realized or comprised by relay node processor(s)  74 . 
       FIG.  23    shows child node  30  as comprising, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment.  FIG.  23    further shows child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, as also comprising node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  48  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. 
     In an example, non-limiting embodiment and mode shown in  FIG.  23   , the child node  30  may include frame/message generator/handler  94 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes. 
       FIG.  24    shows example, representative acts or steps performed by the wireless access node  22 - 23  of  FIG.  23   . Act  24 - 1  comprises including routing loop prevention information for a cell selection procedure in a message. The routing loop prevention information may be generated, for example, by node processor(s)  54  and the routing loop prevention information generator  200  in particular. Alternatively, the routing loop prevention information may be generated by a network entity, such a network server that comprises either the radio access network or a core network. In the event that the routing loop prevention information is generated by a network server, the node processor(s)  54  may serve to include the server-generated routing loop prevention information into a routing loop prevention information message. Act  24 - 2  comprises transmitting the routing loop prevention information message to a wireless relay node, such as in routing loop prevention information message  202 , for example. 
       FIG.  25    shows example, representative acts or steps performed by the IAB node  24 - 23  of  FIG.  23   . Act  25 - 1  comprises receiving routing loop prevention information, e.g., receiving routing loop prevention information message  202 . Act  25 - 2  comprises using the routing loop prevention information in a cell selection procedure to select a cell as a candidate. The routing loop prevention information precludes the IAB node  24 - 23  from selecting a cell of one of its child or grandchild nodes. 
     Various example embodiments and modes generically covered by the example embodiment and mode of  FIG.  23    are now further described. In the ensuing descriptions of the nodes of the telecommunications systems of the further example embodiments and modes, any suffixes affixed to node descriptors are done so for sake of simplicity of reference, it being understood that such nodes are still subsumed under the general and generic embodiment and mode and that comments directed to such suffixed node appellations are not necessarily and generally are not confined to that particular example embodiment and mode. Moreover, it should be understood that features and/or components of the various example embodiments and modes and implementations described herein may be combined with one another. 
     Preventing Routing Loops in Cell Selection: Using Configuration Parameter(s) 
     In order to prevent a routing loop from happening, in some example embodiments and modes illustrated in  FIG.  26 A  and  FIG.  26 B , the routing loop prevention information may be configuration information. Accordingly, an IAB-node  24 - 26  (e.g., a node such as  24 -A- 21  of  FIG.  21    or IAB node  24 - 23  of  FIG.  23   ) may be configured with configuration parameters  210  to provide guidelines (or policies, rules, restrictions, etc.) to help the IAB-node  24 - 26  to perform cell selections after an event such as an RLF. 
     In the example implementation of  FIG.  26 A  the configuration parameters may be generated by routing loop prevention information generator  200  of wireless access node  22 - 26 A, and may be included in the routing loop prevention information message  202  provided to an IAB-node  24 - 26  while the IAB-node is connected with IAB-donor  22 - 26 A (e.g., before an RLF). In one example configuration or implementation shown in  FIG.  26 A , the configuration parameters  210  may be generated by the CU part of the IAB-donor  22 - 26  and transmitted by its DU part via (broadcast or dedicated) signaling, such as RRC and F1AP. 
     In another example implementation shown in  FIG.  26 B  the configuration parameters  210  may be generated and transmitted by a network entity, such as a network server  220 . In an example embodiment and mode, the network entity  220  may comprise server configuration parameter(s) generator  222 , which may comprise or be realized by processor circuitry, and network server interface  224 . The server processor circuitry or server configuration parameter(s) generator  222  is configured to generate routing loop prevention information for a cell selection procedure in a message. The interface  224  is configured to transmit the routing loop prevention information message through a radio access network to a wireless relay node. The routing loop prevention information may be generated by a configuration parameter generator  222  of the network server  220  and transmitted to wireless access node  22 - 26 B via IP data packets. The wireless access node  22 - 26 B may then include the routing loop prevention information which was generated by network server  220  in the routing loop prevention information message  202 . In the example embodiment and mode of  FIG.  26 B , the CU of wireless access node  22 - 26 B may thus serve as a routing loop prevention information message generator  200 B. The configuration parameters that were generated by the server configuration parameter(s) generator  222  of network entity  220  may thus be included in a routing loop prevention information message by message generator  200 B, which may comprise the CU part of the IAB-donor  22 - 26 B, and be transmitted by the DU part of wireless access node  22 - 26 B via (broadcast or dedicated) signaling, such as RRC and F1AP. The IAB-node  24 - 26  that receives the configuration parameters may save them in its storage and may make use of them upon an event such as an RLF. 
     In one configuration or implementation of the example embodiments and modes such as  FIG.  26 A  and  FIG.  26 B , for example, the configuration parameters may comprise a “whitelist” of cell/node identities, which white-listed cell/node identities the IAB-node  24 - 26  may be allowed to select during the cell selection procedure. The cell/node identities may be Physical Cell IDs (PCIs), NR Cell Identities (CellIdentities or NCIs), NR Cell Global Identifiers (NCGIs), gNB identifiers (gNB IDs), Global gNB identifiers (all specified in 3GPP TS 38.300, all existing versions thereof being incorporated herein by reference), or any other identifiers to identify cells/nodes. During RRC_CONNECTED state, the IAB-donor such as wireless access node  22 - 26 A of  FIG.  26 A  or a network entity such as network entity  220  of  FIG.  26 B  may generate a whitelist  210 -WL for the IAB-node, which may include identities of cells/nodes near by the IAB-node and may exclude the identities of cells served by the DU parts of the IAB-node&#39;s (grand)child nodes. The whitelist  210 -WL may be updated and sent to the IAB-node as necessary. For example, when an IAB-node nearby IAB node  24 - 26  (the nearby Integrated Access and Backhaul (IAB) node not being illustrated) becomes a (grand)child node of IAB node  24 - 26 , the cell/node identity of the nearby IAB-node may be removed from the whitelist (if already included) and the updated whitelist may be sent to IAB node  24 - 26 . Likewise, when a (grand)child node of IAB node  24 - 26  hands over to another IAB-node and no longer is a (grand)child node of IAB node  24 - 26 , cell/node identity for such an IAB-node may now be added to the whitelist to be sent to IAB node  24 - 26 . In one configuration, upon an update the entire whitelist  210 -WL may be delivered to IAB node  24 - 26 . Additionally or alternatively, only updated parts of the whitelist may be delivered (such as a “to add”, “to modify” or “to remove” list). 
     In a case that the whitelist  210 -WL comprises a list of PCIs (or one or more ranges of PCIs), upon an RLF the MT part of IAB node  24 - 26  may initiate the cell selection procedure, where the MT part attempts to acquire synchronization signals, such as Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS), from neighbor cells. If the PCI decoded from the synchronization signals broadcasted by one of the neighbor cells is included in the whitelist  210 -WL, the MT part may proceed to further acquiring system information blocks (such as MIB and SIB1) from the cell. Otherwise, the MT part of Node A may consider the cell as not a candidate (“not suitable” or “barred”) and continue the cell selection process by searching for other cells. Meanwhile, in a case that the whitelist comprises a list of CellIdentity fields, the MT part of Node A may acquire the synchronization signals, MIB and SIB1, and if a Cellldentity(s) contained in SIB1 is included in the whitelist, the cell selection may be successfully completed. If the Cellldentity(s) is not in the whitelist, the MT part of Node A may continue the cell selection process, searching for other cells. 
     In an example, non-limiting implementation, the whitelist  210 -WL may be a prioritized list. In such prioritized case, if IAB node  24 - 26  Node A finds a low-priority cell, it may continue to find higher priority cells in the whitelist  210 -WL. In one configuration, cells served by IAB-nodes/IAB-donor may of higher priority than cells with no IAB capabilities. 
     In another configuration of the example embodiment and mode, the configuration parameters may comprise a “blacklist”  200 -BL of cell/node identities, which the IAB-node  24 - 26  should avoid during cell selections. Similar to the previous configuration, the cell identities may be Physical Cell IDs (PCIs), NR Cell Identities (Cellldentitys or NCIs), NR Cell Global Identifiers (NCGIs), gNB identifiers (gNB IDs), Global gNB identifiers, or any other identifies to identify cells/nodes. During RRC_CONNECTED state, the IAB-donor such as wireless access node  22 - 26 A of  FIG.  26 A  or a network entity such as network entity  220  of  FIG.  26 B  may generate a blacklist  200 -BL for the IAB-node  24 - 26 , which may include identities of cells served by (grand)child nodes of the IAB-node of concern. The blacklist  200 -BL may further comprise identities of nearby cells served by nodes with no IAB capabilities. The blacklist may be updated and sent to the IAB-node  24 - 26  as necessary. For example, when another IAB-node (not illustrated) which is nearby IAB node  24 - 26  becomes a (grand)child node of IAB node  24 - 26  , the cell/node identity of the nearby IAB-node may be added to the blacklist and the updated blacklist  200 -BL may be sent to IAB node  24 - 26 . Likewise, when a (grand)child node of IAB node  24 - 26  hands over to another IAB-node and no longer is a (grand)child node of IAB node  24 - 26 , the cell/node identity of such an IAB-node may be removed from the blacklist and an updated blacklist may be sent to IAB node  24 - 26 . Similar to the whitelist  200 -WL, the entire blacklist  200 -BL or only updated parts of the blacklist (such as a “to add”, “to modify” or “to remove” list) may be delivered. 
     In a case that the blacklist  200 -BL comprises a list of PCIs (or one or more ranges of PCIs), upon an RLF the MT part of IAB node  24 - 26  may initiate the cell selection procedure, where the MT part attempts to acquire synchronization signals, such as Primary Synchronization Signal (PSS) and Secondary Synchronization Signal (SSS), from neighbor cells. If the PCI decoded from the synchronization signals broadcasted by one of the neighbor cells is not included in the blacklist  200 -BL, the MT part may proceed to further acquiring system information blocks (such as SIB1) from the cell. Otherwise, the MT part of IAB node  24 - 26  may consider the cell as not a candidate (“not suitable” or “barred”) and continue the cell selection process by searching for other cells. Meanwhile, in a case that the blacklist comprises a list of CellIdentity fields, the MT part of IAB node  24 - 26  may acquire the synchronization signals, MIB and SIB1, and if a Cellldentity(s) contained in SIB1 is not included in the blacklist  200 -BL, the cell selection may be successfully completed. If the Cellldentity(s) is in the blacklist  200 -BL, the MT part of IAB node  24 - 26  may continue the cell selection process, searching for other cells. 
     In addition, the blacklist  200 -BL may further include some topology information associated with cell/node identities. That is, the topology information may indicate parent-child relationship among entries of the blacklist  200 -BL. For example, in the case of  FIG.  21   , after Child node  30 - 2 - 21  is attached to the relay network, the blacklist  200 -BL may indicate Child node  30 - 2 - 21  as a direct child of Node  24 -A- 21  and Child node  30 - 2 - 21  as a direct child of Child node  30 - 1 - 21 . A blacklist  200 -BL with topology information may be referred as a routing table, or a topology table. 
     Either the whitelist  200 -WL or the blacklist  200 -BL may be carried via RRCReconfiguration message to the MT part of an IAB-node as shown in the example message flow of  FIG.  27   . Alternatively, either the whitelist  200 L or the blacklist  200 -BL may be carried via an F1-AP message to the DU part of an IAB-node, then handed to a MT part collocated in the IAB-node. The MT part of IAB node  24 - 26  may save the list, e.g., either whitelist  200 -WL or blacklist  200 -BL, and upon a radio link failure (RLF) the MT part of the IAB node  24 - 26  may use the latest list, either whitelist  200 -WL or blacklist  200 -BL, for cell selections. 
       FIG.  28    shows example, representative acts or steps which may be performed by the IAB node  24 - 26  of  FIG.  26 A  and  FIG.  26 B . Act  28 - 1  comprises receiving a signaling message comprising configuration parameters for the cell selection procedure. Act  28 - 2  comprises initiating the cell selection procedure and in the cell selection procedure making a decision to select a cell as the candidate based on the configuration parameters. 
       FIG.  29    shows example, representative acts or steps which may be performed by the wireless access donor node  22 - 26 A of  FIG.  26 A . Act  29 - 1  comprises generating a signaling message comprising configuration parameters for a cell selection procedure. Act  29 - 2  comprises transmitting, to the wireless relay node, the signaling message to enable the wireless relay node to make a decision to select a cell as a candidate based on the configuration parameters. 
       FIG.  30    shows example, representative acts or steps which may be performed by the wireless access donor node  22 - 26 B of  FIG.  26 B . Act  30 - 1  comprises including the routing loop prevention information received from network entity  220  in a signaling message comprising for a cell selection procedure. Act  30 - 2  comprises transmitting, to the wireless relay node, the signaling message to enable the wireless relay node to make a decision to select a cell as a candidate based on the configuration parameters. 
       FIG.  31    shows example, representative acts or steps which may be performed by the network entity  220  of  FIG.  26 B . Act  31 - 1  comprises generating routing loop prevention information for a cell selection procedure in a message. Act  31 - 2  comprises transmitting the routing loop prevention information message through a radio access network to a wireless relay node. 
     In the above configurations of the example embodiments and modes, such as  FIG.  26 A  and  FIG.  26 B , for example, the configuration parameters  210  may further comprise one or more radio-related parameters, such as frequency band lists, which the MT part of the IAB-node  24 - 26  may be directed to search on or not to search on upon an RLF. 
     Moreover, in the foregoing example embodiments and modes such as  FIG.  26 A  and  FIG.  26 B , validity of the configuration parameters  210  may be limited in time. In other words, for example, once configured, the configuration parameters  210  may be valid within a (pre)configured time period. The MT part of an IAB-node such as IAB node  24 - 26  may start a timer, e.g., configuration parameter(s) validity timer  230  as shown in  FIG.  32   , and may invalidate the configuration parameters upon the timer expiring. In one example implementation, the timer  230  is started when the configuration parameters are configured. In another example implementation, the timer  230  is started when an event (such as an RLF) triggering the cell selection procedure occurs. The value of the timer  230  may be pre-configured or configured by a network node (a parent IAB-node, an IAB-donor, or any other network entity) by dedicated signaling (e.g. RRC, F1-AP) or broadcast signaling (e.g. system information (MIB, SIB1 or other SIB(s))). In addition, a stored set of configuration parameters may become invalid when a new set of configuration parameters is received. 
     Preventing Routing Loops in Cell Selection: Using System Information 
       FIG.  33    shows an example embodiment and mode wherein the same issue of “routing loops” is addressed by an alternative approach, e.g., using system information. In the example embodiment and mode of  FIG.  33   , a distributed unit  72  of each IAB-node, such as IAB node  24 - 33 , may broadcast system information (SI) comprising a list of identifiers to identify the (grand)parent cells/nodes located on the upstream path of the SI-broadcasting IAB-node, in addition to a cell/node identification of its own.  FIG.  33    particularly shows that distributed unit  72  of IAB node  24 - 33  includes parent node-identifying system information generator  240  which includes, in the system information broadcast by IAB node  24 - 33 , the list of identifiers to identify the (grand)parent cells/nodes located on the upstream path. In the example embodiment of  FIG.  33   , system information in which the parent node list is included may comprise synchronization signals (e.g. PSS/SSS), Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), MIB, SIB1, other SIB(s) or any combination of one or more thereof. 
     Operation of the example embodiment and mode of  FIG.  33    is illustrated in  FIG.  34   .  FIG.  34    shows a telecommunications system comprising wireless access donor node  22 -D- 33 , IAB node  24 - 0 - 1 - 33 ; IAB node  24 - 0 - 2 - 33 ; IAB node  24 - 0 - 1 - 1 - 33 ; IAB node  24 - 0 - 1 - 2 - 33 ; and IAB node  24 - 0 - 1 - 1 - 1 - 33 . Each of the IAB nodes  24 - 33  of  FIG.  34    include a mobile termination unit  70  and a distributed unit  72 , with the distributed unit  72  including the aforementioned parent node-identifying system information generator  240 . 
       FIG.  34    illustrates an example operation and mode of the example embodiment and mode of  FIG.  33   . First, the DU part of an IAB-donor may broadcast its own cell/node identification (e.g. PCI, Cellldentity(s), or other identification(s)) via system information (System Information  0  in  FIG.  34   ). 
     Next in  FIG.  34   , two child nodes, IAB node  24 - 0 - 1 - 33  and IAB node  24 - 0 - 2 - 33  of  FIG.  34   , attach to the relay network. The two nodes IAB node  24 - 0 - 1 - 33  and IAB node  24 - 0 - 2 - 33  are in RRC_IDLE or RRC_INACTIVE state, acquiring the system information broadcast from the IAB-donor  22 -D- 33 , and then performing the RRC connection setup procedure (as previously disclosed). During the system information acquisition, the two nodes IAB node  24 - 0 - 1 - 33  and IAB node  24 - 0 - 2 - 33  may obtain the cell/node identification of the IAB-donor  22 -D- 33 . In a case that some of the two child nodes have already been in RRC_CONNECTED state and handover to the IAB-donor, the system information (at least some essential parts including at least the cell identification of a target cell (i.e. the IAB-donor)) may be provided to the nodes IAB node  24 - 0 - 1 - 33  and IAB node  24 - 0 - 2 - 33  by dedicated signaling (e.g. RRCReconfiguration message) before or after the handover. 
     After establishing an RRC connection, followed by F1-AP setting up their respective DU parts, each of the nodes IAB node  24 - 0 - 1 - 33  and IAB node  24 - 0 - 2 - 33  may start broadcasting its own system information. In the example embodiment of  FIG.  34   , this system information may include its own cell/node identification and may further include a list of cell/node identifications for parent nodes. For example, the DU part of IAB node  24 - 33 - 0 - 1 - 33  may broadcast system information (System Information  0 - 1 ) comprising the cell/node identification of Node  24 - 0 - 1 - 33  and a list of parent cell identification including the cell/node identification for the IAB-donor  22 -D- 33 . 
     Next in  FIG.  34   , other two nodes, Node  24 - 0 - 1 - 1 - 33  and Node  24 - 0 - 1 - 2 - 33 , may attach to the relay network via Node  24 - 0 - 1 - 33 . Each of Node  24 - 0 - 1 - 1 - 33  and Node  24 - 0 - 1 - 2 - 33  perform the same action(s) as Node  24 - 0 - 1 - 33  or Node  24 - 0 - 2 - 33 . In this case the system information (System Information  0 - 1 ) additionally includes the list of cell/node identifications for the parent nodes of Node  24 - 0 - 1 - 33  (e.g., includes the identification of the IAB-donor  22 -D- 33 ). 
     When broadcasting system information (System Information  0 - 1 - 1  and System Information  0 - 1 - 2 , respectively), the Node  24 - 0 - 1 - 1 - 33  and Node  24 - 0 - 1 - 2 - 33  may compose a list comprising the parent cell identifications received from Node  24 - 0 - 1 - 33  and the cell identification of Node  24 - 0 - 1 - 33 . Similarly, any (grand)child node attaching to the relay network may perform the same acts. 
     In the operation and mode described above, it is assumed that the MT part of an IAB-node informs the collocated DU part of necessary information, e.g. parent node identifications, received in the system information. 
     When an IAB-node detects a radio link failure (RLF) on its upstream radio link, the MT part of the IAB-node may initiate the cell selection procedure as described in the previous embodiments, and determine suitability of any discovered cells by acquiring system information (at least synchronization signals, MIB and SIB1, possibly other SIB(s)). In the operation and mode of the example embodiment of  FIG.  34   , the MT part of the IAB-node may decode the system information to ensure that the selected cell is not served by a child node of its own. In order to do this, the MT part of the IAB-node may examine the list of parent node identifications included in the system information and check if its own cell/node identification is in the list. If the check is positive, the MT part of the IAB-node may determine the selected cell served by its own child node and therefore attempt to look for other cells. Otherwise, the MT part of the IAB-node may examine other parameters in the system information, such as barring status, and may further proceed to the RRC reestablishment procedure as disclosed earlier. 
     In another example operation and mode, a different type of identifications may be used for the list of identifiers identifying (grand)parent nodes to be included in the system information. For example, Physical Cell IDs (PCIs), NR Cell Identities (Cellldentitys or NCIs), NR Cell Global Identifiers (NCGIs), gNB identifiers (gNB IDs), Global gNB identifiers, gNB-ID (specified in 3GPP TS 38.473) or any other identifies to identify cells/nodes may be used. 
     At least some of the example operations and modes disclosed above in the example embodiment of  FIG.  33    and  FIG.  34    assume that each IAB-node is implemented in such a way that the identifications of (grand)parent nodes on its upstream path towards an IAB-donor are retrieved from received system information by the MT part and transferred to the collocated DU part, where the identifications are further used in the system information that the collocated DU part may broadcast. For example, the cell selection routing loop prevention controller  206  of the Integrated Access and Backhaul (IAB) node may include or have access to the upstream node identifications. 
     In an alternative approach shown in  FIG.  35   , the IAB-donor  22 -D- 33  (or any other network entity) may configure each IAB-node with a set of parent node identifications to be broadcasted by the IAB-node. In this case, during IAB-node being attached to the IAB-donor, the set of parent node identifications may be configured by an RRC message (e.g. RRCReconfiguration message) or an F1-AP message.  FIG.  33    shows such optional alternative by the routing loop prevention information generator takes the form of a parent node identifications generator  200 - 33 . 
       FIG.  36    shows example, representative acts of steps that may be performed by an IAB node  24 - 33  of the example embodiment and mode of  FIG.  33   - FIG.  35   . Act  36 - 1  comprises receiving or obtaining first system information including a first list comprising at least one identification of a donor node and identifications of zero or more intermediate relay nodes located between the donor node and the wireless relay node. Act  36 - 2  comprises transmitting second system information including a second list comprising an identification of the wireless relay node, the at least one identification of the donor node and the identifications of zero or more intermediate relay nodes. Act  36 - 3  comprises initiating a cell selection procedure. Act  36 - 4  comprises, in the cell selection procedure, further receiving, from a selected cell during the cell selection procedure, third system information including a third list comprising one or more identifications of nodes. Act  36 - 5  comprises, in the cell selection procedure, making a decision to select the selected cell/node as a candidate based on whether a third list includes the identification of the wireless relay node. 
       FIG.  37    shows example, representative acts of steps that may be performed by a wireless access donor node such as node  22 -D- 33  of the example embodiment and mode of  FIG.  33   - FIG.  35   . Act  37 - 1  comprises generating a signaling message for a wireless relay node, the signaling message comprising a list of one or more identifications identifying the donor node and zero or more intermediate relay nodes located between the donor node and the wireless relay node. Act  37 - 2  comprises transmitting the signaling message to the wireless relay node. As understood from the foregoing, the list of one or more identifications is configured to enable the wireless relay node to make a decision to select a cell/node as a candidate during a cell selection procedure. 
     Enhanced Re-Establishment 
     The example embodiments and modes of  FIG.  38   - FIG.  44    address issues with with regard to an IAB-node performing a re-establishment procedure, upon receiving a Backhaul RLF indication from its parent node. The Backhaul RLF notification, also referred as Upstream RLF Notification or a condition notification message  42  in the previous embodiments, may be sent when the MT part of a parent node fails to recover after a radio link failure, RLF. 
       FIG.  38    shows an example scenario wherein child node  30  receives the Backhaul RLF Indication, e.g., condition notification  42 , from Node  24 A, the parent node of the child node  30 . Similar to the preceding embodiments, child node  30  may be an IAB-node, or a UE. A child node, either in the form of an IAB-node or a UE as shown in  FIG.  38   , may be referred to as a “wireless terminal”. In  FIG.  38   , it is assumed that the DU part  72 A of IAB-node  24 A is serving multiple cells, Cell A 1 , A 2  and A 3 , and that child node  30  is camping on Cell A 1  at the time of receiving the Backhaul RLF Indication, e.g., condition notification  42 . 
     Upon receiving the Backhaul RLF Indication in  FIG.  38   , child node  30  may store the identification of the cell that transmits the Backhaul RLF Indication. The identification of the cell may be a Physical Cell ID encoded in Physical Broadcast Channel (PBCH). Additionally or alternatively, other types of identification, such as previously disclosed NR Cell Identity (NCI) included in SIB1, may be used. The child node  30  may proceed to the cell selection procedure as disclosed in the previous embodiments. During the cell selection procedure, if child node  30  eventually finds a broadcast signal, e.g. Synchronization Signal Block (SSB), MIB and/or SIB1, from Cell A 1 , child node  30  may de-prioritize selecting Cell A 1  (or not consider Cell A 1  as a candidate) and look for other cells, since child node  30  may recognize, using the stored identification, that Cell Al was, and possibly is still, experiencing the RLF upstream. 
     In further performing the cell selection procedure, child node  30  may eventually find Cell A 2 , another cell served by Node A, e.g., IAB-node  24 A. In this case, child node  30  may not know that Cell A 2  is served by the same parent node which is experiencing the RLF. The child node  30  finding Cell A 2  may lead to child node  30  selecting Cell A 2 , receiving MIB and SIB1, i.e. minimum system information, and the child node  30  initiating the re-establishment procedure with respect to Cell A 2  in order to recover the RRC connection to the donor node. However, re-establishment to Cell A 2 , which is also served by IAB-node  24 A, will result in a failure since the radio link failure (RLF) occurred upstream from IAB-node  24 A. Consequently, the child node  30  may waste time in recovering the connection by selecting cells to be avoided, e.g. cells which are barred, not to be considered as candidates, not-suitable or reserved, or de-prioritized, e.g. low-ranked. 
     To avoid such waste of time and to enhance the cell selection procedure and the re-establishment procedure, the example embodiment and mode of  FIG.  38    shows that IAB-node  24 A transmits node-serving cell information (NSCI)  250 , which enables the child node  30  to more efficiently and effectively perform a re-establishment procedure. Moreover, the child node  30  comprises cell preferential re-establishment controller  252 , which utilizes the node-serving cell information to perform a re-establishment procedure which more intelligently and preferentially selects a cell for re-establishment, thereby avoiding the waste of time and/or inefficiency described above. Thus,  FIG.  38    shows another example and generic telecommunications system in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. 
       FIG.  38    thus shows that the IAB-node  24 A communicates over at least two radio interfaces, including a first interface and a second interface. The first interface is configured to establish a radio resource control (RRC) connection with a donor node, e.g., donor or parent IAB node  22 - 1 . The second interface is configured to serve one or more cells to communicate with one or more wireless terminals, such as child node  30 . The IAB node comprises parent node processor circuitry  74  which, as understood with reference to the foregoing example embodiments and modes, for example, is configured to detect a radio link failure (RLF) on the first interface. The IAB-node  24 A further comprises transmitter circuitry, e.g., IAB node distributed unit (DU)  72 A, which is configured to transmit, using the second interface, to the one or more wireless terminals. The IAB node distributed unit (DU)  72 A is configured to transmit the aforementioned backhaul RLF indication upon a failure of recovery from the RLF, e.g., condition notification  42 . In addition, in the  FIG.  38    example embodiment and mode, the IAB node distributed unit (DU)  72 A is configured to transmit the node-serving cell information  250  to identify the one or more cells served by the IAB-node  24 A. 
       FIG.  38    also shows that a wireless terminal such as the child node  30  communicates with an integrated access and backhaul (IAB) node, e.g., IAB-node  24 A. The wireless terminal comprises receiver circuitry configured to receive, from the IAB node, both the node serving cell information and the backhaul radio link failure (RLF) indication. The node-serving cell information  250  is configured to identify one or more cells served by the IAB node  24 A. The backhaul radio link failure (RLF) indication indicates that the IAB node fails to recover from an RLF, when such RLF does occur.  FIG.  38    further shows that the child node  30  further comprises cell preferential re-establishment controller  252 , which may be realized or comprise terminal processor(s)  90 . The cell preferential re-establishment controller  252  is configured to perform, upon receiving the backhaul RLF indication, a re-establishment procedure based on the node serving cell information  252 . 
       FIG.  39    shows example, representative, basic acts or steps performed by the IAB-node  24 A of  FIG.  38   . Act  39 - 1  comprises detecting a radio link failure (RLF) on the first interface. Act  39 - 2  comprises transmitting, using the second interface, to the one or more wireless terminals the node serving cell information configured to identify the one or more cells and a backhaul RLF indication upon a failure of recovery from the RLF. As understood, e.g., with reference to ensuing implementations, the node-serving cell information and the backhaul RLF indication, e.g., condition notification  42 , may be transmitted together or separately, and the transmission of the node-serving cell information may precede transmission of the backhaul RLF indication. 
       FIG.  40    shows example, representative, basic acts or steps performed by the child node  30  in an example mode of  FIG.  38   . Act  40 - 1  comprises the child node  30  receiving from the IAB-node  24 A the node serving cell information which is configured to identify one or more cells served by the IAB node, and the backhaul radio link failure (RLF) indication indicating that the IAB node fails to recover from an RLF. The reception of the node serving cell information may either precede or accompany reception of the backhaul RLF indication. Act  40 - 2  comprises the child node  30 , and the cell preferential re-establishment controller  252  in particular, upon receiving the backhaul RLF indication, performing a re-establishment procedure which, importantly, is based on the node serving cell information. 
       FIG.  38    thus shows a generic telecommunications system in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure, with  FIG.  39    and  FIG.  40    showing various example generic acts or steps which may be performed by the IAB-node  24 A and child node  30 , respectively. The generic system of  FIG.  39    may have differing implementations, as shown below with respect to  FIG.  41 A - FIG.  41 C . Unless otherwise noted, descriptions above regarding the generic system and mode of  FIG.  39   ,  FIG.  39   , and  FIG.  40    are applicable to each of the differing implementations. First is described, with respect to  FIG.  41 A ,  FIG.  43 A , and  FIG.  44 A , an example implementation in which the node-serving cell information  250  comprises a list of cells served by the IAB-node  24 A, and which list is transmitted to child node  30  in advance of determination and notification of a radio link failure (RLF). Then is described, with respect to  FIG.  41 B ,  FIG.  43 B , and  FIG.  44 B , an example implementation in which a list of cells served by the IAB-node  24 A is transmitted to child node  30  with the notification of a radio link failure (RLF). Then is described, with respect to  FIG.  41 C ,  FIG.  43 C , and  FIG.  44 C , an example implementation in which the node-serving cell information comprises an identification of IAB-node  24 A, which is transmitted to the child node  30  in advance of determination and notification of a radio link failure (RLF). 
       FIG.  41 A ,  FIG.  41 B , and  FIG.  41 C  show in more detail the respective example implementations telecommunications system in which an IAB node may transmit node-serving cell information to permit a child node to perform a cell preferential re-establishment procedure. Components of  FIG.  41 A ,  FIG.  41 B , and  FIG.  41 C  have similar names and/or reference numbers as components of preceding embodiments and modes have comparable structure and function as in the preceding embodiments and modes, unless otherwise noted or clear from the context. For example, the donor or parent IAB node  22 - 1  comprises central unit  50 - 1  and distributed unit  52 - 1 , which may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., node processor(s)  54 - 1 . The distributed unit  52 - 1  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, de-modulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  41 A ,  FIG.  41 B , and  FIG.  41 C , the IAB-node  24 - 1 , also known as wireless relay node  24 - 1 , in an example embodiment and mode comprises relay mobile termination (MT) unit  70 A and relay distributed unit (DU)  72 A. The relay mobile termination unit  70 - 1  and relay distributed unit  72 - 1  may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., relay node processor(s)  74 A. The relay node processor(s)  74 A comprise the condition detector  96 , as described in previous embodiments and modes, which may detect a radio link failure (RLF), and notification generator  98 , which may generate the condition notification  42  upon detection of the radio link failure (RLF). The one or more relay node processor(s)  74  may be shared by relay mobile termination unit  70  and relay distributed unit  72 A, or each of mobile termination unit  70 A and distributed unit  72 A may comprise one or more relay node processor(s)  74 . The relay node distributed unit  72 A may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  41 A ,  FIG.  41 B , and  FIG.  41 C , child node  30  comprises, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  86  includes antenna(e) for the wireless transmission. Transmitter circuitry  87  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  88  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. The child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, also comprises node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  48  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. In an example, non-limiting embodiment and mode shown in  FIG.  23   , the child node  30  may include frame/message generator/handler  94 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes. 
     In the example implementation shown in  FIG.  41 A ,  FIG.  43 A , and  FIG.  44 A , an IAB-node or a UE such as child node  30  may be informed of identifications of cells served by the current parent node. For example, the child node  30  may receive a list of identifications of cells, i.e., Cell A 1 , A 2  and A 3 , served by IAB-node  24 A. When receiving the Backhaul RLF Indication, the cell preferential re-establishment controller  252  of child node  30  may de-prioritize, e.g., avoid, selecting a cell whose identification is included in the list. 
     The child node  30  may camp on Cell Bl, served by Node B, e.g., IAB-node  24 B, since the identity of Cell B 1  is not included in the list. In one configuration, the list of identifications of cells comprise Physical Cell IDs (PCIs). In this case, during the cell selection procedure Child Node may decode PBCH transmitted from a discovered cell and determine whether or not to select the cell, based on the list of identifications of cells. In another configuration, the list of identification of cells may comprise NR Cell Identities, where Child Node may have to receive a SIB(s), such as SIB1, (after receiving MIB) to determine whether or not to select the cell. 
     In the example implementation of  FIG.  41 A , a list of identifications of cells served by IAB-node  24 A and the condition notification  42 , which advises of the detected radio link failure (RLF), are separately transmitted by IAB-node  24 A to child node  30 . The transmission of the list of identifications of cells precedes the transmission of the condition notification  42 .  FIG.  41 A  shows that the donor or parent IAB node  22  may comprise a memory or server(s)  254  that maintains a list of identifications of cells served by IAB-node  24 A. The list maintained by memory/server  254  is communicated over a first interface to IAB-node  24 A, whereat it may be stored in memory/server  256  of IAB-node  24 A, e.g., by processor(s)  74 A. The IAB node distributed unit (DU)  72 A of IAB-node  24 A transmits the list of identifications of cells, obtained from memory/server  256 , as the node-serving cell information  250 , to child node  30 , and does so in advance of detection and notification of any radio link failure (RLF). The child node  30  comprises an RRC controller  258 , which in turn realizes or comprises the cell preferential re-establishment controller  252 . 
     In the example implementation of  FIG.  41 B , the list of identifications of cells served by IAB-node  24 A is included in the condition notification  42 , e.g., is included in the backhaul RF indication. That is, the backhaul RF indication includes the list of identifications of cells served by IAB-node  24 A, so that the list of identifications of cells and condition notification  42  are transmitted together, e.g., simultaneously. 
     In the example implementation of  FIG.  41 A , the list of identification of cells, in one configuration, may be included in system information, such as MIB, SIB1, or any other SIB(s). In this configuration, an IAB node or a UE, e.g. Child Node in  FIG.  38    and  FIG.  41 A , may obtain the list whenever it acquires the system information. In another configuration of the implementation of  FIG.  41 A , the IAB node or the UE may obtain the list from the donor node via RRC signaling and/or F1AP signaling during RRC_CONNECTED. In the example implementation of  FIG.  41 B , the list of identification of cells may be included in a payload, a message body or a protocol data unit (PDU) of the Backhaul RLF indication. 
     In the example implementation of  FIG.  41 C , each cell may broadcast a node identification, such as gNB-DU ID per 3GPP TS 38.473 that identifies the node that serves the cell via system information. For example, in  FIG.  18    and  FIG.  41 C , the system information, e.g., MIB, SIB1, and/or other SIB(s), broadcasted by each of the cells (A 1 , A 2  and A 3 ) may include a node identification of Node A as the node-serving cell information. When receiving the Backhaul RLF Indication, an IAB node or UE may save the node identification obtained from the cell that transmitted the Backhaul RLF Indication, then during the cell selection procedure Child Node may de-prioritize, or avoid, cells that broadcast the saved node identification. In the  FIG.  41 C  implementation of the scenario shown in  FIG.  38   , child node  30  may obtain the node identification of Node A, e.g., IAB-node  24 A, from Cell A 1  when camping, then after receiving the Backhaul RLF Indication from Cell A 1 , child node  30  may avoid camping on A 2  or A 3  since these cells also broadcast the node identification of Node A. Meanwhile, child node  30  may camp on Cell B 1 , served by IAB-node  24 B, as Cell B 1  may broadcast the node identification of IAB-node  24 B, different from the node identification of IAB-node  24 A. 
     Thus,  FIG.  40 C  shows that information which specifies the IAB node which serves a child node is transmitted to the child node  30 . This information which specifies the IAB node which serves a child node may also be shown in  FIG.  40 C  as IIIAB. The information which specifies the IAB node which serves a child node (IIIAB) may be maintained in memory/server  260  of donor or parent IAB node  22 - 1 , and also in memory/server(s)  262  of IAB-node  24 A. Similar to the situation of the implementation of  FIG.  41 A , the transmission to child node  30  of the information which specifies the IAB node which serves a child node (IIIAB) is separate from and precedes the transmission of the condition notification  42 , of the backhaul RLF indication. 
       FIG.  42    is an example message flow of the generic scenario shown in  FIG.  38   . As depicted by act  42 - 1 , child node  30  is in Cell A 1 , RRC-CONNECTED with Donor  1 , e.g., donor or parent IAB node  22 - 1 , through IAB-node  24 A. As shown by act  42 - 2 , the MT part  70 - 1  of IAB-node  24 A detects a radio link failure (RLF) on the upstream radio link and declares a failure of recovery from the RLF. As act  42 - 3  the DU part  72 - 1  of IAB-node  24 A transmits the Backhaul RLF Indication to its downstream nodes/UEs, which is received by child node  30 . As shown by symbol  42 - 4 , at this moment child node  30  has information indicating cells served by Node A (also referred as “node serving cell information” or “NSCI”), where the information indicating cells served by Node A may refer to a list of identities of cells served by Node A, as in the cases of the implementation of  FIG.  41 A  and the implementation of  FIG.  41 B , and/or a node identification of Node A as in the case of  FIG.  41 C . The child node  30  may have been obtained the information indicating cells served by Node A via system information, a dedicated signaling, or the Backhaul RLF Indication. The child node  30  then initiates a cell selection procedure, and eventually finds a cell, Cell Ax, served by Node A, where Ax may be Al, A 2  or A 3 . As reflected by act  42 - 5 , child node  30  then acquires system information (MIB, SIB1 and/or other SIB(s)) from Cell Ax, where the system information may comprise an identification of Cell Ax, and or the node identification of Node A, e.g., IAB-node  24 A. From the information indicating cells served by Node A, e.g., from the node-serving cell information, the child node  30  may learn that Cell Ax should be avoided and/or de-prioritized. The child node  30  may then look for other cells and eventually find Cell B  1 . For example, as reflected by act  42 - 6 , the child node  30  may, from system information broadcasted by Cell B 1 , may recognize Cell B 1  as a suitable cell. Upon determining that Cell B 1  may be a suitable cell, child node  30  proceed to initiating a Random Access procedure. The Random Access procedure is reflected by a message which transmits a Random Access Preamble as shown by act  42 - 7 , and a Random Access Response, message reflected by act  42 - 8 . Upon completion of the Random Access procedure, as act  42 - 9  the child node  30  transmits a RRCReestablishmentRequest message to donor or parent IAB node  22 - 1 . As act  42 - 10  the donor or parent IAB node  22  may respond to child node  30  by sending a RRCReestablishment message. As act  42 - 11  the child node  30 may complete this re-establishment procedure by sending a RRCReestablishmentComplete message. 
       FIG.  43 A ,  FIG.  43 B , and  FIG.  43 C  are flowcharts showing example, representative acts or steps performed by an IAB node of the implementations of  FIG.  41 A,  41 B, and  41 C , respectively. 
       FIG.  43 A  is a flow chart showing example representative steps or acts performed by IAB-node  24  of  FIG.  18    and  FIG.  41 A , where the information indicating cells served by IAB-node  24 A is a list of identifications of cells served by IAB-node  24 A and is transmitted prior to sending the Backhaul RLF Indication. Act  43 A- 1  comprises each of the cells served by IAB-node  24 A, i.e. Cell A 1 , A 2  and A 3 , periodically broadcasting its cell identification in the system information, e.g., MIB, SIB1 and/or other SIB(s). Act  43 A- 2  comprises the IAB-node  24 A transmitting the list of identifications of cells served by IAB-node  24 A, via a dedicated signaling or by broadcast. Act  43 A- 3  comprises IAB-node  24 A declaring a failure of recovery from an RLF. Act  43 A- 4  comprises the IAB-node  24 A transmitting the Backhaul RLF Indication to nodes/UEs downstream, including child node  30  of  FIG.  18    and  FIG.  41 A . 
       FIG.  43 B  is a flow chart showing example representative steps or acts performed by the IAB-node  24 A of  FIG.  18    and  FIG.  41 B , where the information indicating cells served by the IAB-node  24 A is a list of identifications of cells served by IAB-node  24 A and is transmitted in conjunction with the Backhaul RLF Indication. Act  43 B- 1  and Act  43 B- 2  are the same as Act  43 A- 1  and Act  43 A- 3 , respectively. Act  43 B- 3  comprises transmitting the Backhaul RLF Indication to nodes/UEs downstream, including child node  30  of  FIG.  18    and  FIG.  41 B , where the Backhaul RLF Indication includes the list of identifications of cells served by IAB-node  24 A. 
       FIG.  43 C  is a flow chart showing example representative steps or acts performed by the IAB-node  24 A of  FIG.  18    and  FIG.  41 C , where the information indicating cells served by IAB-node  24 A is a node identification of IAB-node  24 A. Act  43 C- 1  comprises each of the cells served by IAB-node  24 A, i.e. Cell A 1 , A 2  and A 3 , periodically broadcasting the node identification of IAB-node IAB-node  24 A in the system information, e.g., in MIB, SIB1 and/or other SIB(s). Act  43 C- 2  and Act  43 C- 3  are the same as Act  43 A- 3  and Act  43 A- 4 , respectively. 
       FIG.  44 A ,  FIG.  44 B , and  FIG.  44 C  are flowcharts showing example, representative acts or steps performed by a child node of the implementations of  FIG.  41 A,  41 B, and  41 C , respectively. 
       FIG.  44 A  is a flow chart showing example representative steps or acts performed by child node  30  of  FIG.  18    and  FIG.  41 A  and corresponding to the acts performed by IAB-node  24 A in  FIG.  43 A , where the information indicating cells served by IAB-node  24 A, e.g., the node-serving cell information, is a list of identifications of cells served by IAB-node  24 A and is transmitted prior to sending the Backhaul RLF Indication. Act  44 A- 1  comprises receiving a cell indication included in the system information periodically broadcasted by Cell A 1 . Act  44 A- 2  comprises receiving a list of identifications of cells served by IAB-node  24 A, via a dedicated signaling or by broadcast. Act  44 A- 3  comprises receiving the Backhaul RLF Indication. Act  44 A- 4  comprising performing a cell selection/re-establishment procedure, avoiding (or de-prioritizing) a cell that broadcasts one of the cell identifications in the list. 
       FIG.  44 B  is a flow chart showing example representative steps or acts performed by IAB-node  24 A of  FIG.  18    and  FIG.  41 B , and corresponding to acts performed by the IAB-node  24 A as shown in  FIG.  43 B , where the information indicating cells served by IAB-node  24 A, e.g., the node-serving cell information, is a list of identifications of cells served by IAB-node  24 A and is transmitted in conjunction with the Backhaul RLF Indication. Act  44 B- 1  is the same as Act  44 A- 1 . Act  44 B- 2  comprises receiving the Backhaul RLF Indication including a list of identifications of cells served by Node A. Act  44 B- 3  is the same as Act  44 A- 4 . 
       FIG.  44 C  is a flow chart showing example representative steps or acts performed by child node  30  of  FIG.  18    and  FIG.  41 C  and corresponding to the acts performed by IAB-node  24 A as shown in  FIG.  43 C , where the information indicating cells served by IAB-node  24 A, e.g., the node-serving cell information, is a node identification of IAB-node  24 A. Act  44 C- 1  comprises receiving a node identification of IAB-node  24 A included in the system information periodically broadcasted by Cell A 1 . Act  44 C- 2  is the same as Act  44 A- 3 . Act  44 C- 4  comprises performing a cell selection/re-establishment procedure, avoiding or de-prioritizing cells that broadcast the node identification of IAB-node  24 A.
         The example embodiment and mode herein described thus handles cases where an IAB node performs an RRC re-establishment procedure. Specifically:   The IAB node transmits to its child nodes/UEs node serving cell information that is used to identify cells served by the IAB node.   The JAB node transmits a backhaul radio link failure (RLF) indication to the child nodes/UEs when it fails to recover an RLF detected on the upstream radio link.   Upon receiving the backhaul RLF indication, the child nodes/UEs performs an RRC re-establishment procedure, wherein a cell identified by the node serving cell information is considered to be barred or treated as a low rank cell.   The node serving cell information may comprise a list of identifications of cells that are served by the IAB node, or may comprise a node identification of the IAB node.   Each of the cells served by the IAB node may broadcast the node identification in system information.   In a case that the IAB node performs an inter-CU (inter-donor) RRC re-establishment procedure to a target donor (CU), the JAB node transmit, to the child nodes/UEs, a re-establishment indication.   Upon receiving the re-establishment indication, each of the child nodes/UEs performs an RRC re-establishment procedure with the target donor (CU).       

     Inter-Donor Node RRC Update Procedure 
     As disclosed in the preceding embodiments, an IAB node may initiate an RRC re-establishment procedure in a case that it detects an RLF upstream, or in a case that it receives the Backhaul RLF Indication.  FIG.  45    illustrates a scenario where an IAB node, such as IAB-node  24 A, communicates with a donor node/CU, e.g., donor or parent IAB node  22 - 1 , then detects a radio link failure (RLF), and then performs the RRC re-establishment procedure to a different donor node/CU, e.g., donor or parent IAB node  22 - 2 . In the  FIG.  45    example embodiment and mode the two donor nodes (CUs) are inter-connected by inter-node protocols, such as Xn Application Protocol (XnAP) per 3GPP TS 38.423, over a wired backhaul connection  32 . 
       FIG.  46 A  shows one example message flow of IAB-node  24 A performing an interCU (inter-donor) re-establishment procedure in the scenario shown in  FIG.  45   . As shown by act  46 - 1 , IAB-node  24 A is in RRC_CONNECTED with donor IAB node  22 - 1 . Act  46 - 3  shows IAB-node  24 A detecting a radio link failure (RLF) on its upstream. Following the detection of the RLF, as act  46 - 3  IAB-node  24 A may initiate the cell selection procedure to find a suitable cell, which leads to finding a cell served by a DU part  52 - 2  of donor IAB node  22 - 2 . IAB-node  24 A may then perform the Random Access procedure, which includes as act  46 - 4  sending a random access preamble to donor IAB node  22 - 2  and, as act  46 - 5 , receiving a random access response message from donor IAB node  22 - 2 . Then, as act  46 - 6 , IAB-node  24 A may send a RRCReestablishmentRequest to donor IAB node  22 - 2 . The RRCReestablishmentRequest of act  46 - 6  may comprise an identity of the mobile termination  70 - 1  of IAB-node  24 A and a security token field. The identity of the mobile termination  70 - 1  of IAB-node  24 A may comprise the Physical Cell ID (PCI) of the old serving cell (the cell served by donor IAB node  22 - 1  that IAB-node  24 A camped before the RLF), and the C-RNTI (Cell-Radio Network Temporary Identifier) assigned by the old serving cell. The security token field, e.g. shortMAC-I per 3GPP TS 38.331, computed based on security keys configured by donor IAB node  22 - 1 , may be used by donor IAB node  22 - 2  to authenticate IAB-node  24 A. Upon receiving the RRCReestablishmentRequest of act  46 - 6 , the donor IAB node  22 - 2  may identify, from the identity of the mobile termination  70 - 1  of IAB-node  24 A, the old serving node, e.g., donor IAB node  22 - 1 , and as act  46 - 7  send to donor IAB node  22 - 1  a RETRIEVE UE CONTEXT REQUEST, which includes the identity of the mobile termination  70 - 1  of IAB-node  24 Aand the security token field. The donor IAB node  22 - 1  may then check, based on saved context of IAB-node  24 A, if the security token field is correct, and if the check is positive, donor IAB node  22 - 1  may proceed to derive a fresh Access Stratum (AS) security key(s) using a Next Hop Chaining Count, NCC, and as act  46 - 8  send back to donor IAB node  22 - 2   a  RETRIEVE UE CONTEXT RESPONSE which includes the fresh security key(s) as well as Next Hop Chaining Count (NCC). As act  46 - 9  the donor IAB node  22 - 2  may transmit a RRCReestablishment message to IAB-node  24 A, which RRCReestablishment message may include the NCC and may be integrity-protected by the fresh security key(s). Upon receiving the RRCReestablishment, as act  46 - 10  IAB-node  24 A may generate a AS security key(s) using the NCC and check if the integrity protection of the RRCReestablishment is valid. If this check is positive, then the generated AS security key(s) may replace the AS security key(s) and may be used for encryption and integrity protection of messages between IAB-node  24 A and donor IAB node  22 - 2 , including the RRCReestablishmentComplete shown as act  46 - 11  in  FIG.  46 A . 
     After completing the RRC re-establishment procedure, as act  46 - 12  the DU part  722 - 1  of IAB-node  24 A may initiate an F1 Setup procedure by sending a F1 SETUP REQUEST to donor IAB node  22 - 2 . The F1 SETUP REQUEST may comprise identifications of cells, such as CGIs and/or PCIs, that IAB-node  24 A is able to serve. Hereafter, the cells are recognized as being bound to donor IAB node  22 - 2 . The donor IAB node  22 - 2  may then as act  46 - 13  send back F1 SETUP RESPONSE to activate some or all of the cells. 
     In the  FIG.  46 A  operation as described above, at the moment that IAB-node  24 A successfully finishes the re-establishment procedure, any nodes/UEs that connect to IAB-node  24 A, such as child node  30  in  FIG.  45   , may not be aware that the parent node, IAB-node  24 A, has changed its donor node, e.g., changed from donor IAB node  22 - 1  to donor IAB node  22 - 2 . In addition, the child node  30  has not established a security context with the new donor IAB node  22 - 2 . Moreover, the radio bearers, data radio bearers (DRBs) and signaling radio bearers (SRB_s) for the child node  30 , which were established with donor IAB node  22 - 1 , are now all lost after the re-establishment performed by IAB-node  24 A. Therefore, there is a need for a child node such as child node  30  to re-establish the radio bearers with a new security context for donor IAB node  22 - 2   
     The IAB-node  24 A and child node  30  of  FIG.  45    are configured to address issues that may arise when an RRC connection involving a child node needs to be updated. One example situation in which the RRC connection involving child node  30  needs to be updated is the situation described above in which an IAB-node  24  has changed its donor IAB node, such as IAB-node  24 A changing from donor IAB node  22 - 1  to donor IAB node  22 - 2  as described above. Another situation in which the RRC connection involving child node  30  needs to be updated is described further below, when the RRC connection is handed over from one donor IAB node to another donor IAB node, e.g., when the update of the RRC connection includes an RRC reconfiguration with sync procedure to the second donor node.  FIG.  45    generically shows that, for addressing such an RRC connection involving child node  30  needs to be updated, the IAB-node  24 A generates and transmits to child node  30  a re-establishment indication  270 . 
     The IAB-node  24 A of  FIG.  45    communicates over at least two radio interfaces including a first interface and a second interface. The first interface is configured to establish a radio resource control (RRC) connection with at least one donor node; the second interface is configured to serve one or more cells to communicate with one or more wireless terminals, such as child node  30 . The IAB-node  24 A of  FIG.  45    comprises processor circuitry and transmitter circuitry. The processor circuitry, illustrated by parent node processor circuitry  74 A, is configured to establish an RRC connection with a first donor node and to perform an update of the RRC connection to be used for a second donor node. The transmitter circuitry may be realized by or comprise IAB node distributed unit (DU)  72 A, and is configured to transmit, using the second interface, the re-establishment indication  270 , upon performing the update of the RRC connection. The re-establishment indication is used to request that each of the one or more wireless terminals initiate an RRC re-establishment procedure. 
     The re-establishment indication  270  may be generated by re-establishment indication generator  272 . The re-establishment indication generator  272  may be hosted or comprise an RRC entity  274 . The RRC entity  274  may also comprise or include an RRC connection update controller  276 , which performs the RRC connection update procedure, whether a procedure involving change of donor IAB node for the IAB-node  24  or a handover. The RRC entity  274  may be realized or be comprised by parent node processor circuitry, e.g., IAB node processor(s)  74 A. 
     The child node  30  comprises receiver circuitry and processor circuitry, such as processor circuitry  90 . The receiver circuitry is configured to receive the re-establishment indication  270  from the IAB node. The processor circuitry is configured to initiate an RRC re-establishment procedure, based on the re-establishment indication. During the re-establishment procedure, one or more cells that served by the IAB node are considered as candidate cells. Thus, upon receipt of the re-establishment indication  270 , child node  30  a re-establishment controller  280  performs a cell preferential re-establishment procedure. The re-the establishment controller  280  may be realized or comprised by processor circuitry  90  of child node  30 . 
       FIG.  47    is a flowchart showing example, representative, acts or steps performed by a generic IAB node of the system of  FIG.  45   . Act  47 - 1  comprises establishing an RRC connection with a first donor node. Act  47 - 2  comprises performing an update of the RRC connection to be used for a second donor node. Act  47 - 3  comprises transmitting, using the second interface, a re-establishment indication, upon performing the update of the RRC connection. The re-establishment indication  270  is configured to require each of the one or more wireless terminals initiate an RRC re-establishment procedure. In an example embodiment and mode during the RRC re-establishment procedure, the one or more cells are considered as candidate cells. 
       FIG.  48    is a flowchart showing example, representative, acts or steps performed by a generic child node of the system of  FIG.  45   . Act  48 - 1  comprises receiving, from the IAB node, a re-establishment indication. Act  48 - 2  comprises initiating an RRC re-establishment procedure, based on the re-establishment indication. In an example embodiment and mode, during the RRC re-establishment procedure one or more cells that served by the IAB node are considered as candidate cells. 
       FIG.  49    shows in more detail an example implementation of the generic telecommunications system of  FIG.  45   . Components of the system of  FIG.  49    which have similar names and/or reference numbers as components of preceding embodiments and modes have comparable structure and function as in the preceding embodiments and modes, unless otherwise noted or clear from the context. For sake of simplicity,  FIG.  49    shows only one of the donor or parent IAB nodes illustrated in  FIG.  45   , e.g., donor IAB node  22 - 1  which is illustrated as comprising central unit  50 - 1  and distributed unit  52 - 1 , which may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., node processor(s)  54 - 1 . The distributed unit  52 - 1  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  49   , also known as wireless relay node  24 - 1 , in an example embodiment and mode comprises relay mobile termination (MT) unit  70 A and relay distributed unit (DU)  72 A. The relay mobile termination unit  70 A and relay distributed unit  72 A may be realized by, e.g., by comprised of or include one or more processor circuits, e.g., relay node processor(s)  74 A. The relay node processor(s)  74 A comprise the condition detector  96 , as described in previous embodiments and modes, which may detect a radio link failure (RLF), and notification generator  98 , which may generate the condition notification  42  upon detection of the radio link failure (RLF). In addition, as shown in  FIG.  45   , the IAB node processor circuitry  74 A may comprise RRC entity  274 , which in turn may comprise re-establishment indication generator  272  and RRC connection update controller  276 . The one or more relay node processor(s)  74 A may be shared by relay mobile termination unit  70 A and relay distributed unit  72 A, or each of mobile termination unit  70 A and distributed unit  72 A may comprise one or more relay node processor(s)  74 A. The relay node distributed unit  72 A may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  49   , child node  30  comprises, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. The child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, also comprises node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  48  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. In an example, non-limiting embodiment and mode shown in  FIG.  23   , the child node  30  may include frame/message generator/handler  94 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes. As shown also in  FIG.  45   , the child done processor(s)  90  may comprise re-establishment controller  280 . 
     As one aspect of addressing some of the issues that may arise when an RRC connection involving a child node needs to be updated, an example embodiment and mode of the system of  FIG.  45    and  FIG.  49    may transfer UE contexts of child/grandchild nodes, IAB-nodes/UEs, that are currently connected to a source donor node via a parent IAB node to a target donor node, upon the parent IAB-node&#39;s inter-CU re-establishment.  FIG.  46 B  shows one example message flow of such an example embodiment and mode, where, in addition to the message flow shown in  FIG.  46 A , donor IAB node  22 - 1 , also referred to as the source or source donor node, may transfer the contexts to donor IAB node  22 - 2 , which may also be referred to as the target or target donor node. The transfer may involve or comprise UE contexts of some or all of the child/grandchild nodes of the affected IAB-node  24 , such as child node  30  in  FIG.  45   , for example. Since, in a typical implementation, a donor node, and preferably a CU part of the donor node, manages routings and topologies of the relay network belonging to the donor node, the source donor node, e.g., donor IAB node  22 - 1 , may have knowledge of which contexts need to be transferred to the target donor node when it becomes aware of a re-establishment procedure performed by an IAB-node. A context of an IAB-node or a UE may include, but not limited to, an AS security key, a Next Hop Chaining Count, NCC and a security token (e.g. shortMAC-I) to be used in the target donor node. Accordingly, each donor IAB node  22  may comprise context memory  282 , which may store context information for the IAB-nodes and grand-children nodes.  FIG.  49    shows such context memory  282  for donor IAB node  22 - 1 , but it should also be understood that donor IAB node  22 - 2  may also have context memory  282  which stores contexts for its child and grandchild nodes, as well as contexts which are transferred thereto from donor IAB node  22 - 1 . The context memory  282  is preferably hosted by a processor and/or memory structure of the CU part  50 , and IAB node processor(s)  54 , of the respective donor IAB node  22 . 
     Thus, as understood from the foregoing, the flow of  FIG.  46 B  primarily differs from that of  FIG.  46 A  by further including act  46 B- 1 . As shown in  FIG.  46 B , the context transfer for the child/grandchild nodes which is represented by act  46 B- 1  may be initiated immediately after the RETRIEVE UE CONTEXT RESPONSE, e.g., context retrieval for IAB-node  24 A, which occurs as act  46 - 8 . 
       FIG.  50    shows another implementation of the system of  FIG.  45    and  FIG.  49    in which the context transfer may be performed by a different technique: the context transfer may be performed per each child/grandchild node basis, where XnAP HANDOVER REQUEST messages, such as messages  50 - 1 ,  50 - 3 , and  50 - 5  may be used to transfer each child/grandchild&#39;s context.  FIG.  50    also shows respective HANDOVER REQUEST ACKNOWLEDGEMENT messages  50 - 2 ,  50 - 4 , and  50 - 6 . 
       FIG.  51 A  shows an example message flow of another RRC re-establishment procedure for child node  30 . In the scenario shown in  FIG.  51 A , the donor IAB node  22 - 1 , the IAB-node  24 A, and the child node  30  are all in RRC_Connected state, as shown by act  51 - 1 . Moreover, the re-establishment procedure of  FIG.  46 B  is performed as act  51 - 2 . In the scenario of  FIG.  51 A , the parent node, e.g. IAB-node  24 A, may inform its child nodes of the completion of the RRC re-establishment procedure, which is shown by act  51 - 3  as “re-establishment indication” in  FIG.  51 A . The re-establishment indication of act  51 - 3  is also shown as the re-establishment indication  270  in  FIG.  45   . Upon receiving the re-establishment indication, each of the child nodes, e.g. child node  30 , may perform the RRC re-establishment procedure for its own, as reflected by act  51 - 4  which is labeled “successful cell selection”. After the cell selection, the child node  30  may then perform the Random Access procedure, which includes as act  51 - 5  sending a random access preamble to IAB-node  24 A and, as act  51 - 6 , receiving a random access response message from IAB-node  24 A. Then, as act  51 - 7 , child node  30  may send a RRCReestablishmentRequest to donor IAB node  22 - 2 . The RRCReestablishmentRequest of act  46 - 6  may comprise an identity of the child node  30  and a security token field. The identity of the child node  30  may comprise the Physical Cell ID (PCI) of the old serving cell, e.g., the cell served by IAB-node  24 A that the child node  30  camped before receiving the re-establishment indication, and the C-RNTI (Cell-Radio Network Temporary Identifier) assigned by the old serving cell. As mentioned before, the security token field, e.g. shortMAC-I per 3GPP TS 38.331, computed based on security keys configured by donor IAB node  22 - 1 , may be used by donor IAB node  22 - 2  to authenticate the child node  30 . Upon receiving the RRCReestablishmentRequest of act  51 - 7 , the donor IAB node  22 - 2  may identify, from the identity of the child node  30 , the child node  30 , and as act  51 - 8 , retrieve the UE context for child node  30  locally. After locally obtaining the UE context, as act  51 - 9  the donor IAB node  22 - 2  may transmit a RRCReestablishment message to IAB-node  24 A, which RRCReestablishment message may include the Next Hop Chaining Count, NCC, and may be integrity-protected by the fresh security key(s). Upon receiving the RRCReestablishment, as act  51 - 10 , the child node  30  may send a RRCReestablishmentComplete message to donor or parent IAB node  22 - 2 . 
       FIG.  51 A  shows a case where the cell selection of act  51 - 4  results in child node  30  selecting a cell served by IAB-node  24 A. If child node  30  ends up with selecting a cell not served by IAB-node  24 A, child node  30  may perform the re-establishment procedure in the similar manner as IAB-node  24 A performs as illustrated in  FIG.  46 A , except for the F1 SETUP REQUEST/RESPONSE. 
     The re-establishment indication, e.g., re-establishment indication  270 , may be transmitted from IAB-node  24 A in a dedicated signaling or by broadcast. The re-establishment indication  270  may be carried by physical layer signaling, e.g., such as PDCCH, MAC layer, e.g., such as by a MAC Control Element, BAP layer signaling, broadcast in system information, or by any other protocol layer. The re-establishment indication  270  may be transmitted multiple times on the downlink of IAB-node  24 A downstream. 
     In some example embodiments and modes the re-establishment indication  270  may have to be distinguishable from the aforementioned Backhaul RLF Indication, e.g., condition notification  42 , which indicates a failure of an RLF recovery. In a case of the failure of the RLF recovery, child node  30  may have to avoid or de-prioritize the cell(s) served by IAB-node  24 A, as disclosed in the previous embodiment. Whereas in a case in which IAB-node  24 A successfully performs an inter-CU re-establishment, child node  30  can consider the cell(s) served by IAB-node  24 A as candidate cell(s), i.e. child node  30  does not need to avoid or de-prioritize the cell(s). For this reason, the re-establishment indication  270  may be a separate message in one example implementation. In another example implementation, the re-establishment indication  270  may be included as an additional information element of another message, such as the aforementioned Backhaul RLF Indication, e.g., condition notification  42 . 
     It should be understood that when child node  30  transmits the RRCReestablishmentRequest message such as shown in  FIG.  51 A , the PCI included in the message was the one of the old serving cell that child node  30  camped on before initiating the RRC re-establishment procedure. In the scenario depicted in  FIG.  45   , the old serving cell is one of the cells served by IAB-node  24 A, which is currently recognized as bounded to donor IAB node  22 - 2  as a result of the F1 setup procedure shown in  FIG.  46 B . Thus, when receiving the RRCReestablishmentRequest from child node  30 , based on the received PCI, donor IAB node  22 - 2  may look for the UE context of child node  30  in a local storage as shown in by act  51 - 8  in  FIG.  51 A . The context transfer for child/grandchild nodes of IAB-node  24 A shown in  FIG.  46 B  is a necessary step for the UE contexts to be present in the target donor node. 
     As mentioned above, the operation and mode disclosed above in the present embodiment, e.g., in the generic system and scenario of  FIG.  45   , may be also applicable to a case where IAB-node  24 A performs an inter-CU, e.g., inter-donor, handover, e.g. RRC reconfiguration with sync procedure.  FIG.  52    shows in more detail an example donor IAB node  22 , IAB-node  24 A, and child node  30  in which IAB-node  24 A performs such an inter-CU, e.g., inter-donor, handover. Unless otherwise noted, the structure and operation of the system of  FIG.  52    is similar to that of  FIG.  49   , and components and units in  FIG.  52    which have like reference numbers as the components and units of  FIG.  49    have same or similar structure or operation as in  FIG.  49   .  FIG.  52    additionally shows that donor IAB node  22 - 1  comprises handover controller  284 , which may be realized by or comprise the central unit (CU)  50 - 1  of donor IAB node  22 - 2 , and thus the donor node processor(s)  54 - 1 . Further, the IAB-node  24 A includes AS key generator  286 , which may be realized or comprise IAB node processor(s)  74 A. 
       FIG.  46 C  is an example message flow of the inter-CU handover that IAB-node  24 A of the system of  FIG.  52    performs as directed by donor IAB node  22 - 1 . Acts of  FIG.  46 C  which are similar to those of  FIG.  46 A  have the same act numbers, but differing acts have the act prefix  46 C. For example, as reflected by act  46 - 1 , before the handover both IAB-node  24 A and donor IAB node  22 - 1  are in RRC_Connected state for the connection involving child node  30 . As act  46 C- 1 , donor IAB node  22 - 1  may make a decision to handover IAB-node  24 A to a cell served by donor IAB node  22 - 2 . As act  46 C- 2 , donor IAB node  22 - 1  may then send a HANDOVER REQUEST message to donor IAB node  22 - 2  using XnAP, where the HANDOVER REQUEST may comprise the context of IAB-node  24 A. As act  46 - 3  the donor IAB node  22 - 2  acknowledges the handover request. Following reception of HANDOVER REQUEST ACKNOWLEDGE of act  46 C- 2 , as act  46 C- 4  donor IAB node  22 - 1  may send an RRCReconfiguration message to IAB-node  24 A, which may comprise NCC for generating a new AS security key(s) to be used with donor IAB node  22 - 2 . As act  46 C- 5 , the AS key generator  286  of IAB-node  24 A generates the AS security key(s) for use with donor IAB node  22 - 2 . As act  46 - 4  and act  46 - 5 , IAB-node  24 A may proceed to performing the Random Access procedure, followed by sending RRCReconfigurationComplete, e.g., as act  46 C- 5 . Similar to  FIG.  46 B , as act  46 C- 6  donor IAB node  22 - 1  may transfer to donor IAB node  22 - 2  UE contexts of some or all of the child/grandchild nodes of IAB-node  24 A. Likewise, IAB-node  24 A may initiate the F1 setup procedure with donor IAB node  22 - 2 , as reflected by act  46 - 12  and  46 - 13 . 
       FIG.  51 B  shows an example message flow of yet another RRC re-establishment procedure for child node  30 , which covers a case of the system of  FIG.  51    in which IAB-node  24 A performs an inter-CU handover as shown in  FIG.  46 C . The inter-CU handover is depicted as act  51 - 2  in  FIG.  51 B . As understood from  FIG.  51 B , the procedure after IAB-node  24 A perform the inter-CU handover is identical to the one shown in  FIG.  51 A . That is, the re-establishment indication  270 , shown as act  51 - 3 , can be also used for the case where IAB-node  24 A performs an inter-CU handover. 
       FIG.  53    shows example, representative, acts or steps performed by an IAB node of the system of  FIG.  52   . Act  53 - 1  comprises establishing RRC and F1AP connection with a first donor IAB node, e.g., with donor IAB node  22 - 1 . Act  53 - 2  comprises detecting an radio link failure (RLF) upstream, which may be detected at the direct upstream radio path of IAB-node  24 A, or informed by the parent IAB-node (if any) of IAB-node  24 A using a Backhaul RLF Indication. Act  53 - 3  comprises performing a re-establishment procedure with a second IAB donor node, e.g., donor IAB node  22 - 2 , as shown in  FIG.  46 B . Act  53 - 4  comprising setting up an F1AP connection with the second IAB donor node, e.g., donor IAB node  22 - 2 , also as shown in  FIG.  46 B . Act  53 - 5  comprises transmitting a re-establishment indication to the child nodes/UEs of IAB-node  24 A. 
       FIG.  54    shows example, representative, acts or steps performed by a child node of the system of  FIG.  52   . Act  54 - 1  comprises establishing an RRC connection with a first donor IAB node, e.g., donor IAB node  22 - 1 , through IAB-node  24 A. Act  54 - 2  comprises receiving a re-establishment indication  270  from the IAB node, e.g., IAB-node  24 A. Act  54 - 3  comprises performing a re-establishment procedure with a second IAB donor node, e.g., donor IAB node  22 - 2 , whereby child node  30 , may select a cell served by the IAB node, e.g., IAB-node  24 A. 
       FIG.  55    shows example, representative, acts or steps performed by a donor IAB node  22  of the systems of  FIG.  49    and  FIG.  52   . The donor IAB node such as donor IAB node  22 - 1  communicates over at least one radio interface to serve an IAB node and at least one inter-node interface to communicate with another access node, such as donor IAB node  22 - 2 . Act  55 - 1  comprises performing a first context transfer to send an RRC context of the IAB node; e.g., to donor IAB node  22 - 2 . Act  55 - 2  comprises initiating, based on the first context transfer, a second context transfer to send RRC contexts of wireless terminals that the IAB donor is serving through the IAB node. Act  55 - 3  comprises transmitting, to the access node, e.g., to donor IAB node  22 - 2 , the RRC context of the IAB node and the RRC contexts of wireless terminals. 
     Enhanced Conditional Handover Procedure 
     In some configurations or implementations, a child node (UE/IAB-node) may be configured with a conditional handover (CHO) configuration, e.g., a conditional reconfiguration, comprising one or more candidate target cells, also sometimes called “target candidate cells” or “candidate target SpCells” (Special Cells). Such candidate target cells may be served by the same current parent IAB-node of the child node. For example, in  FIG.  56   , a parent IAB-node, e.g., IAB node  24 A, serves Cell A 1 , A 2  and A 3 , and child node  30  is currently camping on Cell A 1 . In the scenario of  FIG.  56    child node  30  has been configured by Donor  22 - 1  with an RRCReconfiguration message  300  that facilitates conditional handover, CHO. The RRCReconfiguration message  300  indicates that Cell A 2  and Cell A 3  are the candidate target cells for a conditional handover. Table 1 is a listing which shows an example format and content of the RRCReconfiguration message  300 . 
       FIG.  57    is a graphical representation of relevant information elements in the RRCReconfiguration message  300  shown in Table  1 . The RRCReconfiguration message  300  may also be referred to herein as a first RRCReconfiguration message. The RRCReconfiguration message  300 , shown at the top of  FIG.  57   , may comprise a measurement configuration (measConfig) and a list of conditional reconfigurations  302  (condReconfigToAddMod). Each conditional reconfiguration  302 , which may correspond to one candidate target cell, may further comprise one or more measurement IDs (measId) and a cascaded RRCReconfiguration message  304 , also referred to as a second RRCReconfiguration message. The second RRCReconfiguration message  304  may be generated by an access node, e.g. gNB, IAB-CU, etc., that serves the corresponding candidate target cell. If the access node of the corresponding candidate target cell is different from the access node of the currently serving cell, the second RRCReconfiguration message  304  may be handed over to the currently serving access node, IAB-CU, via an inter-node protocol, such as Xn Application Protocol , XnAP, per 3GPP TS 38.423. Otherwise., e.g., in the scenario shown in  FIG.  56   , the second RRCReconfiguration message  304  may be generated by the currently serving access node, e.g., the CU part of Donor  22 - 1 . The second RRCReconfiguration message  304  may comprise an identity of the candidate target cell, e.g., physCellId, and may further comprise an uplink configuration, a downlink configuration and a RACH configuration to be used during a conditional handover execution for the candidate target cell. 
     As further shown in  FIG.  57   , each of the one or more measurement IDs, measId, may point to a measurement object, measObjectToAddMod, and a report configuration. reportConfigToAddMod. As shown in  FIG.  57   , the first RRCReconfiguration message  300  may include a list of measurement objects and a list of report configurations. It should be understood that the one or more measurement IDs, measId, included in a conditional reconfiguration  302  may be linked, e.g., through one of the measIdToAddMods in measConfig, to a pair of a measurement object ID, measObjectId, and a report configuration ID, reportConfigID, where the measurement object ID and the report configuration ID may point to one of the measurement objects, measObjectToAddMod, and one of the report configurations, reportConfigToAddMod, in the first RRCRecofiguration message  300 , respectively. 
     The measurement object may comprise configuration parameters necessary to perform measurements of cell(s) including the candidate target cell. The report configuration may comprise one or more events, each of which may further comprise offset/threshold(s) and other parameters, e.g., hysteresis and timeToTrigger. The report configuration associated with the conditional reconfiguration may have to be designated for a conditional handover. In other words, in Listing  1 , condTriggerConfig, not other choices like eventTriggerConfig, should be chosen for reportConfigNR associated with condReconfigToAddMod. 
     In  FIG.  57   , measConfig, condReconfigToAddMod, measId, RRCReconfiguration message  304 , physCellId, measObjectToAddMod, reportConfigToAddMod, measIdToAddMods, measObjectId, reportConfigID, may be information elements or other constituent components, e.g., of the RRCReconfiguration message  300 . 
     Table 2 is a listing which shows an example procedure for evaluating the conditional reconfiguration and executing a conditional handover. 
       FIG.  58 A  shows an example of a successful scenario for child node  30  of  FIG.  56    performing CHO, where Cell A 1  is the currently serving cell, e.g. PCell or SpCell, and Cell A 2  and Cell A 3  are the candidate target cells. First, child node is in RRC_CONNECTED with Donor  22 - 1  via Node  24 A, Act  58 A- 1 . Donor  22 - 1  may then decide to configure conditional handover, Act  58 A- 2 . Donor  22 - 1  may send, via a CU-DU protocol, such as aforementioned Fl-AP, one or more UE CONTEXT SETUP REQUEST messages to the DU part of Node A, illustrated by act  58 A- 3  and act  58 A- 4 . Each of the UE CONTEXT SETUP REQUEST message may comprise an identity of each of the candidate target cells, e.g., Cell A 2  or Cell A 3 , and handover preparation parameters, e.g., handoverPreparationInformation. Donor  22 - 1  may then send to the DU part of Node  24 A, using the CU-DU protocol, a DL RRC MESSAGE TRANSFER message, shown as act  58 A- 5 , which may include the RRCReconfiguration message of Table 1/ FIG.  57   , e.g., first RRCReconfiguration message  300 . In this example scenario, the first RRCReconfiguration message  300  may include two information elements of the type condReconfigToAddMod, each of which may comprise a second RRCReconfiguration message  302  for each of the candidate target cells. Upon receiving the DL RRC MESSAGE TRANSFER message, as act  58 - 6  the DU part of Node  24 A may send the first RRCReconfiguration message  300  to child node  30 , and child node  30  may respond with a RRCReconfigurationComplete message shown as act  58 A- 7 , which may be transferred to Donor  22 - 1  using an UL RRC MESSAGE TRANSFER message shown as act  58 A- 8 . 
     Based on the measurement configuration (measConfig) in the (first) RRCReconfiguration message  300 , child node  30  may perform measurements. In the scenario of  FIG.  58 A , child node  30  observes that the conditional event(s), condEventA 3 /condEventA 5 , in reportConfigNR is(are) fulfilled for Cell A 2 , as shown by act  58 A- 9 . For example, the measurements may indicate that the signal quality for Cell A 1  is degrading and/or the signal quality for Cell A 2  is increasing. Child node  30  may then apply the second RRCReconfiguration message  302  with the physical cell ID, physCellId, of reconfigurationWithSync being that of Cell A 2  to execute a handover to Cell A 2 . The handover execution may comprise sending Random Access Preamble as shown by act  58 A- 10 , receiving Random Access Response as shown by act  58 A- 11 , and sending RRCReconfigurationComplete as shown by act  58 A- 12 . Finally, the DU part of Node  24 A may send the RRCReconfigurationComplete to Donor  22 - 1  via UL RRC MESSAGE TRANSFER as shown by act  58 A- 13 . 
     The arrow for DL RRC MESSAGE TRANSFER shown as act  58 A- 3  or  58 A- 4  in  FIG.  58 A  is pointed to Cell A 2  or Cell A 3 , in order to depict that the handover preparation parameters, and possibly other parameters, are configured for the concerned cell. Indeed, DL RRC MESSAGE TRANSFER is sent to the DU part of the Node  24 A through the MT part, not through the DL/UL signals of the concerned cell. Likewise, UL RRC MESSAGE TRANSFER, shown as act  58 A- 8  or  58 A- 13 , is generated by the DU part for the concerned cell, and transmitted to Donor  22 - 1  by the MT part. 
       FIG.  58 B  shows a problematic scenario due to CHO triggered by the aforementioned backhaul (BH) RLF indication. Act  58 B- 1  to act  58 B- 8  of  FIG.  58 B  are identical to act  58 A- 1  to act  58 A- 8  of  FIG.  58 A . However, in the scenario of  FIG.  58 B , the MT part of Node  24 A may detect an event on the upstream link, e.g., towards Donor  22 - 1 , as act  58 B- 9 , that may trigger transmission of a backhaul, BH, radio link failure, RLF, indication, e.g., BH RLF. As disclosed in the preceding embodiments, the event may be: (1) detection of the RLF, (2) recovery failure of the RLF, unsuccessful reestablishment, (3) signal quality degraded to a (pre)configured threshold(s), or (4) any other event related to the upstream link. The DU part of Node  24 A may then transmit the BH RLF Indication in Cell A 1 , as shown by act  58 B- 10 , as well as Cell A 1 , Cell A 2  (not illustrated). 
     In the scenario of  FIG.  58 B , upon receiving the BH RLF indication, child node  30  may consider as if the RLF were detected for Cell A 1 , and decide to execute the conditional handover to Cell A 2 , as shown by Act  58 B- 11 . In similar manner as act  58 A- 10  to act  58 A- 12  of  FIG.  58 A , the conditional handover may involve sending a Random Access Preamble as shown by act  58 B- 12 , receiving a Random Access Response as shown by act  58 B- 13 , followed by sending a RRCReconfigurationComplete as shown by act  58 B- 14 . 
     In the scenario of  FIG.  58 B , Node  24 A is currently losing the upstream connection, and therefore may not be able to take any further actions. As a result, the execution of the conditional handover will not only become unsuccessful but will also be wasteful. This situation is caused by receiving the BH RLF indication from the currently serving cell and attempting to execute a conditional handover to the candidate target cell, without knowing that the candidate target cell is also served by the node experiencing the RLF. 
     In some configurations (not illustrated), when experiencing an RLF, Node  24 A may not even respond to Random Access Preambles. This would cause the random access procedure to fail after child node  30  re-transmitting a number of Random Access Preambles. 
       FIG.  59    shows an embodiment and mode which take advantages of node serving cell information, such as the node serving cell information  250  disclosed in the preceding embodiment, “ENHANCED RE-ESTABLISHMENT PROCEDURE”, and which utilizes the node serving cell information for the execution of a conditional handover. As used herein, node serving cell information may be list of cells or node identification information, e.g., information from which the identity of a serving node, such as IAB node  24 A in  FIG.  59   , may be determined. To cover both the situation in which the node serving cell information may be list of cells or and the situation in which the node identification information may be node identification information, the node serving information is said to “indicate” one or more cells served by the IAB node. 
       FIG.  59    particularly shows that the child node  30 , which may be an IAB node or a UE, for example, comprises node serving cell information-based conditional handover controller  310 . The node serving cell information-based conditional handover controller  310  is configured, upon receiving the backhaul RLF indication, to determine whether to trigger a conditional handover which was configured by a conditional reconfiguration, and to make such determination based on the node serving cell information. 
     The node serving cell information, in one configuration, may comprise a list of identities of cells served by Node  24 A. In another configuration, the node serving cell information may comprise a node identification transmitted by each of the served cells. 
     The node serving cell information  250  may be transmitted to the child node  30  in various ways. For example, the node serving cell information may be broadcasted via system information, e.g., via master information block, MIB, system information block 1, SIB1, and/or other system information block(s), SIB(s). Alternatively, the node serving cell information  250  may be signaled in a dedicated way such as a RRCReconfiguration message, for example. As another alternative, the node serving cell information  250  may be transmitted using Backhaul Adaptation Protocol, BAP. In yet another alternative or configuration, the node serving cell information may be included in the BH RLF indication. 
     In the embodiment of  FIG.  59   , child node  30  may be provided with the node serving cell information  250  and a configuration for a conditional handover, e.g., a reconfiguration message  300 . The reconfiguration message  300  may comprise a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, for example in the manner of the conditional reconfiguration  302  of  FIG.  57   . In being “provided” with the node serving cell information  250  and the reconfiguration message  300 , one or both of the node serving cell information  250  and reconfiguration message  300  may be either pre-configured at the child node  30  or supplied over the radio interface to the child node  30  by the network. 
     When receiving a condition notification  42 , the node serving cell information-based conditional handover controller  310  of child node  30  may not attempt to execute the conditional handover if the node serving cell information indicates that the candidate target cell is also served by the cell from which the condition notification  42  was received. On the other hand, the node serving cell information-based conditional handover controller  310  of child node  30  may allow the conditional handover to be performed in a case that the candidate target cell is not indicated by the node serving cell information, e.g. Cell B 1  in  FIG.  28   . p In the embodiment and mode of  FIG.  59   , the condition notification  42  may be any message or signal indicative of any problematic situation on a wireless backhaul link upstream from node  24 A, such as a BH RLF indication. 
     Thus, the node serving cell information-based conditional handover controller  310  of the child node  30  of  FIG.  59    essentially serves to selectively permit or deny conditional handovers based on the content of node serving cell information  250 . As such, the node serving cell information-based conditional handover controller  310  filters or excludes attempted conditional handovers that would be futile and/or wasteful. The node serving cell information-based conditional handover controller  310  does so by having advance knowledge or premonition of cells served by the IAB node  24 A which would commonly be affected by a condition that gave rise to the condition notification  42 , e.g., to the radio link failure (RLF). 
       FIG.  60    is a schematic view showing in more detail nodes of the example and generic telecommunications system of  FIG.  59    according to a non-limiting example embodiment and mode.  FIG.  60    shows wireless access node  22 - 1  as comprising central unit  50 - 1  and distributed unit  52 - 1 . The central unit  50 - 1  and distributed unit  52 - 1  may be realized by, e.g., be comprised of or include, one or more processor circuits, e.g., node processor(s)  54 - 1 . The one or more node processor(s)  54 - 1  may be shared by central unit  50 - 1  and distributed unit  52 - 1 , or each of central unit  50 - 1  and distributed unit  52 - 1  may comprise one or more node processor(s)  54 - 1 . Moreover, central unit  50 - 1  and distributed unit  52 - 1  may be co-located at a same node site, or alternatively one or more distributed units  52 - 2  may be located at sites remote from central unit  50 - 1  and connected thereto by a packet network. The distributed unit  52 - 1  may comprise transceiver circuitry  56 , which in turn may comprise transmitter circuitry  57  and receiver circuitry  58 . The transceiver circuitry  56  includes antenna(e) for the wireless transmission. Transmitter circuitry  57  includes, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  58  comprises, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
     As further shown in  FIG.  60   , node processor(s)  54 - 1  of wireless access node  22 - 1  may comprise message generator  60 ( 60 ) and handover coordinator  62 . The message generator  60 ( 60 ) serves to generate, e.g., the RRCReconfiguration message  300  as described herein. As mentioned above, the RRCReconfiguration message  300  comprises a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, understood, for example, with reference to  FIG.  57   . As understood with reference to one or more previously described example embodiments and modes, handover coordinator  62  may communicate with another wireless access node in a case in which a handover may be arranged for a target cell that is under control of another IAB donor node, such as wireless access node  22 - 2  illustrated in  FIG.  12   , for example. 
     As shown in  FIG.  60    the IAB-node  24 A, also known as wireless relay node  24 A, in an example embodiment and mode comprises relay node mobile termination unit  70 A and relay node distributed unit  72 A. The relay node mobile termination unit  70 A and relay node distributed unit  72 A may be realized by, e.g., by comprised of or include, one or more processor circuits, e.g., relay node processor(s)  74 A. The one or more relay node processor(s)  74 A may be shared by relay node mobile termination unit  70 A and relay node distributed unit  72 A, or each of relay node mobile termination unit  70 A and relay node distributed unit  72 A may comprise one or more relay node processor(s)  74 A. The relay node distributed unit  72 A may comprise transceiver circuitry  76 , which in turn may comprise transmitter circuitry  77  and receiver circuitry  78 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment. 
       FIG.  60    further shows that IAB-node  24 A may comprise radio condition detector  80  and notification generator  82 . Both condition detector  80  and notification generator  82  may be realized or comprised by relay node processor(s)  74 . The notification generator  82  serves to generate the condition notification  42 , based on a condition detected by condition detector  80 . 
       FIG.  60    shows child node  30  as comprising, in an example, non-limiting embodiment and mode, transceiver circuitry  86 . The transceiver circuitry  86  in turn may comprise transmitter circuitry  87  and receiver circuitry  88 . The transceiver circuitry  76  includes antenna(e) for the wireless transmission. Transmitter circuitry  77  may include, e.g., amplifier(s), modulation circuitry and other conventional transmission equipment. Receiver circuitry  78  may comprise, e.g., amplifiers, demodulation circuitry, and other conventional receiver equipment.  FIG.  60    further shows child node  30 , which (as indicated before) may be a user equipment or Integrated Access and Backhaul (IAB) node, as also comprising node processor circuitry, e.g., one or more node processor(s)  90 , and interfaces  92 , including one or more user interfaces. Such user interfaces may serve for both user input and output operations, and may comprise (for example) a screen such as a touch screen that can both display information to the user and receive information entered by the user. The user interface  92  may also include other types of devices, such as a speaker, a microphone, or a haptic feedback device, for example. 
     In an example, non-limiting embodiment and mode shown in  FIG.  60   , the child node  30  may include frame/message generator/handler  94  and a handover controller, shown particularly in  FIG.  60    as node serving cell information-based conditional handover controller  310 . As is understood by those skilled in the art, in some telecommunications system messages, signals, and/or data are communicated over a radio or air interface using one or more “resources”, e.g., “radio resource(s)”. The frame/message generator/handler  94  serves to handle messages, signals, and data received from other nodes, including but not limited to the conditional handover preparation message  40  and condition notification  42  described herein. 
       FIG.  61    illustrates an example scenario of the example embodiment and mode of  FIG.  59    and  FIG.  60   , wherein the node serving cell information is provided to the child node  30  (act  61 - 0 ). Act  61 - 1  to act  61 - 10  are identical to act  58 B- 1  to act  58 B- 10  in  FIG.  58 B , respectively. As act  61 - 11 , due to the configured node serving cell information, the child node  30  may refrain from executing the conditional handover to Cell A 2  or Cell A 3 , regardless of the signal quality/strength measured at any of these cells. Instead, child node  30  may initiate a re-establishment procedure, including a cell selection for a cell not indicated by the node serving cell information, followed by transmitting RRCReestablishmentRequest. For example, child node  30  may perform a re-establishment procedure for Cell B 1  of  FIG.  59   . If the conditional reconfiguration, e.g., of the RRCReconfiguration message  304 , includes Cell B 1  as a candidate target cell, child node  30  may perform the conditional handover to Cell B 1  (cell B 1  is illustrated in  FIG.  56    and  FIG.  59   ), as discussed in conjunction with  FIG.  62    below. 
     Table 2-2 shows an example procedure for evaluation and execution of the conditional reconfiguration, for the example embodiment and mode of  FIG.  59    and  FIG.  60   , where nodeServingCellInfo is an information element for the node serving cell information configured to child node  30 . 
       FIG.  62    is a flow chart showing example representative steps or acts performed by child node of  FIG.  59   . Act  62 - 0  comprises receiving node serving cell information from a serving cell. Act  62 - 1  comprises receiving a conditional reconfiguration to facilitate a conditional handover. As indicated above, in an embodiment and mode the conditional reconfiguration may be included in an RRCReconfiguration message  300 , in the example manner of conditional reconfiguration  302  Act  62 - 3  comprises receiving a condition notification. The condition notification  42  may be a backhaul (BH) radio link failure (RLF) indication, and may be received from the IAB node  24 A. Act  62 - 4  comprises using the node serving cell information to make a determination whether to trigger a conditional handover configured by the conditional reconfiguration. The determination of act  62 - 4  may comprise making a determination whether all of candidate target cell(s) in the conditional reconfiguration is(are) indicated in the node serving cell information. 
       FIG.  62    further shows optional acts  62 - 5  and  62 - 6 , one or both of which may be performed by the child node  30 , e.g., by node serving cell information-based conditional handover controller  310 , when appropriate. The optional nature of act  62 - 5  and act  62 - 6  is indicated by the acts being illustrated by broken lines in  FIG.  62   . Act  62 - 5  comprises initiating a re-establishment procedure, and in so doing avoiding (or deprioritizing) cell(s) indicated in the node serving cell information. Act  62 - 6  comprises executing a conditional handover to a candidate target cell not indicated in the node serving cell information, based on the conditional reconfiguration. Act  62 - 5  and act  62 - 6  are not performed when, for example, there are no candidate target cells other than those included in the node serving cell information. 
     Concerning act  62 - 5 , even when a candidate target cell is not indicated in the node serving cell information, child node  30  may or may not be able to execute a conditional handover to the candidate target cell. For example, if the signal quality/strength of the candidate target cell is not sufficient, child node  30  may choose not to perform the conditional handover and to look for other cell(s). 
       FIG.  63    is a flow chart showing example representative steps or acts that may be performed by Donor IAB node  22 - 1  of  FIG.  59    and  FIG.  60   . Act  63 - 0  comprises transmitting node serving cell information to a child node, such as child node  30 . The node serving cell information  250  may be transmitted, for example, via a dedicated signaling, e.g. RRCReconfiguration, via Node  24 A. Act  63 - 0  may not apply in a case that the node serving cell information is otherwise provided, e.g., is provided via system information, and for that reason is shown with broken lines as an optional act in  FIG.  63   . Act  63 - 1  comprises sending handover preparation information to the IAB nodes that serve(s) the candidate target cell(s). In an example embodiment and mode the handover preparation information may be sent via a CU-DU protocol, such as F1-AP, and may be sent to the DU part of Node  24 A that serve(s) candidate target cell(s), e.g., which serves Cell A 2  and Cell A 3  in the  FIG.  59    example scenario. Act  63 - 2  comprises transmitting a message including a conditional reconfiguration, such as RRCReconfiguration shown in Table 1/ FIG.  57   . 
     The message of act  63 - 2  which includes the conditional reconfiguration may be generated by the donor IAB node  22 - 1 , and is configured for use by the wireless terminal in conjunction with node serving cell information, upon receipt of a backhaul (BH) radio link failure (RLF) indication from the IAB node, to determine whether to trigger a conditional handover to the target candidate cell. The node serving cell information indicates one or more cells served by the IAB node. 
       FIG.  64    is a flow chart showing example representative steps or acts that may be performed by an IAB node such as IAB node  24  of  FIG.  59    and  FIG.  60   . Act  64 - 0  comprises transmitting a node serving cell information to the child node. In one example implement, the node serving cell information is broadcasted via system information, e.g. MIB, SIB1 or other SIB(s). In another example implement, the node serving cell information may be transmitted using BAP. Act  64 - 0  is an optional act, as indicated by broken lines in  FIG.  64   , and may not apply in a case that the node serving cell information is provided by a donor IAB node via a dedicated signaling. Act  64 - 1  comprises receiving handover preparation information to configure candidate target cells. For example, in the scenario of  FIG.  59    act  64 - 1  may comprise receiving handover preparation information to configure Cell A 2  and Cell A 3  as candidate target cells. Act  64 - 2  comprises detecting a condition for sending a condition notification. Such a condition may be, as disclosed earlier, a detection of an RLF, a recovery failure of an RLF, signal quality/strength becoming below a threshold(s), or any other radio condition(s) with regard to the upstream radio link(s) of Node  24 A. Act  64 - 3  comprises sending downstream, e.g., to child node  30 , an indication of the condition based on the detection of the condition, e.g., a BH RLF indication. The indication of the condition, e.g., condition notification  42 , is configured to be used in conjunction with serving cell information by the wireless terminal to determine to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     The technology disclosed herein, including the technology of the example embodiment and mode of  FIG.  59    and  FIG.  60   , discloses, among its many aspects, methods for handling cases where a child node of an IAB node performs a conditional handover procedure. The technology includes or encompasses one or more of the following non-exhaustive features:
         The IAB node may transmit, to the child node, node serving cell information that is used to identify cells served by the IAB node.   The child node may be configured with a conditional reconfiguration by an IAB donor.   The IAB node may transmit a backhaul radio link failure (RLF) indication to the child nodes/UEs when it detects an RLF or fails to recover an RLF detected on the upstream radio link.   Upon receiving the backhaul RLF indication, the child node may perform a conditional handover based on the conditional reconfiguration, wherein the child node refrains from executing a handover to a cell identified by the node serving cell information.   The node serving cell information may comprise a list of identifications of cells that are served by the IAB node, or may comprise a node identification of the IAB node.   The node serving cell information may be broadcasted via system information, or transmitted to the child node via a dedicated signaling.       

     
       
         
           
               
               
             
               
                 TABLE 1 
               
               
                   
               
             
            
               
                   
                 RRCReconfiguration ::=  SEQUENCE { 
               
               
                   
                   rrc-TransactionIdentifier     RRC-TransactionIdentifier, 
               
               
                   
                   criticalExtensions       CHOICE { 
               
               
                   
                     rrcReconfiguration      RRCReconfiguration-IEs, 
               
               
                   
                     criticalExtensionsFuture     SEQUENCE { } 
               
               
                   
                   } 
               
               
                   
                 } 
               
               
                   
                 RRCReconfiguration-IEs ::=    SEQUENCE { 
               
               
                   
                   radioBearerConfig       RadioBearerConfig 
               
               
                   
                 OPTIONAL, -- Need M 
               
               
                   
                   secondaryCellGroup       OCTET STRING (CONTAINING CellGroupConfig) 
               
               
                   
                 OPTIONAL, -- Need M 
               
               
                   
                   measConfig        MeasConfig 
               
               
                   
                 OPTIONAL, -- Need M 
               
               
                   
                   lateNonCriticalExtension     OCTET STRING 
               
               
                   
                 OPTIONAL, 
               
               
                   
                   nonCriticalExtension     RRCReconfiguration-v1530-IEs 
               
               
                   
                 OPTIONAL 
               
               
                   
                 } 
               
               
                   
                 RRCReconfiguration-1530-IEs ::= SEQUENCE { 
               
               
                   
                   masterCellGroup     OCTET STRING (CONTAINING CellGroupConfig) 
               
               
                   
                 OPTIONAL, -- Need M 
               
               
                   
                   fullConfig      ENUMERATED {true} 
               
               
                   
                 OPTIONAL, -- Cond FullConfig 
               
               
                   
                   dedicatedNAS-MessageList  SEQUENCE (SIZE(1..maxDRB)) OF DedicatedNAS-Message 
               
               
                   
                 OPTIONAL, -- Cond nonHO 
               
               
                   
                   masterKeyUpdate      MasterKeyUpdate 
               
               
                   
                 OPTIONAL, -- Cond MasterKeyChange 
               
               
                   
                   dedicatedSIB1-Delivery     OCTET STRING (CONTAINING SIB1) 
               
               
                   
                 OPTIONAL, -- Need N 
               
               
                   
                   dedicatedSystemInformationDelivery OCTET STRING (CONTAINING SystemInformation) 
               
               
                   
                 OPTIONAL, -- Need N 
               
               
                   
                   otherConfig            OtherConfig      OPTIONAL, -- 
               
               
                   
                   Need M 
               
               
                   
                   nonCriticalExtension         RRCReconfiguration-v1540-IEs 
               
               
                   
                 OPTIONAL 
               
               
                   
                 } 
               
               
                   
                 RRCReconfiguration-v1540-IEs ::=   SEQUENCE { 
               
               
                   
                   otherConfig-v1540      OtherConfig-v1540     OPTIONAL, -- Need M 
               
               
                   
                   nonCriticalExtension      RRCReconfiguration-v1560-IEs    OPTIONAL 
               
               
                   
                 } 
               
               
                   
                 RRCReconfiguration-v1560-IEs ::=     SEQUENCE { 
               
               
                   
                   mrdc-SecondaryCellGroupConfig    SetupRelease { MRDC-SecondaryCellGroupConfig } 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   radioBearerConfig2       OCTET STRING (CONTAINING RadioBearerConfig) 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   sk-Counter       SK-Counter 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   nonCriticalExtension    RRCReconfiguratioii-v16xy-IEs-v16xy-IEs { } 
               
               
                   
                 OPTIONAL 
               
               
                   
                 } 
               
               
                   
                 RRCReconfiguration-v16xy-IEs ::=     SEQUENCE { 
               
               
                   
                   conditionalReconfiguration-r16   ConditionalReconfiguration-r16 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   daps-SourceRelease-r16    ENUMERATED{true} 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   nonCriticalExtension     SEQUENCE { } 
               
               
                   
                 OPTIONAL 
               
               
                   
                 } 
               
               
                   
                 ... 
               
               
                   
                 ConditionalReconfiguration-r16 ::=        SEQUENCE { 
               
               
                   
                   attemptCondReconfig-r16        ENUMERATED {true}  OPTIONAL, -- 
               
               
                   
                 Need N 
               
               
                   
                   condReconfigToRemoveList-r16    CondReconfigToRemoveList-r16 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   condReconfigToAddModList-r16     CondReconfigToAddModList-r16 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 CondReconfigToRemoveList-r16 ::=  SEQUENCE (SIZE (1.. maxNrofCondCells)) OF 
               
               
                   
                 CondReconfigId-r16 
               
               
                   
                 CondReconfigToAddModList-r16 ::=      SEQUENCE (SIZE (1.. maxNrofCondCells)) 
               
               
                   
                 OF CondReconfigToAddMod-r16 
               
               
                   
                 CondReconfigToAddMod-r16 ::=   SEQUENCE { 
               
               
                   
                   condReconfigId-r16       CondConfigId-r16, 
               
               
                   
                   condExecutionCond-r16    SEQUENCE (SIZE (1..2)) OF MeasId OPTIONAL, 
               
               
                   
                  -- Need S 
               
               
                   
                   condRRCReconfig-r16  OCTET STRING (CONTAINING RRCReconfiguration) OPTIONAL, 
               
               
                   
                 -- Need S 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 CellGroupConfig ::=     SEQUENCE { 
               
               
                   
                   cellGroupId        CellGroupId, 
               
               
                   
                   rlc-BearerToAddModList  SEQUENCE (SIZE(1..maxLC-ID)) OF RLC-BearerConfig 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   rlc-BearerToReleaseList SEQUENCE (SIZE(1..maxLC-ID)) OF LogicalChannelIdentity 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   mac-CellGroupConfig    MAC-CellGroupConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   physicalCellGroupConfig  PhysicalCellGroupConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   spCellConfig     SpCellConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   sCellToAddModList     SEQUENCE (SIZE (1..maxNrofSCells)) OF 
               
               
                   
                 SCellConfig     OPTIONAL, -- NeedN 
               
               
                   
                   sCellToReleaseList      SEQUENCE (SIZE (1..maxNrofSCells)) OF SCellIndex 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   ..., 
               
               
                   
                   [[ 
               
               
                   
                   reportUplinkTxDirectCurrent    ENUMERATED {true} 
               
               
                   
                 OPTIONAL  -- Cond BWP-Reconfig 
               
               
                   
                   ]] 
               
               
                   
                 } 
               
               
                   
                 -- Serving cell specific MAC and PHY parameters for a SpCell: 
               
               
                   
                 SpCellConfig :=        SEQUENCE { 
               
               
                   
                   servCellIndex    ServCellIndex 
               
               
                   
                 OPTIONAL,  -- Cond SCG 
               
               
                   
                   reconfigurationWithSync   ReconfigurationWithSync 
               
               
                   
                 OPTIONAL,  -- Cond ReconfWithSync 
               
               
                   
                   rlf-TimersAndConstants   SetupRelease { RLF-Timers AndConstants } 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   rlmInSyncOutOfSyncThreshold   ENUMERATED {n1} 
               
               
                   
                 OPTIONAL,  -- Need S 
               
               
                   
                   spCellConfigDedicated    ServingCellConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 ReconfigurationWithSync ::=    SEQUENCE { 
               
               
                   
                   spCellConfigCommon    ServingCellConfigCommon 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   newUE-Identity     RNTI-Value, 
               
               
                   
                   t304       ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000, ms2000, 
               
               
                   
                 ms 10000}, 
               
               
                   
                   rach-ConfigDedicated    CHOICE { 
               
               
                   
                   uplink          RACH-ConfigDedicated, 
               
               
                   
                     supplementaryUplink    RACH-ConfigDedicated 
               
               
                   
                   }                        OPTIONAL,  -- Need N 
               
               
                   
                   ..., 
               
               
                   
                   [[ 
               
               
                   
                   smtc      SSB-MTC 
               
               
                   
                 OPTIONAL  -- Need S 
               
               
                   
                   ]] 
               
               
                   
                 } 
               
               
                   
                 ServingCellConfigCommon ::=    SEQUENCE { 
               
               
                   
                   physCellId       PhysCellId 
               
               
                   
                 OPTIONAL,  -- Cond HOAndServCellAdd, 
               
               
                   
                   downlinkConfigCommon  DownlinkConfigCommon 
               
               
                   
                 OPTIONAL,  -- Cond HOAndServCellAdd 
               
               
                   
                   uplinkConfigCommon   UplinkConfigCommon 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   supplementaryUplinkConfig  UplinkConfigCommon 
               
               
                   
                 OPTIONAL,  -- Need S 
               
               
                   
                   n-TimingAdvanceOffset   ENUMERATED { n0, n25600, n39936 } 
               
               
                   
                 OPTIONAL,  -- Need S 
               
               
                   
                   ssb-PositionsInBurst    CHOICE { 
               
               
                   
                     shortBitmap      BIT STRING (SIZE (4)), 
               
               
                   
                     mediumBitmap    BIT STRING (SIZE (8)), 
               
               
                   
                     longBitmap     BIT STRING (SIZE (64)) 
               
               
                   
                   } 
               
               
                   
                 OPTIONAL, -- Cond AbsFreqSSB 
               
               
                   
                   ssb-periodicityServingCell    ENUMERATED { ms5, ms10, ms20, ms40, ms80, ms160, 
               
               
                   
                 spare2, spare 1 } OPTIONAL, -- Need S 
               
               
                   
                   dmrs-TypeA-Position        ENUMERATED {pos2, pos3}, 
               
               
                   
                   lte-CRS-ToMatchAround          SetupRelease { RateMatchPatternLTE-CRS } 
               
               
                   
                 OPTIONAL, -- Need M 
               
               
                   
                   rateMatchPattemToAddModList   SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF 
               
               
                   
                 RateMatchPattern  OPTIONAL, -- Need N 
               
               
                   
                   rateMatchPatternToReleaseList   SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF 
               
               
                   
                 RateMatchPatternId OPTIONAL, -- Need N 
               
               
                   
                   ssbSubcarrierSpacing    SubcarrierSpacing 
               
               
                   
                 OPTIONAL, -- Cond HOAndServCellWithSSB 
               
               
                   
                   tdd-UL-DL-ConfigurationCommon   TDD-UL-DL-ConfigCommon 
               
               
                   
                 OPTIONAL, -- Cond TDD 
               
               
                   
                   ss-PBCH-BlockPower     INTEGER (−60..50), 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 MeasConfig :=            SEQUENCE { 
               
               
                   
                   measObjectToRemoveList       MeasObjectToRemoveList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   measObjectToAddModList      MeasObjectToAddModList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   reportConfigToRemoveList      ReportConfigToRemoveList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   reportConfigToAddModList      ReportConfigToAddModList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   measIdToRemoveList        MeasIdToRemoveList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   measIdToAddModList        MeasIdToAddModList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   s-MeasureConfig         CHOICE { 
               
               
                   
                     ssb-RSRP          RSRP-Range, 
               
               
                   
                     csi-RSRP          RSRP-Range 
               
               
                   
                   }                            OPTIONAL,  -- Need M 
               
               
                   
                   quantityConfig         QuantityConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   measGapConfig         MeasGapConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   measGapSharingConfig       MeasGapSharingConfig 
               
               
                   
                 OPTIONAL,  -- Need M 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 MeasObjectToAddModList  ::=    SEQUENCE (SIZE (SIZE (1..maxNrofObjectId))  OF 
               
               
                   
                 MeasObjectToAddMod  
               
               
                   
                 MeasObjectToAddMod ::=         SEQUENCE { 
               
               
                   
                   measObjectId           measObjectId, 
               
               
                   
                   measObject          CHOICE { 
               
               
                   
                     measObjectNR        measObjectNR, 
               
               
                   
                     ..., 
               
               
                   
                     measObjectEUTRA        MeasObjectEUTRA 
               
               
                   
                   } 
               
               
                   
                 } 
               
               
                   
                 MeasObjectNR ::=     SEQUENCE { 
               
               
                   
                   ssbFrequency     ARFCN-ValueNR 
               
               
                   
                 OPTIONAL,  -- Cond SSBorAssociatedSSB 
               
               
                   
                   ssbSubcarrierSpacing       SubcarrierSpacing 
               
               
                   
                 OPTIONAL,  -- Cond SSBorAssociatedSSB 
               
               
                   
                   smtc1      SSB-MTC 
               
               
                   
                 OPTIONAL,  -- Cond SSBorAssociatedSSB 
               
               
                   
                   smtc2      SSB-MTC2 
               
               
                   
                 OPTIONAL,  -- Cond IntraFreqConnected 
               
               
                   
                   refFreqCSI-RS     ARFCN-ValueNR 
               
               
                   
                 OPTIONAL,  -- Cond CSI-RS 
               
               
                   
                   referenceSignalConfig   ReferenceSignalConfig, 
               
               
                   
                   absThreshSS-BlocksConsolidation  ThresholdNR 
               
               
                   
                 OPTIONAL,  -- Need R 
               
               
                   
                   absThreshCSI-RS-Consolidation   ThresholdNR 
               
               
                   
                 OPTIONAL,  -- Need R 
               
               
                   
                   nrofSS-BlocksToAverage    INTEGER (2..maxNrofSS-BlocksToAverage) 
               
               
                   
                 OPTIONAL,  -- Need R 
               
               
                   
                   nrofCSI-RS-ResourcesToAverage   INTEGER (2..maxNrofCSI-RS- 
               
               
                   
                 ResourcesToAverage) 
               
               
                   
                 OPTIONAL,  -- Need R 
               
               
                   
                   quantityConfigIndex     INTEGER (1..maxNrofQuantityConfig), 
               
               
                   
                   offsetMO        Q-OffsetRangeList, 
               
               
                   
                   cellsToRemoveList     PCI-List 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   cellsToAddModList     CellsToAddModList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   blackCellsToRemoveList   PCI-RangeIndexList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   blackCellsToAddModList  SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI- 
               
               
                   
                 RangeElement 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   whiteCellsToRemoveList  PCI-RangeIndexList 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   whiteCellsToAddModList SEQUENCE (SIZE (1..maxNrofPCI-Ranges)) OF PCI- 
               
               
                   
                 RangeElement 
               
               
                   
                 OPTIONAL,  -- Need N 
               
               
                   
                   ..., 
               
               
                   
                   [[ 
               
               
                   
                   freqBandIndicatorNR   FreqBandIndicatorNR 
               
               
                   
                 OPTIONAL,  -- Need R 
               
               
                   
                   measCycleSCell    ENUMERATED {sf160, sf256, sf320, sf512, sf640, sf1024, sf1280} 
               
               
                   
                 OPTIONAL  -- Need R 
               
               
                   
                   ]], 
               
               
                   
                   [[ 
               
               
                   
                   t312-r16       SetupRelease ( T312-r16 ) 
               
               
                   
                 OPTIONAL  -- Need M 
               
               
                   
                   ]] 
               
               
                   
                 } 
               
               
                   
                 ReportConfigToAddModList ::=       SEQUENCE (SIZE (1..maxReportConfigId)) OF 
               
               
                   
                 ReportConfigToAddMod 
               
               
                   
                 ReportConfigToAddMod ::=     SEQUENCE { 
               
               
                   
                   reportConfigId      ReportConfigId, 
               
               
                   
                   reportConfig       CHOICE { 
               
               
                   
                     reportConfigNR     ReportConfigNR, 
               
               
                   
                     ..., 
               
               
                   
                     reportConfigInterRAT     ReportConfigInterRAT 
               
               
                   
                   } 
               
               
                   
                 } 
               
               
                   
                 ReportConfigNR ::=     SEQUENCE { 
               
               
                   
                   reportType      CHOICE { 
               
               
                   
                     periodical     PeriodicalReportConfig, 
               
               
                   
                     eventTriggered    EventTriggerConfig, 
               
               
                   
                     ..., 
               
               
                   
                     reportCGI    ReportCGI, 
               
               
                   
                     reportSFTD     ReportSFTD-NR, 
               
               
                   
                     condTriggerConfig-r16  CondTriggerConfig-r16 
               
               
                   
                   } 
               
               
                   
                 }  
               
               
                   
                 CondTriggerConfig-r16 ::=   SEQUENCE { 
               
               
                   
                   condEventId       CHOICE { 
               
               
                   
                     condEventA3     SEQUENCE { 
               
               
                   
                       a3-Offset    MeasTriggerQuantityOffset, 
               
               
                   
                       hysteresis    Hysteresis, 
               
               
                   
                       timeToTrigger   TimeToTrigger 
               
               
                   
                     }, 
               
               
                   
                     condEventA5     SEQUENCE { 
               
               
                   
                       a5-Threshold1   MeasTriggerQuantity, 
               
               
                   
                       a5-Threshold2   MeasTriggerQuantity, 
               
               
                   
                       hysteresis    Hysteresis, 
               
               
                   
                       timeToTrigger   TimeToTrigger 
               
               
                   
                     }, 
               
               
                   
                     ... 
               
               
                   
                   }, 
               
               
                   
                   rsType-r16       NR-RS-Type, 
               
               
                   
                   ... 
               
               
                   
                 } 
               
               
                   
                 MeasIdToAddModList ::=  SEQUENCE (SIZE (1..maxNrofMeasId)) OF 
               
               
                   
                 MeasIdToAddMod 
               
               
                   
                 MeasIdToAddMod ::=   SEQUENCE { 
               
               
                   
                   measId     MeasId, 
               
               
                   
                   measObjectId   MeasObjectId, 
               
               
                   
                   reportConfigId   ReportConfigId 
               
               
                   
                 } 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
             
               
                 TABLE 2-1 
               
               
                   
               
             
            
               
                   
                 5.3.5.13.4     Conditional reconfiguration evaluation 
               
               
                   
                 The UE shall: 
               
               
                   
                  1&gt; for each condReconfigId within the VarCondtionalReconfig: 
               
               
                   
                   2&gt; consider the cell which has a physical cell identity matching the value indicated in the 
               
               
                   
                    ServingCellConfigCommon included in the reconfigurationWithSync in the received 
               
               
                   
                    condRRCReconfig to be applicable cell; 
               
               
                   
                   2&gt; for each measId included in the measIdList within VarMeasConfig indicated in the 
               
               
                   
                    condExecutionCond associated to condReconfigId: 
               
               
                   
                    3&gt; if the entry condition(s) applicable for this event associated with the condReconfigId, i.e. the 
               
               
                   
                     event corresponding with the condEventId(s) of the corresponding condTriggerConfig 
               
               
                   
                     within VarConditionalReconfig, is fulfilled for the applicable cells for all measurements 
               
               
                   
                     after layer 3 filtering taken during the corresponding timeToTrigger defined for this event 
               
               
                   
                     within the VarConditionalReconfig: 
               
               
                   
                     4&gt; consider the event associated to that measId to be fulfilled; 
               
               
                   
                    3&gt; if the leaving condition(s) applicable for this event associated with the condReconfigId, i.e. 
               
               
                   
                     the event corresponding with the condEventId(s) of the corresponding condTriggerConfig 
               
               
                   
                     within VarConditionalReconfig, is fulfilled for the applicable cells for all measurements 
               
               
                   
                     after layer 3 filtering taken during the corresponding timeToTrigger defined for this event 
               
               
                   
                     within the VarConditionalReconfig: 
               
               
                   
                     4&gt; consider the event associated to that measId to be not fulfilled; 
               
               
                   
                   2&gt; if trigger conditions for all associated measId(s) within condTriggerConfig are fulfilled for all 
               
               
                   
                    associated measId(s) in condTriggerConfig: 
               
               
                   
                    3&gt; consider the target candidate cell within the stored condRRCReconfig, associated to that 
               
               
                   
                     condReconfigId, as a triggered cell; 
               
               
                   
                    3&gt; initiate the conditional reconfiguration execution, as specified in 5.3.5.13.5; 
               
               
                   
                  Note : up to 2 MeasId can be configured for each condReconfigId. The conditional handover event of 
               
               
                   
                     the 2 MeasId may have the same or different event conditions, triggering quantity, time to 
               
               
                   
                     trigger, and triggering threshoId. 
               
               
                   
                 5.3.5.13.5     Conditional reconfiguration execution 
               
               
                   
                 The UE shall: 
               
               
                   
                  1&gt; if more than one triggered cell exists: 
               
               
                   
                   2&gt; select one of the triggered cells as the selected cell for conditional reconfiguration execution; 
               
               
                   
                  1&gt; for the selected cell of conditional reconfiguration execution: 
               
               
                   
                   2&gt; apply the stored condRRCReconfig of the selected cell and perform the actions as specified in 
               
               
                   
                    5.3.5.3; 
               
               
                   
                 NOTE: If multiple NR cells are triggered in conditional reconfiguration execution, it is up to UE 
               
               
                   
                 implementation which one to select, e.g. the UE considers beams and beam quality to select one of the 
               
               
                   
                 triggered cells for execution. 
               
               
                   
               
            
           
         
       
     
     
       
         
           
               
               
             
               
                 TABLE 2-2 
               
               
                   
               
             
            
               
                   
                 5.3.5.13.4     Conditional reconfiguration evaluation 
               
               
                   
                 The UE shall: 
               
               
                   
                  1&gt; if UE receives BH RLF indication from a parent IAB-node: 
               
               
                   
                   2&gt; consider as if an RLF occurred on the radio link to the parent IAB-node; 
               
               
                   
                  1&gt; for each condReonfigId within the VarCondtionalReconfig: 
               
               
                   
                   2&gt; consider the cell which has a physical cell identity matching the value indicated in the 
               
               
                   
                    SeirvingCellConfigCommon included in the reconfigurationWithSync in the received 
               
               
                   
                    condRRCReconfig to be applicable cell; 
               
               
                   
                   2&gt; for each measId included in the measIdList within VarMeasConfig indicated in the 
               
               
                   
                    condExecutionCond associated to condReconfigId: 
               
               
                   
                    3&gt; if the entry condition(s) applicable for this event associated with the condReconfigId, i.e. the 
               
               
                   
                     event corresponding with the condEventId(s) of the corresponding condTriggerConfig 
               
               
                   
                     within VarConditionalReconfig, is fulfilled for the applicable cells for all measurements 
               
               
                   
                     after layer 3 filtering taken during the corresponding timeToTrigger defined for this event 
               
               
                   
                     within the VarConditionalReconfig: 
               
               
                   
                     4&gt; consider the event associated to that measId to be fulfilled; 
               
               
                   
                   3&gt; if the leaving condition(s) applicable for this event associated with the condReconfigId, i.e. 
               
               
                   
                    the event corresponding with the condEventId(s) of the corresponding condTriggerConfig 
               
               
                   
                    within VarConditionalReconfig, is fulfilled for the applicable cells for all measurements 
               
               
                   
                    after layer 3 filtering taken during the corresponding timeToTrigger defined for this event 
               
               
                   
                    within the VarConditionalReconfig: 
               
               
                   
                    4&gt; consider the event associated to that measId to be not fulfilled; 
               
               
                   
                  2&gt; if trigger conditions for all associated measId(s) within condTriggerConfig are fulfilled for all 
               
               
                   
                   associated measId(s) in condTriggerConfig: 
               
               
                   
                   3&gt; if the target candidate cell is not indicated by nodeServingCellInfo, or 
               
               
                   
                    nodeServingCellInfo is not configured: 
               
               
                   
                    4&gt; consider the target candidate cell within the stored condRRCReconfig, associated to 
               
               
                   
                     that condReconfigId, as a triggered cell; 
               
               
                   
                    4&gt; initiate the conditional reconfiguration execution, as specified in 5.3.5.13.5; 
               
               
                   
                 Note : up to 2 MeasId can be configured for each condReconfigId. The conditional handover event of 
               
               
                   
                    the 2 MeasId may have the same or different event conditions, triggering quantity, time to 
               
               
                   
                    trigger, and triggering threshold. 
               
               
                   
                 5.3.5.13.5     Conditional reconfiguration execution 
               
               
                   
                 The UE shall: 
               
               
                   
                  1&gt; if more than one triggered cell exists: 
               
               
                   
                   2&gt; select one of the triggered cells as the selected cell for conditional reconfiguration execution; 
               
               
                   
                  1&gt; for the selected cell of conditional reconfiguration execution: 
               
               
                   
                   2&gt; apply the stored condRRCReconfig of the selected cell and perform the actions as specified in 
               
               
                   
                    5.3.5.3; 
               
               
                   
                 NOTE: If multiple NR cells are triggered in conditional reconfiguration execution, it is up to UE 
               
               
                   
                 implementation which one to select, e.g. the UE considers beams and beam quality to select one of the 
               
               
                   
                 triggered cells for execution. 
               
               
                   
               
            
           
         
       
     
     It should be understood that the various foregoing example embodiments and modes may be utilized in conjunction with one or more example embodiments and modes described herein. 
     Certain units and functionalities of the systems  20  may be implemented by electronic machinery. For example, electronic machinery may refer to the processor circuitry described herein, such as IAB donor node processor(s)  54 , relay node processor(s)  74 , and node processor(s)  90 . Moreover, the term “processor circuitry” is not limited to mean one processor, but may include plural processors, with the plural processors operating at one or more sites. Moreover, as used herein the term “server” is not confined to one server unit, but may encompasses plural servers and/or other electronic equipment, and may be co-located at one site or distributed to different sites. With these understandings,  FIG.  65    shows an example of electronic machinery, e.g., processor circuitry, as comprising one or more processors  390 , program instruction memory  392 ; other memory  394  (e.g., RAM, cache, etc.); input/output interfaces  396  and  397 , peripheral interfaces  398 ; support circuits  399 ; and busses  400  for communication between the aforementioned units. The processor(s)  390  may comprise the processor circuitries described herein, for example, node processor(s)  54 , relay node processor(s)  74 , and node processor(s)  90 . 
     A memory or register described herein may be depicted by memory  394 , or any computer-readable medium, 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 is preferably of non-volatile nature, as and such may comprise memory. The support circuits  399  are coupled to the processors  390  for supporting the processor in a conventional manner. These circuits include cache, power supplies, clock circuits, input/output circuitry and subsystems, and the like. 
     Although the processes and methods of the disclosed embodiments may be discussed as being implemented as a software routine, some of the method steps that are disclosed therein may be performed in hardware as well as by a processor running software. As such, the embodiments may be implemented in software as executed upon a computer system, in hardware as an application specific integrated circuit or other type of hardware implementation, or a combination of software and hardware. The software routines of the disclosed embodiments are capable of being executed on any computer operating system, and is capable of being performed using any CPU architecture. 
     The functions of the various elements including functional blocks, including but not limited to those labeled or described as “computer”, “processor” or “controller”, may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented, and thus machine-implemented. 
     In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) [ASIC], and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. 
     In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer or processor or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, use of the term “processor” or “controller” may also be construed to refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above. 
     Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology disclosed herein may additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. 
     Moreover, each functional block or various features of the wireless terminal  30  and Integrated Access and Backhaul (IAB) nodes employed in each of the aforementioned embodiments may be implemented or executed by circuitry, which is typically an integrated circuit or a plurality of integrated circuits. The circuitry designed to execute the functions described in the present specification may comprise a general-purpose processor, a digital signal processor (DSP), an application specific or general application integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic, or a discrete hardware component, or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, a controller, a microcontroller or a state machine. The general-purpose processor or each circuit described above may be configured by a digital circuit or may be configured by an analogue circuit. Further, when a technology of making into an integrated circuit superseding integrated circuits at the present time appears due to advancement of a semiconductor technology, the integrated circuit by this technology is also able to be used. 
     It will be appreciated that the technology disclosed herein is directed to solving radio communications-centric issues and is necessarily rooted in computer technology and overcomes problems specifically arising in radio communications. Moreover, the technology disclosed herein improves basic function of a radio access network, e.g., methods and procedures to deal with problematic conditions on a backhaul link, such as radio link failure (RLF), for example, and avoiding routing loop problems when performing a cell selection procedure, e.g., after a radio link failure (RLF). 
     The technology disclosed herein encompasses one or more of the following non-limiting, non-exclusive example embodiments and modes: 
     Example Embodiment 1: A wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the wireless terminal comprising: receiver circuitry configured to receive: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; processor circuitry configured, upon receiving the BH radio link condition indication, to determine whether to trigger a conditional handover configured by the conditional reconfiguration based on the node serving cell information. 
     Example Embodiment 2: The wireless terminal of Example Embodiment 1, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover configured by the conditional reconfiguration is not triggered. 
     Example Embodiment 3: The wireless terminal of Example Embodiment 2, wherein the processor circuitry is further configured to initiate a re-establishment procedure in a case that a determination is made not to trigger a conditional handover to the one or more cells served by the IAB node. 
     Example Embodiment 4: The wireless terminal of Example Embodiment 2, wherein the processor circuitry is further wherein the processor circuitry is further configured to execute a conditional handover to a candidate target cell not indicated in the node serving cell information, based on the conditional reconfiguration. 
     Example Embodiment 5: The wireless terminal of Example Embodiment 1, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 6: The wireless terminal of Example Embodiment 1, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 7: The wireless terminal of Example Embodiment 1, wherein the node serving cell information is broadcasted by each of the one or more cells via system information. 
     Example Embodiment 8: The wireless terminal of Example Embodiment 1, wherein the node serving cell information is transmitted to the wireless terminal via a dedicated signaling. 
     Example Embodiment 9: The wireless terminal of Example Embodiment 1, wherein the node serving cell information is transmitted to the wireless terminal using Backhaul Adaptation Protocol (BAP). 
     Example Embodiment 10: The wireless terminal of Example Embodiment 1, wherein the node serving cell information is included in the BH radio link condition indication. 
     Example Embodiment 11: The wireless terminal of Example Embodiment 1, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 12: The wireless terminal of Example Embodiment 11, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 13: An integrated access and backhaul (IAB) node which communicates over at least two radio interfaces including a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the IAB node comprising: processor circuitry configured to detect a radio link condition on the first interface, and; transmitter circuitry configured to transmit, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine whether to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     Example Embodiment 14: The IAB node of Example Embodiment 13, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered. 
     Example Embodiment 15: The IAB node of Example Embodiment 13, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 16: The IAB node of Example Embodiment 13, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 17: The IAB node of Example Embodiment 13, wherein the transmitter circuitry is further configured to transmit to wireless terminal the node serving cell information using Backhaul Adaptation Protocol (BAP). 
     Example Embodiment 18: The IAB node of Example Embodiment 13, wherein the node serving cell information is included in the BH radio link condition indication. 
     Example Embodiment 19: The IAB node of Example Embodiment 13, wherein the transmitter circuitry is further configured to transmit, on each of the one or more cells, the node serving cell information via system information. 
     Example Embodiment 20: The IAB node of Example Embodiment 13, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 21: The IAB node o Example Embodiment 13, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 22: An Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the IAB donor comprising: processor circuitry configured to generate a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitter circuitry configured to transmit the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     Example Embodiment 23: The IAB donor of Example Embodiment 22, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered by the wireless terminal. 
     Example Embodiment 24: The IAB donor of Example Embodiment 22, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 25: The IAB donor of Example Embodiment 22, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 26: The IAB donor of Example Embodiment 22, wherein the transmitter circuitry is further configured to transmit to the wireless terminal the node serving cell information via a dedicated signaling. 
     Example Embodiment 27: The IAB donor of Example Embodiment 22, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 28: The IAB donor of Example Embodiment 22, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 29: A method for a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the method comprising: receiving: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; upon receiving the BH radio link condition indication, using the node serving cell information to make a determination whether to trigger a conditional handover configured by the conditional reconfiguration. 
     Example Embodiment 30: The method of Example Embodiment 29, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover configured by the conditional reconfiguration is not triggered. 
     Example Embodiment 31: The method of Example Embodiment 30, further comprising initiating a re-establishment procedure in a case that a determination is made not to trigger a conditional handover to the one or more cells served by the IAB node. 
     Example Embodiment 32: The method of Example Embodiment 30, further comprising executing a conditional handover to a candidate target cell not indicated in the node serving cell information, based on the conditional reconfiguration. 
     Example Embodiment 33: The method of Example Embodiment 29, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 34: The method of Example Embodiment 29, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 35: The method of Example Embodiment 34, the identification of the IAB node is broadcasted by each of the one or more cells via system information. 
     Example Embodiment 36: The method of Example Embodiment 29, wherein the node serving cell information is transmitted to the wireless terminal via a dedicated signaling. 
     Example Embodiment 37: The method of Example Embodiment 29, the node serving cell information is transmitted to the wireless terminal using Backhaul Adaptation Protocol (BAP). 
     Example Embodiment 38: The method of Example Embodiment 29, wherein the node serving cell information is included in the BH radio link condition indication. 
     Example Embodiment 39: The method of Example Embodiment 29, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 40: The method of Example Embodiment 29, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 41: A method for an integrated access and backhaul (IAB) node which communicates across at least two radio interfaces comprising a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the method comprising: detecting a radio link condition on the first interface, and; transmitting, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     Example Embodiment 42: The method of Example Embodiment 41, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered. 
     Example Embodiment 43: The method of Example Embodiment 41, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 44: The method of Example Embodiment 41, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 45: The method of Example Embodiment 41, further comprising transmitting to wireless terminal the node serving cell information using Backhaul Adaptation Protocol (BAP). 
     Example Embodiment 46: The method of Example Embodiment 41, wherein the node serving cell information is included in the BH condition indication. 
     Example Embodiment 47: The method of Example Embodiment 41, further comprising transmitting, on each of the one or more cells, the node serving cell information via system information. 
     Example Embodiment 48: The method of Example Embodiment 41, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 49: The method of Example Embodiment 41, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 50: A method for an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the method comprising: generating a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitting the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     Example Embodiment 51: The method of Example Embodiment 50, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional is not triggered by the wireless terminal. 
     Example Embodiment 52: The method of Example Embodiment 50, wherein the node serving cell information comprises identifications of the one or more cells. 
     Example Embodiment 53: The method of Example Embodiment 50, wherein the node serving cell information comprises an identification of the IAB node. 
     Example Embodiment 54: The method of Example Embodiment 50, further comprising transmitting to the wireless terminal the node serving cell information via a dedicated signaling. 
     Example Embodiment 55: The method of Example Embodiment 50, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     Example Embodiment 56: The method of Example Embodiment 50, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     One or more of the following documents may be pertinent to the technology disclosed herein (all of which are incorporated herein by reference in their entirety): 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                 R2-2000273 
                 Discussion on IAB BH RLF report mechanism in case of DCvivo 
               
               
                 R2-2000274 
                 Verification of BH RLF notification vivo 
               
               
                 R2-2000275 
                 [Draft] LS on BH RLF notification verification vivo 
               
               
                 R2-2000276 
                 RLF Notification Messages vivo 
               
               
                 R2-2000469 
                 Parent selection at IAB nodes during Initial Setup Intel 
               
               
                 R2-2000472 
                 Further discussion on Backhaul RLF handling Intel 
               
               
                 R2-2000484 
                 IAB access barring Qualcomm Incorporated 
               
               
                 R2-2000509 
                 Discussion on IAB BH RLF handling ZTE, Sanechips 
               
               
                 R2-2000510 
                 Discussion on BAP control PDU of RLF indication ZTE, Sanechips 
               
               
                 R2-2000512 
                 Consideration on IAB node access control ZTE, Sanechips 
               
               
                 R2-2000516 
                 Possible issues on Backhaul RLF handling Kyocera 
               
               
                 R2-2000522 
                 Backhaul RLF Recovery Huawei, HiSilicon 
               
               
                 R2-2000523 
                 Leftover issue for cell barring Huawei, HiSilicon 
               
               
                 R2-2000662 
                 Considerations on Intra-CU indication KDDI Corporation 
               
               
                 R2-2000743 
                 On Multi-connectivity for IAB Ericsson 
               
               
                 R2-2000744 
                 Security for inter-IAB node Signalling Ericsson 
               
               
                 R2-2000749 
                 Further details on Backhaul link RLF Notification Types to Downstream 
               
               
                   
                 Node(s) Ericsson 
               
               
                 R2-2000751 
                 On cell Reservations in MIB and SIB1 Ericsson 
               
               
                 R2-2000752 
                 Draft CR to 36.304 on cell Reservations for IAB-MTs Ericsson 
               
               
                 R2-2000753 
                 Draft CR to 38.304 on cell Reservations for IAB-MTs Ericsson 
               
               
                 R2-2000754 
                 IAB-MT Feature Capabilities Ericsson 
               
               
                 R2-2000824 
                 PWS information handling in IAB Sony 
               
               
                 R2-2000835 
                 IAB Cell Barring Sony 
               
               
                 R2-2000892 
                 Views on Cell Barring Mechanism for IAB CATT 
               
               
                 R2-2001021 
                 Cell selection for IAB RLF recovery Lenovo, Motorola Mobility 
               
               
                 R2-2001056 
                 BH link failure handling Nokia, Nokia Shanghai Bell 
               
               
                 R2-2001057 
                 Remaining aspects of F1AP transport in EN-DC Nokia, Nokia Shanghai 
               
               
                   
                 Bell 
               
               
                 R2-2001058 
                 Remaining aspects of IAB initial access Nokia, Nokia Shanghai Bell 
               
               
                 R2-2001348 
                 Cell Selection for Backhaul RLF Recovery Futurewei Technologies 
               
               
                 R2-2001523 
                 Access control in IAB networks LG Electronics France 
               
               
                 R2-2001524 
                 Necessity of even earlier BH RLF notification LG Electronics France 
               
               
                 R2-2001525 
                 BH RLF Notification Termination Layer LG Electronics France 
               
               
                 R2-2001605 
                 Differential barring for IAB nodes and UEsFuturewei Technologies 
               
               
                 R2-2001624 
                 NR-DC support in IAB (signaling perspective) Samsung R&amp;D Institute 
               
               
                   
                 UK 
               
               
                 R2-2001625 
                 F1AP related terminology in NSA IAB Samsung R&amp;D Institute UK 
               
               
                 R2-2001633 
                 Remaining issues on IAB RLF Samsung R&amp;D Institute UK 
               
               
                 R2-2001634 
                 EN-DC support in IAB Samsung R&amp;D Institute UK 
               
               
                 R2-2002058 
                 Summary of 6.1.5.3: SI Broadcast, cell Restrictions/Reservation and 
               
               
                   
                 Barring, Initial Access, and Connection Setup Ericsson 
               
               
                 R2-2002285 
                 Email discussion to progress on: SI Broadcast, cell 
               
               
                   
                 Restrictions/Reservation and Barring, Initial Access, and Connection Setup Ericsson 
               
               
                   
                 (rapporteur) 
               
               
                   
               
            
           
         
       
     
     Although the description above contains many specificities, these should not be construed as limiting the scope of the technology disclosed herein but as merely providing illustrations of some of the presently preferred embodiments of the technology disclosed herein. Thus the scope of the technology disclosed herein should be determined by the appended claims and their legal equivalents. Therefore, it will be appreciated that the scope of the technology disclosed herein fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the technology disclosed herein is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more.” The above-described embodiments could be combined with one another. All structural, chemical, and functional equivalents to the elements of the above-described preferred embodiment that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the technology disclosed herein, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. 
     In one example, a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the wireless terminal comprising: receiver circuitry configured to receive: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; processor circuitry configured, upon receiving the BH radio link condition indication, to determine whether to trigger a conditional handover configured by the conditional reconfiguration based on the node serving cell information. 
     In one example, the wireless terminal, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover configured by the conditional reconfiguration is not triggered. 
     In one example, the wireless terminal, wherein the processor circuitry is further configured to initiate a re-establishment procedure in a case that a determination is made not to trigger a conditional handover to the one or more cells served by the IAB node. 
     In one example, the wireless terminal, wherein the processor circuitry is further wherein the processor circuitry is further configured to execute a conditional handover to a candidate target cell not indicated in the node serving cell information, based on the conditional reconfiguration. 
     In one example, the wireless terminal, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the wireless terminal, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the wireless terminal, wherein the node serving cell information is broadcasted by each of the one or more cells via system information. 
     In one example, the wireless terminal, wherein the node serving cell information is transmitted to the wireless terminal via a dedicated signaling. 
     In one example, the wireless terminal, wherein the node serving cell information is transmitted to the wireless terminal using Backhaul Adaptation Protocol (BAP). 
     In one example, the wireless terminal, wherein the node serving cell information is included in the BH radio link condition indication. 
     In one example, the wireless terminal, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the wireless terminal, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, an integrated access and backhaul (IAB) node which communicates over at least two radio interfaces including a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the IAB node comprising: processor circuitry configured to detect a radio link condition on the first interface, and; transmitter circuitry configured to transmit, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine whether to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, the IAB node, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered. 
     In one example, the IAB node, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the IAB node, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the IAB node, wherein the transmitter circuitry is further configured to transmit to wireless terminal the node serving cell information using Backhaul Adaptation Protocol (BAP). 
     In one example, the IAB node, wherein the node serving cell information is included in the BH radio link condition indication. 
     In one example, the IAB node, wherein the transmitter circuitry is further configured to transmit, on each of the one or more cells, the node serving cell information via system information. 
     In one example, the IAB node, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the IAB node, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the IAB donor comprising: processor circuitry configured to generate a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitter circuitry configured to transmit the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     In one example, the IAB donor, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered by the wireless terminal. 
     In one example, the IAB donor, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the IAB donor, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the IAB donor, wherein the transmitter circuitry is further configured to transmit to the wireless terminal the node serving cell information via a dedicated signaling. 
     In one example, the IAB donor, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the IAB donor, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the method comprising: receiving: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; upon receiving the BH radio link condition indication, using the node serving cell information to make a determination whether to trigger a conditional handover configured by the conditional reconfiguration. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover configured by the conditional reconfiguration is not triggered. 
     In one example, the method, further comprising initiating a re-establishment procedure in a case that a determination is made not to trigger a conditional handover to the one or more cells served by the IAB node. 
     In one example, the method, further comprising executing a conditional handover to a candidate target cell not indicated in the node serving cell information, based on the conditional reconfiguration. 
     In one example, the method, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the method, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the method, the identification of the IAB node is broadcasted by each of the one or more cells via system information. 
     In one example, the method, wherein the node serving cell information is transmitted to the wireless terminal via a dedicated signaling. 
     In one example, the method, the node serving cell information is transmitted to the wireless terminal using Backhaul Adaptation Protocol (BAP). 
     In one example, the method, wherein the node serving cell information is included in the BH radio link condition indication. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for an integrated access and backhaul (IAB) node which communicates across at least two radio interfaces comprising a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the method comprising: detecting a radio link condition on the first interface, and; transmitting, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional handover is not triggered. 
     In one example, the method, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the method, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the method, further comprising transmitting to wireless terminal the node serving cell information using Backhaul Adaptation Protocol (BAP). 
     In one example, the method, wherein the node serving cell information is included in the BH condition indication. 
     In one example, the method, further comprising transmitting, on each of the one or more cells, the node serving cell information via system information. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the method comprising: generating a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitting the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the conditional is not triggered by the wireless terminal. 
     In one example, the method, wherein the node serving cell information comprises identifications of the one or more cells. 
     In one example, the method, wherein the node serving cell information comprises an identification of the IAB node. 
     In one example, the method, further comprising transmitting to the wireless terminal the node serving cell information via a dedicated signaling. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the wireless terminal comprising: receiver circuitry configured to receive: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; processor circuitry configured, upon receiving the BH radio link condition indication, to determine whether to trigger a conditional handover configured by the conditional reconfiguration based on the node serving cell information. 
     In one example, the wireless terminal, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger the conditional handover. 
     In one example, the wireless terminal, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers the conditional handover. 
     In one example, the wireless terminal, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node. 
     In one example, the wireless terminal, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, an integrated access and backhaul (IAB) node which communicates over at least two radio interfaces including a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the IAB node comprising: processor circuitry configured to detect a radio link condition on the first interface, and; transmitter circuitry configured to transmit, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine whether to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, the IAB node, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger the conditional handover. 
     In one example, the IAB node, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers the conditional handover. 
     In one example, the IAB node, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the IAB node, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the IAB donor comprising: processor circuitry configured to generate a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitter circuitry configured to transmit the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     In one example, the IAB donor, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger the conditional handover. 
     In one example, the IAB donor, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers the conditional handover. 
     In one example, the IAB donor, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the IAB donor, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for a wireless terminal that communicates with an Integrated Access and Backhaul (IAB) donor via an IAB node, the method comprising: receiving: node serving cell information indicating one or more cells served by the IAB node; a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; a backhaul (BH) radio link condition indication; upon receiving the BH radio link condition indication, using the node serving cell information to make a determination whether to trigger a conditional handover configured by the conditional reconfiguration. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger the conditional handover. 
     In one example, the method, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers the conditional handover. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for an integrated access and backhaul (IAB) node which communicates across at least two radio interfaces comprising a first interface and a second interface, the first interface being configured to establish a radio resource control (RRC) connection with an IAB donor, the second interface being configured to serve one or more cells to communicate with a wireless terminal, the method comprising: detecting a radio link condition on the first interface, and; transmitting, based on the radio link condition, a backhaul (BH) radio link condition indication via the one or more cells; wherein the BH radio link condition indication is configured to be used in conjunction with node serving cell information by the wireless terminal to determine to trigger a conditional handover to a target candidate cell, the node serving cell information being used to indicate the one or more cells. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger the conditional handover. 
     In one example, the method, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers the conditional handover. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein the BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails. 
     In one example, a method for an Integrated access and backhaul (IAB) donor that communicates with a wireless terminal via an IAB node, the method comprising: generating a reconfiguration message comprising a conditional reconfiguration, the conditional reconfiguration further comprising at least one identity of a target candidate cell, and; transmitting the reconfiguration message to the wireless terminal; wherein the conditional reconfiguration is configured to be used by the wireless terminal, in conjunction with node serving cell information, to determine, upon receipt of a backhaul (BH) radio link condition indication from the IAB node, whether to trigger a conditional handover to the target candidate cell, the node serving cell information indicating one or more cells served by the IAB node. 
     In one example, the method, wherein, in a case that the target candidate cell is indicated by the node serving cell information, the BH radio link condition indication does not trigger conditional. 
     In one example, the method, wherein, in a case that the target candidate cell is not indicated by the node serving cell information, the BH radio link condition indication triggers conditional. serving cell information via a dedicated signaling. 
     In one example, the method, wherein the BH radio link condition indication indicates that a radio link failure (RLF) is detected on a radio link between the donor node and the IAB node fails. 
     In one example, the method, wherein BH radio link condition indication indicates that a recovery procedure for a radio link failure (RLF) detected on a radio link between the donor node and the IAB node fails.