WO2022071869A1

WO2022071869A1 - Methods and network nodes for handling communication

Info

Publication number: WO2022071869A1
Application number: PCT/SE2021/050968
Authority: WO
Inventors: Marco BELLESCHI; Julien Muller; Filip BARAC
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2020-10-02
Filing date: 2021-10-01
Publication date: 2022-04-07
Anticipated expiration: 2023-04-02

Abstract

Embodiments herein relate to for example, a method performed by a first network node (120) for handling communication in a wireless communications network (1). The first network node transmits to a second network node (150) a context store request message comprising context of a third network node (140) and/or of one or more other nodes (10,13) that are served, directly or indirectly, by the third network node (140). The first network node receives a request, from the second network node, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. The first network node further transmits a response to the second network node comprising the remaining data associated with the context of the third network node and/or the other nodes.

Description

METHODS AND NETWORK NODES FOR HANDLING COMMUNICATION

TECHNICAL FIELD

Embodiments herein relate to a first network node, a second network node, a third network node, and methods performed therein regarding wireless communication. Furthermore, a computer program product and a computer-readable storage medium are also provided herein. In particular, embodiments herein relate to handling communication, such as controlling/managing migration of nodes such as setup of communication and/or control signalling for nodes such as relay nodes, in a wireless communications network.

BACKGROUND

In a typical wireless communications network, user equipment (UE), also known as wireless communication devices, mobile stations, stations (STA) and/or wireless devices, 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 UEs within range of the radio network node. The radio network node communicates over a downlink (DL) to the UE, and the UE 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 (2G) 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 6G networks and development of 5G 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 5G 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.

Next generation systems are expected to support a wide range of use cases with varying requirements ranging from fully mobile devices to stationary internet of things (loT) or fixed wireless broadband devices. The traffic pattern associated with many use cases may be expected to consist of short or long bursts of data traffic with varying length of waiting period in between, here called inactive state. In NR, both license assisted access and standalone unlicensed operation are to be supported. Hence the procedure of Physical Random Access Channel (PRACH) transmission and/or Scheduling Request (SR) transmission in unlicensed spectrum may be investigated in 3GPP.

3GPP is studying potential solutions for efficient operation of integrated access and wireless access backhaul (IAB) in NR, or integrated access backhaul in short. In the context of IAB there are two kinds of nodes that are identified as components of a RAN: lAB-node: a RAN node that supports wireless access to UEs and wirelessly backhauls the access traffic. lAB-donor: an IAB node i.e. RAN node which provides UE s interface to core network and wireless backhauling functionality to IAB nodes.

3GPP is currently standardizing integrated access and wireless access backhaul in NR (IAB) in Rel-16 (RP-182882).

The usage of short range mm Wave spectrum in NR creates a need for densified deployment with multi-hop backhauling. However, optical fiber to every base station will be too costly and sometimes not even possible, for example, due to historical sites. The main IAB principle is the use of wireless links for the backhaul, instead of fiber, to enable flexible and very dense deployment of cells without the need for densifying the transport network. Use case scenarios for IAB may 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 multi-beam and multiple input multiple output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.

During the study item phase of the IAB work, summary of the study item can be found in the technical report TR 38.874 v0.7.0, it has been agreed to adopt a solution that leverages the Central Unit (CU)/Distributed Unit (DU) split architecture of NR, where the IAB node will be hosting a DU part that is controlled by a central unit. The IAB nodes also have a Mobile Termination (MT) part, denoted as IAB-MT, 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, 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, is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.

The MT function has been defined as a component of the IAB node. In the context of this disclosure, MT is referred to as a function residing on an lAB-node that terminates the radio interface layers of the backhaul llu interface toward the lAB-donor or other IAB- nodes.

Fig. 1 shows a reference diagram for IAB in standalone mode, which contains one lAB-donor and multiple lAB-nodes. The lAB-donor may be treated as a single logical node that comprises a set of functions such as gNB-Dll, gNB-CU-control plane (CP), gNB-CU- user plane (UP), and potentially other functions. In a deployment, the lAB-donor can be split according to these functions, which can all be either collocated or non-collocated, as allowed by 3GPP NG-RAN architecture. lAB-related aspects may arise when such split is exercised. Also, some of the functions presently associated with the lAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform lAB-specific tasks. Thus, Fig. 1 shows a high-level architectural view of an IAB network such as a Reference diagram for lAB-architectures (TR 38.874 v0.7.0).

The baseline user plane and control plane protocol stacks for IAB are shown in Figs. 2 and 3.

Fig. 2 shows a Baseline User Plane (UP) Protocol stack for IAB in release (rel)-16. Fig. 3 shows a Baseline control plane (CP) Protocol stack for IAB in rel-16.

As shown, the chosen protocol stacks reuse the current CU-DU split specification in rel-15, where the full user plane F1-U (GTP-U/UDP/IP) is terminated at the IAB node, like a normal DU, and the full control plane F1-C (F1-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 datagram transport layer security (DTLS) in the case of CP. IPsec could also be used for the CP protection instead of DTLS, in this case no DTLS layer would be used.

A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is 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 ingress and egress backhaul RLC channels in intermediate IAB nodes, to satisfy the end to end quality of service (QoS) requirements of bearers.

BAP entities

On the lAB-node, the BAP sublayer contains one BAP entity at the MT function and a separate collocated BAP entity at the DU function. On the lAB-donor-DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of a BAP entity at the lAB-node or lAB-donor-DU across the backhaul link.

Fig. 4 shows one example of the functional view of the BAP sublayer. This functional view should not restrict implementation. Fig. 4 is based on the radio interface protocol architecture defined in TS 38.300 v.16.1.0. In the example of Fig. 4, the receiving part on the BAP entity delivers BAP Protocol data units (PDU) to the transmitting part on the collocated BAP entity. Alternatively, the receiving part may deliver BAP service data units (SDU) to the collocated transmitting part. When passing BAP SDlls, the receiving part removes the BAP header and the transmitting part adds the BAP header with the same BAP routing ID as carried on the BAP PDU header prior to removal. Passing BAP SDUs in this manner is therefore functionally equivalent to passing BAP PDUs, in implementation.

Services provided to upper layers

The following services are provided by the BAP sublayer to upper layers: data transfer.

Services expected from lower layers

A BAP sublayer expects the following services from lower layers per RLC entity, for a detailed description see TS 38.322 v.16.1.0: acknowledged data transfer service; unacknowledged data transfer service. Functions

The BAP sublayer supports the following functions:

Data transfer;

Determination of BAP destination and path for packets from upper layers;

Determination of egress backhaul (BH) RLC channels for packets routed to next hop;

Routing of packets to next hop;

Differentiating traffic to be delivered to upper layers from traffic to be delivered to egress link;

Flow control feedback and polling signalling.

Topology Adaptation Scenarios for Baseline Architecture Fig. 5 shows an example of some possible lAB-node migration cases listed in the order of complexity and more details, as follows:

Intra-CU Case (A): In this case, the lAB-node (E) along with it serving UEs, is moved to a new parent node (lAB-node (B)) under the same donor-DU (1). The successful intra-donor DU migration requires establishing UE context setup for the lAB- node (E) MT in the DU of the new parent node (lAB-node (B)), updating routing tables of IAB nodes along the path to lAB-node (E) and allocating resources on the new path. The IP address for lAB-node (E) will not change, while the F1-U tunnel/connection between donor-CU (1) and lAB-node (E) DU will be redirected through lAB-node (B).

Intra-CU Case (B): The procedural requirements/complexity of this case is the same as that of Case (A). Also, since the new lAB-donor DU, i.e. DU (2), is connected to the same L2 network, the lAB-node (E) can use the same IP address under the new donor DU. However, the new donor DU, i.e. DU (2), will need to inform the network using lAB-node (E) L2 address in order to get/keep the same IP address for lAB-node (E) by employing some mechanism such as Address Resolution Protocol (ARP).

Intra-CU Case (C): This case is more complex than Case (A) as it also needs allocation of new IP address for the lAB-node (E). In case IPsec is used for securing the F1-U tunnel/connection between the Donor-CU (1) and lAB-node (E) DU, then it may be possible to use an existing IP address along the path segment between the Donor-CU (1) and security gateway (SeGW), and new IP address for the IPsec tunnel between SeGW and lAB-node (E) DU.

Inter-CU Case (D): This is the most complicated case in terms of procedural requirements and it may need new specification procedures, such as enhancement of RRC, F1AP, XnAP, and Ng signalling, which are beyond the scope of 3GPP Rel-16.

Note that 3GPP Rel-16 has standardized procedure only for intra-CU migration, which is described below.

Thus, Fig. 5 shows examples of different possible scenarios for lAB-node migration.

Intra-CU topology adaptation procedure

During the intra-CU topology adaptation, both the source node and the target parent node are served by the same lAB-donor-CU. The target parent node may use a different lAB-donor-DU than the source parent node. The source path may further have common nodes with the target path. Fig. 6a shows an example of the topology adaptation procedure, where the target parent node uses a different lAB-donor-DU than the source parent node.

Thus, Fig. 6a shows an IAB intra-CU topology adaptation procedure.

Action 1. The migrating IAB-MT sends a Measurement Report message to the source parent node gNB-Dll. This report is based on a Measurement Configuration the migrating IAB-MT received from the lAB-donor-CU before.

Action 2. The source parent node gNB-Dll sends an UL RRC MESSAGE TRANSFER message to the lAB-donor-CU to convey the received Measurement Report.

Action 3. The lAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node gNB-DU to create the UE context for the migrating IAB-MT and setup one or more bearers. These bearers are used by the migrating IAB- MT for its own data and signalling traffic.

Action 4. The target parent node gNB-DU responds to the lAB-donor-CU with a UE CONTEXT SETUP RESPONSE message.

Action 5. The lAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node gNB-DU, which includes a generated RRCReconfiguration message. The Transmission Action Indicator in the UE CONTEXT MODIFICATION REQUEST message indicates to stop the data transmission to the migrating lAB-node.

Action 6. The source parent node gNB-DU forwards the received RRCReconfiguration message to the migrating IAB-MT.

Action 7. The source parent node gNB-DU responds to the lAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.

Action 8. A Random Access procedure is performed at the target parent node gNB-DU.

Action 9. The migrating IAB-MT responds to the target parent node gNB-DU with an RRCReconfigurationComplete message.

Action 10. The target parent node gNB-DU sends an UL RRC MESSAGE TRANSFER message to the lAB-donor-CU to convey the received RRCReconfigurationComplete message. Also, uplink packets can be sent from the migrating IAB-MT, which are forwarded to the lAB-donor-CU through the target parent node gNB-DU. These DL and UL packets belong to the MT’s own signalling and data traffic. Action 11. The lAB-donor-CU configures BH RLC channels and BAP-layer route entries on the target path between migrating lAB-node and target lAB-donor-DU. This step also includes allocation of transport network layer (TNL) address(es) that is (are) routable via the target lAB-donor-DU. These configurations may be performed at an earlier stage, e.g. right after action 3. The new TNL address(es) is (are) included in the RRCReconfiguration message at action 5.

Action 12. All F1-U tunnels and F1-C are switched to use the migrating IAB- node’s new TNL address(es).

Action 13. The lAB-donor-CU sends a UE CONTEXT RELEASE COMMAND message to the source parent node gNB-DU.

Action 14. The source parent node gNB-DU releases the migrating lAB-MT’s context and responds the lAB-donor-CU with a UE CONTEXT RELEASE COMPLETE message.

Action 15. The lAB-donor-CU releases BH RLC channels and BAP routing entries on the source path. The migrating lAB-node may further release the TNL address(es) it used on the source path.

NOTE: In case that the source route and target route have common nodes, the BH RLC channels and BAP routing entries of those nodes may not need to be released in action 15.

NOTE: Actions 11, 12 and 15 also have to be performed for the migrating IAB- node’s descendant nodes, as follows:

The descendant nodes must also switch to new TNL addresses that are anchored in the target lAB-donor-DU. The lAB-donor-CU may send these addresses to the descendant nodes and release the old addresses via corresponding radio resource control (RRC) signalling.

If needed, the lAB-donor-CU configures BH RLC channels, BAP-layer route entries on the target path for the descendant nodes and the BH RLC Channel mappings on the descendant nodes in the same manner as described for the migrating lAB-node in action 11.

The descendant nodes switch their F1-U and F1-C tunnels to new TNL addresses that are anchored at the new lAB-donor-DU, in the same manner as described for the migrating lAB-node in action 12.

Based on implementation, these actions can be performed after or in parallel with the handover of the migrating lAB-node. In Rel-16, in-flight packets in UL direction that were dropped during the migration procedure may not be recoverable. NOTE: In upstream direction, in-flight packets between the source parent node and the lAB-donor-CU can be delivered even after the target path is established.

NOTE: On-going downlink data in the source path may be discarded up to implementation.

NOTE: lAB-donor-CU can determine the unsuccessfully transmitted downlink data over the backhaul link by implementation.

Inter-CU migration is depicted in Fig. 5, and it is planned to be considered as part of the Rel.17 IAB enhancements. The reasons to consider inter-CU migration in IAB networks are various. For example, inter-CU migration can be beneficial in case of load balancing. Load balancing may also be achieved in the case of intra-CU migration; in case some of the IAB nodes or in the network are overloaded, part of the traffic can be routed through other IAB nodes less loaded. However, in case the objective is to reduce the load at the IAB donor CU or at the IAB donor DUs controlled by such IAB donor CU, it can be beneficial to re-route the traffic through other IAB nodes controlled by other CUs.

Additional scenarios for inter-CU migration can be related to radio measurements and more in general to mobility. For example, if radio link failure (RLF) occurs at one IAB node which is located at the edge of the network controlled by a certain donor CU, it can happen that the IAB node selects for reestablishment a cell which is controlled by a different neighbor donor CU. Moreover, in case of mobile IAB nodes it can happen that an IAB node is handed over to a cell controlled by a different target CU.

While the detailed signalling over the Xn, F1 , and RRC interface has not been specified yet in the 3GPP standard, it is foreseen that the procedure for inter-CU migration implies an handshake between source donor CU and target donor CU on the IAB node to be migrated and on the traffic that it is currently serving under the source donor CU. Such handshake can be quite similar to what happens for ordinary handover mechanisms for a UE, in which the source cell prepares the target cell with information related to such UE for the sake of admission control at the target.

Re-establishment and context fetch.

In case of RLF in the serving cell, the UE will try to re-establish the connection in one of the neighbour cells. This neighbour cell was not prepared or warned that the UE will try to connect and do not have the UE context needed to perform the re-establishment and keep the UE in RRC connected state. Therefore, it may try, if supported, to fetch the context from the cell where the RLF occurred. This procedure is described in TS 38.300 section 9.2.3.3 v.16.1.0, and also described below:

A UE in RRC_CONNECTED may initiate the re-establishment procedure to continue the RRC connection when a failure condition occurs, e.g. radio link failure, reconfiguration failure, integrity check failure, etc.

The following Fig. 6b describes the re-establishment procedure started by the UE:

Action 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.

Action 2. If the UE Context is not locally available, the gNB requests the last serving gNB to provide UE Context data.

Action 3. The last serving gNB provides UE context data.

Action 4/4a. The gNB continues the re-establishment of the RRC connection. The message is sent on signalling radio bearer (SRB) such as SRB1.

Action 5/5a. The gNB may perform the reconfiguration to re-establish SRB2 and data radio bearers (DRB) when the re-establishment procedure is ongoing.

Action 6/7. If loss of user data buffered in the last serving gNB shall be prevented, the gNB provides forwarding addresses, and the last serving gNB provides the sequence number (SN) status to the gNB.

Action 8/9. The gNB performs path switch.

Action 10. The gNB triggers the release of the UE resources at the last serving gNB.

The IAB-MT in SA mode follows the same re-establishment procedure as described for the UE. After the backhaul has been established, the re-establishment procedure of the IAB-MT is part of the intra-CU backhaul RLF recovery procedure for IAB- nodes defined in TS 38.401 [4], Modifications to the configuration of BAP sublayer and higher protocol layers above the BAP sublayer are described in TS 38.401 [4],

SUMMARY

In case RLF occurs at an IAB node, according to legacy procedures, the IAB node would select another suitable cell and perform an RRC Connection Reestablishment procedure. If the selected cell is hosted by another IAB node or donor DU which is controlled by a different CU, such CU would need to retrieve the IAB context, e.g. by fetching the context from the source CU, perform admission control, and eventually reestablish or reject the reestablishment request. While the above procedure is certainly feasible for ordinary UEs, in the context of I AB it can be prohibitive. That is because the IAB node may in turn serve, directly or indirectly, many other IAB nodes and UEs, and accommodate many BH channels that are to be routed to other underlying IAB nodes. In addition, the new ancestor nodes of the IAB node, under the target CU, also need to be reconfigured. Therefore, the context fetch and the aforementioned admission control procedure may become prohibitive, both in terms of computational complexity and signalling overhead due to the potentially very large amount of information that needs to be exchanged and processed at source and target donor CU. Additionally, in case latency-sensitive traffic is involved in the migration, the above procedure is not efficient.

The same issue may also apply to other scenarios, such handover (HO) or load balancing. Unlike RLF, at HO or load balancing, the source CU has the possibility to prepare the target CU to allow admission control in advance, i.e. before the actual HO or load balancing procedure takes place. However, if the preparation occurs right before the HO, the whole HO procedure might be delayed, given the very large amount of information to be exchanged and processed.

To this end, at least for the case of handover, conditional HO (CHO) is seen as a promising feature in the mobility area, since that allows the source cell to prepare the target cell quite much in advance before the HO command is issued. However, applying CHO in IAB networks might be prohibitive, since in CHO it is assumed that the target cell has already reserved resources for the incoming UE when it executes the handover. From resource utilization perspective, doing that in the case of IAB is infeasible, due the potentially very big amount of traffic that a migrating IAB node serves. Also, the time between the configuration of the CHO in the target nodes and the actual execution of the HO is unknown and may be substantial. It is not adequate to reserve such an amount of resources for such a long time. Another reason why CHO would not be suitable is that during this time, the resources needed for the IAB node may change (i.e. more UEs or IAB nodes are connected). This would result in a lot of signalling in order to update the CHO configurations in the target nodes.

An object herein is to provide a mechanism to enable communication, e.g. handle or manage signalling, in an efficient manner in a wireless communications network.

According to an aspect the object is achieved by providing a method performed by a first network node for handling or managing signalling or communication in a wireless communications network. The first network node transmits to a second network node a context store request message comprising context of a third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node. The first network node receives a request, from the second network node, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. The first network node further transmits a response to the second network node comprising the remaining data associated with the context of the third network node and/or the other nodes. Thus, the first network node may receive a message, e.g. a “Remaining Context Fetch Request”, from the second network node indicating that a migration request message for the third network node has been received by the second network node and/or to fetch additional data related to the third network node not already sent by the first network node to the second network node. The first network node transmits a message, e.g. a “Remaining Context Fetch Response”, to the second network node comprising the remaining information associated to the contexts of the third network node and/or served IAB nodes and/or UEs.

According to another aspect the object is achieved by providing a method performed by a second network node, such as an IAB node, for handling or managing communication and/or control signalling in a wireless communications network. The second network node receives from a first network node, a context store request message comprising context of a third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node. The second network node transmits a request, to the first network node, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. The second network node further receives a response from the first network node, wherein the response comprises the remaining data associated with the context of the third network node and/or the other nodes. Hence, the second network node may transmit a message, e.g. the “Remaining Context Fetch Request”, to the first network node indicating that a migration request message for the third network node has been received by the second network node and/or to fetch additional data related to the third network node not already sent by the first network node to the second network node. The second network node receives a message, e.g. the “Remaining Context Fetch Response”, from the first network node comprising the remaining information associated to the contexts of the third network node and/or served IAB nodes and/or UEs. According to yet another aspect the object is achieved by providing a method performed by a third network node, such as an IAB node, for handling or managing communication in a wireless communications network. The third network node receives a message from a first network node indicating that a second network node has stored the context(s) associated with the third network node and/or one or more other nodes that are served, directly or indirectly, by the third network node. For example, context(s) may be associated to the third network node and/or some or all the IAB nodes/UEs served by the third network node. The third network node transmits a migration request message, to the second network node or the first network node, requesting migration to the second network node.

It is furthermore provided herein a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the methods above, as performed by the first, the second, and the third radio network nodes, respectively. It is additionally provided herein a computer- readable storage medium, having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the methods above, as performed by the first, the second, and the third radio network nodes, respectively.

The object is achieved by providing a first network node, a second network node, and a third network node configured to perform the methods herein, respectively.

Embodiments herein allow the second network node, such as a target CU, to reduce the latency needed to retrieve the IAB context for a migrating network node, such as the third network node, and prepare the resources at the target CLI’s network when migration is triggered. Additionally, this also allows to prevent abrupt signalling storms between the first network node and the second network node, such as a source CU and donor CU, at the time of migration. Thus, embodiments herein enable communication, e.g. handle or manage signalling, in an efficient manner in a wireless communications network.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described in more detail in relation to the enclosed drawings, in which: Fig. 1 is a reference diagram depicting lAB-architectures;

Fig. 2 shows a baseline User Plane (UP) Protocol stack for IAB in rel-16 according to prior art; Fig. 3 shows a baseline control plane (CP) Protocol stack for IAB in rel-16 according to prior art;

Fig. 4 shows an example Dof functional view of BAP sublayer according to prior art;

Fig. 5 shows examples of different possible scenarios for lAB-node migration according to prior art;

Fig. 6a is an IAB intra-CU topology adaptation procedure according to prior art;

Fig. 6b shows a re-establishment procedure started by the UE;

Fig. 7a is a schematic overview depicting a wireless communications network according to embodiments herein;

Fig. 7b is a schematic overview depicting a wireless communications network according to embodiments herein;

Fig. 8 is a combined signalling scheme and flowchart according to some embodiments herein;

Fig. 9 is a combined signalling scheme and flowchart according to some embodiments herein;

Fig. 10a is a schematic flowchart depicting a method performed by a first network node according to embodiments herein;

Fig. 10b is a schematic flowchart depicting a method performed by a second network node according to embodiments herein;

Fig. 11 is a schematic flowchart depicting a method performed by a third network node according to embodiments herein;

Fig. 12 is a block diagram depicting a first network node according to embodiments herein;

Fig. 13a is a block diagram depicting a second network node according to embodiments herein;

Fig. 13b is a block diagram depicting a third network node according to embodiments herein;

Fig. 14 illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments;

Fig. 15 illustrates a host computer communicating via a base station with a user equipment over a partially wireless connection in accordance with some embodiments;

Fig. 16 illustrates methods implemented in a communication system including a host computer, a base station, and a user equipment in accordance with some embodiments;

RECTIFIED SHEET (RULE 91) ISA/EP Fig. 17 illustrates methods implemented in a communication system including a host computer, a base station, and a user equipment in accordance with some embodiments;

Fig. 18 illustrates methods implemented in a communication system including a host computer, a base station, and a user equipment in accordance with some embodiments; and

Fig. 19 illustrates methods implemented in a communication system including a host computer, a base station, and a user equipment in accordance with some embodiments.

DETAILED DESCRIPTION

Embodiments herein relate to wireless communications networks in general. Fig. 7a is a schematic overview depicting a wireless communications network 1. The wireless communications network 1 comprises one or more RANs and one or more CNs. The wireless communications network 1 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 developments of existing wireless communications systems such as e.g. LTE or Wideband Code Division Multiple Access (WCDMA).

In the wireless communications network 1, a user equipment (UE) 10, such as a mobile station, a wireless device, a non-access point (non-AP) STA, a STA, and/or a wireless terminal, is 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 “UE” is a non-limiting term which means any terminal, wireless communications terminal, user equipment, NB-loT 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 1 comprises a first radio network node 12 e.g. an IAB node such as an lAB-donor node or an IAB-CU, baseband unit (BBU), 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), MME, AMF, a stand-alone access point, or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a first radio access technology and terminology used. The first radio network node 12 may also be referred to as serving or source node or RAN node. 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. This first radio network node 12 is herein an example of a first network node 120.

The wireless communication network 1 further comprises a first intermediate radio network node 13 connected in-between the first radio network node 12 and the UE 10. The first intermediate radio network node 13 may be an IAB node e.g. a radio remote unit (RRU), 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 a service area served by the radio network node depending e.g. on a first radio access technology and terminology used.

The wireless communication network further comprises a second intermediate radio network node 14 connected in-between the first radio network node 12 and the UE 10. The second intermediate radio network node 14 may be connected to the UE 10 directly and may be an egress point. The second intermediate radio network node 14 may be an IAB node, e.g. a radio remote unit (RRU), 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 a service area served by the radio network node depending e.g. on a radio access technology and terminology used. It should be noted that a service area may be denoted as a cell, beam, beam group or similar, to define an area of radio coverage. This second intermediate radio network node 14 is herein being an example of a third network node 140 also being referred to as a migrating network node.

Furthermore, the wireless communications network 1 comprises a second radio network node 15, e.g. an IAB node such as an lAB-donor node or an IAB-CU, a baseband unit (BBU), 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), MME, AMF, a stand-alone access point, or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used. The second radio network node 15 may be referred to as a target node or RAN node. It should be noted that a service area may be denoted a as cell, beam, beam group or similar, to define an area of radio coverage. This second radio network node is herein being an example of a second network node 150 also referred to as a target network node.

The wireless communication network 1 may further comprise a third intermediate radio network node 16 connected in-between the second radio network node 15 and served UEs. The third intermediate radio network node 16 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 a service area served by the radio network node depending e.g. on a radio access technology and terminology used. It should be noted that a service area may be denoted as a cell, beam, beam group or similar, to define an area of radio coverage.

Embodiments herein disclose signalling during a cell change or a handover of an IAB node/UE, such as the second intermediate radio network node 14, to exchange context information regarding the migrating network node and associated radio network nodes and/or UEs between RAN nodes (e.g. gNBs, gNB-CUs, gNB-CU-CPs), implicitly and/or explicitly served by the migrating network node. Context may relate to an amount of resources required for serving the migrating IAB node and all the children IAB nodes and UEs being served (either directly or indirectly) by the concerned IAB node.

The scenarios considered herein are depicted in Error! Reference source not found. Fig. 7b, wherein an IAB node, i.e. the migrating IAB node E, being an example of the third network node 140, is subject to migration along with other UEs/IAB nodes directly or indirectly served by the migrating IAB node E. CU-1 is an example of the first network node 120 and Cll-2 is an example of the second network node 150.

The solution disclosed herein leverages on the availability of the context related to the IAB node which is subject to migration (defined as migrating IAB node) at the CU where the IAB is migrating to, before the migration takes place.

The essential protocols and procedures disclosed herein are illustrated in Fig. 8. The detailed embodiments are disclosed in the following. The solution is applicable to any type of migration that can be applied to an IAB node.

Action 801. The first network node 120 may select a target network node such as the second network node 150.

The first network node 120 then transmits a context store request message, for nodes associated with the first network node, to the second network node 150 that responds with a context store response.

Action 802. The second network node 150 may then perform context storing of the nodes related to the first network node such as the third network node 140, IAB- nodel . The second network node 150 may optionally perform an admission control for the nodes related to the first network node.

Furthermore, in some embodiments, the first network node 120 may transmit an RRC configuration to the third network node 140 indicating that the second network node 150 has stored context of the third network node 140 and/or events to trigger migration.

Action 803. The third network node 140 may then experience an event triggering a migration. For example, the migration can be due to an RLF experienced at the IAB node upon which the IAB node performs a reestablishment, or due to a migration due to an HO triggered by the source CU towards a target CU, or due to an HO, e.g. conditional handover, triggered by the IAB node following a certain event, such as A3/A5 events or RLF, or due to a load balancing procedure triggered by the source CU for some of the traffic traversing the IAB node.

The third network node 140 may then, for example, transmit a migration request, e.g. a RRC migration request, to the second network node 150.

The second network node 150 transmits a Remaining context fetch request to the first network node 120, which transmits a remaining context fetch response to the second network node 150.

Action 804. The second network node 150 then, based on the stored context and the context in the remaining context fetch response, performs an admission control for the third network node 140. The second network node 150 may then transmit a migration completed message to the first network node 120 and a RRC migration response to the third network node 140.

The following should be noted in the context of embodiments of the present disclosure:

• The inter-CU IAB node migration may be caused by e.g. RLF, load balancing, IAB node mobility, HO, CHO. These are non-limiting examples.

• The terms migration, handover, and mobility are used interchangeably.

• The term “migrating IAB node” refers to the IAB node which is subject to migration from one serving cell to another serving cell.

• The terms “gNB-CU” and “Donor-CU”, “CU-CP,” and “CU” are used interchangeably.

• The term “gNB” applies to all variants therein, e.g. “gNB”, “en-gNB,” etc.

• The term “a LIE/IAB node directly served by the migrating IAB node" refers to a LIE/IAB node that is directly connected to the IAB node.

• The term “a LIE/IAB node is indirectly served by the migrating IAB node" means that the IAB node is an ancestor node to an IAB node that is currently serving the UE or IAB node.

• The term “first network node" refers to a source gNB-CU currently serving the migrating IAB node.

• The term “second network node" refers to a target gNB-CU to which the IAB node is migrating.

• The term “third network node" refers to an IAB node which performs migration.

Fig. 9 is a combined signalling scheme and flowchart depicting some embodiments herein wherein the first network node 120 is the first radio network node 12 and is exemplified as a donor CU. The second network node 150 is the second radio network node 15, and the third network node 140 is the second intermediate radio network node 14.

Action 901. The first radio network node 12 may select, for the migrating IAB node, e.g. second intermediate radio network node 14, the second radio network node 15 i.e. a target gNB-CU, to which the second intermediate radio network node 14 might be migrated.

Action 902. The first radio network node 12 transmits a context store request message such as a migrating context request to the second radio network node 15, wherein the migrating context request comprises data (indication) associated with the (migrating) node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the node. The data indicates one or more resources required to serve the node and/or other nodes.

Action 903. The second radio network node 15 may then decide or determine whether to accept and store, or not accept and store, the context of the (migrating) node, e.g. IAB node, and data related to the other nodes, such as IAB nodes and/or UEs, served.

Action 904. The second radio network node may inform the first radio network node 12 upon decision, and the first radio network node may inform the second intermediate radio network node 14, e.g., that the second radio network node 15 has context related to the second intermediate radio network node 14.

Action 905. The third network node i.e. the second intermediate radio network node 14 may then transmit a migration request to migrate to the second radio network node 15.

Action 906. The second radio network node 15 transmits, after triggered migration of the second intermediate radio network node 14 to the second radio network node 15, a request , for example, a remain request denoted as a “Remaining Context Fetch Request,” to the first radio network node 12 indicating to fetch additional data related to the second intermediate radio network node 14 and not already stored. The remain request may also indicate that a migration request message has been received by the second network node from the third network node.

Action 907. The first radio network node 12 transmits a response such as a remain response, e.g. a “Remaining Context Fetch Response,” to the second radio network node 15, comprising the remaining information associated to the contexts of the second intermediate radio network node 14 and/or served IAB nodes and/or UEs.

Action 908. The second radio network node 15 may then transmit a migration response, e.g. “Migration Completed”, indicating that the third network node (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node. Alternatively, the message may indicate that the third network node and/or all or some of the served IAB nodes/UEs have been rejected. This may be forwarded or indicated to the second intermediate radio network node 14.

The method actions performed by the first network node, such as the first radio network node 12 being, for example, an IAB node, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 10a. The wireless communications network 1 may comprise the first radio network node 12 and the second radio network node 15 and one or more nodes relaying data packets between the radio network nodes and the UE 10 and/or intermediate radio network nodes between the first network node and UEs.

Action 1001. The first network node 120 may select the second (target) network node 150 to migrate to the third network node 140.

Action 1002. The first network node 120 transmits to the second network node 150 the context store request message comprising context of the third network node 140 and/or of one or more other nodes 10,13 that are served, directly or indirectly, by the third network node 140. For example, the first network node may transmit the migrating context request to the second network node, wherein the migrating context request comprises data (indication) associated with the (migrating) node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node. The context store request message may request the second network node to store the context of the third network node and/or of the one or more other nodes. The context store request message may comprise a plurality of information comprising one or more of: a RRC context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of BAP addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes. The context store request message may also indicate one or more of the following: for how long context of a third network node 140 and/or of one or more other nodes 10,13 should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration. Along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node may be transmitted and may be indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instances.

Action 1003. The first network node 120 may receive the context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes. The context store response may indicate that only some of the contexts have been stored by the second network node.

Action 1004. The first network node 120 receives the request, from the second network node 150, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. Thus, the first network node 120 may receive the message, e.g. the remain request e.g. a “Remaining Context Fetch Request”, from the second network node indicating that a migration request message for the third network node has been received by the second network node 150 and to fetch additional data related to the third network node 140 not already sent by the first network node 120 to the second network node 150.

Action 1005. Upon receiving the request, the first network node 120 may compare current contexts associated to the third network node 140 and/or served one or more other nodes with information received in the context store response. In case the context store response does not indicate any additional information, i.e., it is just an acceptance or a rejection signal, the first network node 120 may compare the current contexts with the context previous signalled in the context store request message.

Action 1006. The first network node 120 transmits a response to the second network node 150 comprising the remaining data associated with the context of the third network node 140 and/or the other nodes. For example, the first network node 120 transmits a message, such as the remain response, e.g. a “Remaining Context Fetch Response” to the second network node 150 comprising the remaining information associated to the contexts of the third network node and/or served I AB nodes and/or UEs. The transmitted response may comprise information based on the comparison.

Action 1007. The first network node 120 may then receive a migration response, e.g. “Migration Completed”, indicating that the third network node 140 (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node 150. Alternatively, the message may indicate that the third network node 140 and/or all or some of the served IAB nodes/UEs have been rejected. Thus, the first network node 120 may receive the migration response, indicating that the third network node and/or one or more of the other nodes have been migrated to the second network node and/or have been rejected. The method actions performed by the second network node 150, such as an I AB node, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 10b. The wireless communications network may comprise the first network node and the second network node and one or more nodes relaying data packets between a central network node and a UE.

Action 1011. The second network node 150 receives from the first network node 120, the context store request message comprising context of the third network node 140 and/or of one or more other nodes that are served, directly or indirectly, by the third network node 140. For example, the second network node 150 may receive the migrating context request from the first network node 120, wherein the migrating context request comprises data (indication) associated with the (migrating) node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node. The second network node may store data from the migrating context request. The context store request message may request the second network node 150 to store the context of the third network node 140 and/or of the one or more other nodes. The context store request message may comprise a plurality of information comprising one or more of: a RRC context; measurements related to neighbour cells belonging to the second network node 150; context of a distributed unit connected to the first network node 120; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of BAP addresses and BAP routing IDs assigned to the third network node 140 and/or the one or more other nodes. Along with the context of the third network node 140, context of each of the one or more other nodes that is served directly or indirectly by the third network node may be received and indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instance. The context store request message may also indicate one or more of the following: for how long context of a third network node 140 and/or of one or more other nodes should be kept by the second network node 150; a prediction on when a migration of the third network node 140 occurs; a probability of migration within a certain time window; and a purpose of the migration.

Action 1012. The second network node 150 may determine acceptance or rejection to store the context of the third network node 140 and/or of the one or more other nodes. Action 1013. The second network node 150 may transmit the context store response from the second network node 150 indicating acceptance or rejection to store the context of the third network node 140 and/or of the one or more other nodes. The context store response may indicate that only some of the contexts have been stored by the second network node.

Action 1014. The second network node 150 may receive the request for the third network node to migrate to the second network node. The second network node 150 may receive a migration request message, from the third network node 140 or the first network node 120, requesting migration of the third network node 140 to the second network node 150.

Action 1015. The second network node 150 transmits the request, to the first network node 120, indicating to fetch remaining data associated with the context of the third network node 140 and/or of one or more other nodes that are served, directly or indirectly, by the third network node 140, not already sent by the first network node 120 to the second network node 150. Thus, the second network node 150 may transmit the message, e.g. the remain request e.g. a “Remaining Context Fetch Request”, to the first network node indicating that a migration request message for the third network node has been received by the second network node and/or to fetch additional data related to the third network node not already sent by the first network node to the second network node 150.

Action 1016. The second network node 150 receives the response from the first network node 120, wherein the response comprises the remaining data associated with the context of the third network node 140 and/or the other nodes. For example, the second network node 150 may receive the message, such as the remain response e.g. a “Remaining Context Fetch Response” from the first network node 120 comprising the remaining information associated to the contexts of the third network node 140 and/or served I AB nodes and/or UEs.

Action 1017. The second network node 150 may determine, based on the received response, if there are radio resources available and capacity at the second network node 150 to handle the third network node 140 and/or the served one or more other nodes and related traffic.

Action 1018. The second network node 150 may transmit a reconfiguration message, indicating acceptance or rejection of the third network node and/or the one or more other nodes. The second network node 150 may transmit the migration response, to the first network node, indicating that the third network node and/or the one or more other nodes have migrated to the second network node. The second network node 150 may transmit the migration response, e.g. “Migration Completed”, indicating that the third network node 140 (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node. Alternatively, the message may indicate that the third network node and/or all/some of the served IAB nodes/UEs have been rejected.

The method actions performed by the third network node 140, such as an IAB node or a UE, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 11. The wireless communications network may comprise the first network node 120 and the second network node 150 and one or more nodes relaying data packets between a central network node and a UE.

Action 1101. The third network node 140 receives a message from the first network node 120 indicating that the second network node 150 has stored context associated with the third network node 140 and/or one or more other nodes that are served, directly or indirectly, by the third network node 140. The third network node 140 may, thus, receive a message from the first network node 120 indicating that the second network node 150 has stored the context(s) associated to the third network node 140 and/or some or all the IAB nodes/UEs served by the third network node 140.

Action 1102. The third network node 140 may execute the migration upon fulfilling certain conditions, e.g. RLF at the backhaul link with the parent node, reception of BH RLF recovery failure indication from the parent node, execution of CHO, congestion higher than certain threshold at the backhaul link with the parent, reception of HO command etc..

Action 1103. The third network node 140 transmits a migration request message to the second network node 150 or the first network node 120, requesting the migration to the second network node.

The first method defined for a first network node 120, i.e. the source gNB-CU (e.g. CU1 in Fig. 8), may comprise:

• (Optionally) Selecting (see above action 1001) for a certain migrating IAB node, i.e. third network node 140, a second network node 150, i.e. a target gNB-CU, to which the third network node 140 might be migrated. • Transmitting (see above action 1002) to the second network node a “Context Store Request” message, i.e. the context of the third network node 140 and the contexts of each I AB node/UE that is served directly or indirectly by the third network node 140 and that should be migrated to the second network node 150 when the migration is triggered for the third network node 140.

• (Optionally) Receiving (see above action 1003) from the second network node a message, i.e., “Context Store Response” acknowledging that that the transmitted contexts above are now stored by the second network node 150, or a message rejecting the transmitted contexts or a message indicating that only some of the contexts have been stored by the second network node 150. For example, the second network node 150 may indicate that only some of the contexts associated to IAB nodes/UEs directly or indirectly served by the third network node 140 have been stored. The reason might be the second network node 150 not being able to handle some of the BH RLC channels traversing the third network node 140 or DRBs associated to UEs directly or indirectly served by the third network node 140.

• (Optionally) Transmitting a modification message to the second network node 150 to modify the context(s) previously stored by the second network node 150.

• (Optionally) Receiving a message acknowledging or rejecting the modification message.

• (Optionally) Receiving a message from the second network node 150 with a request to remove/modify some of the context(s) previously stored by the second network node 150.

• (Optionally) Transmitting (see above action 1011) a message to the third network node 140 indicating that the second network node 150 has stored the context(s) associated to the third network node 140 and some or all the IAB nodes/UEs served by the third network node 140. The message may also contain information on how to operate at migration to the second network node 150.

• (Optionally) Performing the actions above for the IAB nodes whose contexts have been rejected by the second network node 150, e.g. selecting another target CU (i.e. a different second network node).

• Receiving (see above action 1004) after triggered migration of the third network node to the second network node, a message, i.e. “Remaining Context Fetch Request” from the second network node 150 indicating that a migration request message has been received by the second network node 150 from the third network node 140. This message serves the purpose to fetch any additional context(s) related to the third network node 140 or served IAB nodes/UEs that has not yet been communicated by the first network node 120, or that has not been stored by the second network node 150 as per previous methods.

• Transmitting (see above action 1006) a message, i.e. “Remaining Context Fetch Response” to the second network node 150 containing the remaining information associated to the contexts of the third network node and served IAB nodes/UEs

• (Optionally)Receiving (see above action 1007) a message, i.e. “Migration Completed”, from the second network node 150 indicating that the third network node 140 (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node 150. Alternatively, the message may indicate that the third network node 140 and/or all/some of the served IAB nodes/UEs have been rejected

• (Optionally) Performing the actions above for the IAB nodes that were not admitted by the second network node 150 at migration.

The second method defined for the second network node 150, i.e. the target gNB- CU (e.g. CU2 in Figure 8), may comprise:

• (Optionally) Receiving (see above action 1011) from the first network node 120 a message, i.e., “Context Store Request”, indicating the context of the third network node 140, i.e., a migrating IAB node, and the contexts of each IAB node/UE that is served directly or indirectly by the third network node 140.

• (Optionally) Determining (see above action 1012) whether the contexts received can be stored.

• (Optionally) Storing the contexts of the third network node 140 and served IAB nodes/UEs (or portions of them) received in action 1011 on the basis of the action 1012.

• (Optionally) Reserving a limited set of resources to accommodate the third network node 140 and the UEs/IAB nodes that are directly or indirectly served by it.

• (Optionally) Transmitting (see above action 1013) a message, i.e. “Context Store Response” to the first network node 120 acknowledging or rejecting the contexts or portions of them received in action 1011.

• (Optionally) Receiving a modification message from the first network node 120 to modify the context(s) previously stored by the second network node 150. • (Optionally) Transmitting a message acknowledging or rejecting the modification message.

• (Optionally) Transmitting a message indicating release or modification of some of the context previously stored.

• (Optionally) Receiving (see above action 1014) a migration request message, i.e. “RRC Migration Request”, from the third network node 140 requesting the migration to the second network node 150. The migration request can be represented by a new RRC message requesting migration or included in existing messages such as RRC Reestablishment Request, or by an RRC Resume Request, or by an RRC Setup Request, or by a new RRC message.

• (Optionally) Retrieving the concerned contexts stored.

• Transmitting (see above action 1015) a message, i.e. “Remaining Context Fetch Request”, to the first network node 120 indicating that the migration request message has been received from the third network node 140. This message serves the purpose to fetch any additional context(s) related to the third network node 140 or served IAB nodes/UEs that has not yet been communicated by the first network node 120, or that has not been stored by the second network node 150 as per previous methods.

• Receiving (see above action 1016) a message, i.e. “Remaining Context Fetch Response”, from the first network node 120 containing the remaining information associated to the contexts of the third network node 140 and served IAB nodes/UEs.

• (Optionally) Determining (see above action 1017) based on the retrieved information if there are radio resources available and capacity at the second network node 150 to handle the third network node 140 and served UEs/IAB nodes and related traffic. This action may correspond to an admission control procedure for the third network node 140.

• (Optionally) Transmitting (see above action 1018) a reconfiguration message, i.e. “RRC Migration Response”, indicating acceptance or reject to the third network node 140. The reconfiguration message may include a rejection for the whole migration of the third network node 140 and served UEs/IAB nodes, or just a rejection for a portion of the contexts associated to the third network node 140.

• (Optional) Transmitting (see above action 1018) a message, i.e. “Migration Completed”, to the first network node indicating that the third network node (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node. Alternatively, the message may indicate that the third network node and/or all/some of the served IAB nodes/UEs have been rejected.

• (Optionally) Releasing, in case of rejection, the context(s) associated to the third network node and/or to the served IAB nodes/UEs. Alternatively, even in case of rejection the context(s) are not released. That might be beneficial in case a further event (e.g. RLF) occurs at the third network node 140 and a new migration to the second network node 150 is triggered.

The third method defined for the third network node 140, i.e. the IAB node that performs migration (e.g. IAB node 1 in Figure 8), may comprise:

• (Receiving (see above action 1101) the message from the first network node 120 indicating that the second network node 150 has stored the context(s) associated to the third network node 140 and some or all the IAB nodes/UEs served by the third network node 140. The message may also contain information on how to operate at migration to the second network node 150.

• (Optionally) Executing (see above action 1102) the migration upon fulfilling certain conditions, e.g. RLF at the backhaul link with the parent node, reception of BH RLF recovery failure indication from the parent node, execution of CHO, congestion higher than certain threshold at the backhaul link with the parent, reception of HO command etc.

• Transmitting (see above action 1103) the migration request message to the second network node 150 requesting the migration to the second network node 150. The migration request can be represented by a new RRC message requesting migration or included in existing messages such as RRC Reestablishment Request, or by an RRC Resume Request, or by an RRC Setup Request, or by a new RRC message. In some scenarios, such as load balancing in which the third network node 140 still has connection to the first network node 120, the migration request can also be encapsulated in an F1 message (modified exiting or newly defined F1 signalling) from the third network node 140 to the first network node 120. The first network node 120 may then decapsulate the request and forward it to the second network node 150 by means of Xn signalling (modified exiting or newly defined Xn signalling).

• (Optionally) Receiving (see above action 1018) a reconfiguration message indicating acceptance or rejection to the third network node 140. The reconfiguration message may include a rejection for the whole migration of the third network node 140 and served UEs/IAB nodes, or just a rejection for a portion of the contexts associated to the third network node 140. In some scenarios, such as load balancing in which the third network node 140 still has connection to the first network node 120, the reconfiguration message can, similarly as described above for the migration request message, be encapsulated in Xn signalling between the second and first network node, and then decapsulated and forwarded by the first network node 120 to the third network node 140 by means of F1 signalling.

• (Optionally) Transmitting a reconfiguration message to directly/indirectly served IAB nodes/UEs to inform them about the migration. The reconfiguration message may be an RRC message including the message in a transparent container received by the second network node 150 and first network node 120, or a BAP message sent between directly connected IAB nodes. For example, the message may also include the Packet Data Convergence Protocol (PDCP) security keys that UEs/IAB nodes should use for communications after migration to the second network node 150. For the IAB nodes/UEs that have been rejected by the second network node 150, the reconfiguration message may include instructions to reselect an alternative parent/serving IAB node or another frequency.

Other embodiments related to previous methods.

Related to action 1001: The selection may be based on measurements received from the IAB node related to the serving cell and to neighbouring cells hosted by other IAB nodes/donor DUs controlled by the second network node 150, wherein a measurement may imply reporting of experienced reference signal received power (RSRP), reference signal received quality (RSRQ) or received signal strength indicator (RSSI) and RLM indication with respect to the serving cell (e.g. experienced out-of-sync indications, RLC transmission failures, etc. with respect to the serving cell).

In yet another alternative, the selection may depend on the specific type of traffic and/or on the volume of data that may traverse the third network node. For example, if the type of traffic handled by the third network node requires large amount of radio resources or if the amount of IAB nodes/UEs that can be served directly or indirectly by the IAB node is high, then the first network node may select the second network node for load balancing/offloading purposes.

Alternatively, the selection may be based on the specific deployment, i.e. the third network node may be deployed in a region where radio coverage is also provided by other IAB nodes/donor Dlls controlled by the second network node, or radio coverage is poor meaning that reliable radio links cannot be ensured towards a specific donor CU. In yet another alternative, the selection may be based on OAM configuration.

The selection takes place before the migration is initiated at the IAB node, e.g. it may take place when the third network node 140 is configured, or upon reception of a measurement result from the IAB node, or at BH channel configuration depending on the QoS or amount of UEs multiplexed.

The selection may involve one or more target CUs, i.e. second network nodes

Related to action 1002: The context of an IAB node indicated by the first network node 120 to the second network node 150 may contain a plurality of information such as the RRC context, the measurements related to neighbour cells belonging to the second network node 150, the context of the DU of the IAB node (e.g. the context of the F1 connection to the first network node), the information about IP addresses allocated to the IAB node (number of addresses, type (IPv4 or IPv6), usage etc.), the BH RLC channel list, including the QoS, priority and traffic mapping type (1:1 or N:1), the amount of UEs/IAB nodes directly or indirectly served, the topology information (e.g. which IAB node/UE is served by which IAB node), the routing information associated to each BH RLC channel (e.g. the BAP routing IDs mapped to the channel), the number of BAP addresses and BAP routing IDs assigned to the IAB node, etc.

Along with the context of the third network node 140, the first network node 120 may also transmit the context of each IAB node/UE that is served directly or indirectly by the third network node 140 and that should be migrated to the second network node 150 when the migration is triggered for the third network node 140. The first network node 120 may also indicate a list of one more cells that are controlled by the second network node 150 and that the third network node 140 may select at migration, as per the measurement results (e.g. strongest cell reported by the third network node 140) or specific deployment.

The transmission of such additional context may be indicated as part of the IE indicating the context of the third network node 140 or in separate lEs or message transmission instance.

As part of this transmission, the first network node 120 may also indicate for how long this context should be kept by the second network node, a prediction on when the migration of the third network node may occur, the probability of migration within a certain time window, the purpose of the migration, e.g. HO, RLF, CHO, load balancing, etc. The modification message can be triggered by change in the context of the third network node 140 or any other IAB node/UE served directly or indirectly, e.g. due to changes in the BH RLC channels, due to change in the routing table of nodes served by the third network node 140, or due to connection release/setup of new UEs/IAB nodes served directly or indirectly by the third network node 140, or due to change in routes that terminate at the third network node 140or any change in one or multiple parameters sent. Such message may also be due to changes on how long this context should be kept by the second network node 150, or change in the prediction on when the migration of the third network node 140 may occur, or on the probability of migration.

Such message may be transmitted whenever there is a change in the context of the third network node 140 or any other served IAB node/UEs, e.g. new DRB/BH RLC channel established, new UE attached to an IAB node, etc., or periodically.

A message may be generated by the second network node 150 due to changes to the traffic or to the amount of IAB nodes/UEs or DRBs, or BH RLC channels currently handled by the second network node donor CU/DU or by the IAB nodes controlled by the second network node 150 that might need to serve the third network node 140 after migration. For example, if the current load in the second network node 150 exceeds a certain threshold, the second network node 150 may release some of the contexts (or portions of them) stored, e.g. by indicating release of certain BH RLC channels, DRBs or entire UE/IAB node contexts.

A message can be represented, for example, by an RRC Reconfiguration message. The message may contain an indication of the cell hosted by an IAB node or IAB donor DU controlled by the second network node 150 which accepted the context related to the third network node 140. The third network node, i.e. the concerned IAB node, may adopt this information, for example, when an RLF is triggered, so that at cell reselection, the third network node prioritizes selection of such cell.

The message may also include an explicit indication of the IAB nodes/UEs served directly or indirectly by the third network node whose contexts have been stored by the second network node. This message may also include an indication of which BH RLC channels that can be kept at migration, since, if only some of the IAB nodes/UEs currently served have been stored by the second network node, it could be that at migration certain BH RLC channels need to be released. For the IAB nodes/UEs served by the third network node 140 whose contexts has been accepted by the second network node 150, such message may also contain the PDCP security keys to be used for communications after migration to the second network node 150.

The message may also indicate the event under which the information contained in this message should be executed, e.g. upon RLF, upon fulfilling of certain conditions (such as A3/A5 events like in CHO), upon reception of reconfiguration message indicating handover of certain BH RLC channel towards the second network node for load balancing purposes, etc.

Actions 1004, 1006, 1015 and 1016: The “Remaining Context Fetch Request” and “Remaining Context Fetch Response” messages can be an enhancement of the existing “Retrieve UE Context Request” and “Retrieve UE Context Response” messages, to include the lAB-specific information, such as the parameters described above. An example of a possible implementation is given below in bold and underlined text: 9.1.1.8 RETRIEVE UE CONTEXT REQUEST

This message is sent by the new NG-RAN node to request the old NG-RAN node to transfer the UE Context to the new NG-RAN.

Direction: new NG-RAN node old NG-RAN node.

9.1.1.9 RETRIEVE UE CONTEXT RESPONSE

This message is sent by the old NG-RAN node to transfer the UE context to the new NG-RAN node.

Direction: old NG-RAN node

new NG-RAN node.

Related to actions 1007 and 1018: The “Migration Completed message” can be a message that can be used for self-organizing network (SON) purposes. For example, with this message, the first network node 120 can figure out whether the migration procedure was correctly executed, and that second network node 150 can be used in future for migration. Additionally, at reception of this message, the first network node 120 may release the context associated to the third network node 140 and to served I AB nodes/UEs. In case multiple target CUs different than the second network node 150, stored the contexts related to the third network node 140, the first network node 120 can request such target CUs to release the contexts associated to the third network node 140. In another example, the migration completed message can contain a request to the first network node 120 to keep the contexts of the third network node 140 and/or of all/some of the served IAB nodes/UEs which have been rejected by the admission control at the second network node 150. For example, the migration completed message could be represented by a migration request message from the second network node 150 to the first network node 120, in which the second network node requests the first network node 120 to keep stored the IAB nodes/UEs that were rejected. After such migration request, the second network node 150 may send an RRCReconfiguration message, e.g. “RRC migration response” to those IAB nodes/UEs that were rejected indicating to migrate back to the first network node 120.

The message can be optional in case the migration completed successfully and no IAB nodes/UEs involved in the migration is rejected.

Related to action 1012: The “determining” action may depend on a plurality of factors, such as the current amount of available radio resources, the capacity in terms of amount of DRBs, BH RLC channels, UEs, IAB nodes that can be handled by the donor DU/CU of the second network node 150, and/or by the IAB nodes controlled by the second network node 150 that would need to handle the traffic indicated in the message received currently traversing the third network node 140. Such latter evaluation can be based on the cell that the third network node 140 may select at migration, and the topology/routing table of the IAB node serving that cell.

Related to action 1012: For example, the second network node 150 may determine to store only some of the contexts associated to IAB nodes/UEs directly or indirectly served by the third network node 140. The reason might be the second network node 150 not being able to handle some of the BH RLC channels traversing the third network node 140 or DRBs associated to UEs directly or indirectly served by the third network node 140.

About reserving resources, the second network node 150 may reserve a set of random access channel (RACH) resources, e.g. for a contention free random access (CFRA), for the migration of the third network node 140, or a portion of time/frequency resources just for critical BH RLC channels/DRBs traversing the third network node. The second network node may also reserve a number of IP addresses, BAP addresses and BAP routing IDs, based on the IAB node context information received from the first network node. The second network node 150 may also assemble a set of reconfiguration messages (e.g. BH RLC channel setup/modification messages or routing update messages) that are to be used for reconfiguring the IAB nodes under the second network node 150 that are to be affected by the migration (e.g. the new parent of the third network node 140).

Related to actions 1014 and 1103: The migration request message may be represented by a new RRC message requesting migration or included in existing messages such as RRC Reestablishment Request, or by an RRC Resume Request, or by an RRC Setup Request, or by a new RRC message. In some scenarios, such as load balancing in which the third network node 140 still has connection to the first network node 120, the migration request can also be encapsulated in an F1 message (modified exiting or newly defined F1 signalling) from the third network node 140 to the first network node 120. The first network node 120 can then decapsulate the request and forward it to the second network node 150 by means of Xn signalling (modified exiting or newly defined Xn signalling).

Related to actions 1004 and 1015: The “Remaining Context Fetch Request” may be triggered by the second network node 150 after it receives the migration request. This message is needed because at the time of triggered migration, the context(s) stored by the second network node 150 may not be up-to-date. That is because the context(s) associated to the third network node 140 and served UEs/IAB nodes that were saved by the second network node 150 (as indicated in “Context Store Accept”) may have changed compared with the last transmission of “Context Store Request”, e.g. new DRBs/BH RLC Channels may have been established/old channels released or new UEs/IAB nodes may have connected to the first network node 120. Upon receiving such request, the first network node 120 compares the current contexts associated to third network node 140 and served IAB nodes/UEs with the information received in “Context Store Accept” and it transmits the delta to the second network node 150. UEs/IAB nodes that were indicated as not stored by the second network node 150 may be included or not included in the “Remaining Context Fetch Response”.

Related to action 1018: The reconfiguration message from the second network node 150 may indicate that only some of the IAB nodes or UEs directly or indirectly served by the third network node 140 are admitted by the second network node 150. The message may also contain a reconfiguration of the DRBs and of BH RLC channels and related routing table, QoS requirements, wherein some of the BH RLC channels configured by the first network node 120 may be removed or modified by the second network node 150. For example, several N:1-mapped BH RLC channels under the first network node 120 may be bundled into one N:1-mapped BH RLC channels under the second network node 150. In case of rejection, the message may also indicate an alternative carrier in which the IAB nodes/UEs not admitted can attempt migration.

Fig. 12 is a block diagram depicting the first network node 120 for handling communication in the wireless communications network 1 according to embodiments herein.

The first network node 120 may comprise processing circuitry 1201 , e.g. one or more processors, configured to perform the methods herein.

The first network node 120 may comprise a transmitting unit 1202, e.g. a transmitter or a transceiver. The first network node 120, the processing circuitry 1201, and/or the transmitting unit 1202 are configured to transmit to the second network node 150 the context store request message comprising context of the third network node 140 and/or of one or more other nodes that are served, directly or indirectly, by the third network node 140. For example, the first network node 120, the processing circuitry 1201, and/or the transmitting unit 1202 may be configured to transmit the migrating context request to the second network node, wherein the migrating context request comprises data (indication) associated with the (migrating) node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node. The first network node 120, the processing circuitry 1201, and/or the transmitting unit 1202 may be configured to transmit the response to the second network node comprising the remaining data associated with the context of the third network node and/or the other nodes. For example, the first network node 120, the processing circuitry 1201, and/or the transmitting unit 1202 may be configured to transmit the message, the remain response e.g. a “Remaining Context Fetch Response” to the second network node comprising the remaining information associated to the contexts of the third network node and/or served IAB nodes and/or UEs. The context store request message may request the second network node to store the context of the third network node and/or of the one or more other nodes. The context store request message may comprise a plurality of information comprising one or more of: a RRC context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of BAP addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes. The context store request message may also indicate one or more of the following: for how long context of a third network node and/or of one or more other nodes should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration. The first network node 120, the processing circuitry 1201, and/or the transmitting unit 1202 may be configured to, upon receiving the request, compare current contexts associated to the third network node 140 and/or served other nodes with information received in the context store response and the transmitted response comprises information based on the comparison. The information received in the context store response may comprise information that context of one or more of the third network node and/or the one or more other nodes have been stored by the second network node 150. For example, the second network node may indicate that only some of the contexts associated to I AB nodes/UEs directly or indirectly served by the third network node have been stored. Along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node may be transmitted and may be indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instances.

The first network node 120 may comprise a selecting unit 1203. The first network node 120, the processing circuitry 1201, and/or the selecting unit 1203 may be configured to select the second network node to migrate to, for the third network node.

The first network node 120 may comprise a receiving unit 1204, e.g. a receiver or a transceiver. The first network node 120, the processing circuitry 1201, and/or the receiving unit 1204 is configured to receive the request, from the second network node, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. For example, receive the message, e.g. the remain request e.g. a “Remaining Context Fetch Request”, from the second network node indicating that a migration request message for the third network node has been received by the second network node and/or to fetch additional data related to the third network node not already sent by the first network node to the second network node. The first network node 120, the processing circuitry 1201, and/or the receiving unit 1204 may be configured to receive the context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes. The first network node 120, the processing circuitry 1201, and/or the receiving unit 1204 may be configured to receive the migration response, indicating that the third network node and/or one or more of the other nodes have been migrated to the second network node and/or have been rejected. For example, receive a migration response, e.g. “Migration Completed”, indicating that the third network node (possibly with some or all of the served I AB nodes/UEs) has now migrated to the second network node. Alternatively, the message may indicate that the third network node and/or all/some of the served IAB nodes/UEs have been rejected.

The first network node 120 further comprises a memory 1205. The memory 1205 comprises one or more units to be used to store data on, such as indications, contexts, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the first network node 120 may comprise a communication interface 1208 such as comprising a transmitter, a receiver and/or a transceiver.

The methods according to the embodiments described herein for the first network node 120 are respectively implemented by means of e.g. a computer program product 1206 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 network node 120. The computer program product 1206 may be stored on a computer-readable storage medium 1207, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1207, having stored thereon 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 network node 120. 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 network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first network node is operative to perform any of the methods herein. Fig. 13a is a block diagram depicting the second network node 150 such as the second radio network node 15, for handling communication in a wireless communications network 1 according to embodiments herein.

The second network node 150 may comprise processing circuitry 1301 , e.g. one or more processors, configured to perform the methods herein.

The second network node 150 may comprise a transmitting unit 1302, e.g. a transmitter or a transceiver. The second network node 150, the processing circuitry 1301, and/or the transmitting unit 1302 is configured to transmit the request, to the first network node 120, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node. For example, the second network node 150, the processing circuitry 1301 , and/or the transmitting unit 1302 may be configured to transmit the message, e.g. the remain request e.g. a “Remaining Context Fetch Request”, to the first network node 120 indicating that a migration request message for the third network node has been received by the second network node 150 and/or to fetch additional data related to the third network node 140 not already sent by the first network node 120 to the second network node 150. The second network node 150, the processing circuitry 1301, and/or the transmitting unit 1302 may be configured to determine acceptance or rejection to store the context of the third network node and/or of the one or more other nodes; and to transmit the context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes. The second network node 150, the processing circuitry 1301, and/or the transmitting unit 1302 may be configured to determine based on the received response if there are radio resources available and capacity at the second network node to handle the third network node and the served one or more other nodes and related traffic. The second network node 150, the processing circuitry 1301 , and/or the transmitting unit 1302 may be configured to transmit the reconfiguration message, indicating acceptance or rejection of the third network node and/or the one or more other nodes.

In some embodiments, the second network node 150, the processing circuitry 1301, and/or the transmitting unit 1302 may be configured to transmit the migration response, e.g. “Migration Completed”, indicating that the third network node 140 (possibly with some or all of the served IAB nodes/UEs) has now migrated to the second network node. Alternatively, the message may indicate that the third network node and/or all/ or some of the served IAB nodes/UEs have been rejected.

The second network node 150 may comprise a receiving unit 1304, e.g. a receiver or a transceiver. The second network node 150, the processing circuitry 1301, and/or the receiving unit 1304 is configured to receive from the first network node 120, the context store request message comprising context of the third network node 140 and/or of one or more other nodes that are served, directly or indirectly, by the third network node 140. For example, the second network node 150, the processing circuitry 1301, and/or the receiving unit 1304 may be configured to receive the migrating context request from the first network node, wherein the migrating context request comprises data (indication) associated with the (migrating) node, e.g. IAB node, and data related to other nodes, such as IAB nodes and/or UEs, directly and indirectly served by the migrating node. The second network node 150 may store data from the migrating context request. The context store request message may request the second network node to store the context of the third network node and/or of the one or more other nodes. The context store request message may comprise a plurality of information comprising one or more of: a RRC context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of BAP addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes. The context store request message may also indicate one or more of the following: for how long context of a third network node 140 and/or of one or more other nodes should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration. The second network node 150, the processing circuitry 1301, and/or the receiving unit 1304 may be configured to receive the request for the third network node to migrate to the second network node. The second network node 150, the processing circuitry 1301, and/or the receiving unit 1304 is configured to receive the response from the first network node, wherein the response comprises the remaining data associated with the context of the third network node and/or the other nodes. For example, the second network node 150, the processing circuitry 1301 , and/or the receiving unit 1304 may be configured to receive the message, the remain response e.g. a “Remaining Context Fetch Response” from the first network node comprising the remaining information associated to the contexts of the third network node and/or served I AB nodes and/or UEs. Along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node may be received and indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instance. The second network node 150, the processing circuitry 1301, and/or the receiving unit 1304 may be configured to receive the migration request message, from the third network node or the first network node, requesting migration of the third network node to the second network node. The second network node 150, the processing circuitry 1301 , and/or the transmitting unit 1302 may be configured to transmit the migration response, to the first network node, indicating that the third network node and/or the one or more other nodes have migrated to the second network node.

The second network node 150 further comprises a memory 1305. The memory 1305 comprises one or more units to be used to store data on, such as indications, contexts, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the second network node 150 may comprise a communication interface 1308 such as comprising a transmitter, a receiver and/or a transceiver.

The methods according to the embodiments described herein for the second network node 150 are respectively implemented by means of e.g. a computer program product 1306 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 network node 150. The computer program product 1306 may be stored on a computer-readable storage medium 1307, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1307, having stored thereon 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 network node 150. 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 for handling communication in a wireless communications network, wherein the second network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said second network node is operative to perform any of the methods herein.

Fig. 13b is a block diagram depicting the third network node 140 such as the second intermediate radio network node 14, for handling communication in the wireless communications network 1 according to embodiments herein.

The third network node 140 may comprise processing circuitry 1311 , e.g. one or more processors, configured to perform the methods herein.

The third network node 140 may comprise a transmitting unit 1314, e.g. a transmitter or a transceiver. The third network node 140, the processing circuitry 1311 , and/or the transmitting unit 1314 is configured to transmit the migration request message, to the second network node or the first network node, requesting migration to the second network node. For example, transmit the migration request message to the second network node requesting the migration to the second network node.

The third network node 140 may comprise a receiving unit 1312, e.g. a receiver or a transceiver. The third network node 140, the processing circuitry 1311 , and/or the receiving unit 1312 is configured receive the message from the first network node indicating that the second network node has stored context associated with the third network node and/or one or more other nodes that are served, directly or indirectly, by the third network node 140. For example, the third network node 140, the processing circuitry 1311 , and/or the receiving unit 1312 may be configured to receive the message from the first network node 120 indicating that the second network node 150 has stored the context(s) associated to the third network node 140 and/or some or all the I AB nodes/UEs served by the third network node.

The third network node 140 may comprise an executing unit 1313. The third network node 140, the processing circuitry 1311 , and/or the executing unit 1313 may be configured to execute the migration upon fulfilling certain conditions, e.g. RLF at the backhaul link with the parent node, reception of BH RLF recovery failure indication from the parent node, execution of CHO, congestion higher than certain threshold at the backhaul link with the parent, reception of HO command etc.The third network node 140 further comprises a memory 1315. The memory 1315 comprises one or more units to be used to store data on, such as indications, contexts, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the third network node 140 may comprise a communication interface such as comprising a transmitter, a receiver and/or a transceiver. The methods according to the embodiments described herein for the third network node 140 are respectively implemented by means of e.g. a computer program product 1316 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 third network node 140. The computer program product 1316 may be stored on a computer-readable storage medium 1317, e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1317, having stored thereon 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 third network node 140. 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 third network node for handling communication in a wireless communications network, wherein the third network node comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said third network node is operative 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 loT capable device, 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. Other hardware, conventional and/or custom, may also be included. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

Fig. 14 shows a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments. With reference to Fig. 14, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises access network 3211, such as a radio access network, and core network 3214. Access network 3211 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 12 above, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to core network 3214 over a wired or wireless connection 3215. A first UE 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291 , 3292 are illustrated in this example being examples of the wireless device 10 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 3212.

Telecommunication network 3210 is itself connected to host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud- implemented server, a distributed server or as processing resources in a server farm. Host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 3221 and 3222 between telecommunication network 3210 and host computer 3230 may extend directly from core network 3214 to host computer 3230 or may go via an optional intermediate network 3220. Intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; intermediate network 3220, if any, may be a backbone network or the Internet; in particular, intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Fig. 14 as a whole enables connectivity between the connected UEs 3291, 3292 and host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. Host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signalling via OTT connection 3250, using access network 3211, core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. OTT connection 3250 may be transparent in the sense that the participating communication devices through which OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Fig. 15 shows a host computer communicating via a base station and with a user equipment over a partially wireless connection in accordance with some embodiments Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig 15. In communication system 3300, host computer 3310 comprises hardware 3315 including communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system 3300. Host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Host computer 3310 further comprises software 3311, which is stored in or accessible by host computer 3310 and executable by processing circuitry 3318. Software 3311 includes host application 3312. Host application 3312 may be operable to provide a service to a remote user, such as UE 3330 connecting via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the remote user, host application 3312 may provide user data which is transmitted using OTT connection 3350.

Communication system 3300 further includes base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with host computer 3310 and with UE 3330. Hardware 3325 may include communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system 3300, as well as radio interface 3327 for setting up and maintaining at least wireless connection 3370 with UE 3330 located in a coverage area (not shown in Fig. 15) served by base station 3320. Communication interface 3326 may be configured to facilitate connection 3360 to host computer 3310. Connection 3360 may be direct or it may pass through a core network (not shown in Fig 15) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, hardware 3325 of base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. Base station 3320 further has software 3321 stored internally or accessible via an external connection.

Communication system 3300 further includes UE 3330 already referred to. It’s hardware 3333 may include radio interface 3337 configured to set up and maintain wireless connection 3370 with a base station serving a coverage area in which UE 3330 is currently located. Hardware 3333 of UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE 3330 further comprises software 3331, which is stored in or accessible by UE 3330 and executable by processing circuitry 3338. Software 3331 includes client application 3332. Client application 3332 may be operable to provide a service to a human or non-human user via UE 3330, with the support of host computer 3310. In host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the user, client application 3332 may receive request data from host application 3312 and provide user data in response to the request data. OTT connection 3350 may transfer both the request data and the user data. Client application 3332 may interact with the user to generate the user data that it provides.

It is noted that host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 15 may be similar or identical to host computer 3230, one of base stations 3212a, 3212b, 3212c and one of UEs 3291, 3292 of Fig. 14, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 15 and independently, the surrounding network topology may be that of Fig. 14.

In Fig. 15, OTT connection 3350 has been drawn abstractly to illustrate the communication between host computer 3310 and UE 3330 via base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from UE 3330 or from the service provider operating host computer 3310, or both. While OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

Wireless connection 3370 between UE 3330 and base station 3320 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 3330 using OTT connection 3350, in which wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments make it possible to migrate e.g. IAB nodes. Thereby the data communication, e.g. the handling or managing setup of communication may be performed in an efficient manner.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring OTT connection 3350 between host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring OTT connection 3350 may be implemented in software 3311 and hardware 3315 of host computer 3310 or in software 3331 and hardware 3333 of UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect base station 3320, and it may be unknown or imperceptible to base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signalling facilitating host computer 3310’s measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that software 3311 and 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection 3350 while it monitors propagation times, errors, etc.

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

Fig. 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 16 will be included in this section. In step 3410, the host computer provides user data. In substep 3411 (which may be optional) of step 3410, the host computer provides the user data by executing a host application. In step 3420, the host computer initiates a transmission carrying the user data to the UE. In step 3430 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3440 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

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

Fig. 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 17 will be included in this section. In step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 3530 (which may be optional), the UE receives the user data carried in the transmission.

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

Fig. 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 18 will be included in this section. In step 3610 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 3620, the UE provides user data. In substep 3621 (which may be optional) of step 3620, the UE provides the user data by executing a client application. In substep 3611 (which may be optional) of step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in substep 3630 (which may be optional), transmission of the user data to the host computer. In step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

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

Fig. 19 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 14 and Fig. 15. For simplicity of the present disclosure, only drawing references to Fig. 19 will be included in this section. In step 3710 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 3720 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 3730 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

Modifications and other embodiments of the disclosed embodiments will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiment(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Abbreviation Explanation

ACK (positive) Acknowledgment

AUL Autonomous uplink

BLER Block error rate

BWP Bandwidth Part

CAPC Channel access priority class CBG Code block group

CCA Clear channel assessment

CO Channel occupancy

COT Channel occupancy time CWS Contention window size

DL Downlink

ED Energy detection eNB 4G base station gNB 5G base station

HARQ Hybrid automatic repeat request

IS In synch

LAA Licensed assisted access

LBT Listen before talk

MAC Medium access control

MCOT Maximum channel occupancy time

NACK Negative acknowledgment

NDI New data indicator

NR 3GPP defined 5G radio access technology

NR-U NR unlicensed

OOS out of synch

PCell Primary cell

PCI Physical cell identity

PDCCH A downlink control channel

PDU Protocol data unit

PHICH Physical channel Hybrid ARQ Indicator Channel

PLMN Public land mobile network

PSCell Primary SCG cell

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

QCI QoS class identifier

QoS Quality of service

RAT Radio access technology

RLF Radio link failure

RLM Radio link monitoring

RLC Radio link control

RRC Radio resource control

RS Reference signal

SCG Secondary cell group

SDU Service data unit SMTC SSB — based measurement timing configuration

SpCell Special cell (PCell or PSCell)

SPS Semi persistent scheduling

TTI Transmission time interval UCI Uplink Control Information

UE User equipment

UL Uplink

Claims

1. A method performed by a first network node (120) for handling communication in a wireless communications network (1), wherein the method comprises: transmitting (1002) to a second network node (150) a context store request message comprising context of a third network node (140) and/or of one or more other nodes (10,13) that are served, directly or indirectly, by the third network node (140); receiving (1004) a request, from the second network node (150), indicating to fetch remaining data associated with the context of the third network node (140) and/or of one or more other nodes that are served, directly or indirectly, by the third network node (140), not already sent by the first network node (120) to the second network node (150); and transmitting (1006) a response to the second network node (150) comprising the remaining data associated with the context of the third network node (140) and/or the other nodes.

2. The method according to claim 1 , wherein the context store request message requests the second network node (150) to store the context of the third network node (140) and/or of the one or more other nodes.

3. The method according to any of the claims 1-2, further comprising receiving (1003) a context store response from the second network node (150) indicating acceptance or rejection to store the context of the third network node (140) and/or of the one or more other nodes.

4. The method according to any of the claims 1-3, further comprising, upon receiving (1004) the request, comparing (1005) current contexts associated to the third network node and served one or more other nodes with information received in the context store response and the transmitted response comprises information based on the comparison.

5. The method according to any of the claims 1-4, further comprising receiving (1007) a migration response, indicating that the third network node and/or the one or more of the other nodes have been migrated to the second network node and/or have been rejected.

6. The method according to any of the claims 1-5, wherein the context store request message comprises a plurality of information comprising one or more of: a radio resource control, RRC, context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of Backhaul Adaptation Protocol, BAP, addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes.

7. The method according to any of the claims 1-6, wherein, along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node is transmitted and is indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instances.

8. The method according to any of the claims 1-7, wherein the context store request message also indicates one or more of the following: for how long context of a third network node (140) and/or of one or more other nodes (10,13) should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration.

9. A method performed by a second network node (150) for handling communication in a wireless communications network, the method comprising: receiving (1011) from a first network node (120), a context store request message comprising context of a third network node (140) and/or of one or more other nodes (10,13) that are served, directly or indirectly, by the third network node (140); transmitting (1015) a request, to the first network node, indicating to fetch remaining data associated with the context of the third network node (140) and/or of one or more other nodes that are served, directly or indirectly, by the third network node (140), not already sent by the first network node (120) to the second network node (150); and receiving (1016) a response from the first network node (120), wherein the response comprises the remaining data associated with the context of the third network node (140) and/or the other nodes. The method according to claim 9, wherein the context store request message requests the second network node to store the context of the third network node and/or of the one or more other nodes. The method according to any of the claims 9-10, further comprising determining (1012) acceptance or rejection to store the context of the third network node and/or of the one or more other nodes transmitting (1013) a context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes. The method according to any of the claims 9-11, further comprising determining (1017) based on the received response if there are radio resources available and capacity at the second network node to handle the third network node and/or the served one or more other nodes and related traffic. The method according to claim 12, further comprising transmitting (1018) a reconfiguration message, indicating acceptance or rejection of the third network node and/or the one or more other nodes. The method according to any of the claims 9-13, further comprising receiving (1014) a migration request message, from the third network node or the first network node, requesting migration of the third network node to the second network node; and transmitting (1018) a migration response, to the first network node, indicating that the third network node and/or the one or more other nodes have migrated to the second network node.

15. The method according to any of the claims 9-14, wherein the context store request message comprises a plurality of information comprising one or more of: a radio resource control, RRC, context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of Backhaul Adaptation Protocol, BAP, addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes.

16. The method according to any of the claims 9-15, wherein, along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node is received and indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instance.

17. The method according to any of the claims 9-16, wherein the context store request message also indicates one or more of the following: for how long context of a third network node (14) and/or of one or more other nodes (10,13) should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration.

18. A method performed by a third network node (140) for handling communication in a wireless communications network, the method comprising: receiving (1101) a message from a first network node (120) indicating that a second network node (150) has stored context associated with the third network node (140) and/or one or more other nodes that are served, directly or indirectly, by the third network node (140); and transmitting (1103) a migration request message, to the second network node (150) or the first network node (120), requesting migration to the second network node (150).

19. A first network node (120) for handling communication in a wireless communications network (1), wherein the first network node is configured to: transmit to a second network node (150) a context store request message comprising context of a third network node (140) and/or of one or more other nodes (10,13) that are served, directly or indirectly, by the third network node (140); receive a request, from the second network node, indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node; and transmit a response to the second network node comprising the remaining data associated with the context of the third network node and/or the other nodes.

20. The first network node (120) according to claim 19, wherein the context store request message requests the second network node to store the context of the third network node and/or of the one or more other nodes.

21. The first network node (120) according to any of the claims 19-20, wherein the first network node is further configured to receive a context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes.

22. The first network node (120) according to any of the claims 19-21 , wherein the first network node is further configured to, upon receiving the request, compare current contexts associated to the third network node and/or the served one or more other nodes with information received in the context store response, and wherein the transmitted response comprises information based on the comparison.

23. The first network node according to any of the claims 19-22, wherein the first network node is further configured to receive a migration response, indicating that the third network node and/or one or more of the other nodes have been migrated to the second network node and/or have been rejected.

24. The first network node according to any of the claims 19-23, wherein the context store request message comprises a plurality of information comprising one or more of: a radio resource control, RRC, context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of Backhaul Adaptation Protocol, BAP, addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes.

25. The first network node according to any of the claims 19-24, wherein along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node is transmitted and is indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instances.

26. The first network node according to any of the claims 19-25, wherein the context store request message also indicates one or more of the following: for how long context of a third network node and/or of one or more other nodes (10,13) should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration.

27. A second network node (150) for handling communication in a wireless communications network; wherein the second network node is configured to: receive from a first network node (120), a context store request message comprising context of a third network node (140) and/or of one or more other nodes (10,13) that are served, directly or indirectly, by the third network node (140); transmit a request to the first network node (120), indicating to fetch remaining data associated with the context of the third network node and/or of one or more other nodes that are served, directly or indirectly, by the third network node, not already sent by the first network node to the second network node; and receive a response from the first network node, wherein the response comprises the remaining data associated with the context of the third network node and/or the other nodes.

28. The second network node according to claim 27, wherein the context store request message requests the second network node to store the context of the third network node and/or of the one or more other nodes.

29. The second network node according to any of the claims 27-28, wherein the second network node is further configured to determine acceptance or rejection to store the context of the third network node and/or of the one or more other nodes; and transmit a context store response from the second network node indicating acceptance or rejection to store the context of the third network node and/or of the one or more other nodes.

30. The second network node according to any of the claims 27-29, wherein the second network node is further configured to determine based on the received response if there are radio resources available and capacity at the second network node to handle the third network node and the served one or more other nodes and related traffic.

31. The second network node according to claim 30, wherein the second network node is further configured to transmit a reconfiguration message, indicating acceptance or rejection of the third network node and/or the one or more other nodes.

32. The second network node according to any of the claims 27-31 , wherein the second network node is further configured to receive a migration request message, from the third network node or the first network node, requesting migration of the third network node to the second network node; and transmit a migration response, to the first network node, indicating that the third network node and/or the one or more other nodes have migrated to the second network node.

33. The second network node according to any of the claims 27-32, wherein the context store request message comprises a plurality of information comprising one or more of: a radio resource control, RRC, context; measurements related to neighbour cells belonging to the second network node; context of a distributed unit connected to the first network node; information about IP addresses allocated to the third network node; backhaul radio link control channel list; amount of other nodes directly or indirectly served; topology information of the one or more other nodes; routing information associated to each backhaul radio link control channel; and number of Backhaul Adaptation Protocol, BAP, addresses and BAP routing IDs assigned to the third network node and/or the one or more other nodes.

34. The second network node according to any of the claims 27-33, wherein along with the context of the third network node, context of each of the one or more other nodes that is served directly or indirectly by the third network node is received and indicated as part of an information element indicating the context of the third network node or in separate information elements or message transmission instance.

35. The second network node according to any of the claims 27-34, wherein the context store request message also indicates one or more of the following: for how long context of a third network node (140) and/or of one or more other nodes (10,13) should be kept by the second network node; a prediction on when a migration of the third network node occurs; a probability of migration within a certain time window; and a purpose of the migration. A third network node for handling communication in a wireless communications network, wherein the third network node is configured to: receive a message from a first network node indicating that a second network node has stored context associated with the third network node and/or one or more other nodes that are served, directly or indirectly, by the third network node (14); and transmit a migration request message, to the second network node or the first network node, requesting migration to the second network node.