Patent Description:
In a typical wireless communications network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or user equipment (UE), communicate via a Radio Access Network (RAN) with one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, with each service area or cell area being served by radio network node such as an access node e.g. a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB. The service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node operates on radio frequencies to communicate over an air interface with the wireless devices within range of the radio network node. The radio network node communicates over a downlink (DL) to the wireless device and the wireless device communicates over an uplink (UL) to the radio network node.

A Universal Mobile Telecommunications System (UMTS) is a third generation telecommunication network, which evolved from the second generation (<NUM>) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High-Speed Packet Access (HSPA) for communication with user equipment. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for present and future generation networks and UTRAN specifically, and investigate enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. The RNCs are typically connected to one or more core networks.

Specifications for the Evolved Packet System (EPS) have been completed within the 3GPP and this work continues in the coming 3GPP releases, such as <NUM> and <NUM> networks such as New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network. As such, the Radio Access Network (RAN) of an EPS has an essentially "flat" architecture comprising radio network nodes connected directly to one or more core networks.

With the emerging <NUM> technologies such as new radio (NR), the use of very many transmit- and receive-antenna elements is of great interest as it makes it possible to utilize beamforming, such as transmit-side and receive-side beamforming. Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions. Similarly, on the receive-side, a receiver can amplify signals from a selected direction or directions, while suppressing unwanted signals from other directions.

3GPP is studying potential solutions for efficient operation of integrated access and wireless access backhaul (IAB) in NR, i.e. using relay nodes to enhance performance of the wireless communication network.

In integrated access and wireless access backhaul, or integrated access backhaul (IAB) for short, there are two kinds of network nodes that are identified as components of a RAN. First, a radio network node denoted as IAB-node, which is a RAN node that supports wireless access to UEs and wirelessly backhauls the access traffic. Furthermore a central network node denoted as an IAB-donor, which is a RAN node which provides UE's interface to core network and wireless backhauling functionality to IAB nodes.

IAB strives to reuse existing functions and interfaces defined for access. In particular, Mobile-Termination (MT), gNodeB (gNB)-Distributed Unit (DU), gNB-Central Unit (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), F1, 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 will be explained in the context of the architecture discussion. Additional functionality, such as multi-hop forwarding i.e. using multiple IAB nodes and intermediate nodes before reaching the IAB-donor, is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.

The Mobile-Termination (MT) function has been defined as a component of the Mobile Equipment. In the context of this study, MT is referred to as a function residing on an IAB-node that terminates the radio interface layers of a backhaul Uu interface toward the IAB-donor or other IAB-nodes.

<FIG> shows a reference diagram for IAB in standalone mode, which comprises one IAB-donor and multiple IAB-nodes. The IAB-donor may be treated as a single logical node that comprises a set of functions such as gNB-DU, gNB-CU-control plane (CP), gNB-CU-user plane (UP) and potentially other functions. In a deployment, the IAB-donor may be split according to these functions, which may 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 IAB-donor in case it becomes evident that they do not perform IAB-specific tasks. <FIG> is a reference diagram for IAB-architectures (TR <NUM> v0.

<FIG>-e illustrate different potential architecture options to implement IAB, as identified in TR <NUM> v0. <NUM>:
After analyzing the differences between these options during the study item phase of IAB specifications, 3GPP has concluded to standardize the architecture shown in <FIG> for Release <NUM>. And the proposed User Plane (UP) and Control Plane (CP) protocol stacks are shown below:
<FIG> shows a UP protocol stack for the architecture shown in <FIG>.

<FIG>-c shows CP protocol stacks for the architecture shown in <FIG>. <FIG> shows an UE's Radio Resource Control (RRC), <FIG> shows a MT's RRC and <FIG> shows an IAB DU's F1-AP. The chosen protocol stacks reuse the current CU-DU split specification in Release15, where the full F1-U, GPRS Tunneling Protocol user data (GTP-U)/ User Datagram Protocol (UDP)/Internet Protocol (IP), is terminated at the IAB node, like a normal DU, and the full F1-C interface (F1-AP/ Stream Control Transmission Protocol (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 Datagram Transport Layer Security (DTLS) in the case of CP. IPsec may also be used for the CP protection instead of DTLS.

One commonality between the CP and UP protocol stacks is that a new layer, e.g. adaptation layer, has been introduced in the intermediate IAB nodes and the IAB donor, which may be used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul Radio Link Control (RLC) channel, and also between backhaul RLC channels in intermediate IAB nodes, to satisfy the end to end Quality of Service (QoS) requirements of bearers.

Some highlights about the operation of the transmitter and receiver side follows:.

The PDCP entity receives PDCP Service Data Units (SDUs) from higher layers and these SDUs are assigned a Sequence Number (SN) and delivered to lower layers, i.e. RLC. A discardTimer is also started at the time a PDCP SDU is received. When the discardTimer expires, the PDCP SDU is discarded and a discard indication is sent to lower layers. RLC, when possible, will then discard the RLC SDU.

In the receiver side, the PDCP entity starts a timer denoted t-reordering of a reordering process when it receives packets in out-of-order. When the t-reordering expires, the PDCP entity updates the variable RX_DELIV which indicates the value of the first PDCP SDU not delivered to the upper layers i.e. it indicates the lower side of the receiving window.

In the transmitter side, when a RLC SDU is received from higher layers a SN is associated to it. The transmitter may set the poll bit to request the receiver side to transmit a status report. When this is done, a timer called the t-pollRetransmit is started. Upon expiration of this timer, the transmitter will again set the poll bit and may further retransmit those Protocol Data Units (PDU) which were waiting to be acknowledged.

The receiver, on the other hand, will start a timer called the t-reassembly when RLC PDUs are not received in sequence. The function is similar to the t-reordering in PDCP. The timer is started when there is a SN gap i.e. a RLC PDU is missing. When t-reassembly expires, for acknowledgement mode (AM), the receiver will transmit a status report to trigger a retransmission in the transmitter side.

When the UE has data to be transmitted, it will request for a grant by means of the Scheduling Request (SR) or Buffer Status Report (BSR).

Backhaul link failure recovery scenarios.

A backhaul link when used herein refers to a link from IAB nodes to a donor IAB DU or to other IAB nodes which are parents of the first IAB node.

Due to various reasons, different scenarios of backhaul-link failure may happen in IAB networks. In <FIG>-c example scenarios are described for backhaul-link failure. Each scenario is depicted with an illustrative figure (<FIG>) aiming at establishing a route between an IAB-donor and IAB-node D after a BH-link failure, where:.

<FIG> shows an example of backhaul-link failure scenario <NUM>.

In this scenario, depicted in <FIG>, the backhaul-link failure occurs between on 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, i.e. IAB-node C, has an additional link established to another parent node, i.e. IAB-node E.

In this scenario, depicted in <FIG>, 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, i.e. 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.

In this scenario, depicted in <FIG>, 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.

Principal steps of BH Radio Link Failure (RLF) recovery of the architecture shown in <FIG>.

In the following, three scenarios of backhaul RLF and subsequent recovery are described:.

<FIG> illustrates Scenario <NUM>: procedure for BH RLF recovery using existing backhaul link.

In scenario <NUM>, <FIG>-b and <FIG>, the MT on IAB-node-<NUM> is dual-connected to IAB-node-<NUM> and IAB-node-<NUM>, which hold Master Cell Group (MCG) and Secondary Cell Group (SCG), respectively. Two adaptation layer routes have been established, one referred to as Adapt route A via IAB-node-<NUM>, and the other referred to as Adapt route B via IAB-node <NUM>. It is assumed that Adapt route A is used for backhauling of access traffic for the UE attached to IAB-node-<NUM>. The RLF is further assumed to occur on the link to the MCG on IAB-node-<NUM>. The SCG link to IAB-node-<NUM> may further be in RRC-inactive state.

<FIG> shows one example for the recovery procedure for scenario <NUM>:.

After BH RLF recovery, the CU-CP can add topologically redundant BH links and routes.

NOTE: While the Scenario <NUM> recovery procedure is presented for the case of multi-connectivity of single-MT IAB-nodes, it is expected that a similar solution is applicable to the case of multi-connected multi-MT IAB-nodes.

<FIG>: Scenario <NUM>: BH topology with BH RLF and after recovery via new BH link using same CU (3b).

<FIG>: Scenario <NUM>: Procedure for BH RLF recovery using new BH link using same CU.

In scenario <NUM>, <FIG> and b and <FIG>, the MT on IAB-node-<NUM> is single connected to IAB-node-<NUM>. One adaptation layer route has been established via IAB-node-<NUM> referred to as Adapt route A. The RLF is assumed to occur on the link between IAB-node-<NUM> and its parent node IAB-node-<NUM>.

<FIG> shows one example the recovery procedure for scenario <NUM>:.

<FIG> and b. Scenario <NUM>: BH topology with BH RLF and after recovery via new BH link with different CU.

Scenario <NUM>: Procedure for BH RLF recovery using new BH link with different CU.

In scenario <NUM> (<FIG>, and <FIG>), the MT on IAB-node-<NUM> is single-connected to IAB-node-<NUM>. One adaptation layer route has been established via IAB-node-<NUM> referred to as Adapt route A. The RLF is assumed to occur on the link between IAB-node-<NUM> and its parent node IAB-node-<NUM>.

The CU-CP releases Adapt route A. This release may be based on F1*-C failure detection.

Steps <NUM>, <NUM>, A, B, C and potentially steps <NUM> and <NUM> also have to be applied by all descendant IAB-nodes of IAB-node-<NUM>. Further, steps <NUM>, <NUM> and <NUM> will also be applied by all UEs connected to descendant IAB-nodes of IAB-node-<NUM>.

As these steps show, the BH RLF recovery procedure via new backhaul link with a different CU may cause multiple subsequent RLFs for descendant IAB-nodes and UEs. This may cause long service interruption for UEs. Further enhancements are needed to reduce this service interruption.

Downstream notification of BH RLF as illustrated in the architecture in <FIG> above.

<FIG> shows a topology with multiple IAB-node generations below BH RLF. When the IAB-node observes RLF on its parent link, it cannot provide further backhaul service to downstream IAB-nodes. Also, child IAB-nodes cannot further serve their descendant IAB-nodes. One example is shown in <FIG>, where IAB-node-<NUM> observes RLF to its parent IAB-node-<NUM> and subsequently cannot provide backhaul service to its child node, i.e., IAB-node-<NUM>.

While the IAB-node observing RLF is aware about backhaul connectivity loss, the descendent IAB-nodes do not have explicit means to identify this upstream backhaul connectivity loss. In case the RLF can be recovered swiftly, as it can be expected for BH-RLF-recovery scenario <NUM>, there may be no need to explicitly inform the descendant IAB-nodes about the temporary BH connectivity loss. When the BH RLF cannot be recovered swiftly, it may be beneficial to release backhaul connectivity to descendant IAB-nodes so that they themselves can seek means to recover from the BH RLF. For this purpose, three options may be considered:.

In case a descendant IAB-node, such as IAB-node <NUM> may recover from such an upstream RLF by using one of the procedures described above, its DU can provide BH RLF-recovery for former ancestor nodes, such as IAB-node <NUM>.

The recovery procedure for backhaul failure in scenarios <NUM> and <NUM> consists of identifying an alternate parent node and establishing/re-establishing control plane and user plane through the alternate parent node. However, identifying and attaching to an alternate node may take a significant amount of time and may also not always be possible, e.g. due to lost connectivity with Donor CU or due to lack of alternative parent nodes, especially in millimeter-wave deployments. It may be necessary to consider how the IAB network is reorganized when there is a backhaul failure in a way that minimizes interruption time of connection with the IAB-donor.

<FIG> shows an example of a recovery after BH RLF in an IAB network.

<FIG> thus illustrates a scenario of a backhaul failure on one of the links in an IAB network. In such scenario, many IAB-nodes and UEs may be left without a connection to the IAB-donor and may need to find alternate parent nodes. Downstream IAB-nodes, e.g. IAB-nodes <NUM>, <NUM> in <FIG>, and the IAB-donor may need to be informed of the backhaul failure. Furthermore, if all the affected IAB-nodes simultaneously try to find alternate parent nodes, the resulting topology may be inefficient.

The following may be considered for recovery from backhaul failures:.

As described above there are different backhaul failure scenarios and different mechanisms to recover from them. A drawback is illustrated in <FIG>, where several IAB nodes, e.g. descendant/child IAB nodes, may be left disconnected from the IAB-donor, i.e. Node A1, due to a failure of a backhaul link on the path to the donor. For the scenario shown in <FIG>, the failure of the backhaul link of IAB node C will cause the descendant nodes of IAB node C (D, I, J, and K) to be disconnected as well.

As already described above, mechanisms are already proposed where the affected IAB node, i.e. node C, may send indications to its descendant IAB nodes. The descendant IAB nodes may then try to find alternate parent nodes. However, this may lead to a chaotic situation where several nodes in the worst case could re-connect to other nodes which are also affected by the same backhaul failure.

It has previously been explored mechanisms on how the children IAB nodes behave upon the reception of the indication from their parent IAB node that it has experienced a backhaul link failure, e.g. throttle UL transmission or stop sending scheduling requests. A children IAB node is a node that, in the upstream direction, is connected to a second IAB node or the donor IAB node.

Further are solutions explored where the nodes involved in the failure could exchange information about existing alternative paths which could be used to recover the connection. This solution could enable fast link recovery via these paths, it would however not assist the nodes in connecting through paths that are not set up yet. Since the nodes involved in the link failure also temporarily lose contact with the rest of the network and the IAB donor node, it is not possible to obtain information of these possible alternative paths from IAB donor at the time of the link failure. In the previous solutions, however, it is not described how a radio network node such as an IAB node experiencing a link failure and performing re-establishment also known as recovery procedure should determine when to indicate to children nodes, or wireless devices connected to the IAB node that the recovery has failed. Recovery failure could happen due to many different reasons e.g. related to that the IP address the IAB node was assigned prior to the link failure is no longer valid, which in turn could mean that the IAB node need to re-establish the F1 connection, which in turn can lead to that the F1 UE contexts setup prior to the link failure is lost.

Furthermore, no mechanism is described on how the children IAB node could determine, by themselves, when to stop waiting for a parent node to recover the link and instead attempt recovery themselves.

An object herein is to provide a mechanism to enable communication, e.g. handle or manage connection failure, in an efficient manner in a wireless communications network. The object is achieved by the independent claims.

An advantage of embodiments herein is to provide means for connected radio network nodes to remain connected to a parent radio network node such as the first radio network node performing the first recovery procedure until it is determined that the first recovery procedure will not be successful, or it is taking too long time, e.g. exceeding service requirements. Thus, embodiments herein enable communication, e.g. handle or manage connection failure, in an efficient manner in a wireless communications network.

Since the success of a recovery procedure is highly depended on which node the first radio network node attempts to perform the requirement in, e.g. if that node is connected to a same network node such as an IAB donor gNB as first radio network node, or if an IP address of the first radio network node is still valid in the network node that the first radio network node is recovery with, this mechanism will be useful as a mean to determine when it is time to for connected nodes, such as the radio network node or wireless devices, to attempt their own recovery.

The subject-matter of <FIG> and <FIG> and their descriptions, even if described or named as "embodiment(s)", "invention(s)", "aspect(s)", "example(s)" or "disclosure(s)" etc., does not fully and thus only partly correspond to the invention as defined in the claims, since one or more features present in and required by the independent claims are missing in the "embodiment(s)", "invention(s)", "aspect(s)", "example(s)" or "disclosure(s)" etc. The subject-matter of <FIG> and <FIG> and their descriptions is therefore not covered by the claims and is useful to highlight specific aspects of the claims.

Embodiments herein relate to wireless communications networks in general. <FIG> is a schematic overview depicting a wireless communications network <NUM>. The wireless communications network <NUM> comprises one or more RANs and one or more CNs. The wireless communications network <NUM> may use one or a number of different technologies. Embodiments herein relate to recent technology trends that are of particular interest in a New Radio (NR) context, however, embodiments are also applicable in further development of existing wireless communications systems such as e.g. LTE or Wideband Code Division Multiple Access (WCDMA).

In the wireless communications network <NUM>, a wireless device <NUM> such as a mobile station, a non-access point (non-AP) STA, a STA, a user equipment (UE) and/or a wireless terminal, is comprised communicating via e.g. one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN). It should be understood by the skilled in the art that "wireless device" is a non-limiting term which means any terminal, wireless communications terminal, user equipment, NB-IoT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station capable of communicating using radio communication with a radio network node within an area served by the radio network node.

The wireless communications network <NUM> comprises a network node <NUM> such as a IAB-donor node e.g. baseband unit (BBU) such as an access node, an access controller, a base station, e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a stand-alone access point or any other network unit or node capable of communicating with a wireless device within the area served by the radio network node depending e.g. on a first radio access technology and terminology used. It should be noted that a service area may be denoted as cell, beam, and beam group or similar to define an area of radio coverage.

The wireless communication network <NUM> further comprises a first radio network node <NUM> connected in-between the network node <NUM> and the wireless device <NUM>. The first radio network node <NUM> may be an IAB node e.g. a radio remote unit (RRU) such as an access node, antenna unit, radio unit of e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within the area served by the radio network node depending e.g. on a first radio access technology and terminology used. It should be noted that a service area may be denoted as cell, beam, and beam group or similar to define an area of radio coverage.

The wireless communication network further comprises a second radio network node <NUM> connected in-between the network node <NUM> and the wireless device <NUM>. The second radio network node <NUM> may be connected to the wireless device <NUM> directly and may be an egress point. The second radio network node <NUM> may be an IAB node e.g. a radio remote unit (RRU) such as an access node, antenna unit, radio unit of e.g. a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within the area served by the radio network node depending e.g. on a first radio access technology and terminology used. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.

Embodiments herein disclose a solution wherein an IAB node, e.g. the first radio network node <NUM>, is performing an RRC re-establishment procedure, e.g. a first recovery procedure, due to a link failure and depending on the outcome of that procedure determine that the recovery procedure has failed and that any UEs, e.g. wireless device <NUM>, and children IAB nodes, e.g. the second radio network node <NUM>, connected to the first radio network node <NUM>, should initiate recovery by themselves. In this case the first radio network node <NUM> may also release the context stored in the first radio network node <NUM> related to the wireless device and one or more second radio network nodes <NUM>.

Thus, the first radio network node <NUM> decides upon a failure of a first recovery procedure of a connection or loss of the connection at the first radio network node <NUM>, to trigger an initiation of a second recovery procedure of a second connection at a second radio network node <NUM> and/or the wireless device <NUM>. Furthermore, the first radio network node <NUM> transmits to the second radio network node <NUM> and/or the wireless device <NUM>, an indication for triggering the initiation of the second recovery procedure of the second connection.

<FIG> is a combined signalling scheme and flowchart according to some embodiments herein. This figure shows the method in the involved nodes, the first radio network node, the wireless device <NUM> and the second radio network node <NUM>.

Action <NUM>. The first radio network node <NUM>, such as an IAB node, an intermediate IAB node or a relay node, may perform a first recovery procedure, such as an RRC re-establishment procedure, e.g. due to a link failure. Depending on the outcome of the first recovery procedure, the first radio network node <NUM> may determine that the first recovery procedure has failed and that any wireless device <NUM> and second radio network node <NUM>, such as a child IAB node, connected to the first radio network node <NUM>, should initiate recovery by themselves. This is related to Action <NUM> described below.

Action <NUM>. Upon a failure of the first recovery procedure of the connection at the first radio network node <NUM>, the second radio network node <NUM> and/or the wireless device <NUM> should initiate recovery by themselves. Thus, the first radio network node <NUM> decides to trigger an initiation of a second recovery procedure at the second radio network node <NUM> and/or the wireless device <NUM>. The second radio network node <NUM> and the wireless device <NUM> may be children IAB nodes and UEs, respectively, which may be connected to the first radio network node <NUM>. In this case the first radio network node <NUM>, may also release the context stored in the IAB node, e.g. the first radio network node <NUM>, related to the wireless device <NUM>, and second radio network nodes <NUM>. The first radio network node may further e.g. select second radio network nodes and/or wireless devices for initiating the second recovery procedure. This is related to Action <NUM> described below.

Action <NUM>. The first radio network node <NUM> therefore transmits to the second radio network node <NUM> and/or the wireless device <NUM>, an indication for triggering the initiation of the second recovery procedure of the second connection. In some embodiments this is performed upon loss of the connection e.g. decided and transmitted an indication indicating that the first radio network node <NUM> performs the first recovery procedure. The indication may thus be associated with triggering the second recovery procedure being e.g. informing about the first recovery procedure performed at the first radio network node <NUM>.

When the indication indicates that the connection at the first radio network node <NUM> has been lost, the second recovery procedure may comprise an explicit control message e.g. at PHY, MAC, RLC, IAB adaptation layer or an implicit message, e.g. that the first radio network node <NUM> switches off downlink transmissions, including pilot signals, reference signals and broadcast signals.

When the indication indicates that that the first radio network node <NUM> has initiated the first recovery procedure e.g. due to a link failure, the second radio network node <NUM> and/or the wireless device <NUM> may initiate a timer for monitoring the progress of the first recovery procedure.

The indication may also indicate that the first recovery procedure has succeeded. Then the first radio network node <NUM> checks to see if it is still connected to the same network node, e.g. IAB donor, or that it is still using the same IP address. If so, i.e. if first recovery procedure has succeeded, the first radio network node <NUM> notifies the second radio network node <NUM> and/or the wireless device <NUM> that the backhaul link has been recovered. In this case, no second recovery procedure is needed. This is related to Action <NUM> described below.

Action <NUM>. The second radio network node <NUM> and/or the wireless device <NUM>, receives, from the first radio network node <NUM>, the indication for triggering an initiation of a second recovery procedure of the second connection. This is related to Action <NUM> described below.

Action <NUM>. Depending on the received indication, the second radio network node <NUM> and/or the wireless device <NUM>, initiates an appropriate operation associated to the second recovery procedure of the second connection. The initiation of the operation may be, e.g. to start a timer to monitor the progress of the first recovery procedure or to initiate the second recovery procedure of the second connection. It may also be that the second recovery procedure does not need to be performed. Furthermore, the second recovery procedure may also be performed upon the timer expiring without receiving a confirmation of success of the first recovery procedure.

The method actions performed by the first radio network node <NUM> for handling data packets or handling communication in a wireless communications network <NUM> according to embodiments herein will now be described with reference to a flowchart depicted in <FIG>. This figure thus shows the method as seen from the perspective of the first radio network node <NUM>. The first radio network node <NUM>, may be a relay node and may also denoted as an IAB node. The wireless communications network <NUM> comprises the first radio network node <NUM> relaying data packets between a network node and a wireless device <NUM>. The actions do not have to be taken in the order stated below, but may be taken in any suitable order.

Action <NUM>. The first radio network node <NUM> may determine that a first recovery procedure has failed. This is related to Action <NUM> described above.

Action <NUM>. The first radio network node <NUM> decides to trigger an initiation of a second recovery procedure of a second connection at a second radio network node <NUM> and/or the wireless device <NUM>. This is decided upon a failure of the first recovery procedure of a connection or upon loss of the connection at the first radio network node <NUM>. This is related to Action <NUM> described above.

Action <NUM>. The first radio network node <NUM> transmits to the second radio network node <NUM> and/or the wireless device <NUM>, an indication for triggering the initiation of the second recovery procedure of the second connection. This is related to Action <NUM> described above.

The method actions performed by the second radio network node <NUM> or the wireless device <NUM> for handling data packets or handling communication in a wireless communications network <NUM> according to embodiments herein will now be described with reference to a flowchart depicted in <FIG>. This figure shows the method as seen from the wireless device <NUM> and/or the second radio network node <NUM> perspective. As mentioned above, the wireless communications network <NUM> comprises the first radio network node <NUM> and/or the second radio network node <NUM> relaying data packets between a network node and the wireless device <NUM>. The actions do not have to be taken in the order stated below, but may be taken in any suitable order.

Action <NUM>. The second radio network node <NUM> and/or the wireless device <NUM>, receives, from the first radio network node <NUM>, an indication for triggering an initiation of a second recovery procedure of a second connection. This is related to Action <NUM> described above.

Action <NUM>. Depending on the received indication, the second radio network node <NUM> and/or the wireless device <NUM> initiates an operation associated to the second recovery procedure of the second connection. This is related to Action <NUM> described above.

The example scenario shown in <FIG> is used to illustrate the concepts of embodiments herein. In this example scenario, the node that has experienced backhaul failure is IAB2. In this example scenario, the first radio network node <NUM> is represented the IAB2 node. The second radio network node <NUM> may be represented by any of the nodes. IAB donor DU = <NUM>, IAB1 = <NUM>, IAB2 = <NUM>, IAB3/<NUM>/<NUM> = <NUM>/<NUM>/<NUM>, IAB6/<NUM> = <NUM>/<NUM>'. The wireless device <NUM> is represented by the UE _o.

<FIG> depicts an example scenario of several descendant/child IAB nodes disconnected from IAB-donor, e.g. Node A1 as described above.

<FIG> shows steps performed at an IAB node upon backhaul link failure recovery, according to some embodiments herein. <FIG> depicts a Backhaul link recovery procedure at an IAB node such as the first radio network node <NUM>.

The procedure may comprise the following steps:.

Embodiments herein disclose e.g. when and how the first radio network node <NUM> detects a failure to recover the backhaul link and sends the corresponding indication.

<FIG> shows the steps performed at an IAB node, e.g. first radio network node <NUM>, upon backhaul link failure recovery, according to some embodiments herein, where a timer is also employed to control the backhaul recovery procedure. <FIG> depicts an backhaul link recovery procedure at an IAB node.

NOTE: In the above procedures, the check for timer expiration in steps <NUM>, <NUM> and <NUM> may be optional, i.e. the notification to the children node may be sent regardless of the timer status.

It is herein disclosed when and how the IAB node detects a failure to recover the backhaul link and sends the corresponding indication, and also the introduction of a timer used by the IAB node to.

<FIG> shows the steps performed at an IAB node, e.g. the first radio network node <NUM>, upon receiving a control message from a parent node regarding the parent's backhaul link connectivity to the donor, according to some embodiments herein.

<FIG> depicts steps at an IAB node upon the reception of backhaul link status indication from a parent. The procedure may comprise the following steps:.

<FIG> shows the steps performed at an IAB node upon receiving a control message from a parent node regarding the parent's backhaul link connectivity to the donor, according to some embodiments herein.

<FIG> shows steps at an IAB node upon the reception of backhaul link status indication from a parent.

Embodiments herein disclose usage of a timer in step <NUM> and <NUM>. The advantage with the timer is that it allows the children IAB node to initiate recovery in case the parent IAB node is not able to do this in time. In this way the service interruption can be minimized. Also, the timer value may be different for the different children nodes (e.g. different timers included in the indication sent by the parent), so that the different children can start searching for an alternate parent at different times. This way, one can prevent all the child nodes trying to reconnect to another parent and overwhelm the system with signaling overload. Also, if a child IAB node is at the moment being used to relay only low priority (e.g. best effort) bearers, while another child IAB node is being used to relay very high priority data (e.g. very strict latency requirements), it will be optimal if the latter child tries to reconnect to another parent while the former child can wait for more time for the parent to recover the connection.

The backhaul recovery procedure, where the IAB node that has a failed backhaul link manages to re-establish a connection with another IAB node that is also connected to the same IAB donor is shown in <FIG> and b.

<FIG> depicts steps <NUM>-<NUM> and <FIG> depicts steps <NUM>-<NUM> of a backhaul RLF recovery procedure in an IAB network, successful case.

Note that the above steps are included for illustrative purposes.

Embodiments herein provide different mechanisms for recovering backhaul link failures in multi-hop IAB networks.

Briefly described, the provided mechanisms comprise:.

The indication may comprise any one out of:.

<FIG> is a block diagram depicting the first radio network node <NUM>, such as a relay node also denoted as an IAB node, for handling data packets or handling communication in a wireless communications network <NUM> according to embodiments herein.

The first radio network node <NUM> may comprise processing circuitry <NUM>, e.g. one or more processors, configured to perform the methods herein.

The first radio network node <NUM> may comprise a determining unit <NUM>. The first radio network node <NUM>, the processing circuitry <NUM>, and/or the determining unit <NUM> may be configured to determine that the first recovery procedure has failed.

The first radio network node <NUM> may comprise a deciding unit <NUM>. The first radio network node <NUM>, the processing circuitry <NUM>, and/or the deciding unit <NUM> is configured to decide upon the failure of the first recovery procedure of the connection or upon loss of the connection at the first radio network node <NUM>, to trigger the initiation of the second recovery procedure of the second connection at the second radio network node <NUM> and/or the wireless device <NUM>.

The first radio network node <NUM> may comprise a transmitting unit <NUM>. The first radio network node <NUM>, the processing circuitry <NUM>, and/or the transmitting unit <NUM> is configured to transmit to the second radio network node <NUM> and/or the wireless device <NUM>, the indication for triggering the initiation of the second recovery procedure of the second connection.

The first radio network node <NUM> further comprises a memory <NUM>. The memory <NUM> comprises one or more units to be used to store data on, such as data packets, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the first radio network node <NUM> may comprise a communication interface such as comprising a transmitter, a receiver and/or a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the first radio network node <NUM> are respectively implemented by means of e.g. a computer program product <NUM> or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first radio network node <NUM>. The computer program product <NUM> may be stored on a computer-readable storage medium <NUM>, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium <NUM>, having stored there on the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first radio network node <NUM>. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a first radio network node for handling communication in a wireless communications network, wherein the first radio network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first radio network node is operative to to perform any of the methods herein.

<FIG> is a block diagram depicting the second radio network node <NUM>, such as a relay node also denoted as an IAB node, or the wireless device <NUM>, for handling data packets or handling communication in a wireless communications network <NUM> according to embodiments herein.

The second radio network node <NUM> and/or the wireless device <NUM> may comprise processing circuitry <NUM>, e.g. one or more processors, configured to perform the methods herein.

The second radio network node <NUM> and/or the wireless device <NUM> may comprise a receiving unit <NUM>. The second radio network node <NUM> and/or the wireless device <NUM>, the processing circuitry <NUM>, and/or the receiving unit <NUM> is configured to receive, from the first radio network node <NUM>, the indication for triggering an initiation of a second recovery procedure of the second connection.

The second radio network node <NUM> and/or the wireless device <NUM> may comprise an initiating unit <NUM>. The second radio network node <NUM> and/or the wireless device <NUM>, the processing circuitry <NUM>, and/or the initiating unit <NUM> is configured to initiate the operation associated to the second recovery procedure of the second connection.

The second radio network node <NUM> and/or the wireless device <NUM> further comprises a memory <NUM>. The memory <NUM> comprises one or more units to be used to store data on, such as data packets, events and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the second radio network node <NUM> and/or the wireless device <NUM> may comprise a communication interface such as comprising a transmitter, a receiver and/or a transceiver and/or one or more antennas.

The methods according to the embodiments described herein for the second radio network node <NUM> and/or the wireless device <NUM> are respectively implemented by means of e.g. a computer program product <NUM> or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second radio network node <NUM> and/or the wireless device <NUM>. The computer program product <NUM> may be stored on a computer-readable storage medium <NUM>, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium <NUM>, having stored there on the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second radio network node <NUM> and/or the wireless device <NUM>. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a second radio network node and/or the wireless device for handling communication in a wireless communications network, wherein the second radio network node and/or the wireless device comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said second radio network node and/or wireless device is operative to to perform any of the methods herein.

In some embodiments a more general term "radio network node" is used and it can correspond to any type of radio-network node or any network node, which communicates with a wireless device and/or with another network node. Examples of network nodes are NodeB, MeNB, SeNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc..

In some embodiments the non-limiting term wireless device or user equipment (UE) is used and it refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc..

Embodiments are applicable to any RAT or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

As will be readily understood by those familiar with communications design, that functions means or circuits may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a wireless device or network node, for example.

Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term "processor" or "controller" as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware and/or program or application data. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

<FIG> shows a Telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments. Access network <NUM> comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the radio network node <NUM> above, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE <NUM> in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs <NUM>, <NUM> are illustrated in this example being examples of the wireless device <NUM> above, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station <NUM>.

<FIG> shows a host computer communicating via a base station and with a user equipment over a partially wireless connection in accordance with some embodiments.

It's hardware <NUM> may include radio interface <NUM> configured to set up and maintain wireless connection <NUM> with a base station serving a coverage area in which UE <NUM> is currently located.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 3212a, 3212b, 3212c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments make it possible to decrease delay and responsiveness since the recovery procedure is handled in an efficient manner. Thereby the data communication, e.g. the handling or managing of data packets may be performed in an efficient manner.

<FIG> shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

<FIG> show methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.

It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings. Instead, the embodiments herein are limited only by the following claims.

Claim 1:
A method for recovering link failures in a multi-hop wireless communications network (<NUM>), wherein the multi-hop wireless communications network (<NUM>) comprises a first radio network node (<NUM>) and a second network node (<NUM>), wherein the first and second network nodes relay data packets between a donor node and a wireless device (<NUM>) via a parent node, the method being performed by the first radio network node (<NUM>) comprising:
determining (<NUM>) that a first recovery procedure of a connection at the first radio network node (<NUM>) has failed, wherein the determining comprises any one or more of:
- an RRC re-establishment succeeds and determining that the first radio network node (<NUM>) is not connected to same donor node as before the recovery procedure,
- an RRC re-establishment succeeds and determining that the first radio network node (<NUM>) is not using the same IP address as before the recovery procedure;
deciding (<NUM>) upon a failure of the first recovery procedure of the connection at the first radio network node (<NUM>), to trigger an initiation of a second recovery procedure of a second connection at the second radio network node (<NUM>),
transmitting (<NUM>) to the second radio network node (<NUM>), an indication for triggering the initiation of the second recovery procedure of the second connection.