WO2021028807A1

WO2021028807A1 - Dual connectivity recovery on backhaul failure

Info

Publication number: WO2021028807A1
Application number: PCT/IB2020/057488
Authority: WO
Inventors: Oumer Teyeb; Ajmal MUHAMMAD; Jose Luis Pradas
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2019-08-09
Filing date: 2020-08-07
Publication date: 2021-02-18
Anticipated expiration: 2022-02-09

Abstract

According to some embodiments, an integrated access and backhaul (IAB) network node is operating in dual connectivity with a master cell group (MCG) and a secondary cell group (SCG). The IAB node performs a method comprising: receiving a backhaul radio link failure (RLF) notification message from a secondary node (SN) of the SCG; and triggering a SCG failure recovery procedure. The SCG failure recovery procedure comprises: suspending forwarding of uplink data via backhaul radio link control (RLC) channels towards the SN; and transmitting a SCG failure information message to a IAB donor central unit (CU) via a master node (MN) of the MCG. Some embodiments include a similar method with respect to a MCG failure recovery procedure.

Description

DUAL CONNECTIVITY RECOVERY ON BACKHAUL FAILURE

TECHNICAL FIELD

Embodiments of the present disclosure are directed to wireless communications and, more particularly, to dual connectivity recovery on backhaul failure for integrated access and backhaul (IAB) networks.

BACKGROUND

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

Third Generation Partnership Project (3GPP) wireless networks support dual connectivity (DC). A network operator may deploy a fifth generation (5G) new radio (NR) wireless network in various ways with or without interworking with long term evolution (LTE) (also referred to as evolved universal terrestrial radio access (E-UTRA)). Some examples are illustrated in FIGURE 1.

FIGURE 1 includes block diagrams illustrating LTE and NR interworking options. In principle, NR and LTE can be deployed without any interworking, denoted by NR stand-alone (SA) operation. A gNB in NR can be connected to a 5G core network (5GC) and an eNB can be connected to evolved packet core (EPC) with no interconnection between the two (Option 1 and Option 2 in FIGURE 1).

On the other hand, the version of NR illustrated in Option 3 of FIGURE 1 is referred to as EN-DC (E-UTRAN-NR dual connectivity). In such a deployment, dual connectivity between NR and LTE is applied with LTE as the master and NR as the secondary node. The radio access network (RAN) node (gNB) supporting NR may not have a control plane connection to the core network (EPC). Instead, it relies on the LTE as master node (MeNB). This may also be referred to as “Non-standalone NR" . In this case the functionality of an NR cell is limited and is used for connected mode UEs as a booster and/or diversity leg, but an RRC IDLE UE cannot camp on these NR cells.

With the introduction of 5GC, other options may also be valid. As described above, Option 2 supports stand-alone NR deployment where a gNB is connected to a 5GC. Similarly, LTE can also be connected to 5GC using option 5 (also known as eLTE, E-UTRA/5GC, or LTE/5GC and the node can be referred to as an ng-eNB). In these cases, both NR and LTE are seen as part of the NG-RAN (and both the ng-eNB and the gNB can be referred to as NG-RAN nodes). Option 4 and option 7 are other variants of dual connectivity between LTE and NR which may be standardized as part of NG-RAN connected to 5GC, denoted by MR-DC (multi radio dual connectivity).

The MR-DC umbrella includes: EN-DC (Option 3), where LTE is the master node and NR is the secondary (EPC CN employed); NE-DC (Option 4), where NR is the master node and LTE is the secondary (5GCN employed); NGEN-DC (Option 7), where LTE is the master node and NR is the secondary (5GCN employed); and NR-DC (variant of Option 2), which includes dual connectivity where both the master and secondary are NR (5GCN employed).

Because migration for these options may differ from different operators, it is possible to have deployments with multiple options in parallel in the same network. For example, an eNB base station supporting options 3, 5 and 7 may exists in the same network as a NR base station supporting options 2 and 4.

In combination with dual connectivity solutions between LTE and NR it is also possible to support CA (carrier aggregation) in each cell group (i.e., master cell group (MCG) and secondary cell group (SCG)) and dual connectivity between nodes on the same radio access technology (RAT) (e.g., NR-NR DC). For the LTE cells, a consequence of the different deployments is the co-existence of LTE cells associated to eNBs connected to EPC, 5GC or both EPC/5GC.

As described above, DC is standardized for both LTE and E-UTRA -NR DC (EN-DC). LTE DC and EN-DC are designed differently with respect to which nodes control what operations. The two basic options are a centralized solution (like LTE-DC) and a decentralized solution (like EN-DC).

FIGURE 2 illustrates the schematic control plane architecture for dual connectivity in LTE DC and EN-DC. The main difference is that in EN-DC, the secondary node (SN) has a separate radio resource control (RRC) entity (NR RRC). This means that the SN can control the UE also; sometimes without the knowledge of the master node (MN) but often the SN needs to coordinate with the MN. In LTE-DC, the RRC decisions are come from the MN (MN to UE). The SN, however, still decides the configuration of the SN, because it is only the SN itself that has knowledge of its resources, capabilities, etc.

Two different DC specifications and their RRC messages are described in more detail below. For EN-DC, the major changes compared to LTE DC are the introduction of split bearer from the SN (known as SCG split bearer), the introduction of split bearer for RRC, and the introduction of a direct RRC from the SN (also referred to as SCG SRB, direct SRB or SRB3).

FIGURES 3 and 4 illustrate the user plane (UP) and control plane (CP) architectures for EN-DC. FIGURE 3 illustrates the network side protocol termination options for MCG, SCG and split bearers in MR-DC with EPC (EN-DC). FIGURE 4 illustrates a network architecture for control plane in EN-DC.

The SN is sometimes referred to as SgNB (where gNB is an NR base station), and the MN as MeNB when the LTE is the master node and NR is the secondary node. In the other case where NR is the master and LTE is the secondary node, the corresponding terms are SeNB and MgNB.

Split RRC messages are mainly used for creating diversity, and the sender can either choose one of the links for scheduling the RRC messages, or it can duplicate the message over both links. In the downlink, the path switching between the MCG or SCG legs or duplication on both is left to network implementation. On the other hand, for the uplink, the network configures the UE to use the MCG, SCG or both legs. The terms “leg”, “path” and “RLC bearer” are used interchangeably herein.

One RRC operation is RRC connection re-establishment. LTE RRC connection re establishment operates as follows. Upon the initiation of a re-establishment procedure in LTE, the UE suspends all RBs except SRB0. The UE then sends the RRCConnectionReestablishmentRequest on SRB0. At this stage the UE either receives a RRCConnectionReestablishment on SRB0 or a RRCConnectionReestablishmentReject on SRB0. In case the UE receives an RRCConnectionReestablishment, it re-establishes SRB1 and sends the RRCConnectionReestablishmentComplete on SRB1. According to TS 36.331, the network is not allowed to start sending downlink messages on SRB1 until it receives the RRCConnectionReestablishmentComplete. Examples are illustrated in FIGURES 5 and 6.

FIGURE 5 is a sequence diagram illustrating a successful RRC connection re establishment. FIGURE 6 is a sequence diagram illustrating a failed RRC connection re establishment.

If the UE receives an RRCConnectionReestablishmentReject, the UE will perform actions upon leaving RRC connected state and inform the non-access stratum (NAS) layer about RRC connection failure. This triggers the NAS layer to perform recovery, which includes a new RRC connection setup.

The response messages after the transmission of an RRC Connection Reestablishment Request are sent on SRB0, thus they are not encrypted and not integrity protected.

In NR, the EUTRA re-establishment procedure may be enhanced to speed up the failure recovery, for example, in case of handover failures. Some of the enhancements include the following.

One enhancement is RRCReestablishment on SRBl. The UE may re-establish packet data convergence protocol (PDCP) for SRBl and resume SRBl in the downlink before submitting MSG3 to lower layers. This makes it possible to use SRBl for MSG4 instead of SRB0, which in turn makes it possible to send a subsequent RRC reconfiguration message in conjunction with MSG4 or directly after, instead of waiting for the UE response in MSG5. This saves a roundtrip in the re-establishment of data radio bearers (DRBs).

Another enhancement is RRCSetup in response to RRCReestablishmentRequest. It is possible to support faster NAS recovery in the RAN in when the RAN is not able to re-establish the UE context (e.g., a cell is not prepared during handover failure). The network sends an RRC connection setup message on SRB0 (instead of a RRC re-establishment reject) which may be used to initiate normal RRC connection setup.

Another enhancement is that RRCReestablishmentReject is removed. It is not needed any longer because of the fallback procedure. If the UE tries to re-establish in a cell that is not prepared or that the network cannot re-establish the DRBs, the network can send an RRCSetup message. And, in the scenario where the cell is overloaded, the network may simply wait until the failure timer T301 expires, so that the UE enters RRC IDLE and performs access control before trying again.

FIGURE 7 is a sequence diagram describing the reestablishment procedure in NR where these enhancements were adopted. At step 1, the UE re-establishes the connection, providing the UE Identity (PCI+C-RNTI) to the gNB where the trigger for the re-establishment occurred.

At step 2, if the UE Context is not locally available, the gNB requests the last serving gNB to provide UE Context data. The last serving gNB provides UE context data at step 3.

At steps 4/4a, the gNB continues the reestablishment of the RRC connection. The message is sent on SRBl.

At steps 5/5a, the gNB may perform the reconfiguration to re-establish SRB2 and DRBs when the reestablishment procedure is ongoing.

If loss of downlink user data buffered in the last serving gNB shall be prevented, at step 6 the gNB provides forwarding addresses.

At steps 7/8, the gNB performs path switch.

At step 9, the gNB triggers the release of the UE resources at the last serving gNB.

In both LTE and NR, a UE considers a radio link failure (RLF) to be detected on the MCG (referred to as MCG-RLF henceforth) when: (a) upon detecting a certain number of out of sync indications from the lower layers associated with the PCell (Primary Cell) within a given time; (b) upon random access problem indication from MCG medium access control (MAC); or upon indication from MCG radio link control (RLC) that the maximum number of retransmissions has been reached for a signaling radio bearer (SRB) or for a DRB.

Timer T310 is started by the UE when it encounters out-of-sync issues with the PCell. If the timer expires before synchronization is restored with the PCell, MCG-RLF is considered to be detected.

In both LTE and NR, a UE considers a RLF to be detected on the SCG (referred to as SCG-RLF henceforth) when: (a) upon detecting a certain number of out of sync indications from the lower layers associated with the PSCell (Primary Secondary Cell) within a given time; upon random access problem indication from SCG MAC; or upon indication from SCG RLC that the maximum number of retransmissions has been reached for an SRB or for a DRB.

Timer T313 is started by the UE when it encounters out-of-sync issues with the PSCell. If the timer expires before synchronization is restored with the PSCell, SCG-RLF is considered to be detected.

Before Release 16, MCG-RLF leads re-establishment procedure (i.e., UE re-establishes the connection by going to idle mode, performing cell selection, and sending a re-establishment request as described above), while SCG-RLF triggers SCG failure recovery.

Upon SCG failure detection, a UE shall suspend all SCG DRBs and suspend SCG transmission for MCG split DRBs and SCG split DRBs; suspend direct SCG SRB and SCG transmission for MCG split SRB; reset SCG-MAC; and send the SCGFailurelnformation message to the MN.

The SCG failure information contains a failure type/cause and a measurement report (which includes measurements of serving cells as well as neighbor cells that the UE has available at the time of SCG RLF detection). In LTE, the failure type/cause can take one of the following values:

- t313-expiry: indicating T313 expired before re-synch to PSCell was achieved; randomAccessProblem: indicating random access problem with the PSCell; rlc-MaxNumRetx: indicating passing the max retransmission count on an SCG RLC; and scg-ChangeFailure: indicating change of the SCG failed (i.e. UE was not able to connect to the new SCG/SN indicated in a RRCConnectionReconfiguration message within a given time).

In NR, the failure type/cause can take the one of following values:

- t313 -expiry; randomAccessProblem; rlc-MaxNumRetx; synchReconfigFailureSCG: same as scg-ChangeFailure in LTE; scg-ReconfigFailure: indicating UE failed to compile the RRC Reconfiguration message received from the SN via SRB3; and srb3-IntegrityFailure: indicating integrity protection failure on SRB3.

Upon the reception of the SCGFailurelnformation, the MN can either release the SN, change the SN/PSCell, or reconfigure the SCG. Thus, a failure on the SCG will not lead to a re-establishment to be performed on the MCG.

Release 16 may include a similar approach to handle MCG-RLF as in SCG failure recovery if the UE is operating in DC and it has split SRB1 configured (i.e., an MCGFailurelnformation is sent to the network via the SCG leg of the split SRB1). Thus, MCG- RLF does not necessarily lead to re-establishment, and the network sends back an RRC reconfiguration to handover the UE to another MN (UE ending up either in standalone mode or in DC mode, connected to the old SN or a new SN).

The details of the MCG failure recovery (also referred to as MCG fast recovery or fast MCG recovery) may include the following characteristics. MCG fast recovery targets all MR- DC architecture options. When MCG failure occurs, UE follows SCG failure-like procedure, where the UE does not trigger RRC connection re-establishment, the UE triggers an MCG failure procedure in which a failure information message is transmitted to the network via SCG.

MCG fast recovery targets the MCG leg RLF. MCG fast recovery may only be triggered after access stratum (AS) security has been activated and the SRB2 and at least one DRB have been setup (SCG is not available before AS security has been setup, so this need not be explicitly stated in specification). MCG failure indication should include: (a) available measurement results of MCG; (b) MCG link failure cause; (c) available measurement results of SCG; and (d) available measurement results of non-serving cells.

For MCG failure indication, a new RRC message in introduced, e.g. MCGFailurelnformation. The SCG leg of the split SRB1 can be used for MCG fast recovery. Once the MCG failure indication is triggered, the UE shall: transmit the MCG failure indication; suspend MCG transmission for all SRBs and DRBs; reset MCG-MAC; and maintain the current measurement configurations from both the MN and the SN and continue measurements based on configuration from the MN and the SN if possible. If SCG failure is detected while MCG is suspended, then initiate RRC re-establishment procedure. Upon reception of reconfiguration with synchronization, the UE resumes MCG transmission if suspended. Fast MCG recovery is not supported for (intra and inter-RAT) handover failure, for integrity check failure, or for RRC connection reconfiguration failure.

Some wireless networks include integrated access backhaul (IABH) networks. 3GPP is currently standardizing integrated access and wireless access backhaul in NR (IAB).

The usage of short range mmWave spectrum in NR creates a need for densified deployment with multi -hop backhauling. However, installing optical fiber to every base station is costly and sometimes not even possible (e.g., historical sites).

The main IAB principle is the use of wireless links for the backhaul (instead of fiber) to enable flexible and dense deployment of cells without the need for densifying the transport network. Use case scenarios for IAB can include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA) (e.g., to residential/office buildings).

The larger bandwidth available for NR in mmWave spectrum provides opportunity for self-backhauling, without limiting the spectrum to be used for the access links. On top of that, the inherent multiple-beam and multiple -input multiple-output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.

Particular IAB solutions may leverage the central unit (CU)/distributed unit (DU) split architecture of NR, where the IAB node hosts a DU part that is controlled by a central unit. The IAB nodes also have a mobile termination (MT) part that they use to communicate with their parent nodes.

The specifications for IAB strives to reuse existing functions and interfaces defined in NR. In particular, MT, gNB-DU, gNB-CU, user plane function (UPF), access and mobility management function (AMF) and session management function (SMF) as well as the corresponding interfaces. NR Uu (between MT and gNB), FI, NG, X2 and N4 are used as baseline for the IAB architectures.

Modifications or enhancements to these functions and interfaces for the support of IAB are explained in the context of the architecture discussion. Additional functionality such as multi-hop forwarding is included in the architecture discussion as it is necessary for the understanding of IAB operation.

The mobile-termination (MT) function is defined as a component of the IAB node. As used herein, MT refers to a function residing on an IAB-node that terminates the radio interface layers of the backhaul Uu interface toward the IAB-donor or other IAB-nodes.

FIGURE 8 illustrates a reference diagram for IAB in standalone mode, which contains one IAB-donor and multiple IAB-nodes. The IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. In a deployment, the IAB-donor can be split according to these functions, which can all be either collocated or non-collocated as allowed by 3GPP NG-RAN architecture. IAB- related aspects may arise when such split is exercised. Also, some of the functions presently associated with the IAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform IAB-specific tasks. The baseline user plane and control plane protocol stacks for IAB are illustrated in FIGURES 9 and 10A-C.

FIGURE 9 is a block diagram illustrating a baseline UP protocol stack for IAB. FIGURES 10A-C are block diagrams illustrating a baseline CP protocol stack for IAB. As illustrated, the chosen protocol stacks reuse the current CU-DU split specification in Release 15, where the full user plane Fl-U (GTP-U/UDP/IP) is terminated at the IAB node (like a normal DU) and the full control plane Fl-C (Fl-AP/SCTP/IP) is also terminated at the IAB node (like a normal DU). In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic (IPsec in the case of UP, and DTLS in the case of CP). IPsec may also be used for the CP protection instead of DTLS (in this case no DTLS layer is used).

A protocol layer referred to as Backhaul Adaptation Protocol (BAP) in the IAB nodes and the IAB-donor is used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul RLC channel (and also between ingress and egress backhaul RLC channels in intermediate IAB nodes) to satisfy the end to end QoS requirements of bearers.

The UE establishes RLC channels to the DU on the UE's access IAB-node in compliance with TS 38.300. Each of these RLC -channels is extended via Fl-U between the UE's access DU and the IAB-donor. The information embedded in Fl-U is carried over backhaul RLC-channels across the backhaul links. Transport of Fl-U over the wireless backhaul will be performed by the BAP.

BAP is a newly defined layer for IAB networks and 3GPP has identified the following characteristics related to the BAP layer functionality. Routing and bearer mapping (e.g., mapping of backhaul RFC channels) are BAP layer functions. The transmit part of the BAP layer performs routing and “bearer mapping”, and the receive part of the BAP layer performs “bearer de-mapping”. Service data units (SDUs) are forwarded from the receive part of the BAP layer to the transmit part of the BAP layer (for the next hop) for packets that are relayed by the IAB node. The specification may model BAP layer protocol entities, e.g. whether separate for DU and MT or not, and how these are configured, i.e. via Fl-AP or RRC.

Further BAP characteristics include the following BAP routing characteristics. The BAP routing id (carried in the BAP header) consists of BAP address and BAP path ID. Each BAP address defines a unique destination (unique for IAB network of one donor-IAB, either an IAB access node, or the IAB donor). Each BAP address can have one or multiple entries in the routing table to enable local route selection. Multiple entries are for load balancing, re routing at REF. Portions of load balancing may be decided locally and/or decided by the Donor. Each BAP routing ID has only one entry in the routing table. The routing table can hold other information, e.g. priority level for entries with same BAP address, to support local selection. Configuration of this information is optional. Foad balancing by routing by donor-IAB CU shall be possible. Focal selection of path/route is done at link failure, and potentially other cases.

An IAB-node needs to multiplex the UE DRBs to the backhaul RFC-Channel. The following two options can be considered on bearer mapping in IAB-node.

Option 1 is one-to-one (1: 1) mapping between UE DRB and backhaul RFC-channel. An example is illustrated in FIGURE 11.

In option 1, each UE DRB is mapped onto a separate backhaul RLC -channel. Further, each backhaul RLC -channel is mapped onto a separate backhaul RLC-channel on the next hop. The number of established backhaul RLC-channels is equal to the number of established UE DRBs. Identifiers (e.g., for the UE and/or DRB) may be required (e.g., if multiple backhaul RLC -channels are multiplexed into a single backhaul logical channel). Which identifiers are needed, and which of the identifier(s) are placed within the adaptation layer header depends on the architecture/protocol option.

Option 2 is many-to-one (N: 1) mapping between UE DRBs and backhaul RLC-channel. An example is illustrated in FIGURE 12.

For the many-to-one mapping, several UE DRBs are multiplexed onto a single backhaul RLC-channel based on specific parameters, such as bearer QoS profile. Other information such as hop-count may also be configured. The IAB-node can multiplex UE DRBs into a single backhaul RLC-channel even if they belong to different UEs. Furthermore, a packet from one backhaul RLC-channel may be mapped onto a different backhaul RLC-channel on the next hop (details of IAB L2 structure for bearer multiplexing are given in section 8.2.5 of TR 38.874). All traffic mapped to a single backhaul RLC-channel receive the same QoS treatment on the air interface.

Because the backhaul RLC-channel multiplexes data from/to multiple bearers, and possibly even different UEs, each data block transmitted in the backhaul RLC-channel needs to contain an identifier of the UE, DRB, and/or IAB-node it is associated with. Which identifiers are needed, and which of the identifier(s) are placed within the adaptation layer header depends on the architecture/protocol option.

When it comes to bearer mapping, 3GPP has identified the following characteristics. Potential support for both 1:1 and N:1 bearer mapping, for UE bearers, at least for UP. For user plane, the uplink mapping in the IAB access node to backhaul RLC channels may be based on the knowledge about UE bearers (identified with GTP TEID). For control plane (Fl-C messages), the uplink mapping in the IAB access node to backhaul RLC channels may be based on Fl-C message type, and may be per UE. The mapping may also consider DSCP/Flow labels (e.g., as an intermediate step). The uplink/downlink mapping in intermediate IAB node(s) to egress backhaul RLC channel may account for the ingress backhaul RLC channel. The uplink/downlink mapping in intermediate IAB node(s) to egress backhaul RLC channel may account for some ID(s) (from BAP Layer). The previous two characteristics are applicable for all types of traffic (e.g. UP, CP, OAM). IAB may operate in conjunction with DC. The MT part of an IAB node may connect in DC mode to two parent nodes. Similar to a UE DC connectivity, one of the parent nodes is the MN while the other is the SN. SRB 1/2 is established via the MN, and both SRB 1/2 may be configured as split SRB. SRB3 may also be established towards the SN. An IAB node’s dual connectivity is hidden from the nodes or UEs that it serves (i.e., the PDCP for the dual connectivity is terminated at the MT). As such, just because an IAB node is connected in DC mode does not mean the UE’s or other IAB nodes that it is serving are also operating in DC mode.

For various reasons, different scenarios of backhaul-link failure may happen in IAB networks. In the following, some example scenarios are illustrated for backhaul-link failure. Each scenario is depicted with an illustrative figure (FIGURES 13 to 15). The goal is to establish a route between IAB-donor and IAB-node D after backhaul -link failure, where: nodes A1 and A2 are IAB-donor nodes; nodes B to H are IAB-nodes; the dashed line represents the established connection between two nodes; the arrows represents the established route after backhaul-link failure, and the bold dashed line represents the new established connection.

FIGURE 13 is a network diagram illustrating backhaul link failure scenario 1. In scenario 1, the backhaul-link failure occurs between upstream IAB-node (e.g., IAB-node C) and one of its parent IAB-nodes (e.g., IAB-node B), where the upstream IAB-node (IAB-node C) has an additional link established to another parent node (IAB-node E).

FIGURE 14 is a network diagram illustrating backhaul link failure scenario 2. In scenario 2, the backhaul-link failure occurs between an upstream IAB-node (e.g., IAB-node C) and all its parent IAB-nodes (e.g., IAB-nodes B and E). The upstream IAB-node (IAB-node C) has to reconnect to a new parent node (e.g., IAB-node F), and the connection between IAB- node F and IAB-node C is newly established.

FIGURE 15 is a network diagram illustrating backhaul link failure scenario 3. In scenario 3, the backhaul-link failure occurs between IAB-node C and IAB-node D. IAB-node D has to reconnect to the new IAB-donor (e.g., IAB-donor A2) via a new route.

3GPP has identified the following characteristics related to RLF. There is an RLF- notification at backhaul RLF, at least to downstream node(s). Alternate routes and/or dual connectivity may be used at recovery at a failure of a backhaul link. Current UE RLF detection and recovery is reused as baseline. Other indications may be used, e.g. when link has recovered, or when recovery is in progress.

Some notifications that an IAB node may send to its children may include the following. A Type 1 “Plain” notification indicating that backhaul link RLF is detected by the IAB-node. A Type 2 “Trying to recover” notification indicating that backhaul link RLF is detected by the IAB-node, and the IAB-node is attempting to recover from it. A Type 3 “BH link recovered” notification indicating that the backhaul link successfully recovers from RLF. A Type 4 “Recovery failure” notification indicating that the backhaul link RLF recovery failure occurs.

There currently exist certain challenges. For example, an IAB node can inform its child IAB nodes when the IAB node has an RLF with its parent node. What actions an IAB node takes on reception of these notifications is undefined. This issue is particularly not clear when an IAB node that is connected in DC mode receives a Type4 notification from the MN/SN or both.

FIGURE 16 is a network diagram illustrating an example IAB topology in DC in IAB 3. IAB3 is connected in DC, with the IAB 1 as an MN and IAB2 as an SN, and it is a parent node for IAB4 and IAB5. In the illustrated example, the uplink routing table on IAB3 is configured so that packets that are destined for IAB4 are mapped to the MCG and packets that are destined to the IAB5 are mapped to the SCG. Different failure cases are considered below.

Case 1 comprises SCG link failure. IAB3 sends SCG failure report to the CU via the

MN.

In Case La, the CU reconfigures the SCG (e.g., changes some configuration but keeps IAB2 as the SN because the failure could have been due to reconfiguration failure), or changes the SN (e.g., IAB3 now has a new secondary path via IABx (not illustrated)). No notification is necessary to downstream nodes.

In Case Lb, the CU releases the SN. IAB3 is not dual connected anymore, so the uplink packets of IAB5 will be affected. For Case l.b.l, there is a local re-routing configuration at IAB3 that indicates “if link towards SCG fails, use link towards MCG.” IAB3 performs the re routing. No need to send notification to downstream nodes. For Case 1.b.2, there is no local re routing configuration at IAB3, which means uplink packets coming from IAB5 have nowhere to go. Backhaul RLF notification is sent to IAB5 even though MCG is still up and running. Case 2 comprises an MCG link failure. IAB3 sends MCG failure report to the CU via the SN.

In Case 2.a, the CU configures another MN (e.g., IAB3 now has a new primary path via IABy (not illustrated)). No notification is necessary to downstream nodes.

In Case 2.b, the CU releases the MN (e.g., SN becomes the MN, or SN is also released, and another node becomes the MN). IAB3 is not dual connected anymore, so the uplink packets of IAB5 will be affected. For Case 2.b.1, there is a local re-routing configuration at IAB3 that indicates “if link towards SCG fails, use link towards MCG.” IAB3 performs the re-routing. No need to send notification to downstream nodes. For Case 2.b.2, there is no local re-routing configuration at IAB3, which means uplink packets coming from IAB5 have nowhere to go: backhaul RUF notification is sent to IAB5 even though a MCG is up and running.

Case 3 comprises both MCG and SCG failure. IAB3 tries to do re-establishment.

In Case 3. a, IAB3 re-establishes without DC (i.e., it connects to only one node, IABz). For Case 3.a.l, there is a local re-routing configuration at IAB3 that indicates “if link towards SCG fails, use link towards MCG.” IAB3 performs the re-routing for the packets coming from IAB5. No need to send notification to downstream nodes. For Case 3.a.l, there is no local re routing configuration at IAB3, which means uplink packets coming from IAB5 have nowhere to go. Backhaul RUF notification is sent to IAB5 even though an MCG is up and running.

In Case 3.b, the IAB3 re-establishes with DC (i.e., first reconfiguration after re establishment configures DC). No need to send notification to downstream nodes.

In Case 3.c, re-establishment did not succeed. Uplink packets of both IAB4 and IAB5 have nowhere to go. Backhaul RUF notification are sent to both IAB4 and IAB5.

It is not clear what IAB3’s behavior is if it receives a type-4 notification from the MN, the SN, or both. This could be due to a backhaul RTF detection by IAB 1 (the MN) towards the donor DU, or by IAB2 (the SN) towards the donor DU. When such a notification is received by IAB3, its links to IAB2 and IAB1 may be working. Triggering re-establishment is an overkill and undesired behavior that could lead to significant performance degradation.

SUMMARY

Based on the description above, certain challenges currently exist with backhaul failure during dual connectivity (DC) operation in an integrated access and backhaul (IAB) network. Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. For example, particular embodiments include optimizing IAB node behavior when an IAB node that is operating in DC receives a type-4 notification from one or both of its parents.

Some embodiments include mechanisms to inform the IAB donor node central unit (CU) that a certain node is experiencing a radio link failure (RLF). Particular embodiments describe actions a node configured with DC may take when the node receives a backhaul link failure notification from a parent node. An IAB-MT may trigger an master cell group (MCG)/secondary cell group (SCG) failure recovery procedure resulting in the transmission of an MCG/SCG failure report towards the CU via the other link, i.e., the MCG failure report is sent via the SCG if the parent node that is sending the backhaul notification message was the master node (MN), or the SCG failure report is sent via the MCG if the notification message was received from the secondary node (SN). Upon reception of the failure message by the CU, the CU may perform different reconfigurations, described in more detail below.

In general, particular embodiments include triggering of MCG or SCG failure recovery by an IAB node that is connected in DC mode upon the reception of a backhaul RUF indication from the MN or SN, even though the link to the MN or SN is operating properly. Some embodiments include pausing the transmission of uplink packets to the node that has sent the MN or SN during the MCG or SCG recovery and resuming the transmissions of uplink packets to the new MN or SN when the recovery is complete.

According to some embodiments, an IAB network node is operating in dual connectivity with a MCG and a SCG. The IAB network node performs a method comprising: receiving a backhaul RUF notification message from a SN of the SCG; and triggering a SCG failure recovery procedure. The SCG failure recovery procedure comprises: suspending forwarding of uplink data via backhaul RLC channels towards the SN; and transmitting a SCG failure information message to a IAB donor CU via a MN of the MCG.

In particular embodiments, the IAB network node comprises an IAB DU and an IAB MT. The SCG failure recovery procedure may be triggered by the IAB DU or MT. In particular embodiments, suspending forwarding of uplink data via backhaul RLC channels towards the SN comprises suspending one or more of SCG data radio bearers (DRBs) and SCG transmission of MCG split DRBs and SCG split DRBs, and/or suspending one or more of SCG signaling radio bearers (SRBs) and SCG transmission of MCG split SRBs and SCG split SRBs.

In particular embodiments, the SCG failure recovery procedure further comprises resetting the SGC medium access control (MAC).

In particular embodiments, the method further comprises receiving a reconfiguration message from the IAB donor CU via the MN. The reconfiguration message may include a configuration for a new SN for the IAB node, and the method further comprises resuming the suspended uplink data via backhaul RLC channels towards the new SN. The reconfiguration message may include a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB node, either rerouting the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG or transmitting a backhaul RLF notification to the child IAB node (e.g., if local rerouting not available).

According to some embodiments, the method comprises: receiving a RLF notification message from a MN of the MCG; and triggering a MCG failure recovery procedure. The MCG failure recovery procedure comprises: suspending forwarding of uplink data via backhaul RLC channels towards the MN; and transmitting a MCG failure information message to a IAB donor CU via a SN of the SCG.

In particular embodiments, the MCG failure recovery procedure is triggered by the IAB DU or by the IAB MT.

In particular embodiments, suspending forwarding of uplink data via backhaul RLC channels towards the MN comprises suspending one or more of MCG DRBs and MCG transmission of MCG split DRBs and SCG split DRBs, and/or suspending one or more of MCG SRBs and MCG transmission of MCG split SRBs and SCG split SRBs.

In particular embodiments, the MCG failure recovery procedure further comprises resetting the MGC MAC.

In particular embodiments, the method further comprises receiving a reconfiguration message from the IAB donor CU via the SN. The reconfiguration message may include a configuration for a new MN for the IAB node, and the method further comprises resuming the suspended uplink data via backhaul RLC channels towards the new MN. The reconfiguration message may include a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB node, rerouting the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG and/or transmitting a backhaul RLF notification to the child IAB node.

According to some embodiments, a network node is capable of operating in dual connectivity with a MCG and a SCG. The network node comprises processing circuitry operable to perform any of the network node methods described above.

Also disclosed is a computer program product comprising a non-transitory computer readable medium storing computer readable program code, the computer readable program code operable, when executed by processing circuitry to perform any of the methods performed by the network node described above.

Certain embodiments may provide one or more of the following technical advantages. For example, particular embodiments avoid the undesirable situation where a node configured in DC mode triggers a radio resource control (RRC) re-establishment upon receiving a failure notification message from a parent node. In general, RRC re-establishment can lead to packet delays and might even lead to packet losses as the IAB-MT would have to go to IDLE mode first and all the bearers (in the case of IAB, backhaul radio link control (RLC) channels/bearers) have to be re-established.

The packet loss issue is especially relevant for uplink packets, due to the utilization of hop by hop RLC and packets may not be available to be retransmitted from the UEs when an IAB node (either access IAB node or intermediate IAB node) re-establishes its connection to a parent. Thus, pre-emptively suspending transmission to the MN or SN (depending on which node sent the backhaul RLF notification) while the MCG or SCG recovery process is ongoing ensures that uplink packets will be forwarded to a dead end (because the MN or SN that sent the backhaul RLF notification has lost uplink connectivity to its parent node(s)). On recovery of the MCG/SCG, the buffered uplink packets can be forwarded via the new MCG/SCG link. BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the disclosed embodiments and their features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

FIGURE 1 includes block diagrams illustrating FTE and NR interworking options;

FIGURE 2 illustrates the schematic control plane architecture for dual connectivity in FTE DC and EN-DC;

FIGURE 3 illustrates the network side protocol termination options for MCG, SCG and split bearers in MR-DC with EPC (EN-DC);

FIGURE 4 illustrates a network architecture for control plane in EN-DC;

FIGURE 5 is a sequence diagram illustrating a successful RRC connection re establishment;

FIGURE 6 is a sequence diagram illustrating a failed RRC connection re-establishment;

FIGURE 7 is a sequence diagram illustrating the reestablishment procedure in NR;

FIGURE 8 illustrates a reference diagram for IAB in standalone mode;

FIGURE 9 is a block diagram illustrating a baseline user plane protocol stack for IAB;

FIGURES 10A-C are block diagrams illustrating a baseline control plane protocol stack for IAB;

FIGURE 11 illustrates a one-to-one (1: 1) mapping between UE DRB and backhaul RLC -channel;

FIGURE 12 illustrates a many-to-one (N: 1) mapping between UE DRBs and backhaul RLC -channel;

FIGURE 13 is a network diagram illustrating backhaul link failure scenario 1;

FIGURE 14 is a network diagram illustrating backhaul link failure scenario 2;

FIGURE 15 is a network diagram illustrating backhaul link failure scenario 3;

FIGURE 16 is a network diagram illustrating an example IAB topology in dual connectivity;

FIGURE 17 is a block diagram illustrating an example wireless network; and

FIGURE 18 is flowchart illustrating an example method in a network node, according to certain embodiments. DETAILED DESCRIPTION

As described above, certain challenges currently exist with backhaul failure during dual connectivity (DC) operation in an integrated access and backhaul (IAB) network. For example, IAB node behavior is undefined if the IAB node receives a type-4 notification from the master node (MN), the secondary node (SN), or both. The type 4 notification may be due to a backhaul radio link failure (RLF) detection by a parent IAB node (e.g., MN or SN) towards the donor node distributed unit (DU). When such a notification is received by the IAB node, its links to the MN and/or SN may be working. Triggering re-establishment is an overkill and undesired behavior that could lead to significant performance degradation.

Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. For example, particular embodiments include optimizing IAB node behavior when an IAB node that is operating in DC receives a type-4 notification from one or both of its parents.

Particular embodiments are described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

As used herein, the terms “backhaul RLC channel” and “backhaul bearer” are interchangeable. The term “IAB-donor CU” and “donor CU” are interchangeable. If a behavior/action is to be performed by an IAB node, without an explicit indication as to whether the IAB-MT or the IAB-DU is performing the action or behaving in the specified way, then the action/behavior may be relevant to either the IAB-DU or IAB-MT. In the strictest sense, and MN and SN refer to a gNB. For example, considering the topology of FIGURE 16, the MN is the logical gNB that is realized by the combination of the IAB 1 -DU and donor-CU, while the SN is the logical gNB that is realized by the combination of the IAB2-DU and the donor-CU. However, in the descriptions below the terms MN and SN may be used just for the DU parts of the logical entity that defines the gNB.

A first set of embodiments includes reception of a backhaul RLF notification from the SN. An IAB node that is operating in DC, upon reception of atype-4 backhaul RLF notification message from the SN may perform the following steps.

In particular embodiments, the IAB node triggers an SCG failure recovery procedure, even though the link with the SN is operating correctly. The IAB node suspends forwarding uplink data via any of the backhaul RLC channels towards the SN. Either the IAB-DU, IAB- MT, or both may suspend forwarding uplink data.

For example, the IAB-DU Backhaul Adaptation Protocol (BAP) may stop forwarding data that was supposed to be routed via the SN to the IAB-MT BAP, or IAB-DU may pass all data, but IAB-MT does not forward the ones that were supposed to be routed via the SN, or a combination of both.

In some embodiments, the IAB-MT suspends all SCG data radio bearers (DRBs) and suspends SCG transmission for MCG split DRBs, and SCG split DRBs. This is for the DRB/SRB traffic of the IAB MT.

In some embodiments, the IAB-MT suspends SCG SRB3, and SCG transmission for MCG split signaling radio bearers (SRBs). This is also concerning only IAB SRB traffic.

In some embodiments, the IAB-MT resets its SCG-MAC.

In some embodiments, the IAB-MT sends the SCGFaihirelnformation message to the CU via the MN. In particular embodiments, the IAB-MT may set the cause value in the SCGFailurelnformation message to indicate backhaul RLF failure (e.g., cause value = scg-BH- RLF) and may include the latest measurement reports from the IAB MT.

The donor CU, upon reception of the SCGFailurelnformation, may send an RRC reconfiguration message to the IAB node via the MCG (i.e., SRB 1). After applying the received RRC reconfiguration, the connectivity state of the IAB-node may be one of Case A, where the IAB-node is in DC mode, but the SN/SCG is changed to a new SN/SCG; or Case B, where the IAB-node is in standalone mode (i.e., SCG is released).

In Case A, the donor CU may also configure proper backhaul RLC channels between the IAB-MT and the new SN (e.g., the same mimber/type of backhaul RLC channels as there were between the old SN and the IAB-MT).

In Case A, because a new SN/SCG is available, the IAB node resumes forwarding uplink data that is supposed to be routed via the SN using the new backhaul RLC channels with the new SN. The IAB-MT resumes all SCG DRBs and resumes SCG transmission for MCG split DRBs, and SCG split DRBs. This is for the DRB/SRB traffic of the IAB MT.

The IAB-MT resumes SCG SRB3, if suspended, and SCG transmission for MCG split SRBs, if suspended. This is also concerning only IAB SRB traffic.

In Case B, because the SCG is not available anymore, for each child node of the IAB node whose packets need to be routed via the SCG, if there is a local re-routing configuration for that child IAB node that allows the rerouting to the MCG if the SCG fails, then the IAB node performs the re-routing and no backhaul RLF notification is sent to the child node. Otherwise (i.e., no local rerouting configuration) the IAB node sends a type-4 backhaul RLF notification message to the child node.

A technical advantage of the first group of embodiments (from the IAB-MT perspective) includes triggering SCG failure recovery even though SCG is operating correctly (upon reception of type-4 from the SN). Another advantage is suspension/re sumption of the transmission of uplink data via the backhaul RLC channels towards the SN. Another advantage is the new SCG failure type (e.g., scg-BH-RLF) in the SCGFailurelnformation.

A second set of embodiments includes reception of backhaul RLF notification from the MN. An IAB node that is operating in DC, upon reception of a type-4 backhaul RLF notification message from the MN, may perform the following steps.

In particular embodiments, if the IAB-MT is configured with DC and split SRBl or SRB3 is configured, the IAB node triggers an MCG failure recovery procedure, even though the link with the MN is operating correctly.

In particular embodiments, the IAB node suspends forwarding uplink data via any of the backhaul RLC channels towards the MN. Either the IAB-DU, IAB-MT, or both may perform the suspension. For example, the IAB-DU BAP may stop forwarding data that was supposed to be routed via the MN to the IAB-MT BAP, or the IAB-DU may pass all data, but the IAB-MT does not forward the data that were supposed to be routed via the MN, or a combination of both.

In particular embodiments, the IAB-MT suspends all MCG DRBs and suspends MCG transmission for MCG split DRBs, and SCG split DRBs. This is for the DRB/SRB traffic of the IAB MT. In particular embodiments, the IAB-MT suspends MCG transmission for MCG split SRBs. This is also concerning IAB SRB traffic.

In particular embodiments, the IAB-MT resets its MCG-MAC.

In particular embodiments, the IAB-MT sends the MCGFailurelnformation message to the donor CU via the SN. The cause value in the MCGFailurelnformation message may be set to indicate backhaul RLF failure (e.g., cause value = mcg-BH-RLF). The MCGFailurelnformation message may include the latest measurement reports from the IAB MT.

The donor CU, upon the reception of the MCG failure information, may send an RRC reconfiguration message to the IAB node via the SCG (i.e., split SRB1 or SRB3). After applying the received RRC reconfiguration, the connectivity state of the IAB-node may be in Case A, which is DC mode, or Case B, which is non-DC mode.

In Case AT, the IAB node is connected to a new MN, while keeping the SN. In Case

A.2, the IAB node is connected to a new MN and a new SN.

In Case B.1, the IAB node is connected to a new MN only and SN is released. In Case

B.2, the IAB node is connected to a new MN only, where the new MN is the old SN.

In Case A.1 and A.2, the donor CU configures proper backhaul RLC channels between the IAB-MT and the new MN (e.g., the same number/type of backhaul RLC channels as there were between the old MN and the IAB-MT).

In Case A.2, the donor CU configures proper backhaul RLC channels between the IAB- MT and the new SN (e.g., the same number/type of backhaul RLC channels as there were between the old SN and the IAB-MT).

In Case B.1, the donor CU configures proper backhaul RLC channels between the IAB- MT and the new MN (e.g., the same mimber/type of backhaul RLC channels as there were between the old MN and the IAB-MT).

In Case B.2, the donor CU re-configures proper backhaul RLC channels between the IAB-MT and the new MN, which is the old SN. If the same number/type of backhaul RLC channels were available on the link to the SN as there were at the link between the old MN and IAB-MT, no reconfiguration may be needed.

In Case A, both MCG and SCG are available. The IAB node resumes forwarding the uplink data via any of the backhaul RLC channels towards the MN. The IAB-MT resumes all MCG DRBs and resume MCG transmission for MCG split DRBs, and SCG split DRBs. This is for the DRB/SRB traffic of the IAB MT. The IAB-MT resumes the MCG transmission for MCG split SRBs. This is also concerning IAB SRB traffic.

In case B, because the SCG is not available anymore, for each child node of the IAB node whose packets need to be routed via the SCG, if there is a local re-routing configuration for that child IAB node that allows the rerouting to the MCG if the SCG fails, then the IAB node performs the re-routing and no backhaul RLF notification is sent to the child node. Otherwise (i.e., no local rerouting configuration), the IAB node sends a type-4 backhaul RLF notification message to the child node.

A technical advantages of the second set of embodiments includes (from the IAB-MT point of view) triggering MCG failure recovery even though MCG is operating correctly (upon reception of type-4 from the MN). Another advantage is suspension/resumption of the transmission of uplink data via the backhaul RLC channels towards the MN. Another advantage is the new MCG failure type (e.g., mcg-BH-RLF) in the MCGFaihirelnformation.

A third set of embodiments includes reception of backhaul RLF notification from both the MN and SN. If the IAB node receives a type-4 notification from the MN while it is handling a type-4 notification from the SN (e.g., preparing the SCG failure information, waiting for a reconfiguration from the network after sending the SCG failure information, etc.) or, if the IAB node receives a type -4 notification from the SN while it is handling a type -4 notification from the MN (e.g., preparing the MCG failure information, waiting for a reconfiguration from the network after sending the MCG failure information, etc.) then the IAB node may perform the following steps.

In particular embodiments, the IAB node triggers a re-establishment procedure. If the re-establishment procedure fails, for each child node of the IAB node, the IAB node sends a type-4 backhaul RLF notification message to the child node. Otherwise (i.e., if the re establishment succeeds), if the IAB-MT is configured to standalone mode (i.e., no DC configured after the IAB-MT has received the first reconfiguration after re-establishment), then for each child node of the IAB node whose packets need to be routed via the SCG, if there is a local re-routing configuration for that child IAB node that allows the rerouting to the MCG if the SCG fails, then the IAB node performs the re-routing and no backhaul RLF notification is sent to the child node. Otherwise (i.e., no local rerouting configuration) the IAB node sends a type-4 backhaul RLF notification message to the child node.

FIGURE 17 illustrates an example wireless network, according to certain embodiments. The wireless network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the wireless network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Uong Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards, such as the IEEE 802.11 standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

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

Network node 160 and WD 110 comprise various components described in more detail below. These components work together to provide network node and/or wireless device functionality, such as providing wireless connections in a wireless network. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.

As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or equipment in the wireless network to enable and/or provide wireless access to the wireless device and/or to perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and may then also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations.

A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Yet further examples of network nodes include multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), core network nodes (e.g., MSCs, MMEs), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLCs), and/or MDTs.

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

In FIGURE 17, network node 160 includes processing circuitry 170, device readable medium 180, interface 190, auxiliary equipment 184, power source 186, power circuitry 187, and antenna 162. Although network node 160 illustrated in the example wireless network of FIGURE 17 may represent a device that includes the illustrated combination of hardware components, other embodiments may comprise network nodes with different combinations of components.

It is to be understood that a network node comprises any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Moreover, while the components of network node 160 are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, a network node may comprise multiple different physical components that make up a single illustrated component (e.g., device readable medium 180 may comprise multiple separate hard drives as well as multiple RAM modules).

Similarly, network node 160 may be composed of multiple physically separate components (e.g., aNodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 160 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeB’s. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node.

In some embodiments, network node 160 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate device readable medium 180 for the different RATs) and some components may be reused (e.g., the same antenna 162 may be shared by the RATs). Network node 160 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 160, such as, for example, GSM, WCDMA, LTE, NR, WiFi, or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 160.

Processing circuitry 170 is configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being provided by a network node. These operations performed by processing circuitry 170 may include processing information obtained by processing circuitry 170 by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Processing circuitry 170 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 160 components, such as device readable medium 180, network node 160 functionality.

For example, processing circuitry 170 may execute instructions stored in device readable medium 180 or in memory within processing circuitry 170. Such functionality may include providing any of the various wireless features, functions, or benefits discussed herein. In some embodiments, processing circuitry 170 may include a system on a chip (SOC).

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

In certain embodiments, some or all of the functionality described herein as being provided by a network node, base station, eNB or other such network device may be performed by processing circuitry 170 executing instructions stored on device readable medium 180 or memory within processing circuitry 170. In alternative embodiments, some or all of the functionality may be provided by processing circuitry 170 without executing instructions stored on a separate or discrete device readable medium, such as in a hard-wired manner. In any of those embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry 170 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 170 alone or to other components of network node 160 but are enjoyed by network node 160 as a whole, and/or by end users and the wireless network generally.

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

Interface 190 is used in the wired or wireless communication of signaling and/or data between network node 160, network 106, and/or WDs 110. As illustrated, interface 190 comprises port(s)/terminal(s) 194 to send and receive data, for example to and from network 106 over a wired connection. Interface 190 also includes radio front end circuitry 192 that may be coupled to, or in certain embodiments a part of, antenna 162.

Radio front end circuitry 192 comprises filters 198 and amplifiers 196. Radio front end circuitry 192 may be connected to antenna 162 and processing circuitry 170. Radio front end circuitry may be configured to condition signals communicated between antenna 162 and processing circuitry 170. Radio front end circuitry 192 may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry 192 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 198 and/or amplifiers 196. The radio signal may then be transmitted via antenna 162. Similarly, when receiving data, antenna 162 may collect radio signals which are then converted into digital data by radio front end circuitry 192. The digital data may be passed to processing circuitry 170. In other embodiments, the interface may comprise different components and/or different combinations of components.

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

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

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

Power circuitry 187 may comprise, or be coupled to, power management circuitry and is configured to supply the components of network node 160 with power for performing the functionality described herein. Power circuitry 187 may receive power from power source 186. Power source 186 and/or power circuitry 187 may be configured to provide power to the various components of network node 160 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 186 may either be included in, or external to, power circuitry 187 and/or network node 160.

For example, network node 160 may be connectable to an external power source (e.g., an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry 187. As a further example, power source 186 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry 187. The battery may provide backup power should the external power source fail. Other types of power sources, such as photovoltaic devices, may also be used.

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

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air.

In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network.

Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE) a vehicle-mounted wireless terminal device, etc. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device.

As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.).

In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

As illustrated, wireless device 110 includes antenna 111, interface 114, processing circuitry 120, device readable medium 130, user interface equipment 132, auxiliary equipment 134, power source 136 and power circuitry 137. WD 110 may include multiple sets of one or more of the illustrated components for different wireless technologies supported by WD 110, such as, for example, GSM, WCDMA, LTE, NR, WiFi, WiMAX, or Bluetooth wireless technologies, just to mention a few. These wireless technologies may be integrated into the same or different chips or set of chips as other components within WD 110. Antenna 111 may include one or more antennas or antenna arrays, configured to send and/or receive wireless signals, and is connected to interface 114. In certain alternative embodiments, antenna 111 may be separate from WD 110 and be connectable to WD 110 through an interface or port. Antenna 111, interface 114, and/or processing circuitry 120 may be configured to perform any receiving or transmitting operations described herein as being performed by a WD. Any information, data and/or signals may be received from a network node and/or another WD. In some embodiments, radio front end circuitry and/or antenna 111 may be considered an interface.

As illustrated, interface 114 comprises radio front end circuitry 112 and antenna 111. Radio front end circuitry 112 comprise one or more filters 118 and amplifiers 116. Radio front end circuitry 112 is connected to antenna 111 and processing circuitry 120 and is configured to condition signals communicated between antenna 111 and processing circuitry 120. Radio front end circuitry 112 may be coupled to or a part of antenna 111. In some embodiments, WD 110 may not include separate radio front end circuitry 112; rather, processing circuitry 120 may comprise radio front end circuitry and may be connected to antenna 111. Similarly, in some embodiments, some or all of RF transceiver circuitry 122 may be considered a part of interface 114.

Radio front end circuitry 112 may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. Radio front end circuitry 112 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 118 and/or amplifiers 116. The radio signal may then be transmitted via antenna 111. Similarly, when receiving data, antenna 111 may collect radio signals which are then converted into digital data by radio front end circuitry 112. The digital data may be passed to processing circuitry 120. In other embodiments, the interface may comprise different components and/or different combinations of components.

Processing circuitry 120 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and/or encoded logic operable to provide, either alone or in conjunction with other WD 110 components, such as device readable medium 130, WD 110 functionality. Such functionality may include providing any of the various wireless features or benefits discussed herein. For example, processing circuitry 120 may execute instructions stored in device readable medium 130 or in memory within processing circuitry 120 to provide the functionality disclosed herein.

As illustrated, processing circuitry 120 includes one or more of RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126. In other embodiments, the processing circuitry may comprise different components and/or different combinations of components. In certain embodiments processing circuitry 120 of WD 110 may comprise a SOC. In some embodiments, RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126 may be on separate chips or sets of chips.

In alternative embodiments, part or all of baseband processing circuitry 124 and application processing circuitry 126 may be combined into one chip or set of chips, and RF transceiver circuitry 122 may be on a separate chip or set of chips. In still alternative embodiments, part or all of RF transceiver circuitry 122 and baseband processing circuitry 124 may be on the same chip or set of chips, and application processing circuitry 126 may be on a separate chip or set of chips. In yet other alternative embodiments, part or all of RF transceiver circuitry 122, baseband processing circuitry 124, and application processing circuitry 126 may be combined in the same chip or set of chips. In some embodiments, RF transceiver circuitry 122 may be a part of interface 114. RF transceiver circuitry 122 may condition RF signals for processing circuitry 120.

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

In any of those embodiments, whether executing instructions stored on a device readable storage medium or not, processing circuitry 120 can be configured to perform the described functionality. The benefits provided by such functionality are not limited to processing circuitry 120 alone or to other components ofWD 110, but are enjoyed by WD 110, and/or by end users and the wireless network generally.

Processing circuitry 120 may be configured to perform any determining, calculating, or similar operations (e.g., certain obtaining operations) described herein as being performed by a WD. These operations, as performed by processing circuitry 120, may include processing information obtained by processing circuitry 120 by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored by WD 110, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination.

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

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

User interface equipment 132 may include input interfaces, devices and circuits, and output interfaces, devices and circuits. User interface equipment 132 is configured to allow input of information into WD 110 and is connected to processing circuitry 120 to allow processing circuitry 120 to process the input information. User interface equipment 132 may include, for example, a microphone, a proximity or other sensor, keys/buttons, a touch display, one or more cameras, a USB port, or other input circuitry. User interface equipment 132 is also configured to allow output of information from WD 110, and to allow processing circuitry 120 to output information from WD 110. User interface equipment 132 may include, for example, a speaker, a display, vibrating circuitry, a USB port, a headphone interface, or other output circuitry. Using one or more input and output interfaces, devices, and circuits, of user interface equipment 132, WD 110 may communicate with end users and/or the wireless network and allow them to benefit from the functionality described herein.

Auxiliary equipment 134 is operable to provide more specific functionality which may not be generally performed by WDs. This may comprise specialized sensors for doing measurements for various purposes, interfaces for additional types of communication such as wired communications etc. The inclusion and type of components of auxiliary equipment 134 may vary depending on the embodiment and/or scenario.

Power source 136 may, in some embodiments, be in the form of a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic devices or power cells, may also be used. WD 110 may further comprise power circuitry 137 for delivering power from power source 136 to the various parts of WD 110 which need power from power source 136 to carry out any functionality described or indicated herein. Power circuitry 137 may in certain embodiments comprise power management circuitry.

Power circuitry 137 may additionally or alternatively be operable to receive power from an external power source; in which case WD 110 may be connectable to the external power source (such as an electricity outlet) via input circuitry or an interface such as an electrical power cable. Power circuitry 137 may also in certain embodiments be operable to deliver power from an external power source to power source 136. This may be, for example, for the charging of power source 136. Power circuitry 137 may perform any formatting, converting, or other modification to the power from power source 136 to make the power suitable for the respective components of WD 110 to which power is supplied. Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in FIGURE 17. For simplicity, the wireless network of FIGURE 17 only depicts network 106, network nodes 160 and 160b, and WDs 110, 110b, and 110c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node 160 and wireless device (WD) 110 are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices’ access to and/or use of the services provided by, or via, the wireless network.

FIGURE 18 is a flowchart illustrating an example method in a network node, according to certain embodiments. In particular embodiments, one or more steps of FIGURE 18 may be performed by network node 160 described with respect to FIGURE 17. The network node comprises an IAB network node operating in dual connectivity with a MCG and a SCG.

The method begins at step 1812, where the network node (e.g., network node 160) receives a backhaul RLF notification message from a SN of the SCG or an MN of the MCG.

At step 1814, the network node triggers an SCG/MCG failure recovery procedure. The type of procedure determines on whether the backhaul RLF notification was received from the SCG or MCG.

At step 1816, the failure recovery procedure comprises suspending forwarding of uplink data via backhaul RLC channels towards the SN/MN.

The SCG failure recovery procedure comprises suspending forwarding of uplink data via backhaul RLC channels towards the SN according to any of the embodiments and examples described above; and transmitting a SCG failure information message to a IAB donor CU via a MN of the MCG.

The MCG failure procedure comprises suspending forwarding of uplink data via backhaul RLC channels towards the MN according to any of the embodiments and examples described above; and transmitting a MCG failure information message to a IAB donor CU via a SN of the SCG.

At step 1818, the network node may reset the MCG MAC or the SCG MAC, depending on which failure procedure is being performed.

At step 1820, the network node transmits a SCG/MCG failure information message to a IAB donor central unit (CU) via a MN/MCG or SN/SCG, depending on which failure procedure is being performed, according to any of the embodiments and examples described above.

At step 1822, the network node receives a reconfiguration message from the IAB donor CU via the MN/SN. The reconfiguration may reconfigure the IAB node with one or more new MN or SN nodes, or to standalone mode, according to any of the embodiments and examples described above. The IAB node may reroute the suspended traffic to one of the newly configured parent nodes, or the IAB node may send backhaul RTF notifications to child nodes according to any of the embodiments and examples described above.

Modifications, additions, or omissions may be made to method 1800 of FIGURE 8. Additionally, one or more steps in the method of FIGURE 18 may be performed in parallel or in any suitable order.

The term unit may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

Modifications, additions, or omissions may be made to the systems and apparatuses disclosed herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. Additionally, operations of the systems and apparatuses may be performed using any suitable logic comprising software, hardware, and/or other logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.

Modifications, additions, or omissions may be made to the methods disclosed herein without departing from the scope of the invention. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

The foregoing description sets forth numerous specific details. It is understood, however, that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

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

Although this disclosure has been described in terms of certain embodiments, alterations and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are possible without departing from the scope of this disclosure, as defined by the claims below.

Claims

CLAIMS:

1. A method performed by an integrated access and backhaul (IAB) network node, wherein the IAB network node is operating in dual connectivity with a master cell group (MCG) and a secondary cell group (SCG), the method comprising: receiving (1812) a backhaul radio link failure (RLF) notification message from a secondary node (SN) of the SCG; and triggering (1814) a SCG failure recovery procedure, wherein the SCG failure recovery procedure comprises: suspending (1816) forwarding of uplink data via backhaul radio link control (RLC) channels towards the SN; and transmitting (1820) a SCG failure information message to a IAB donor central unit (CU) via a master node (MN) of the MCG.

2. The method of claim 1, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the SCG failure recovery procedure is triggered by the IAB DU.

3. The method of claim 1, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the SCG failure recovery procedure is triggered by the IAB MT.

4. The method of any one of claims 1-3, wherein suspending forwarding of uplink data via backhaul RLC channels towards the SN comprises suspending one or more of SCG data radio bearers (DRBs) and SCG transmission of MCG split DRBs and SCG split DRBs.

5. The method of any one of claims 1-4, wherein suspending forwarding of uplink data via backhaul RLC channels towards the SN comprises suspending one or more of SCG signaling radio bearers (SRBs) and SCG transmission of MCG split SRBs and SCG split SRBs.

6. The method of any one of claims 1-5, wherein the SCG failure recovery procedure further comprises resetting (1818) a SGC medium access control (MAC).

7. The method of any one of claims 1-6, further comprising receiving (1822) a reconfiguration message from the IAB donor CU via the MN.

8. The method of claim 7, wherein the reconfiguration message includes a configuration for a new SN for the IAB node; and the method further comprises resuming the suspended uplink data via backhaul RLC channels towards the new SN.

9. The method of claim 7, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB network node, rerouting the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG.

10. The method of claim 7, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB network node with suspended uplink data towards the SN, transmitting a backhaul RLF notification to the child IAB node.

11. An integrated access and backhaul (IAB) network node (160), wherein the IAB network node is capable of operating in dual connectivity with a master cell group (MCG) and a secondary cell group (SCG), the network node comprising processing circuitry (170) operable to: receive a backhaul radio link failure (RLF) notification message from a secondary node (SN) of the SCG; and trigger a SCG failure recovery procedure, wherein for the SCG failure recovery procedure the processing circuitry is further operable to: suspend forwarding of uplink data via backhaul radio link control (RLC) channels towards the SN; and transmit a SCG failure information message to a IAB donor central unit (CU) via a master node (MN) of the MCG.

12. The network node of claim 11, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the SCG failure recovery procedure is triggered by the IAB DU.

13. The network node of claim 11, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the SCG failure recovery procedure is triggered by the IAB MT.

14. The network node of any one of claims 11-13, wherein the processing circuitry is operable to suspend forwarding of uplink data via backhaul RUC channels towards the SN by suspending one or more of SCG data radio bearers (DRBs) and SCG transmission of MCG split DRBs and SCG split DRBs.

15. The network node of any one of claims 11-14, wherein the processing circuitry is operable to suspend forwarding of uplink data via backhaul RUC channels towards the SN by suspending one or more of SCG signaling radio bearers (SRBs) and SCG transmission of MCG split SRBs and SCG split SRBs.

16. The network node of any one of claims 11-15, wherein for the SCG failure recovery procedure the processing circuitry is further operable to reset a SGC medium access control (MAC).

17. The network node of any one of claims 11-16, the processing circuitry further operable to receive a reconfiguration message from the IAB donor CU via the MN.

18. The network node of claim 17, wherein the reconfiguration message includes a configuration for a new SN for the IAB node; and the processing circuitry is further operable to resume the suspended uplink data via backhaul RLC channels towards the new SN.

19. The network node of claim 17, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the processing circuitry is further operable to, for each child IAB node of the IAB network node, reroute the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG.

20. The network node of claim 17, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the processing circuitry is further operable to, for each child IAB node of the IAB network node with suspended uplink data towards the SN, transmit a backhaul RLF notification to the child IAB node.

21. A method performed by an integrated access and backhaul (IAB) network node, wherein the IAB network node is operating in dual connectivity with a master cell group (MCG) and a secondary cell group (SCG), the method comprising: receiving (1812) a backhaul radio link failure (RLF) notification message from a master node (MN) of the MCG; and triggering ( 1814) a MCG failure recovery procedure, wherein the MCG failure recovery procedure comprises: suspending (1816) forwarding of uplink data via backhaul radio link control (RLC) channels towards the MN; and transmitting (1820) a MCG failure information message to a IAB donor central unit (CU) via a secondary node (SN) of the SCG.

22. The method of claim 21, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the MCG failure recovery procedure is triggered by the IAB DU.

23. The method of claim 21, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the MCG failure recovery procedure is triggered by the IAB MT.

24. The method of any one of claims 21-23, wherein suspending forwarding of uplink data via backhaul RLC channels towards the MN comprises suspending one or more of MCG data radio bearers (DRBs) and MCG transmission of MCG split DRBs and SCG split DRBs.

25. The method of any one of claims 21-24, wherein suspending forwarding of uplink data via backhaul RLC channels towards the MN comprises suspending one or more of MCG signaling radio bearers (SRBs) and MCG transmission of MCG split SRBs and SCG split SRBs.

26. The method of any one of claims 21-25, wherein the MCG failure recovery procedure further comprises resetting (1818) a MGC medium access control (MAC).

27. The method of any one of claims 21-26, further comprising receiving (1822) a reconfiguration message from the IAB donor CU via the SN.

28. The method of claim 27, wherein the reconfiguration message includes a configuration for a new MN for the IAB node; and the method further comprises resuming the suspended uplink data via backhaul RLC channels towards the new MN.

29. The method of claim 27, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB network node, rerouting the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG.

30. The method of claim 27, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the method further comprises, for each child IAB node of the IAB network node with uplink data towards the SN, transmitting a backhaul RLF notification to the child IAB node.

31. An integrated access and backhaul (IAB) network node (160), wherein the IAB network node is capable of operating in dual connectivity with a master cell group (MCG) and a secondary cell group (SCG), the network node comprising processing circuitry (170) operable to: receive a backhaul radio link failure (RLF) notification message from a master node (MN) of the MCG; and trigger a MCG failure recovery procedure, wherein for the MCG failure recovery procedure the processing circuitry is further operable to: suspend forwarding of uplink data via backhaul radio link control (RLC) channels towards the MN; and transmit a MCG failure information message to a IAB donor central unit (CU) via a secondary node (SN) of the SCG.

32. The network node of claim 31, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the MCG failure recovery procedure is triggered by the IAB DU.

33. The network node of claim 31, wherein the IAB network node comprises an IAB distributed unit (DU) and an IAB mobile termination (MT), and wherein the MCG failure recovery procedure is triggered by the IAB MT.

34. The network node of any one of claims 31-33, wherein the processing circuitry is operable to suspend forwarding of uplink data via backhaul RLC channels towards the MN by suspending one or more of MCG data radio bearers (DRBs) and MCG transmission of MCG split DRBs and SCG split DRBs.

35. The network node of any one of claims 31-34, wherein the processing circuitry is operable to suspend forwarding of uplink data via backhaul RLC channels towards the MN by suspending one or more of MCG signaling radio bearers (SRBs) and MCG transmission of MCG split SRBs and SCG split SRBs.

36. The network node of any one of claims 31-35, wherein for the MCG failure recovery procedure the processing circuitry is further operable to reset a MGC medium access control (MAC).

37. The network node of any one of claims 31-36, the processing circuitry further operable to receive a reconfiguration message from the IAB donor CU via the SN.

38. The network node of claim 37, wherein the reconfiguration message includes a configuration for a new MN for the IAB node; and the processing circuitry is further operable to resume the suspended uplink data via backhaul RLC channels towards the new MN.

39. The network node of claim 37, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the processing circuitry is further operable to, for each child IAB node of the IAB network node, reroute the suspended uplink data for the child IAB node via a backhaul RLC channel towards the MCG.

40. The network node of claim 37, wherein the reconfiguration message includes a configuration for a standalone IAB node, and the processing circuitry is further operable to, for each child IAB node of the IAB network node with uplink data towards the SN, transmit a backhaul RLF notification to the child IAB node.