CN110621050A

CN110621050A - Network link topology adaptation method and access and return integrated node

Info

Publication number: CN110621050A
Application number: CN201910530587.XA
Authority: CN
Inventors: 蔡慈真; 邱俊渊; 林荣懋
Original assignee: Industrial Technology Research Institute ITRI
Current assignee: Industrial Technology Research Institute ITRI
Priority date: 2018-06-20
Filing date: 2019-06-19
Publication date: 2019-12-27

Abstract

The present disclosure relates to a network link topology adaptation method for an access and backhaul integrated node and an access and backhaul integrated node using the same. In one aspect, the present disclosure relates to a network link topology adaptation method used by a transmitting access and backhaul integrated node, and the method will include, without limitation: receiving a topology adaptation configuration from an upstream access and backhaul integration node, the topology adaptation configuration comprising blocking related parameters; determining whether a blocking condition of a radio link has occurred based on the blocking-related parameter; and sending a request to trigger a handover from the first network link topology to the second network link topology.

Description

Network link topology adaptation method and access and return integrated node

Technical Field

The present disclosure relates to a network link topology adaptation method for an Integrated Access and Backhaul (IAB) node and an IAB node using the same.

Background

Currently, in the Fifth Generation (5G) New Radio (NR), the millimeter wave (mmWave) spectrum will be used. Since the available bandwidth of the 5G NR communication system is larger than that of the Long-Term Evolution (LTE) communication system, and in addition, the coming new deployment of the massive multiple-input multiple-output (MIMO) or multi-beam communication system of the 5G NR communication system, there will be opportunities to develop and deploy integrated access and backhaul Integrated (IAB) links.

Fig. 1 illustrates an example of a plurality of IAB nodes in a 5G NR communication system. For the communication system shown in fig. 1, there may be at least three IAB nodes that provide wireless access to multiple User Equipments (UEs) and are connected to each other via backhaul links, which may be wireline or wireless. For example, IAB node a may receive information from the core network via fiber optic transport (fiber optic transport) and deliver such information to IAB node B or IAB node C via respective backhaul links, as each IAB node may provide access to one or more UEs. This network scheme may enable easier deployment of densely connected cell networks by establishing many control and data channels or flows that are integrated to provide access to the UEs.

However, such a deployment scheme as shown in fig. 1 can be easily blocked, since 5G NR tends to have antennas of a directional nature. The blockage may be temporary, such as may be due to a moving object (e.g., a vehicle); may be less transient, such as seasonal changes (e.g., leaves); or may be more permanent in nature, such as an infrastructure change (e.g., a new building). This vulnerability may be more apparent for IAB nodes where the entity is stationary. In addition, traffic variations may cause uneven load distribution on the wireless backhaul link, resulting in congestion (congestion).

Fig. 2A-2B illustrate how an IAB node may react to network blocking. Referring to fig. 2A, assume that a first IAB node 201 receives information from an IAB donor (donor) and forwards the information to a second IAB node 202, but that blocking has occurred between the first IAB node 201 and the second IAB node 202. In this scenario, the network will need to react quickly and correctly. For example, the network may reroute transmissions such that the IAB donor sends information to the third IAB node 203 via the first IAB node 201 such that the third IAB node 203 may forward the information to the second IAB node 202.

Referring to fig. 2B, assume that the first IAB node 201 receives information from an IAB donor and forwards the information to the third IAB node 203, but that blocking has occurred between the first IAB node 201 and the third IAB node 203. In this scenario, the network would need to decide on a suitable second upstream node and at the same time try to reduce the signal overhead. For example, the network may reroute transmissions such that the IAB donor sends information to the fourth IAB node 204, which the fourth IAB node 204 will forward to the third IAB child node (child node) 203. Such an effort may be more efficient than the fourth IAB node 204 forwarding information to the third IAB child node 203 via the fifth IAB node 205.

It is observed that the adaptation may be heavily dependent on the network topology, and the network will need to implement a more appropriate topology adaptation mechanism to address the blocking. Topology adaptation would involve a procedure to autonomously reconfigure the backhaul network under conditions such as blocking or congestion without interrupting service to the UE. Therefore, a physically fixed relay (e.g., IAB node) would need to have a mechanism for dynamic adaptation to mitigate blocking and congestion.

Topology adaptation can affect network performance because different topologies can affect the network in different ways. For example, an IAB node with only one upstream IAB node may have only one upstream IAB node and thus routing simplicity, since there is only one path between the source and destination and only one active radio link needs to be maintained to carry out tasks such as: monitoring a physical downlink-controlled channel (PDCCH), transmitting a buffer status report, synchronizing a Downlink (DL) with an Uplink (UL), transmitting a Physical Head Room (PHR), and the like. However, when the link is poor, subsequent reselection and handoff procedures may cause approximately 350ms to 15ms service interruption.

An IAB node with more than one upstream IAB node has high reliability and fast path switch because a supporting Secondary Cell Group (SCG) can be handed over directly to a Master Cell Group (MCG) without going through the add and release procedure in LTE. But due to the need to maintain more than one active radio link, an increased routing complexity of the network may arise due to having multiple paths and due to the maintenance of multiple entries of routing tables from the source to the destination, etc.

Since the IAB node may need to react dynamically to blocking and network congestion, another robust mechanism (robust mechanism) for network adaptation by the IAB node may be employed.

Disclosure of Invention

Accordingly, the present disclosure relates to a network link topology adaptation method for an IAB node and an IAB node using the same.

In one aspect, the present disclosure relates to a network link topology adaptation method used by a sending IAB node, and the method will include, without limitation: receiving a topology adaptation configuration from an upstream IAB node, the topology adaptation configuration comprising blocking related parameters; determining whether a blocking condition of a radio link has occurred based on the blocking-related parameter; and sending a request to trigger a handover from the first network link topology to the second network link topology.

In one aspect, the present disclosure relates to a network link topology adaptation method for use by a receiving IAB node, and the method will include, without limitation: sending a topology adaptation configuration, the topology adaptation configuration comprising blocking related parameters; receiving a request indicating that a handover from a first network link topology to a second network link topology is triggered; and sending a command to trigger a handover from the first network link topology to the second network link topology.

In one aspect, the present disclosure is directed to a sending IAB node, including, without limitation: a transceiver and a processor coupled to the transceiver. The processor is configured to at least: receiving a topology adaptation configuration from an upstream IAB node, the topology adaptation configuration comprising blocking related parameters; determining whether a blocking condition of a radio link has occurred based on the blocking-related parameter; and sending a request to trigger a handover from the first network link topology to the second network link topology.

In one aspect, the present disclosure is directed to a receiving IAB node, including, without limitation: a transceiver and a processor coupled to the transceiver. The processor is configured to at least: sending a topology adaptation configuration, the topology adaptation configuration comprising blocking related parameters; receiving a request indicating that a handover from a first network link topology to a second network link topology is triggered; and sending a command to trigger a handover from the first network link topology to the second network link topology.

In order that the aforementioned features and advantages of the present disclosure will be readily understood, exemplary embodiments are described in detail below with reference to the accompanying drawings. It is to be understood that both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the disclosure of the claimed subject matter.

It should be understood, however, that the present disclosure may not include all aspects and embodiments of the present disclosure, and is therefore not intended to be limiting or restrictive in any way. In addition, the present disclosure will include improvements and modifications apparent to those skilled in the art.

Drawings

The accompanying drawings are included to provide a further understanding of the disclosure, and are incorporated into and constitute a part of this specification. The drawings illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure.

Fig. 1 illustrates an example of a 5G NR communication network in which a plurality of IAB nodes are deployed to provide access to UEs and to provide backhaul links.

Fig. 2A-2B illustrate how an IAB node may react to network blocking.

Fig. 3A illustrates a network link topology adaptation method used by a sending IAB node or user equipment in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 3B illustrates a network link topology adaptation method used by a receiving IAB node in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 4 illustrates a sending IAB node or a receiving IAB node in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 5 is a signal diagram illustrating sending a second service IAB request in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 6 illustrates a Beam Failure Recovery (BFR) detection mechanism in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 7 illustrates a first exemplary embodiment of a BFR detection mechanism.

Fig. 8 illustrates a second exemplary embodiment of a BFR detection mechanism.

Fig. 9 illustrates a third exemplary embodiment of a BFR detection mechanism.

Fig. 10 illustrates a fourth exemplary embodiment of a BFR detection mechanism.

Fig. 11 illustrates a Radio Link Failure (RLF) detection mechanism in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 12 shows a first exemplary embodiment of an RLF detection mechanism.

Fig. 13 illustrates a second exemplary embodiment of an RLF detection mechanism.

Fig. 14 shows a third exemplary embodiment of an RLF detection mechanism.

Fig. 15 shows a fourth exemplary embodiment of the RLF detection mechanism.

Fig. 16 illustrates a first exemplary embodiment of a Reference Signal Received Power (RSRP)/Reference Signal Received Quality (RSRQ) evaluation mechanism.

Fig. 17 illustrates a second exemplary embodiment of an RSRP/RSRQ evaluation mechanism.

Fig. 18 is a signal diagram illustrating the addition of a second serving IAB node in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 19 is a signal diagram illustrating the release of the second service IAB in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 20 is a signal diagram illustrating a handoff to a second service IAB in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 21 is a signal diagram illustrating another exemplary embodiment of handing off to a second serving IAB.

Fig. 22 shows a signal diagram of an exemplary embodiment of handing off to a target IAB in accordance with one of the exemplary embodiments of the present disclosure.

Fig. 23 illustrates a signal diagram of changing the second service IAB in accordance with one of the exemplary embodiments of the present disclosure.

Detailed Description

Reference will now be made in detail to the present exemplary embodiments of the disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings and the description to refer to the same or like parts.

In view of the above challenges, the present disclosure proposes a solution that includes a way to detect a blocking condition using, for example, the following techniques: detecting Beam Failure Recovery (BFR), detecting Radio Link Failure (RLF), and measuring signal strength as a function of Reference Signal Received Power (RSRP) or Reference Signal Received Quality (RSRQ) of the signal. In response to detecting the blocking condition, the network may adapt to the condition by changing a network link topology of the network. For example, an IAB node may send a request to trigger a Dual Connectivity (DC) to add, change, or delete another IAB node interacting with the IAB node, or may handoff data traffic to another IAB node. The present disclosure also provides four IAB-DC flows including a flow for adding a second serving IAB node, a flow for releasing the second serving IAB node, a flow for handing off a radio link to a second serving or target IAB node, and a flow for changing the second serving IAB node.

It may be noted that although the IAB node may send a request to establish the IAB-DC, beam measurement reporting would not be appropriate since the IAB node may be physically fixed, and may require a long period of time to complete the reporting. However, the blocking condition may also be short-term, and thus occurs without the serving node being aware of the blocking. In addition, the child node may not report the blocking condition quickly. Thus, service interruption may cause harm to the wireless backhaul.

Fig. 3A illustrates a network link topology adaptation method used by a sending IAB node or user equipment in accordance with one of the exemplary embodiments of the present disclosure. In step S301, the IAB node will receive a topology adaptation configuration from an upstream IAB node, the topology adaptation configuration comprising blocking related parameters. After receiving the topology adaptation configuration, the IAB node will determine whether a blocking condition of the radio link has occurred based on the blocking related parameter in step S302. In step S303, the IAB node will send a request to trigger a handover from the first network link topology to the second network link topology.

The blocking condition may be determined in various ways including: detect BFR, detect RLF, or measure RSRP or RSRQ. One embodiment includes determining whether one or more preamble signal transmissions during Beam Fault Recovery (BFR) have exceeded a preamble signal transmission time threshold and sending a request in response to having exceeded the preamble signal transmission time threshold.

Similarly, an embodiment includes determining whether an accumulated time of preamble signal transmissions during the BFR within the monitoring window has exceeded an accumulated time threshold and sending a request in response to the accumulated time threshold having been exceeded.

Similarly, an embodiment includes determining whether the amount of BFRs has exceeded a BFR amount threshold and sending a request in response to having exceeded the BFR amount threshold.

Similarly, an embodiment includes determining whether a quantity of beam failure instances from lower layers has exceeded a beam failure instance quantity threshold and sending a request in response to having exceeded the beam failure instance quantity threshold.

Similarly, an embodiment includes determining whether a time of the radio problem recovery period has exceeded a radio problem recovery period threshold and sending a request in response to the radio problem recovery period threshold having been exceeded.

Similarly, an embodiment includes: determining whether an accumulated time of a radio problem recovery period within a monitoring window has exceeded an accumulated time threshold; and sending the request in response to the cumulative time threshold having been exceeded.

Similarly, an embodiment includes: determining whether an amount of radio problem recovery within a monitoring window has exceeded a radio problem recovery threshold; and sending the request in response to the radio problem recovery threshold having been exceeded.

Similarly, an embodiment includes: judging whether the asynchronous indication quantity in the monitoring window exceeds an asynchronous indication threshold value or not; and transmitting the request in response to the out-of-sync indication threshold having been exceeded.

Similarly, an embodiment includes: determining whether a Reference Signal Received Power (RSRP) or a Reference Signal Received Quality (RSRQ) of the link has dropped below a minimum RSRP threshold or a minimum RSRQ threshold and sending the request in response to the RSRP or the RSRQ of the link having dropped below the minimum RSRP threshold or the minimum RSRQ threshold.

Similarly, an embodiment includes determining whether the RSRP or the number of RSRQs of the links within the monitoring window that are below the standard threshold has exceeded a maximum RSRP number threshold or a maximum RSRQ number threshold and sending a request in response to the RSRP or the number of RSRQs of the links within the monitoring window that are below the standard threshold having exceeded a maximum RSRP number threshold or a maximum RSRQ number threshold.

According to an example embodiment, IAB nodes within a network radio link topology may assume various roles (including child IAB nodes, parent IAB nodes, IAB nodes) to perform changes to a second serving IAB node, and so on. The network may also send signals to alter the network link topology. According to an embodiment, sending a request to trigger a handover from a first network link topology to a second network link topology comprises: sending a request to an upstream IAB node that is a first upstream IAB node to add a second upstream IAB node; receiving a Radio Resource Control (RRC) connection reconfiguration message including information of a second upstream IAB node; and communicate with a second upstream IAB node to operate under a second network link topology.

Sending a request to trigger a handover from a first network link topology to a second network link topology may include: sending a request to an upstream IAB node that is a first upstream IAB node to release a second upstream IAB node; receiving an RRC connection reconfiguration message; and releasing the second upstream IAB node to operate under the second network link topology based on the RRC connection reconfiguration message.

Sending a request to trigger a handover from a first network link topology to a second network link topology includes: sending a request to an upstream IAB node that is a first upstream IAB node to release a second upstream IAB node and to add a third upstream IAB node; receiving an RRC connection reconfiguration message, the RRC connection reconfiguration message including information of a third upstream IAB node; and releasing the second upstream IAB node and communicating with a third upstream IAB node to operate under the second network link topology based on the RRC connection reconfiguration message.

When the upstream IAB node is a first upstream IAB node, sending a request to trigger a handover from a first network link topology to a second network link topology includes: sending a request for handoff to an upstream IAB node; receiving an RRC connection reconfiguration message, the RRC connection reconfiguration message including information of a second upstream IAB node; and communicate with a second upstream IAB node to operate under a second network link topology.

When the first network link topology is dual-connectivity and the upstream IAB node is a first upstream IAB node, communicating with a second upstream IAB node to operate under a second network link topology further comprises: sending an RRC connection reconfiguration complete message to the second upstream IAB node.

When the first network link topology is dual-connectivity and the upstream IAB node is a second upstream IAB node, communicating with the second upstream IAB node to operate under the second network link topology further comprises: sending an RRC connection reconfiguration complete message to the second upstream IAB node.

When the first network link topology is a single connection and the upstream IAB node is a first upstream IAB node, communicating with a second upstream IAB node to operate under a second network link topology further comprises: and performing a random access procedure with the second upstream IAB node.

When the first network link topology is dual connectivity and the IAB node is a first serving IAB node, sending the request for handoff to the IAB node further comprises: an IAB node that is a second serving IAB node is determined to change from a first network link topology to a second network link topology.

When the first network link topology is dual-connectivity and the IAB node is a second serving IAB node, sending the request for handoff to the IAB node further comprises: an IAB node that is a first serving IAB node is determined to change from a first network link topology to a second network link topology. When the network link topology is single connection, sending the request for handoff to the IAB node further comprises: a change in the IAB node from the first network link topology to the second network link topology is determined.

Fig. 3B illustrates a network link topology adaptation method used by a receiving IAB node in accordance with one of the exemplary embodiments of the present disclosure. In step S311, the IAB node will send a topology adaptation configuration, which includes blocking related parameters. In step S312, the IAB node will receive a request indicating that a handover from the first network link topology to the second network link topology is triggered. In step S313, the IAB node will send a command to trigger a handover from the first network link topology to the second network link topology.

Receiving a request indicating that a handover from a first network link topology to a second network link topology is triggered and sending a command to trigger a handover from a first network link topology to a second network link topology may include: receiving a request from a downstream IAB node; determining that an IAB node changes from a first network link topology to a second network link topology; and sending an RRC connection reconfiguration message to the downstream IAB node, the RRC connection reconfiguration message including information of the IAB node.

When the IAB node is a first serving IAB node, receiving the request indicating to trigger the handover from the first network link topology to the second network link topology comprises: receiving a request for a handoff from a downstream IAB node; sending a request for a handoff to the IAB node; receiving a request acknowledgement message for a handoff from the IAB node; and sending an RRC connection reconfiguration message for the handover to the downstream IAB node.

Receiving a request indicating to trigger a handover from a first network link topology to a second network link topology and sending a command to trigger a handover from the first network link topology to the second network link topology includes: receiving a request from a downstream IAB node; sending a request to the IAB node to change from a first network link topology to a second network link topology; and sending an RRC connection reconfiguration message to the downstream IAB node to release the IAB node, the RRC connection reconfiguration message including information of the IAB node.

Receiving a request indicating to trigger a handover from a first network link topology to a second network link topology and sending a command to trigger a handover from the first network link topology to the second network link topology includes: receiving a request from a downstream IAB node; determining a first IAB node and sending a request to a second IAB node to change from a first network link topology to a second network link topology; and sending an RRC connection reconfiguration message to the downstream IAB node, the RRC connection reconfiguration message including information for the added first IAB node and information for the released second IAB node.

Fig. 4 illustrates a hardware block diagram of an IAB node in accordance with one of the exemplary embodiments of the present disclosure. The hardware of the IAB node will include, without limitation, a processor 401, a transceiver 402, and a storage medium 403, the transceiver 402 may include an integrated or separate transmitter and receiver. The processor 401 is electrically connected to the transceiver 402 and the storage medium 403 and is configured at least for implementing an access and backhaul Integration (IAB) node network link topology adaptation method and exemplary embodiments of the network link topology adaptation method.

The transceiver 402 may include one or more transmitters and receivers configured to transmit and receive signals at radio frequencies or at millimeter wave frequencies, respectively. The transceiver 402 may also perform operations such as: low noise amplification, impedance matching, frequency mixing, up or down conversion, filtering, amplification, and the like. Transceiver 402 may include one or more analog-to-digital (a/D) and digital-to-analog (D/a) converters, respectively, configured to convert from an analog signal format to a digital signal format during uplink signal processing and from a digital signal format to an analog signal format during downlink signal processing. The transceiver 402 may also include an antenna array, which may include one or more antennas to transmit and receive omni-directional antenna beams (omni-directional beams) or directional antenna beams. Transceiver 402 may connect to an inter-base station interface to communicate with other IAB nodes or base stations; may be connected to a backhaul interface to communicate with other IAB nodes or a core network, etc.

The processor 401 is configured to process the digital signal and to carry out a flow of a proposed hierarchical registration method according to a proposed exemplary embodiment of the present disclosure. In addition, the processor 401 may access a storage medium 403, the storage medium 403 storing programming code, a codebook configuration, buffer data, and a record configuration allocated by the processor 401. The Processor 401 may be implemented using a Programmable unit such as a microprocessor, microcontroller, Digital Signal Processor (DSP) chip, Field Programmable Gate Array (FPGA), or the like. The functions of the processor 401 may also be implemented as a separate electronic device or Integrated Circuit (IC). It should be noted that the functions of the processor 401 may be implemented in hardware or software.

To further clarify the foregoing disclosed concept, the present disclosure provides various exemplary embodiments and examples shown in fig. 5-23 and their corresponding written descriptions to illustrate the disclosed concept in more detail. Fig. 5 is a signal diagram illustrating sending a second serving IAB request to trigger a Dual Connectivity (DC) scenario during which another IAB node may be added, removed, or changed in accordance with one of the exemplary embodiments of the present disclosure. In step S501, the child IAB node will detect whether blocking of the radio link has occurred. After having determined that blocking of the radio link has occurred, the child IAB node will issue a second serving IAB request to the serving IAB node in step S502. In response to receiving the second serving IAB request, the serving IAB node may decide in step S503 that the second serving IAB node changes the current network radio link topology with possible rerouting by the second serving IAB.

To detect potential blocking conditions, detection may be carried out based on a BFR mechanism. Fig. 6 illustrates a BFR detection mechanism in accordance with one of the exemplary embodiments of the present disclosure. Referring to fig. 6, a physical layer (PHY layer) will indicate whether a beam failure instance 601 has occurred with a flag. Once a beam failure instance 601 has occurred, the Media Access Control (MAC) layer receives this information and the MAC layer updates a counter to keep track of the number of beam failure instances 601. When the number of beam failure instances 601 has exceeded a predetermined number during normal operation, the MAC layer will send a Beam Failure Declaration (BFD)602 to the PHY layer during a window of Beam Failure Declaration (BFD) periods 604. Next, upon receiving BFD 602, it is determined that a blocking condition has occurred. Beam Failure Recovery (BFR)605 on active bandwidth part (BWP) will start. Upon successful completion of the BFR 605, the IAB node may remain in the RRC _ CONNECTED state 606.

Fig. 7 illustrates a first exemplary embodiment of a BFR detection mechanism. In this exemplary embodiment, the child IAB node will determine whether the time of preamble signal transmission during the BFR period has exceeded a preamble signal transmission time threshold. In step S701, the child IAB node may transmit a second serving IAB request in response to determining that the time of preamble signal transmission during the BFR period has exceeded a preamble signal transmission time threshold (e.g., S502). After sending the second serving IAB request, the child node may be connected to both the first serving IAB node (i.e., the current serving IAB node) and the second serving IAB node at the same time, and thus there may be two possible paths between the child IAB node and the IAB donor. One or both of the two possible paths may be used to send data upstream or downstream.

Fig. 8 illustrates a second exemplary embodiment of a BFR detection mechanism. In this exemplary embodiment, the child IAB node will determine whether the cumulative time of preamble signal transmissions during the BFR period within the monitoring window 801 having duration T1 has exceeded the cumulative time threshold. The child IAB node will send a second serving IAB request in response to the cumulative time threshold having been exceeded during the monitoring window (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

Fig. 9 illustrates a third exemplary embodiment of a BFR detection mechanism. In this exemplary embodiment, the child IAB node will determine how many instances of BFRs have occurred within the monitoring window 901 to determine whether the amount of BFRs has exceeded the BFR amount threshold. The child IAB node will send a second serving IAB request in response to the BFR amount threshold having been exceeded during the monitoring window (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

Fig. 10 illustrates a fourth exemplary embodiment of a BFR detection mechanism. In this exemplary embodiment, the child IAB node will determine how many instances of beam failure indications have occurred within the monitoring window 1001 to determine whether the amount of beam failure instances has exceeded the beam failure instance amount threshold. The child IAB node will send a second serving IAB request in response to the beam failure instance amount threshold having been exceeded within the monitoring window (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

To detect potential blocking conditions, detection may be carried out based on an RLF detection mechanism. Fig. 11 illustrates an RLF detection mechanism in accordance with one of the exemplary embodiments of the present disclosure. After a period of normal operation, the IAB node may receive one or more instances of out-of-sync indication 1101 and in-sync indication 1102. Thus, the IAB node may perform radio problem detection by calculating the total number of out-of-sync indications. Assuming that the number of out-of-sync indications is greater than N310, the IAB node will calculate the total number of in-sync indications during the radio problem recovery period T310. Assuming that the total number of synchronization indications is greater than N311, the radio problem recovery is successful and the IAB node enters normal operation. Otherwise, RLF is declared. Fig. 12 shows a first exemplary embodiment of an RLF detection mechanism. In this example embodiment, the child IAB node may determine whether the duration of the radio problem recovery period has exceeded a radio problem recovery period threshold. The child IAB node will send a second serving IAB request in response to the duration of the radio problem recovery period having exceeded the radio problem recovery period threshold (e.g., S502). Therefore, in step S1201, the child IAB node may make a dual connection with the first serving IAB node and the second serving IAB node.

Fig. 13 illustrates a second exemplary embodiment of an RLF detection mechanism. In this example embodiment, the child IAB node may determine whether the cumulative time of the radio problem recovery period has exceeded the cumulative time threshold within the monitoring window 1301. The child IAB node will send a second serving IAB request in response to the cumulative time threshold having been exceeded (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

Fig. 14 shows a third exemplary embodiment of an RLF detection mechanism. In this example embodiment, the child IAB node may determine whether the amount (e.g., number of times) of radio problem recovery has exceeded a radio problem recovery threshold within the monitoring window 1401. The child IAB node will send a second serving IAB request in response to the radio problem recovery threshold having been exceeded (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

Fig. 15 shows a fourth exemplary embodiment of the RLF detection mechanism. In this example embodiment, the child IAB node may determine whether the amount of out-of-sync indication has exceeded the out-of-sync indication threshold within the monitoring window 1501. The child IAB node will send a second serving IAB request in response to the out-of-sync indication threshold having been exceeded (e.g., S502). Thus, the child IAB node may be dual connected with the first serving IAB node and the second serving IAB node.

To detect potential blocking conditions, detection may be carried out based on measuring the reference signal and then evaluating the RSRP or RSRQ of the reference signal. This evaluation may be carried out with or without the use of a monitoring window. Fig. 16 illustrates a first exemplary embodiment of an RSRP/RSRQ evaluation mechanism. In this example embodiment, the child IAB node may determine whether the RSRP or RSRQ of the reference signal received from the first serving IAB node or the second serving IAB node has dropped below a minimum RSRP threshold or a minimum RSRQ threshold. As shown in fig. 16, the sub-IAB nodes may perform periodic measurements of the reference signal. Assume that the child IAB node may have determined that reference signal 1601 has fallen below the minimum RSRP threshold or the minimum RSRQ threshold. Next, in step 1602, the child IAB node will send a second serving IAB request (e.g., S502) to add, release, or change the second IAB serving node to make a dual connection with the first serving IAB node and the second serving IAB node.

Fig. 17 illustrates a second exemplary embodiment of an RSRP/RSRQ evaluation mechanism. In this example embodiment, the child IAB node may determine whether the RSRP or the number of RSRQs of links that have fallen below the minimum requirement within monitoring window 1710 exceeds a RSRP number threshold or an RSRQ number threshold. The child IAB node will send a second serving IAB request in response to the number of RSRPs or RSRQs of links that have fallen below the minimum requirement within the monitoring window 1710 exceeding an RSRP number threshold or RSRQ number threshold (e.g., S502). As shown in fig. 17, assume that periodic measurements (e.g., 1701, 1703) are performed, but a few reference signal measurements 1701 fail to meet a minimum RSRP or RSRQ requirement, and the number of reference signal measurements 1701 that fail to meet the minimum RSRP or RSRQ requirement has exceeded an RSRP number threshold or RSRQ number threshold within the monitoring window 1710. Accordingly, the child IAB node may send a second serving IAB request (e.g., S502) to add, release, or change the second serving node. The child IAB node may then be dually connected to both the first serving IAB serving node and the second IAB serving node.

After the IAB node has determined that a blocking condition has occurred, the child IAB node may add a second IAB serving node. Fig. 18 is a signal diagram illustrating the addition of a second serving IAB node in accordance with one of the exemplary embodiments of the present disclosure. In step S1801, the first serving IAB node will send a topology adaptation configuration message, which may include blocking related parameters, to the child IAB node. The topology adaptation configuration message is used to configure or reconfigure the child IAB nodes to a particular network link topology. In step S1802, the sub-IAB node will continuously detect whether there is blocking in the radio link of the sub-IAB node with the first serving IAB node based on the blocking related parameter. In step S1803, the first serving IAB node will receive a second serving IAB request from the child IAB node in response to having detected the blocking condition. In step S1804, selection of the second serving IAB node may be made and the first serving IAB node will receive information about the second serving IAB node.

In step S1805, the first serving IAB node will send a second serving node addition request to the second serving IAB node, which will include the context of the child node. In step S1806, the first serving IAB node will receive a second serving node addition request acknowledgement from the second serving IAB node. In step S1807, the first serving IAB node will send an RRC connection reconfiguration message to the child IAB node. In step S1808, the child IAB node will send an RRC connection reconfiguration complete message to the first serving IAB node. In step S1809, the first serving IAB node forwards the second serving node reconfiguration complete message to the second serving IAB node. In step S1810, the sub IAB node will perform a random access procedure to start a connection between the sub IAB node and the second serving IAB node. In step S1811, the first serving IAB node, the second serving IAB node, and the IAB donor will update their routing tables, respectively.

In step S1804, the second serving IAB node may be selected based on one or more of the following criteria, including the SSB signal strength of the IAB node, the load of the IAB node, the minimum number of hops from the IAB node of the IAB donor, the load of the IAB node along the data path, and the like. To implement step S1804, there may be at least two alternatives.

In a first alternative, each of all IAB nodes may periodically exchange information of its respective load information and its respective hop location with its IAB donor. When the child IAB node sends a second serving IAB request that includes signal strength information of neighboring IAB nodes of the child IAB node, the serving node (or donor) of the child IAB node may select the second serving IAB node accordingly. The advantage of the first alternative is that the selection of the second serving IAB node can be optimized.

In a second alternative, the child IAB node may collect information including signal strength, load information, hop location, etc. from neighboring IAB nodes by broadcasting a system information message. When issuing the second serving IAB request message to the serving node of the child IAB node, the child IAB node may then report such information to the serving IAB node of the child IAB node. The advantage of the second alternative is that the child IAB node will only send the candidate list with eligible neighboring IAB nodes and measurement information to the serving node of the child IAB node so that the signaling overhead can be reduced.

In some cases, the child IAB node may release the previously added second serving IAB node. For example, the first serving IAB node may be good enough again, and thus dual connectivity with the second serving IAB node may then be considered redundant. For example, the radio link with the second serving IAB node may become unreliable and thus dual connectivity with the second serving IAB node may then also be considered redundant. Fig. 19 is a signal diagram illustrating the release of the second service IAB in accordance with one of the exemplary embodiments of the present disclosure. The signal for releasing the second serving IAB node is largely the same as in fig. 18, except for S1901 and S1902.

In detail, the first serving IAB node will send a topology adaptation configuration message, which may include blocking related parameters, to the child IAB node. The child IAB node will then continuously detect whether there is blocking in the radio link of the child IAB node with the first serving IAB node based on the blocking-related parameter. The first serving IAB node may receive a second serving IAB request from the child IAB node at a point. In response to the connection with the second serving IAB node no longer being required, the first serving IAB node will send a second serving node release request in step S1901. The first serving IAB node will send an RRC connection reconfiguration message to the child IAB node. The child IAB node will send an RRC connection reconfiguration complete message to the first serving IAB node. In step S1902, the first serving IAB node will send a UE context release message to the second serving node. In response to receiving the UE context release message, the second serving IAB node will stop connecting to the child IAB node. Next, the first serving IAB node, the second serving IAB node, and the IAB donor will update their routing tables, respectively.

The child IAB node may also choose to handoff the radio link to another IAB node after the child IAB node has determined that the blocking condition has occurred. To implement the handoff procedure, the present disclosure will provide three options as shown in fig. 20-22, and for the options in fig. 20 and 21, support the following features: the Secondary Cell Group (SCG) may be directly changed to the Master Cell Group (MCG) without performing the add/release procedure in the LTE dual connectivity. Due to the mostly physically fixed characteristics of the IAB node, the second serving node may be a good candidate for the node that becomes the target of the handoff, and thus the handoff time may be minimized since no random access procedure is needed.

Fig. 20 is a signal diagram illustrating a first exemplary embodiment of handing off a first serving IAB node to a second serving IAB node. In step S2001, the first serving IAB node will send a topology adaptation configuration message, which may include blocking related parameters, to the child IAB node. The topology adaptation configuration message is used to configure or reconfigure the child IAB nodes to a particular network link topology. In step S2002, the sub-IAB node will continuously detect whether there is blocking in the radio link of the sub-IAB node with the first serving IAB node based on the blocking related parameter. In step S2003, the first serving IAB node will receive a handoff request from the child IAB node in response to the blocking condition having been detected. In step S2004, the first serving IAB node sends a handoff request to the second serving IAB node. In step S2005, the first serving IAB node will receive a handoff request acknowledgement from the second serving IAB node. In step S2006, the first serving IAB node will send an RRC connection reconfiguration message to the child IAB node. In step S2007, the child IAB node will send an RRC connection reconfiguration complete message to the second serving IAB node. In step S2008, the first serving IAB node, the second serving IAB node, and the IAB donor update their routing tables, respectively. In step S2009, the second serving IAB node will send a UE context release message to the first serving IAB node.

Fig. 21 is a signal diagram illustrating a second exemplary embodiment of handing off a first serving IAB node to a second serving IAB node. This exemplary embodiment is similar to fig. 20 except for S2101 and the flow associated with the release request. First, the first serving IAB node will send a topology adaptation configuration message, which may include blocking related parameters, to the child IAB node. The topology adaptation configuration message is used to configure or reconfigure the child IAB nodes to a particular network link topology. Next, the child IAB node will continuously detect whether there is blocking in the radio link of the child IAB node with the first serving IAB node based on the blocking-related parameter. In response to having detected the blocking condition, the child IAB node will send a handoff to second serving IAB request to the second serving IAB node in step S2101. In response to receiving the handoff to second serving IAB request, the second serving IAB node will send a release request to the first serving IAB. The first serving IAB node will in turn send a release request acknowledgement to the second serving IAB node. Next, the second serving IAB node will send an RRC connection reconfiguration message to the child IAB node. In response, the child IAB node will send an RRC connection reconfiguration complete message to the second serving IAB node. Next, the first serving IAB node, the second serving IAB node, and the IAB donor will update their routing tables, respectively. The second serving IAB node will complete the handover procedure by sending a UE context release message to the first serving IAB node.

Fig. 22 shows a signal diagram of a third exemplary embodiment of handing off a first serving IAB node to a target serving IAB node. In step S2201, the first serving IAB node will send a topology adaptation configuration message, which may include blocking related parameters, to the child IAB node. The topology adaptation configuration message is used to configure or reconfigure the child IAB nodes to a particular network link topology. In step S2202, the sub-IAB node will continuously detect whether there is blocking in the radio link of the sub-IAB node and the first serving IAB node based on the blocking-related parameter. In step S2203, in response to having detected the blocking condition, the first serving IAB node will receive a handoff request from the child IAB node. In step S2204, the first serving IAB node will send a handoff request to the target IAB node. In step S2205, in response to receiving the handoff request, the target IAB node will send a handoff request acknowledgement to the first serving IAB node. In step S2206, the first serving IAB node will send an RRC connection reconfiguration message to the child IAB node. In step S2207, the sub-IAB node performs the device synchronization procedure and the random access procedure with the target IAB node. In step S2208, the child IAB node will send an RRC connection reconfiguration complete message to the target IAB node. In step S2209, the first serving IAB node, the target IAB node, and the IAB donor will update their routing tables, respectively. In step S2210, the target IAB node will send a UE context release message to the first serving IAB node.

The child IAB node may initiate a change from the source second serving IAB node to the target second serving IAB node after the child IAB node has determined that a blocking condition or degradation has occurred on the radio link with the second source serving IAB node. Fig. 23 illustrates a signal diagram of changing a second serving IAB node in accordance with one of the exemplary embodiments of the present disclosure. In step S2301, it is assumed that the child IAB node has detected a blocking condition in the radio link of the child IAB node with the originating second serving IAB node. In step S2302, the first serving IAB node will receive a second serving IAB change request from the child IAB node in response to having detected the blocking condition. In step S2303, after the selection of the target second serving IAB node has been made, the first serving IAB node will then send a second serving node addition request to the target second serving IAB node, which will include the context of the child IAB node. In step S2304, the first serving IAB node will receive a second serving node addition request acknowledgement from the target second serving IAB node. In step S2305, the first serving IAB node will send a second serving node release request message to the originating second serving IAB node.

In step S2306, the first serving IAB node will send an RRC connection reconfiguration message to the child IAB node. In step S2307, the child IAB node will send an RRC connection reconfiguration complete message to the first serving IAB node. In step S2308, the first serving IAB node forwards the second serving node reconfiguration complete message to the target second serving IAB node. In step S2309, the sub IAB node will perform a random access procedure with the target second serving IAB node. In step S2310, the first serving IAB node, the second serving IAB node, and the IAB donor update their routing tables, respectively.

In view of the foregoing, the present disclosure is applicable for use in 5G NR wireless communication systems and wireless communication systems beyond 5G NR wireless communication systems, and is capable of detecting a blocking condition or a changed network condition of a radio link and adjusting an overall network link topology to dynamically handle the blocking condition or the changed condition of the network.

No element, act, or instruction used in the detailed description of the embodiments disclosed herein should be construed as critical or essential to the disclosure unless explicitly described as such. In addition, as used herein, each of the indefinite articles "a" and "an" may comprise more than one item. If only one item is intended, the term "single" or similar language will be used. Furthermore, as used herein, the term "any of" following a list of items and/or categories of items is intended to include "any of," "any combination of," "any plurality of," and/or "any combination of" the items and/or categories of items (either individually or in combination with other items and/or other categories of items). Furthermore, the term "set" as used herein is intended to encompass any number of items, including 0. Further, the term "number" as used herein is intended to include any number, including 0.

It will be apparent to those skilled in the art that various modifications and variations can be made in the structure of the disclosed embodiments without departing from the scope or spirit of the disclosure. In view of the foregoing, it is intended that the present disclosure cover the modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalents.

[ description of symbols ]

201: first IAB node

202: second IAB node

203: third IAB node/third IAB sub-node

204: fourth IAB node

205: fifth IAB node

401: processor with a memory having a plurality of memory cells

402: transceiver

403: storage medium

601: example of Beam failure

602: beam fault statement (BFD)

604: beam Fault Declaration (BFD) period

605: beam Fault Recovery (BFR)

606: RRC _ CONNECTED State

801. 901, 1001, 1301, 1401, 1501, 1710: monitoring window

1101: out-of-sync indication

1102: synchronization indication

1601: reference signal

1602. S301, S302, S303, S311, S312, S313, S501, S502, S503, S701, S1201, S1801, S1802, S1803, S1804, S1805, S1806, S1807, S1808, S1809, S1810, S1811, S1901, S1902, S2001, S2002, S2003, S2004, S2005, S2006, S2007, S2008, S2009, S2101, S2201, S2202, S2203, S2204, S2205, S2206, S2207, S2208, S2209, S2210, S2301, S2302, S3, S2304, S2305, S2306, S2307, S2308, S2309, S2310: step (ii) of

1701: periodic measurement/reference signal measurement

1703: periodic measurement

A. B, C: IAB node

T1: duration of time

T310: radio problem recovery period

Claims

1. A network link topology adaptation method for use by an access and backhaul Integrated (IAB) node or User Equipment (UE), the method comprising:

receiving a topology adaptation configuration from an upstream access and backhaul integration node, the topology adaptation configuration comprising blocking related parameters;

determining whether a blocking condition of a radio link has occurred based on the blocking-related parameter; and

a request is sent to trigger a handover from a first network link topology to a second network link topology.

2. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether one or more preamble signal transmissions during Beam Fault Recovery (BFR) have exceeded a preamble signal transmission time threshold; and

sending a request in response to the preamble signal transmission time threshold having been exceeded.

3. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether an accumulated time of preamble signal transmission during beam failure recovery within a monitoring window has exceeded an accumulated time threshold; and

sending a request in response to the cumulative time threshold having been exceeded.

4. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

judging whether the beam fault recovery quantity exceeds a beam fault recovery quantity threshold value or not; and

transmitting a request in response to the beam failure recovery amount threshold having been exceeded.

5. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether a quantity of beam fault instances from a lower layer has exceeded a beam fault instance quantity threshold; and

sending a request in response to the beam failure instance quantity threshold having been exceeded.

6. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether the time for the radio problem recovery period has exceeded a radio problem recovery period threshold; and

sending a request in response to the radio problem recovery period threshold having been exceeded.

7. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether an accumulated time of a radio problem recovery period within a monitoring window has exceeded an accumulated time threshold; and

8. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether an amount of radio problem recovery within a monitoring window has exceeded a radio problem recovery threshold; and

sending a request in response to the radio problem recovery threshold having been exceeded.

9. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

judging whether the asynchronous indication quantity in the monitoring window exceeds an asynchronous indication threshold value or not; and

sending a request in response to the out-of-sync indication threshold having been exceeded.

10. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

determining whether a Reference Signal Received Power (RSRP) or a Reference Signal Received Quality (RSRQ) of the link has dropped below a minimum reference signal received power threshold or a minimum reference signal received quality threshold; and

sending a request in response to the reference signal received power or the reference signal received quality of the link having dropped below the minimum reference signal received power threshold or the minimum reference signal received quality threshold.

11. The method of claim 1, wherein the determining whether the blocking condition has occurred based on the blocking-related parameter comprises:

judging whether the reference signal received power of the link or the number of the reference signal received quality lower than a standard threshold value in the monitoring window exceeds a maximum reference signal received power number threshold value or a maximum reference signal received quality number threshold value; and

sending a request in response to the reference signal received power or the reference signal received quality of the link within the monitoring window having exceeded the maximum reference signal received power number threshold or the maximum reference signal received quality number threshold.

12. The method of claim 1, wherein the sending a request to trigger a handover from a first network link topology to a second network link topology comprises:

sending a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node to add a second upstream access and backhaul integration node;

receiving a Radio Resource Control (RRC) connection reconfiguration message including information of the second upstream access and backhaul integrated node; and

communicate with the second upstream access and backhaul integration node to operate under the second network link topology.

13. The method of claim 1, wherein the sending a request to trigger a handover from a first network link topology to a second network link topology comprises:

sending a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node to release a second upstream access and backhaul integration node;

receiving a radio resource control connection reconfiguration message; and

releasing the second upstream access and backhaul integration node to operate under the second network link topology based on the radio resource control connection reconfiguration message.

14. The method of claim 1, wherein the sending a request to trigger a handover from a first network link topology to a second network link topology comprises:

sending a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node to release a second upstream access and backhaul integration node and add a third upstream access and backhaul integration node;

receiving a radio resource control connection reconfiguration message, the radio resource control connection reconfiguration message including information of the third upstream access and backhaul integration node; and

releasing the second upstream access and backhaul integration node and communicating with the third upstream access and backhaul integration node to operate under the second network link topology based on the radio resource control connection reconfiguration message.

15. The method according to claim 1, wherein the upstream access and backhaul integration node is a first upstream access and backhaul integration node and the sending a request to trigger a handover from a first network link topology to a second network link topology comprises:

sending a request for handoff to the upstream access and backhaul integration node;

receiving a radio resource control connection reconfiguration message, the radio resource control connection reconfiguration message including information of a second upstream access and backhaul integration node; and

16. The method according to claim 15, wherein the first network link topology is dual connectivity, the upstream access and backhaul integration node is the first upstream access and backhaul integration node, and the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprises:

sending a radio resource control connection reconfiguration complete message to the second upstream access and backhaul integrated node.

17. The method according to claim 15, wherein the first network link topology is dual connectivity, the upstream access and backhaul integration node is the second upstream access and backhaul integration node, and the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprises:

18. The method according to claim 15, wherein the first network link topology is a single connection, the upstream access and backhaul integration node is the first upstream access and backhaul integration node, and the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprises:

and executing a random access process with the second upstream access and backhaul integrated node.

19. An access and backhaul Integrated (IAB) node or User Equipment (UE) comprising:

a transceiver; and

a processor coupled to the transceiver and configured to at least:

receiving, via the transceiver, a topology adaptation configuration from an upstream access and backhaul integrated node, the topology adaptation configuration comprising blocking related parameters;

sending, via the transceiver, a request to trigger a handover from a first network link topology to a second network link topology.

20. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the preamble signal transmission time threshold having been exceeded.

21. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the cumulative time threshold having been exceeded.

22. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

transmitting a request via the transceiver in response to the beam failure recovery amount threshold having been exceeded.

23. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the beam failure instance amount threshold having been exceeded.

24. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the radio problem recovery period threshold having been exceeded.

25. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

26. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

determining whether an amount of radio problem recovery has exceeded a radio problem recovery threshold; and

sending a request via the transceiver in response to the radio problem recovery threshold having been exceeded.

27. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

transmitting a request via the transceiver in response to the out-of-sync indication threshold having been exceeded.

28. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the reference signal received power or the reference signal received quality of the link having dropped below the minimum reference signal received power threshold or the minimum reference signal received quality threshold.

29. The access and backhaul integration node of claim 19, wherein the processor is configured to determine whether the blocking condition has occurred based on the blocking-related parameter, the determining whether the blocking condition has occurred based on the blocking-related parameter comprising:

sending a request via the transceiver in response to the reference signal received power or the reference signal received quality of the link within the monitoring window having exceeded the maximum reference signal received power number threshold or the maximum reference signal received quality number threshold.

30. The access and backhaul integration node of claim 19, wherein the processor is configured to send a request to trigger the handover from the first network link topology to the second network link topology, the sending a request to trigger the handover from the first network link topology to the second network link topology comprising:

sending, via the transceiver, a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node to add a second upstream access and backhaul integration node;

receiving, via the transceiver, a Radio Resource Control (RRC) connection reconfiguration message including information of the second upstream access and backhaul integrated node; and

communicate with the second upstream access and backhaul integration node via the transceiver to operate under the second network link topology.

31. The access and backhaul integration node of claim 19, wherein the processor is configured to send a request to trigger the handover from the first network link topology to the second network link topology, the sending a request to trigger the handover from the first network link topology to the second network link topology comprising:

sending a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node via the transceiver to release a second upstream access and backhaul integration node;

receiving a radio resource control connection reconfiguration message via the transceiver; and

releasing, via the transceiver, the second upstream access and backhaul integration node to operate under the second network link topology based on the radio resource control connection reconfiguration message.

32. The access and backhaul integration node of claim 19, wherein the processor is configured to send a request to trigger the handover from the first network link topology to the second network link topology, the sending a request to trigger the handover from the first network link topology to the second network link topology comprising:

sending, via the transceiver, a request to the upstream access and backhaul integration node as a first upstream access and backhaul integration node to release a second upstream access and backhaul integration node and add a third upstream access and backhaul integration node;

receiving, via the transceiver, a radio resource control connection reconfiguration message including information of the third upstream access and backhaul integration node; and

33. The access and backhaul integration node of claim 19, wherein the processor is configured to send a request to trigger the handover from the first network link topology to the second network link topology, the sending a request to trigger the handover from the first network link topology to the second network link topology comprising:

sending a request for handoff to the upstream access and backhaul integration node via the transceiver;

receiving, via the transceiver, a radio resource control connection reconfiguration message including information of a second upstream access and backhaul integrated node; and

34. The access and backhaul integration node according to claim 33, wherein the first network link topology is dual connectivity, the upstream access and backhaul integration node is a first upstream access and backhaul integration node, and the processor is configured to communicate with the second upstream access and backhaul integration node to operate under the second network link topology, the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprising:

sending a radio resource control connection reconfiguration complete message to the second upstream access and backhaul integrated node via the transceiver.

35. The access and backhaul integration node according to claim 33, wherein the first network link topology is dual connectivity, the upstream access and backhaul integration node is the second upstream access and backhaul integration node, and the processor is configured to communicate with the second upstream access and backhaul integration node to operate under the second network link topology, the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprising:

36. The access and backhaul integration node according to claim 33, wherein the first network link topology is a single connection, the upstream access and backhaul integration node is the first upstream access and backhaul integration node, and the processor is configured to communicate with the second upstream access and backhaul integration node to operate under the second network link topology, the communicating with the second upstream access and backhaul integration node to operate under the second network link topology further comprising:

37. A network link topology adaptation method for use by an access and backhaul Integrated (IAB) node, the method comprising:

sending a topology adaptation configuration, the topology adaptation configuration comprising blocking related parameters;

receiving a request indicating that a handover from a first network link topology to a second network link topology is triggered; and

sending a command to trigger the handover from the first network link topology to the second network link topology.

38. The method of claim 37, wherein the receiving a request indicating to trigger a handover from a first network link topology to a second network link topology and the sending a command to trigger the handover from the first network link topology to the second network link topology comprises:

receiving a request from a downstream access and backhaul integration node;

determining that the access and backhaul integral node changes from the first network link topology to the second network link topology; and

sending a Radio Resource Control (RRC) connection reconfiguration message to a downstream node, the RRC connection reconfiguration message including information of the access and backhaul integration node.

39. The method of claim 37, wherein the receiving a request indicating to trigger a handover from a first network link topology to a second network link topology and the sending a command to trigger the handover from the first network link topology to the second network link topology comprises:

receiving a request from a downstream access and backhaul integration node;

sending a request to another access and backhaul integration node to change from the first network link topology to the second network link topology; and

sending a Radio Resource Control (RRC) connection reconfiguration message to a downstream node to release the other access and backhaul integrated node, the RRC connection reconfiguration message including information of the other access and backhaul integrated node.

40. The method of claim 37, wherein the receiving a request indicating to trigger a handover from a first network link topology to a second network link topology and the sending a command to trigger the handover from the first network link topology to the second network link topology comprises:

receiving a request from a downstream access and backhaul integration node;

determining a first access and backhaul integration node and sending a request to a second access and backhaul integration node to change from the first network link topology to the second network link topology; and

sending a Radio Resource Control (RRC) connection reconfiguration message to a downstream node, the RRC connection reconfiguration message including information for the first access and backhaul integrated node added and information for the second access and backhaul integrated node released.

41. The method according to claim 37, wherein the integrated access and backhaul node is a first serving access and backhaul node and the receiving a request indicating to trigger a handover from a first network link topology to a second network link topology comprises:

receiving a request for handoff from a downstream access and backhaul integration node;

sending a request for handoff to another access and backhaul integration node;

receiving a request confirmation message for handoff from the access and backhaul integration node; and

a radio resource control connection reconfiguration message for the handover is sent to the downstream node.

42. The method according to claim 41, wherein the first network link topology is dual connectivity, the integrated access and backhaul node is the first service access and backhaul node, and the sending the request for handoff to the integrated access and backhaul node further comprises:

determining that the other access and backhaul integration node, which is a second serving access and backhaul integration node, changes from the first network link topology to the second network link topology.

43. The method according to claim 41, wherein the first network link topology is dual connectivity, the other access and backhaul integration node is a second serving access and backhaul integration node, and the sending the request for handoff to the access and backhaul integration node further comprises:

determining that an access and backhaul integration node that is the first service access and backhaul integration node changes from the first network link topology to the second network link topology.

44. The method according to claim 41, wherein the first network link topology is a single connection and the sending a request for handoff to an access and backhaul integration node further comprises:

determining that the other access and backhaul integration node changes from the first network link topology to the second network link topology.

45. An access and backhaul Integrated (IAB) node, comprising:

a transceiver; and

a processor connected to the transceiver and configured to at least:

46. The access and backhaul integration node according to claim 45, wherein the first network link topology is a dual connection, the access and backhaul integration node is a first service access and backhaul integration node, and the processor is configured to send a request for a handoff to another access and backhaul integration node, the sending a request for a handoff to an access and backhaul integration node further comprises:

47. The access and backhaul integration node according to claim 45, wherein the first network link topology is a dual connection, the access and backhaul integration node is a second serving access and backhaul integration node, and the processor is configured to send a request for a handoff to another access and backhaul integration node, the sending a request for a handoff to another access and backhaul integration node further comprising:

determining that an access and backhaul integration node, which is a first service access and backhaul integration node, changes from the first network link topology to the second network link topology.

48. The access and backhaul integration node of claim 45, wherein the first network link topology is a single connection and the processor is configured to send a request for handoff to another access and backhaul integration node, the sending a request for handoff to another access and backhaul integration node further comprising: