TW202207734A - Methods, radio network nodes for handling communication - Google Patents

Abstract

Embodiments herein relate to, for example, a method performed by a first radio network node (12) for handling communication in a wireless communications network. The first radio network node (12) transmits a message related to handover or cell reselection of a migrating node to a second radio network node (15), wherein the message comprises data associated with the migrating node and data related to one or more other nodes directly and indirectly served by the migrating node.

Description

Method and radio network node for handling communications

Embodiments herein relate to a first radio network node, a second radio network node, and methods of wireless communication performed therein. Furthermore, a computer program product and a computer-readable storage medium are also provided herein. In particular, embodiments herein relate to handling communications in a wireless communication network, such as controlling/managing handover or cell reselection to network nodes such as relay nodes.

In a typical wireless communication network, user equipment (UE) (also known as wireless communication device, mobile station, station (STA), and/or wireless device) via a radio access network A road (RAN) communicates with one or more core networks (CN). The RAN covers a geographic area divided into service areas or cell areas, where each service area or cell area is controlled by a network such as an access node (eg, a Wi-Fi access point or a radio base station (RBS), which in some networks A path may also be referred to as a radio network node server such as a NodeB, a gNodeB or an eNodeB). A service area or cell area is a geographic area in which radio coverage is provided by a radio network node. The radio network node operates on radio frequencies to communicate with UEs within range of the radio network node through an air interface. The radio network node communicates with the UE through a downlink (DL), and the UE communicates with the radio network node through an uplink (UL).

A Universal Mobile Telecommunications System (UMTS) is a third generation telecommunications network evolved from the Second Generation (2G) Global System for Mobile Communications (GSM). The UMTS Terrestrial Radio Access Network (UTRAN) is essentially a RAN that uses Wideband Code Division Multiple Access (WCDMA) and/or High Speed Packet Access (HSPA) to communicate with user equipment. In a forum known as the 3rd Generation Partnership Project (3GPP), telecommunications providers specifically propose and agree standards for current and future generation networks and UTRAN, and study enhanced data rates and radio capacity. In some RANs, such as in UMTS, several radio network nodes may be connected to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), eg by wireline communication or microwave ), which supervises and coordinates the various activities of a plurality of radio network nodes connected to it. RNCs are usually connected to one or more core networks.

Specification of the Evolved Packet System (EPS) has been completed within 3GPP and this work continues in upcoming 3GPP releases, such as for 5G networks (such as New Radio (NR) and upcoming generations). EPS includes Evolved Global Terrestrial Radio Access Network (E-UTRAN) (also known as Long Term Evolution (LTE) Radio Access Network) and Evolved Packet Core (EPC) (also known as System Architecture Evolution (SAE) Core) network). E-UTRAN/LTE is a 3GPP radio access technology in which radio network nodes are directly connected to the EPC core network. Thus, the radio access network (RAN) of an EPS has an essentially "flat" architecture comprising radio network nodes directly connected to one or more core networks.

With emerging 5G technologies such as New Radio (NR), the use of very many transmit and receive antenna elements is of great interest because 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 signal in one or more selected directions while suppressing the transmitted signal in other directions. Similarly, on the receive side, a transmitter can amplify signals from one or more selected directions while suppressing unwanted signals from other directions.

Next-generation systems are expected to support a wide range of use cases with different requirements ranging from fully mobile devices to fixed Internet of Things (IoT) or fixed wireless broadband devices. The traffic pattern associated with many use cases can be expected to consist of short or long bursts of data traffic with varying lengths of wait periods (herein referred to as inactive states) in between. In NR, both authorized assisted access and independent unauthorized operations are supported. Therefore, procedures for Physical Random Access Channel (PRACH) transmission and/or Schedule Request (SR) transmission in unlicensed spectrum can be studied in 3GPP.

3GPP is investigating potential solutions for efficient operation of Integrated Access and Radio Access Backhaul (IAB) (or simply Integrated Access Backhaul) in NR. In the context of the IAB, there are two types of nodes that are identified as components of a RAN:

IAB Node: A RAN node that supports wireless access to UEs and wirelessly backloads access traffic.

IAB Donor: An IAB node, ie, a RAN node, which provides the UE's interface to the core network and wireless backhaul functionality to the IAB node.

3GPP is currently standardizing integrated access and radio access backload in NR (IAB) in Rel-16 (RP-193251).

The use of short-range millimeter-wave (mmWave) spectrum in NR requires a densified deployment of multi-hop backhaul. However, fiber optics to the base stations would be prohibitively expensive and sometimes even impossible, eg due to historical sites. The main IAB principle is to use wireless links for backhaul rather than fiber optics to enable flexible and very dense cell deployments without the need for densification of the transport network. Use case cases for IAB can include coverage extension, deployment of large numbers of small cells, and Fixed Wireless Access (FWA), such as to residential/office buildings. The larger bandwidth available for NR in the mmWave spectrum provides the opportunity for self-backloading without limiting the spectrum available for access links. In addition, the inherent multi-beam and multiple-input multiple-output (MIMO) support in NR reduces cross-link interference between backhaul and access links, allowing for higher densification.

During the research project phase of the work of the IAB, a summary of the research project can be found in technical report TR 38.874, which has agreed to use one of the solutions of the central unit (CU)/distributed unit (DU) separation architecture using NR, where the IAB The node will host a DU section controlled by a central unit. IAB nodes also have a mobile terminal (MT) portion, denoted IAB-MT, that their peers use to communicate with their peers' parent nodes.

The IAB specification strives to reuse existing functionality and interfaces defined in NR. Specifically, MT, gNB-DU, gNB-CU, User Plane Function (UPF), Access and Mobility Management Function (AMF) and Work Session Management Function (SMF) and MT and gNB, F1, NG, X2 The corresponding interface NR Uu between and N4 is used as the baseline for the IAB architecture. Modifications or enhancements to these functions and interfaces to support IAB will be described in the context of the architectural discussion. Additional functionality, such as multi-hop forwarding, is included in the architectural discussion because it is necessary to understand IAB operation, and because certain aspects may require standardization.

The MT function has been defined as one of the components of the IAB node. In the context of this study, MT is referred to as a function residing on an IAB node that terminates the radio interface layer carrying the Uu interface back towards the IAB donor or other IAB nodes.

Figure 1 shows a high-level architecture showing a high-level architectural view of an IAB network. Figure 1 shows a reference graph of one of the IABs in standalone mode, which contains one IAB donor and multiple IAB nodes. An IAB donor can be viewed as a single logical node comprising one of a set of functions, such as gNB-DU, gNB-CU-Control Plane (CP), gNB-CU-User Plane (UP) and possibly other functions. In one deployment, IAB donors may be partitioned according to these functions, which may all be co-located or non-co-located, as allowed by the 3GPP NG-RAN architecture. When this segmentation is performed, an IAB-related aspect can be generated. Also, some functions currently associated with IAB donors may eventually be moved out of IAB donors in case they, etc., apparently do not perform IAB-specific tasks. Thus, Figure 1 shows a reference diagram for one of the IAB architecture (TR 38.874 v0.7.0).

The baseline user plane and control plane protocol stacks of the IAB are shown in Figures 2-3.

Figure 2 shows a baseline user plane protocol stack for one of the IABs in rel-16.

Figure 3 shows a baseline control plane protocol stack for one of the IABs in rel-16.

As shown, the selected protocol stack reuses the current CU-DU split specification in rel-15, where the full user plane F1-U (GTP-U/UDP/IP) terminates at the IAB node as a normal DU, and full control The plane F1-C (F1-AP/SCTP/IP) also terminates at the IAB node, like the same normal DU. In the above cases, Network Domain Security (NDS) has been employed to protect both UP and CP traffic, IPsec is employed in the UP case, and Data Packet Transport Layer Security (DTLS) is employed in the CP case. IPsec can also be used for CP protection instead of DTLS, in which case the DTLS layer will not be used.

A new protocol layer called the Load Back Adaptation Protocol (BAP) has been introduced in IAB Nodes and IAB Donors, which is used to route packets to the appropriate downstream/upstream nodes and also map UE payload data to the appropriate backhaul The radio link control (RLC) channel is carried between the ingress and egress backhaul RLC channels in the intermediate IAB nodes to meet the end-to-end quality of service (QoS) requirements of the bearer.

BAP entity

On the IAB node, the BAP sublayer contains a BAP entity at the MT function and a separate co-located BAP entity at the DU function. On the IAB donor DU, the BAP sublayer contains only one BAP entity. Each BAP entity has a transmit part and a receive part. The transmit part of the BAP entity has a corresponding receive part of a BAP entity at the IAB node or IAB donor DU across the backhaul link.

Figure 4 shows one example of a functional view of the BAP sublayer. This functional view should not limit the implementation. Figure 4 is based on the radio interface protocol architecture defined in TS 38.300 v16.1.0. In the example of Figure 4, the receive portion on the BAP entity delivers BAP Protocol Data Units (PDUs) to the transmit portion on the co-located BAP entity. Alternatively, the receiving part may deliver the BAP Service Data Unit (SDU) to the co-located transmitting part. When delivering a BAP SDU, the receiving part removes the BAP header, and the transmitting part adds a BAP header with the same BAP Route ID that was carried on the BAP PDU header prior to removal. Thus, in an embodiment, passing BAP SDUs in this manner is functionally equivalent to passing BAP PDUs.

Provide top-level services.

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

Expected service from below.

A BAP sublayer expects the following services from the layers below each RLC entity, a detailed description is given in TS 38.322 v.16.1.0: - Approved data transfer service; - Unauthorized data transfer service.

Function.

The BAP sublayer supports the following functions: - data transfer; - Determine the BAP destination and path of the packet from the upper layer; - Determining the egress loopback (BH) RLC channel for packets routed to the next hop; - route the packet to the next hop; - Distinguish between traffic to be delivered to the upper layer and traffic to be delivered to the egress link; - Process control feedback and polling signaling;

Topology adaptation case of baseline architecture.

Figure 5 shows an example of some possible IAB node migration scenarios listed in order of complexity and more detail, as follows:

Intra-CU case (A): In this case, the IAB node (e) moves together with its serving UE to a new parent node (IAB node (b)) under the same donor DU (1). Successful intra-donor DU migration requires establishing the UE context setup for the IAB node(e) MT in the DU of the new parent node (IAB node(b)), updating the IAB node's routing table along the path to the IAB node(e), and Allocate resources on the new path. The IP address of the IAB node (e) will not change and the F1-U tunnel/connection between the donor CU (1) and the IAB node (e) DU will be redirected through the IAB node (b).

Intra-CU case (B): The procedural requirements/complexities of this case are the same as case (A). Also, since the new IAB donor DU (ie, DU2) is connected to the same L2 network, the IAB node (e) can use the same IP address under the new donor DU. However, the new donor DU (ie, DU2) will need to inform the network using the L2 address of the IAB node (e) in order to obtain/keep the IAB node (e) by employing some mechanism such as the Address Resolution Protocol (ARP) ) of the same IP address.

Intra-CU case (C): This case is more complicated than case (A) because it also requires allocation of a new IP address for the IAB node (e). If IPsec is used to protect the F1-U tunnel/connection between the donor CU (1) and the IAB node (e) DU, then the path between the donor CU (1) and the secure gateway (SeGW) can be followed The segment uses the existing IP address and uses the new IP address for the IPsec tunnel between the SeGW and the IAB Node(e)DU.

Inter-CU case (D): This is the most complex case in terms of program requirements and may require new specification programs beyond the scope of 3GPP Rel-16.

It should be noted that 3GPP Rel-16 has standardized procedures for intra-CU migration only, which are described below.

Thus, Figure 5 shows examples of different possible cases of IAB node migration.

Intra-CU topology adaptation procedure.

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

Action 1: The migrating IAB-MT sends a measurement report message to the source parent node GNB-DU. This report is based on a measurement configuration previously received by the migrating IAB-MT from the IAB donor CU.

Action 2: The source parent node gNB-DU sends a UL RRC message transfer message to the IAB donor CU to convey the received measurement report.

Action 3: The IAB donor CU sends a UE context setup request message to the target parent node gNB-DU to generate the UE context for migrating IAB-MT and set up one or more bearers. These transports are used by the migrating IAB-MT for its own data and signaling traffic.

Action 4: The target parent node gNB-DU responds to the IAB donor CU with a UE context setup response message.

Action 5: The IAB donor CU sends a UE context modification request message to the source parent node gNB-DU, the message including a generated RRCReconfiguration message. The transmission action indicator in the UE context modification request message indicates to stop data transmission to the relocated IAB 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 IAB donor CU using the UE context modification response message.

Action 8: Execute a random access procedure 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 a UL RRC message transfer message to the IAB donor CU to convey the received RRCReconfigurationComplete message. Also, uplink packets may be sent from the migrating IAB-MT, which are forwarded to the IAB donor CU through the target parent node gNB-DU. These DL and UL packets belong to the MT's own signaling and data traffic.

Action 11: The IAB donor CU configures the BH RLC channel and BAP layer routing entries on the target path between the migrating IAB node and the target IAB donor DU. This step also includes allocating transport network layer (TNL) address(s) that can be routed through the target IAB donor DU. Such configuration can be performed at an early stage, eg just after action 3. The new TNL address(s) are included in the RRCReconfiguration message of Action 5.

Action 12: Switch all F1-U tunnels and F1-C to use the new TNL address(s) of the migrated IAB node.

Action 13: The IAB 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 context of the migrated IAB-MT, and responds to the IAB donor CU with a UE context release complete message.

Action 15: The IAB donor CU releases the BH RLC channel and BAP routing entry on the source path. The migrating IAB node can further free up the TNL address(s) it used on the source path.

Note: In the case where the source route and the destination route have common nodes, the BH RLC channel and BAP route entries for those nodes may not need to be released in act 15.

Note: Actions 11, 12 and 15 must also be performed on the child nodes of the migrated IAB node, as follows: - The child node must also switch to the new TNL address anchored in the target IAB donor DU. The IAB donor CU may send these addresses to the child node and signal the release of the old addresses via the corresponding Radio Resource Control (RRC). - If required, the IAB Donor CU configures the BH RLC channel, BAP layer routing entries on the target path of the child node, and BH RLC channel mapping on the child node in the same manner as described for migrating IAB nodes in action 11 . - The child node switches its equivalent F1-U and F1-C tunnels to the new TNL address anchored at the new IAB donor DU in the same manner as described for the migrating IAB node in act 12. - Depending on the implementation, these actions may be performed after the handover of the migrating IAB node or performed in parallel. In Rel-16, in-flight packets in the UL direction that were dropped during the migration procedure may not be recovered.

Note: In the upstream direction, the in-flight packets between the source parent node and the IAB donor CU can still be delivered even after the destination path is established.

Note: Downlink data in progress in the source path may be discarded depending on the implementation.

Note: The IAB Donor CU may determine by implementation that downlink data was not successfully transmitted on the backhaul link.

As mentioned above, 3GPP Rel-16 only standardizes the intra-IAB CU migration procedure. Considering that inter-CU migration will be an important feature of the IAB Rel-17 Work Item (WI), certain enhancements to the existing UE handover and IAB intra-CU migration procedures are required to reduce service interruption and development due to IAB node migration. signal load.

In the legacy UE case, by accepting a handover from an individual UE, the target RAN node is committed to providing resources and up to 16 data radio bearers (DRBs) for serving the signaling connection of the migrating UE. Compared to serving a legacy DU of several UEs, an IAB node can serve not only UEs, but also up to 1024 directly connected child nodes, and up to 65536 BH RLC channels established to each child node, etc. the connected UE. Furthermore, these child IAB nodes may have their own child IAB nodes that also serve the UE. However, the current specification only implements handover for individual UEs.

One of the objectives herein is to provide a mechanism for enabling communication (eg, processing or management signaling) in a wireless communication network in an efficient manner.

According to one aspect, according to embodiments herein, this objective is achieved by providing a method performed by a first radio network node for processing or managing signaling or communication in a wireless communication network. The first radio network node transmits a message related to handover or cell reselection of a relocation node to a second radio network node, wherein the message includes data associated with the relocation node and information related to the relocation node The node directly and indirectly serves data related to one or more other nodes. Accordingly, the first radio network node (such as an IAB node) transmits to the second radio network node a message for setting up the communication of the relocation node (eg, an IAB node), wherein the message includes communication with the Data associated with the migrating node and data related to other nodes (such as IAB nodes and/or UEs) served directly and indirectly by the migrating node. The data may indicate the resources required to serve the migrating node and/or the other nodes.

According to another aspect, according to embodiments herein, by providing a method executed by a second radio network node, such as an IAB node, for processing or managing communications in a wireless communication network and/or The method of control signaling achieves this goal. The second radio network node receives from a first radio network node a message related to handover or cell reselection of a relocation node, wherein the message includes data associated with the relocation node and information related to the relocation node Data related to one or more other nodes that are directly and indirectly served. Accordingly, the second radio network node receives the message (such as a handover request) from the first radio network node related to handover or cell reselection of a node. The message includes data (indications) associated with the migrating node (eg, IAB node) and data related to the other nodes (such as IAB nodes and/or UEs) served directly and/or indirectly by the migrating node. The data may indicate one or more resources required to serve the migrating node and/or the other nodes. The second radio network node may then determine or decide whether to allow the handover of the migrating node and the one or more other nodes, taking into account the received data, for example for data contained in the received data The UE and IAB nodes perform admission control.

According to yet another aspect of the embodiments herein, this objective is achieved by providing a first radio network node for handling or managing signaling or communication in a wireless communication network. The first radio network node is configured to transmit to a second radio network node a message related to handover or cell reselection of a relocation node, wherein the message includes data associated with the relocation node and Data related to one or more other nodes served directly or indirectly by the migrating node.

According to yet another aspect, according to embodiments herein, by providing a second radio network node (such as an IAB node) for handling or managing communications and/or control signaling in a wireless communication network achieve this goal. The second radio network node is configured to receive, from a first radio network node, a message related to handover or cell reselection of a relocation node, wherein the message includes data associated with the relocation node and data related to the relocation node. Data related to one or more other nodes is served directly and indirectly by the migrating node. The message includes data or an indication associated with the migrating node (eg, IAB node) and data related to other nodes (such as IAB nodes and/or UEs) served directly and/or indirectly by the migrating node. The data may indicate one or more resources required to serve the node and/or other nodes. The second radio network node may be further configured to determine or decide whether to allow the handover of the node in consideration of the received data, eg for the UE and IAB nodes included in the received data Enforce permission control.

Furthermore, provided herein is a computer program product comprising, when executed on at least one processor, causes the at least one processor to perform the above as performed by the first radio network node or the second radio network node, respectively method instructions. Additionally, provided herein is a computer-readable storage medium having stored thereon a computer program product comprising instructions that, when executed on at least one processor, cause the at least one processor to perform operations according to, for example, by the first radio, respectively A method of the above method performed by the network node or the second radio network node.

Embodiments herein are capable of exchanging data, such as handover-related information of a migrating IAB node and its direct and indirect serving IAB nodes and UEs, and can also communicate information about parent-child relationships therein to a second radio network node . For example, in the case where migration/handover of a fixed IAB node is done due to load balancing, UEs or child IAB nodes connected to the migrating IAB node before migration will still be optimally served by the same IAB node after migration . Even in the case of a mobile IAB (eg, an IAB node attached to a bus/train), there may still be several UEs attached to the IAB node, and they will continue to be served by the same IAB node/ Cell Servo. Therefore, it makes sense to optimize this transition and avoid unnecessary service interruptions. In other words, it seems optimal to keep the same topology (topology of UE and child IAB nodes) under the migrating IAB node after handover/migration of IAB nodes. By informing the second radio network node (such as a target gNB/gNB-CU) of the resources required to serve the relocated IAB node and all UE/IAB nodes served directly or indirectly by the IAB node, the parent node and the target gNB- In cases where there are multiple hops between CUs, taking into account the resources available at the parent target node for migrating the IAB node and any intermediate nodes between the target donor CU and the parent target node, the second radio network node Implement appropriate permission controls. Also, the contexts of the migrating IAB node and all IAB nodes/UEs served directly or indirectly by the IAB node can be relocated together to the second radio network node.

Accordingly, embodiments herein enable communication (eg, processing or management signaling) in an efficient manner in a wireless communication network.

Embodiments herein generally relate to wireless communication networks. FIG. 7 depicts a schematic overview of a wireless communication network 1 . The wireless communication network 1 includes one or more RANs and one or more CNs. The wireless communication network 1 may use one or more different technologies. The embodiments herein relate to recent technology trends that are of particular interest in the context of New Radio (NR), however the embodiments are also applicable to existing wireless communication systems such as, for example, LTE or Wideband Code Division Multiple Access (WCDMA) further development.

In the wireless communication 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) includes, for example, a One or more access networks (ANs) (eg, RANs) communicate with one or more core networks (CNs). Those skilled in the art will understand that "UE" is a non-limiting term that means any terminal, wireless communication terminal, user equipment, NB-IoT device, machine type communication (MTC) device, device-to-device (D2D) ) terminals or nodes, such as smart phones, laptops, mobile phones, sensors, repeaters, mobile tablets or even capable of using radio communication with a radio network in an area served by a radio network node A small base station for road node communication.

The wireless communication network 1 includes a first radio network node 12, such as an IAB donor node (such as an access node), an access controller, a base station (eg, a radio base station, such as a gNodeB ( gNB), an evolved Node B (eNB, eNodeB), a NodeB), a transceiver base station, a radio remote unit, an access point base station, a base station router, a wireless local area network (WLAN) storage Access Point or an Access Point Station (AP STA), a Mobility Management Entity (MME), an AMF, a Standalone Access Point, or can be associated with a first radio access technology and terminology used depending on, for example, a first radio access technology. A radio network node serves any other network element or node that communicates with a wireless device within a serving cell. The first radio network node 12 may also be referred to as a serving or source node or a RAN node. It should be noted that a service area may be represented as a cell, beam, beam group or the like to define a radio coverage area.

The wireless communication network 1 further comprises a first intermediate radio network node 13 connected between the first radio network node 12 and the UE 10 . The first intermediate radio network node 13 may be an IAB node (such as an access node), an antenna unit, a radio unit, a radio base station (such as a gNodeB (gNB), an evolved node B (eNB, eNodeB), a NodeB), a transceiver base 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 A transmission configuration of a radio base station, an independent access point, or any other device capable of communicating with a wireless device within a serving cell served by a radio network node depending on, for example, a first radio access technology and terminology used other network elements or nodes.

The wireless communication network further comprises a second intermediate radio network node 14 connected between the first radio network node 12 and the UE 10 . The second intermediate radio network node 14 may be directly connected to the UE 10 and may be an exit point. The second intermediate radio network node 14 may be an IAB node (such as an access node), antenna units, radio units, a radio base station (such as a gNodeB (gNB), an evolved NodeB (eNB, eNodeB), a NodeB), a transceiver base 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 A transmission configuration of a radio base station, an independent access point, or any other network capable of communicating with a wireless device within a serving cell served by a radio network node depending on, for example, a radio access technology and terminology used way element or node.

Furthermore, the wireless communication network 1 includes a second radio network node 15, such as an IAB donor node (eg, an access node), an access controller, a base station (eg, a radio base station, such as a gNodeB (gNB), an evolved NodeB (eNB, eNodeB), a NodeB), a transceiver base 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), an MME, an AMF, a stand-alone access point or can be serviced by a radio network node depending on eg a radio access technology and terminology used Any other network element or node in communication with a wireless device within a serving cell. The second radio network node 15 may be referred to as a target node or RAN node.

The wireless communication network 1 may further comprise a third intermediate radio network node 16 connected between the second radio network node 15 and the served UE. The third intermediate radio network node 16 may be an IAB node (eg, an access node), antenna units, radio units, a radio base station (such as a gNodeB (gNB), an evolved NodeB (eNB, eNodeB), a NodeB), a transceiver base 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 configuration of a radio base station, an independent access point, or any other capable of communicating with a wireless device within a serving cell served by a radio network node depending on, for example, a radio access technology and terminology used network element or node. It should be noted that a service area may be represented as a cell, beam, beam group or the like to define a radio coverage area.

Embodiments herein disclose signaling through the RAN interface to implicitly and/or explicitly to a target RAN during handover of a migration node (eg, an IAB node such as the first intermediate radio network node 13 ). A node (such as the second radio network node 15, eg gNB, gNB-CU, gNB-CU-CP) informs the data (such as serving the relocation node and all child IAB nodes and UEs served directly or indirectly by the relocation node of interest) amount of resources).

Figure 8 shows an example of an IAB network handover case. The IAB node 3, which is an instance of the migration node, will be handed over to the IAB node 2, which is an instance of the second radio network node 15. IAB Node 3 serves one or more other nodes, such as UEa, UEb, UEc, IAB Node 4 and UEe. Figure 8 shows migration between IAB Node 3 and one of its child IAB Nodes and a CU of the connected UE. • Inter-CU IAB node migration can be caused by eg radio link failure (RLF), load balancing, IAB node mobility. These are non-limiting examples. • The terms "gNB-CU" and "donor CU", "donor", "CU-CP" and "CU" are used interchangeably. • All considerations for a segmented donor (ie, donor CU) apply equally to a non-segmented donor (ie, donor gNB). • The terms "reload RLC channel" and "BH RLC channel" and "BH carry" are used interchangeably. • The term "gNB" applies to all variants thereof, eg "gNB", "en-gNB", etc. • The exemplary topology shown in Figure 8 is used for the embodiments herein, where IAB Donor CU1 has an F1 interface with IAB Node 3 DUs, and IAB Node 3 (ie, IAB-MT-3) has MT functionality Connected/served by IAB Node 1. • The term "a UE/IAB node directly served by the migrating IAB node" refers to a UE/IAB node that is directly connected to the migrating IAB node. • The term "a UE/IAB node is indirectly served by the migrating IAB node" means that the migrating IAB node is a parent node of one of the IAB nodes currently serving the UE or the IAB node. • The term UE/IAB node of interest refers to one of the UE/IAB nodes served directly/indirectly by the migrating IAB node. ● The term source parent node refers to the radio network node serving the migrating IAB node prior to handover, i.e. a source donor DU in the case where the migrating IAB node is only one hop away from the source CU, or a Refers to a parental IAB node in one case where the source CU is a number of hops away. • The term target parent node refers to the radio network node that will serve the migrating IAB node after handover, i.e. a target donor DU in the case that the migrating IAB node will be connected to be only one hop away from the target CU, or The migrating IAB node will refer to a parent IAB node in one of the cases where it will be multiple hops away from the target CU. • All cells of DUs controlled by the same donor CU (ie, donor DUs and IAB-DUs of all IAB nodes located under the same donor CU) are also referred to as being served by the donor CU. • The embodiments herein are presented on a non-limiting example of Xn handover, but it is also applicable to NG, S1 and X2 handover.

Figure 9 depicts a combined signaling scheme and flow diagram of some embodiments herein, wherein the first radio network node 12 is illustrated as an IAB donor CU and the second radio network node 15 is illustrated as a second IAB Donor CU.

Action 901: The first radio network node 12 may decide to hand over a node (ie, a migration node, such as an IAB node) to the second radio network node 15 and/or a plurality of other nodes (such as radio network nodes) and/or UE). This may be determined based on measurements, load conditions of different radio network nodes, mobility or configuration. The reasons may be, for example, RLF, load balancing, and/or IAB node mobility.

Action 902: The first radio network node 12 transmits eg a handover request to the second radio network node 15, wherein the handover request includes data or an indication associated with the migrating node (eg, IAB node) and The migration node directly and indirectly serves data related to one or more other nodes, such as IAB nodes and/or UEs. The data may indicate one or more resources required by the server migration node and/or one or more other nodes.

Action 903: The second radio network node 15 may then decide or decide whether to accept the handover (cell reselection).

Action 904: The second radio network node 15 may then transmit back to the first radio network node 12 an indication reflecting one of the decisions. The second radio network node 15 may eg transmit a value indicating accepted and/or data indicating accepted PDU phase, DRB and/or QoS traffic.

Action 905: The first radio network node 12 may then process the handover of the migrating node based on the received indication. For example, a handover command is transmitted to the second radio network node 15 or a handover rejection is transmitted to the second radio network node 15 .

Method actions performed by the first radio network node 12 for handling communications in the wireless communication network 1 according to embodiments herein will now be described with reference to a flowchart depicted in FIG. 10 . The wireless communication network 1 may include a first radio network node 12 and a second radio network node 15 and one or more nodes that relay data packets between the radio network node and the UE 10 . The one or more nodes may be an intermediate radio network node between the first radio network node 12 and the UE.

Action 1001: The first radio network node 12 may decide to hand over the migration node to the second radio network node. For example, based on measurements, load conditions or configuration. For example, the first radio network node 12 may decide to hand over an IAB node to a target cell belonging to the second radio network node 15 (target donor CU). The decision to hand over the IAB node may be due, for example, to one or more of the following reasons: ○ Based on load conditions at the source, such as: ▪ UP/CP resources at the source donor CU, UP/CP resources at the source donor DU, radio resources at the donor DU, at the parent node of the IAB node (such as the source donor DU or another IAB node) radio resources, radio resources at any intermediate nodes between the IAB node and the source donor DU; and/or ○ Based on measurements received from IAB nodes ▪ For example, a mobile IAB node, a stationary IAB node that experiences a congestion on the link between the parent node and the IAB node that degrades the performance of the IAB node's backhaul link, etc. ○ Based on Operations, Administration and Maintenance (OAM) network reconfiguration decisions.

Action 1002: The first radio network node 12 may prepare a handover request for the second radio network node 15. Thus, the first radio network node 12 may prepare a handover request message (a modified version of the Xn handover request message or a new definition message for the purposes of the embodiments herein) to the second radio network node 15 ), and may include one or more of the following in this submission request message: ○ Migrate the context of the MT of the IAB node ▪ This contains a context similar to a UE context and specific information related to IAB nodes only, such as BAP configuration, such as BAP address and UL traffic mapping configuration. ○ the context of the DU of the migrated IAB node (migration IAB-DU), ▪ This contains information, such as information about F1-C and F1-U connections for migrating IAB-DUs, including F1-AP context configuration information related to F1-C or F1-U that can transmit F1-AP connections, about Cell information served by IAB-DU and IAB specific information, such as UL/DL traffic mapping configuration, IAB specific physical layer configuration of cells served by IAB-DU (e.g. IAB-DU and co-located IAB-MT multiplexing capability), etc. ○ The context of the UE directly served by the migrating IAB node ○ The context of the MT of the IAB node directly served by the migrated IAB node ▪ Similar information elements included in the MT of the migrated IAB node, as described above. ○ The context of the DU of the IAB node directly served by the migrating IAB node ▪ Similar information elements included in the DU of the migrated IAB node, as described above. ○ Context of UE served indirectly by the migrating IAB node ○ Context of the MT of the IAB node indirectly served by the migrating IAB node ▪ The context additionally contains an indication of the identity of the parent node's IAB node, ie the parent node's BAP address(s). ○ The context of the DU of the IAB node served indirectly by the migrating IAB node

Note: The information listed in the heading symbol above may be referred to as Group Submission Information (GHI).

Action 1003: The first radio network node 12 transmits to the second radio network node 15 a message (such as a handover request) related to the handover or cell reselection of the relocation node, wherein the message includes information related to the relocation node (eg, a handover request). , the IAB node) and data related to one or more other nodes (such as the IAB node and/or the UE) served directly and indirectly by the migrating node. The data may indicate one or more resources required by the server migration node and/or one or more other nodes. The data may include the context of the migration node and/or one or more other nodes.

Action 1004: The first radio network node 12 may further receive from the second radio network node 15 an indication of whether to confirm the handover. The indication may indicate whether handover or cell reselection has been accepted for the relocated node and/or one or more other nodes, respectively. The received indication may be included in a handover request acknowledgment message, and the transmitted message may include a handover request message. Therefore, the first radio network node 12 can receive a handover response message from the second radio network node 15 .

Action 1005: The first radio network node 12 may then process a handover procedure for the migrating node and/or one or more other nodes based on the received indication, eg, process handover of the migrating node based on the received indication. For example, upon determining that the response message is a handover request approval message (a modified version of the Xn handover request approval message or a newly defined message for this purpose), the first radio network node 12 may: determine the permission of the response message level. ▪ The permission level may be a metric used/computed by the source node (such as the first radio network node 12), taking into account one or more of the following: ● PDU working phase of the UE that is directly and/or indirectly served ● DRB of UE (and optionally IAB-MT) served directly and/or indirectly ● QoS traffic of UE served directly/indirectly ● PDU working phase (if any) of MT of IAB node of direct/indirect server, including migrating IAB-MT ● Number and nature of BH RLC channels on all hops/links of interest (ie, between the migrating IAB node and all its served IAB nodes), ie their configured priority, QoS, 1:1 and the number of N:1 mappings ● Number of UE and IAB-MT contexts migrated ▪ The permission level can be based on the number of accepted PDU sessions, DRBs, QoS traffic, etc. ▪ Permit level can be based on an aggregated metric, such as aggregate data rate of permitted QoS traffic ▪ If the license level is acceptable: ● Send a handover command to the MT of the migrating IAB node ▪ If the license level is not acceptable: ● Send a handover cancellation message to the target network node (such as the second radio network node 15).

For example, when the first radio network node 12 determines that the response message is a handover preparation failure message or that the response message is a handover request approval but finds that the permission level is unacceptable, the first radio network node 12 may: ▪ Suppress the MT that sends the handover command to the migrating IAB node.

The first radio network node 12 may be a source IAB donor central unit and the second radio network node 15 may be a target IAB donor central unit.

Accordingly, disclosed herein is a method for a first radio network node 12 serving as a source donor central unit (eg, for CU) operates as a donor node for an IAB node (migration IAB node) and provides connectivity for a UE.

Method actions performed by a second radio network node 15, such as an IAB node, for processing communications in the wireless communication network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Figure 11 . The wireless communication network 1 may include a first radio network node 12 and a second radio network node 15 and one of relaying data packets between a central network node (such as the first radio network node 12 ) and the UE 10 or multiple nodes.

Action 1101 : The second radio network node 15 receives from the first radio network node 12 a message related to handover or cell reselection of the relocated node, wherein the message includes data associated with the relocated node and information directly related to the relocation node. and indirect server data related to one or more other nodes. Accordingly, the second radio network node 15 may receive a message (such as a handover request) related to handover or cell reselection of a node from the first radio network node 12, wherein the message includes a connection with the (migration) node ( For example, data (indications) associated with an IAB node) and data related to other nodes (such as IAB nodes and/or UEs) served directly and/or indirectly by the node. The data may indicate one or more resources required by the server migration node and/or one or more other nodes. The data may include the context of the migration node and/or one or more other nodes. For example, the second radio network node 15 may receive a handover request message (eg, a modified version of the Xn handover request message or a new definition message for this purpose) from the first radio network node 12 to request that the migration A node (such as an indicated migrating IAB node) is handed over to a cell belonging to the second radio network node 15 (eg, a cell served by a donor DU under the second radio network node 15 or an IAB node) , where the message includes information including one or more of the following: ○ Migrate the context of one or more MTs of the IAB node ▪ This contains a context similar to a UE context and specific information related to IAB nodes only, such as BAP configuration, such as BAP address and UL traffic mapping configuration. ○ Context of migrating IAB node's DU (migrating IAB-DU) ▪ This contains information, such as information about the F1-C and F1-U connections of the relocated IAB-DU, information about the cells served by the relocated IAB-DU, and IAB specific information, such as the mapping configuration of UL/DL traffic, IAB-specific physical layer configuration of cells served by IAB-DUs (eg, multiplexing capability between IAB-DUs and co-located IAB-MTs), etc. ○ The context of the UE directly served by the migrating IAB node ○ The context of the MT of the IAB node directly served by the migrated IAB node ▪ Similar information elements included in the MT of the migrated IAB node. ○ The context of the DU of the IAB node directly served by the migrating IAB node ▪ Similar information elements contained in the DU of the migrated IAB node. ○ Context of UE served indirectly by the migrating IAB node ○ The context of the MT of the IAB node indirectly served by the migrating IAB node ▪ The context additionally contains an indication of the identity of the parent node's IAB node (ie, the parent node's BAP address(s)) ○ The context of the DU of the IAB node served indirectly by the migrating IAB node

Action 1102: The second radio network node 15 may perform admission control to determine whether to accept handover or cell reselection by the relocated node and/or one or more other nodes. For example, the second radio network node 15 may determine or decide whether to allow handover of the node, eg, to perform admission control on the UE and IAB nodes included in the received data. For example, the second radio network node 15 may perform admission control on the UE and IAB nodes included in the handover request, and may take into account one or more of the following: o Granting/handling at the target network node (such as the second radio network node 15) the CP resources required for the CP connection of the indicated one or more other nodes (such as the UE and IAB) and the like ○ UP resources (DRB, QoS traffic, PDU working phase, backload (BH) RLC channel) required for servo migration IAB node and UE ○ Number of UE and IAB-MT contexts migrated o at the target donor DU (i.e., on the first loadback link between the target donor DU and the first IAB node on the path to the parent node to which the migrating IAB node was handed over, or at the migrating IAB node In the case of direct connection to the target donor DU, the backhaul link between the target donor DU and the migrating IAB node) permits/processing the indicated migrating node and one or more other nodes (such as UE and IAB context) required Underlying resources (eg, radio resources such as symbols and frequencies) o Grant/handle the indicated UE and IAB context at any intermediate IAB node between the target donor DU and the parent IAB node to which the migrating IAB node was handed over (i.e. the backhaul link on each hop along the way) Requires lower layer resources (ie, radio resources)

Action 1103: The second radio network node 15 may then transmit to the first radio network node 12 an indication of whether to confirm the handover. For example, the second radio network node 15 may transmit an indication, wherein the indication indicates whether or not to accept. The indication may further indicate whether one or more nodes have been accepted. Thus, the transmitted indication may indicate whether handover or cell reselection has been accepted for the relocated node and/or one or more other nodes, respectively. The transmitted indication may be included in a handover request acknowledgment message, and the received message may include a handover request message. For example, the second radio network node 15 may prepare a handover response message, which may include one or more of the following: ○ If the handover cannot be performed, the handover response message is the handover preparation failure message, for example, a modified version of the Xn handover preparation failure message or a new message defined for this purpose, ○ If handoff is executable, the handoff response message is the handoff request approval message, e.g., a modified version of the Xn handoff request approval message or a new message defined for this purpose, ▪ Include the permitted IAB-MT/UE/DU context in the message (eg, permitted QoS traffic/PDU session)

As stated above, the first radio network node 12 may be a source IAB donor central unit and the second radio network node 15 may be a target IAB donor central unit.

Accordingly, embodiments herein may propose a method for a second radio network node 15 acting as a target donor central unit in an Integrated Access Backhaul (IAB) network (eg, a donor CU) operates as a candidate donor node for an IAB node (migration IAB node) and provides connectivity for a user equipment (UE).

A preparatory example of a signaling implementation is disclosed herein.

XnAP handover signaling.

Note: As mentioned earlier, for brevity, handover information about a migrated node, such as an IAB node, and all IAB nodes and UEs served directly and indirectly by the migrated IAB node may be referred to as group handover information (GHI). ).

In the case of a standalone IAB network and Xn-based handover, the source donor CU (ie, donor CU1 in FIG. 8, which is an instance of the first radio network node 12) may convert the GHI in, for example, the following Sent to the target donor CU (ie, donor CU2 in Figure 8, which is an instance of the second radio network node 15): - an existing XnAP Handover Request message, which needs to be modified to include the GHI, or - A newly defined XnAP message carrying a GHI handover request from an IAB node. This message may not be associated with the UE.

The second radio network node 15 may reply by using, for example, a handover request approval message, such as a modification of an existing message or a new definition message for this purpose.

A non-limiting example of an implementation of handover request messages using a newly defined XnAP IAB is given below. Some Information Elements (IEs) are taken from existing messages for UE handover and modified, while novel IAB specific parts are highlighted as underlined.

In an example, a "migration node" is an IAB node that directly or indirectly serves a large number of one or more other nodes, such as IAB nodes and UEs. 9.1.1.x IAB Handover Request

This message is sent by the source NG-RAN node to the target NG-RAN node to request to prepare resources for the handover of the IAB node and one of the directly and indirectly served child IAB nodes and UEs.

Direction: source NG-RAN node → target NG-RAN node. IE/group name exist Scope IE type and reference semantic description criticality assigned criticality message type M 9.2.3.1 Yes reject Source NG-RAN Node UE XnAP ID Reference M NG-RAN Node UE XnAP ID 9.2.3.16 Assigned at the source NG-RAN node Yes reject reason M 9.2.3.2 Yes reject Target cell global ID M 9.2.3.25 Contains an E-UTRA CGI or an NR CGI Yes reject GUAMI M 9.2.3.24 Yes reject Migrating IAB-MT context information 1 Yes reject >NG-C IAB-MT associated signaling reference M AMF UE NGAP ID 9.2.3.26 Allocated at the AMF on the source NG-C connection. – > TNL associated address at the NG-C side of the signaling source M CP Transport Layer Information 9.2.3.31 This IE indicates the IP address of the SCTP-associated AMF used at the source NG-C interface instance. Note: If there is no UE TNLA association at the source NG-RAN node, the source NG-RAN node indicates the TNL association address it will choose if it has to generate a UE TNLA association. – ＞UE security capability M 9.2.3.49 – ＞AS Safety Information M 9.2.3.50 – > Index to RAT/Frequency Selection Priority O 9.2.3.23 – > UE aggregated maximum bit rate O 9.2.3.17 – ＞Resource list of PDU work stage to be established 0..1 9.2.1.1 Similar to NG-C signaling, UL tunnel information containing per-PDU session resources; and additional source-side QoS traffic DRB mapping – > RRC context M octet string Contains the HandoverPreparationInformation message as defined in subsection 10.2.2 of TS 36.331 [14] if the target NG-RAN node is an ng-eNB, or TS 38.331 [10] if the target NG-RAN node is a gNB The HandoverPreparationInformation message defined in subsection 11.2.2 of . – ＞Location report information O 9.2.3.47 Contains the necessary parameters for location reporting. – > Mobility Restriction List O 9.2.3.53 – >5GC Mobility Restriction List Container O 9.2.3.100 Yes neglect > Migrating IAB-MT Loadback Connectivity Information Migrate the RRC configuration of the BH RLC connectivity between the IAB node and its parent node ( not migrated ) . Yes neglect trace start O 9.2.3.55 Yes neglect shade IMEISV O 9.2.3.32 Yes neglect UE historical information M 9.2.3.64 Yes neglect UE context reference at S-NG-RAN node O Yes neglect ＞Global NG-RAN node ID M 9.2.2.3 – >S-NG-RAN node UE XnAP ID M NG-RAN Node UE XnAP ID 9.2.3.16 – Migration of IAB-DU information The "tree top" IAB-DU is co-located with the migration IAB-MT . > Migrate IAB-DU context M Information about the F1-C/F1-U connection of the migrating IAB-DU , information about the served cell, and other IAB - specific information, such as the multiplexing capability between the IAB-DU and the co- located IAB-MT . > Migrating IAB nodes to load back connectivity information M Migrates the configuration of the backhaul connectivity between the IAB node and its parent node, the UL backhaul traffic mapping information, and the ingress - egress BH carryover mapping information. > List of UE context information for direct server O Contains context information for UEs directly connected to the IAB-DU of the migrating IAB node . Contains the UE context maintained at the source donor CU and migrated IAB-DU . ＞＞ UE context information list item of direct server 1..<max numberofservedUEs> ＞＞＞UE context information M Same as a legacy UE . List of served IAB-MT information 0..1 The list of the child nodes of the migrated IAB node ( direct or indirect server ) and related information - for MT related information ＞ Subsidiary IAB Node Information Project 1..<max numberofchildnodes> ＞＞IAB-MT BAP address M BAP address of IAB-MT ＞＞ Paternal IAB Node Information List M The BAP address of the parental IAB node ( s ) of the IAB-MT . Help the target node understand the topology under the migrated IAB node. The secondary node BAP address is included only in this case where the IAB-MT operates in dual connectivity . ＞＞＞ Master node BAP address M The BAP address of the parent IAB node of the IAB-MT ( or in the case of dual connectivity, the master parent IAB node ) . ＞＞＞ Secondary node BAP parent IAB node BAP address O In the case of dual connectivity, the BAP address of the secondary parent IAB node of the IAB-MT . ＞＞IAB-MT context information M Contextual information for the child IAB-MT . The IE has the same structure as the IAB-MT Context Information IE defined above . ＞＞IAB-MT Loadback Connectivity Information M RRC configuration for migrating BH RLC connectivity between an IAB node and its parent node ( indicated in Parent IAB Node BAP Address IE ) List of served IAB -DU information 0..1 List of child nodes of the migrated IAB node ( direct or indirect server ) and related information - for DU related information ＞ Served IAB-DU information list items 1..<max numberofDUsinIABnetwork> ＞＞ Co- located IAB-MT BAP address M The BAP address of the co- located IAB-MT . > Migrate IAB-DU context M Information about the F1-C/F1-U connection of the migrating IAB-DU , information about the served cell, and other IAB - specific information, such as the multiplexing capability between the IAB-DU and the co- located IAB-MT . > Migrating IAB nodes to load back connectivity information M Migrates the configuration of the backhaul connectivity between the IAB node and its parent node, the UL backhaul traffic mapping information, and the ingress - egress BH carryover mapping information. List of UE context information for indirect server 0..1 Contains the context information of the UE directly connected by the IAB DU of the migrating IAB node . Contains the UE context maintained at the source donor CU and migrated IAB-DU . ＞ UE context information list item of indirect server ＞＞ Servo IAB node BAP address M ID of the IAB node serving the UE . Help the target node understand the topology under the migrated IAB node. ＞＞UE context information M Same as a legacy UE .

The above messages are exemplified as messages sent from the source donor (ie the first radio network node 12) to the target donor (ie the second radio network node 15). The structure of the response message from the target donor is similar to the request message above. E.g: • The handover response from the second radio network node 15 may include information about the migrated IAB-MT, including a list of licensed and unlicensed BH RLC channels and PDU phases established towards the parent node of the migrated IAB-MT. • The handover response from the second radio network node 15 may include information on the migrated IAB-DU, including a list of licensed and unlicensed BH RLC channels and PDU phases established towards the direct-served child IAB-MT and UE. • The handover response from the second radio network node 15 may include information about the IAB-MTs served directly and indirectly by the migrating IAB-DUs, including those established between these IAB-MTs and their equivalent serving IAB-DUs List of licensed and unlicensed BH RLC channels and PDU stages. • The handover response from the second radio network node 15 may include information about the IAB-DUs of the IAB nodes served directly and indirectly by the migrating IAB-DUs, contained in these IAB-DUs and their equivalent served IAB-MTs and a list of licensed and unlicensed BH RLC channels and PDU phases established between UEs. • The handover response from the second radio network node 15 may include information about the UEs directly served by the migrating IAB-DU, including a list of permitted and unlicensed PDU phases established towards these UEs. • The handover response from the second radio network node 15 may include information about the UEs directly served by the children of the migrating IAB node, including a list of permitted and unlicensed PDU phases established towards these UEs.

The handover response message can be an enhanced handover request approval message or a newly defined XnAP message.

If any parameters of the migrating node and one or more other nodes served directly and indirectly by it need to be changed, these new parameters (as discussed above) obtained, for example, from OAM, eg, BAP, can also be provided in the handover response message Configuration, backload channel configuration, cell configuration of relocated IAB-MT, cells served by relocated IAB-DU, etc.

GN signaling state.

In the case of a standalone IAB network and NG-based handover (ie, no Xn interface exists between the source CU and the target CU), the source donor CU (ie, donor CU1 in Figure 8, which is the first radio An instance of the network node 12) may send the GHI to the AMF of the servo-migration IAB-MT/IAB node in, for example: ● Existing NGAP handover required information (which needs to be enhanced to include GHI), or ● Carrying one of the newly defined NGAP messages of GHI. This message may not be associated with the UE

The AMF forwards the handover information towards the target donor CU (ie, donor CU2 in Figure 8, which is an instance of the second radio network node 15). Thus, the first radio network node 12 transmits the message directly or indirectly to the second radio network node 15 . ● In a newly defined NGAP message that causes the IAB node to hand over to the AMF of the servo-migration IAB-MT/IAB node, by using for example: ○ Existing NGAP Handover Request message (which needs to be enhanced to include GHI), ○ AMF includes GHI in a newly defined NGAP message towards the target donor CU. Newly defined NGAP messages carrying GHI may not be associated with the UE.

In the case of a successful handover, the second radio network node 15 may reply to the AMF by eg using a handover request acknowledgement message, an enhancement of an existing message to include GHI or a newly defined message for this purpose. The AMF may reply to the second radio network node 15 by using a handover command message, an enhancement of an existing message to include GAI, or a newly defined message for this purpose. The message content is similar to that described above for the Xn handover.

Figure 12 depicts a block diagram of a first radio network node 12 for handling communications in the wireless communication network 1 according to embodiments herein.

The first radio network node 12 may include processing circuitry 1201, eg, one or more processors, configured to perform the methods herein.

The first radio network node 12 may comprise a transmission unit 1202, eg a transmitter or a transceiver. The first radio network node 12, the processing circuit 1201 and/or the transmission unit 1202 are configured to transmit to the second radio network node 15 a message related to the handover or cell reselection of the relocated node, wherein the message includes and Data associated with the migrating node and data related to one or more other nodes served directly or indirectly by the migrating node. The first radio network node 12, the processing circuit 1201, and/or the transmission unit 1202 may be configured to be used for communication (eg, indicating a handover or cell reset) for the setup node (eg, the second intermediate radio network node 14). The message (including data) selected) is transmitted to the second radio network node. The data is associated with a migration node (eg, an IAB node) and with other nodes (such as IAB nodes and/or UEs) that are served directly and indirectly by the migration node. The data may indicate one or more resources required to serve one or more other nodes. The data may include the context of the migration node and/or one or more other nodes.

The first radio network node 12 may comprise a decision unit 1203 . The first radio network node 12, the processing circuit 1201 and/or the decision unit 1203 may be configured to decide to hand over the migration node to the second radio network node. For example, based on measurements, load conditions or configuration.

The first radio network node 12 may comprise a receiving unit 1204, eg a receiver or a transceiver. The first radio network node 12, the processing circuit 1201 and/or the receiving unit 1204 may be configured to receive an indication from the second radio network node 15 indicating whether to confirm the handover. For example, the indication may indicate whether handover or cell reselection has been accepted for the relocated node and/or one or more other nodes, respectively. The received indication may be included in a handover request acknowledgment message, and the transmitted message may include a handover request message.

The first radio network node 12, the processing circuit 1201 and/or the transmission unit 1202 may be configured to process handover procedures for nodes, eg, the first radio network node 12, the processing circuit 1201 and/or the first radio network node 12, based on the received indication Transmission unit 1202 may be configured to process handover procedures for the migrating node and/or one or more other nodes based on the received indication.

The first radio network node 12 may be a source IAB donor central unit and the second radio network node 15 may be a target IAB donor central unit.

The first radio network node 12 further includes a memory 1205 . Memory 605 includes one or more units for storing data about, for example, indications, measurements, thresholds, data associated with nodes, and applications that, when executed, perform the methods disclosed herein, and the like. Furthermore, the first radio network node 12 may include a communication interface 1208, such as including a transmitter, a receiver and/or a transceiver.

The method according to the embodiments described herein for the first radio network node 12 is implemented by, for example, a computer program product 1206 or a computer program, respectively, comprising, when executed on at least one processor, causing the at least one processor to perform Instructions (ie, software code portions) of actions described herein as performed by the first radio network node 12 . The computer program product 1206 may be stored on a computer-readable storage medium 1207 (eg, a disk, a Universal Serial Bus (USB), or the like). The computer-readable storage medium 1207 having the computer program product stored thereon may include, when executed on at least one processor, cause the at least one processor to perform the actions described herein as performed by the first radio network node 12 command. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Accordingly, embodiments herein may disclose a first radio network node for processing communications in a wireless communication network, wherein the first radio network node includes processing circuitry and a memory including Processing circuitry executes instructions whereby the first radio network node is operable to perform any of the methods herein.

Figure 13 depicts one of the second radio network nodes 15 (such as a relay node, also denoted as an IAB node) for processing data packets or handling communications in the wireless communication network 1 according to embodiments herein block diagram. The wireless communication network 1 may include a first radio network node 12 and a second radio network node 15 and one or more nodes that relay data packets between a central network node and the UE 10 .

The second radio network node 15 may include processing circuitry 1301, eg, one or more processors, configured to perform the methods herein.

The second radio network node 15 may comprise a receiving unit 1302, eg a receiver or a transceiver. The second radio network node 15, the processing circuit 1301 and/or the receiving unit 1302 are configured to receive from the first radio network node 12 a message related to handover or cell reselection of a relocation node, wherein the message includes information related to relocation Data associated with the node and data related to one or more other nodes served directly and indirectly by the migrating node. For example, the second radio network node 15, the processing circuit 1301 and/or the receiving unit 1302 may be configured to receive information from the first radio network node 12 related to handover or cell reselection of a node, such as a handover request). The messages include data associated with the migrating node (eg, IAB node), which is an indication, and data related to other nodes (such as IAB nodes and/or UEs) served directly and/or indirectly by the migrating node. The data may indicate one or more resources required by the server migration node and/or one or more other nodes. The data may include the context of the migration node and/or one or more other nodes.

The second radio network node 15 may comprise a decision unit 1303 . The second radio network node 15, the processing circuit 1301 and/or the decision unit 1303 may be configured to perform admission control to decide whether to accept handover or cell reselection of the relocated node and/or one or more other nodes. For example, configured to determine or decide whether to allow handover of a node, eg, to perform admission control on UE and IAB nodes included in the received data.

The second radio network node 15 may comprise a transmission unit 1304, eg, a transmitter or a transceiver. The second radio network node 15 , the processing circuit 1301 and/or the transmission unit 1304 may be configured to transmit an indication to the first radio network node 12 indicating whether to confirm the handover. For example, configured to transmit an indication, wherein the indication indicates whether to accept or not. The indication may further indicate whether one or more nodes have been accepted. The transmitted indication may indicate whether handover or cell reselection has been accepted for the relocated node and/or one or more other nodes, respectively. The transmitted indication may be included in a handover request acknowledgment message, and the received message may be included in a handover request message.

The first radio network node 12 may be a source IAB donor central unit and the second radio network node 15 may be a target IAB donor central unit.

The second radio network node 15 further includes a memory 1305 . Memory 1305 includes one or more units for storing data about, for example, indications, data about nodes, capacity, allowed nodes, and applications that, when executed, perform the methods disclosed herein, and the like. Furthermore, the second radio network node 15 may include a communication interface 1308, such as including a transmitter with one or more antennas, a receiver and/or a transceiver.

The method according to the embodiments described herein for the second radio network node 15 is implemented by, for example, a computer program product 1306 or a computer program, respectively, comprising, when executed on at least one processor, causing the at least one processor to perform Instructions (ie, software code portions) of the actions described herein as performed by the second radio network node 15 . The computer program product 1306 may be stored on a computer-readable storage medium 1307 (eg, a disk, a Universal Serial Bus (USB), or the like). The computer-readable storage medium 1307 having the computer program product stored thereon may include, when executed on at least one processor, cause the at least one processor to perform the actions described herein as performed by the second radio network node 15 command. 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 15 for processing communications in a wireless communication network, wherein the radio network node includes processing circuitry and a memory that includes processing circuitry capable of Instructions executed by circuitry whereby the second radio network node 15 is operable to perform any of the methods herein.

In some embodiments, the more general term "radio network node" is used and may correspond to any type of radio network node or any network node that communicates with a wireless device and/or with another network node. Examples of network nodes are NodeBs, MeNBs, SeNBs, network nodes belonging to one of the Master Cell Group (MCG) or Secondary Cell Group (SCG), Base Stations (BS), Multi-Standard Radio (MSR) radio nodes (such as MSR BS), eNodeB, Network Controller, Radio Network Controller (RNC), Base Station Controller (BSC), Repeater, Donor Node Control Repeater, Transceiver Base Station (BTS), Access Point (AP), Transmission Point, Transmission Node, Remote Radio Unit (RRU), Remote Radio Head (RRH), Node in Distributed Antenna System (DAS), etc.

In some embodiments, the non-limiting term wireless device or user equipment (UE) is used and refers to any device that communicates with a network node and/or with another wireless device in a cellular or mobile communication system type of wireless device. Examples of UEs are IoT-capable devices, target devices, device-to-device (D2D) UEs, proximity-capable UEs (also known as ProSe UEs), machine-type UEs, or UEs enabling machine-to-machine (M2M) communication, tablets , mobile terminals, smart phones, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB hardware locks, etc.

Embodiments apply to any RAT or multi-RAT system where wireless devices receive and/or transmit signals (eg, data), eg, New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE Advanced, Wideband Division Code Multiple Access (WCDMA), Global System for Mobile Communications/Enhanced Data Rates for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax) or Ultra Mobile Broadband (UMB), to name just a few possible implementations.

As a skilled communications designer will readily understand, functional components or circuits may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, some or all of the various functions may be in a single application-specific integrated circuit (ASIC) or in two or more separate devices with appropriate hardware and/or software interfaces therebetween, such as implemented together. For example, several functions may be implemented on a processor shared with other functional components of a wireless device or network node.

Alternatively, some of the functional elements of the processing components discussed may be provided through the use of dedicated hardware, while other functional elements may be provided using hardware in conjunction with appropriate software or firmware executing software. Thus, the terms "processor" or "controller" as used herein do not refer only 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 communication devices will understand the cost, performance, and maintenance tradeoffs inherent in these design choices.

OTT

14 shows a telecommunications network connected to a host computer via an intermediate network, according to some embodiments. 14, according to one embodiment, a communication system includes a telecommunications network 3210 (such as a 3GPP-type cellular network) that includes an access network 3211 (such as a radio access network) and a core network 3214. The access network 3211 includes a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs, or other types of wireless access points (which are examples of the radio network nodes 12 above), each of which defines a Corresponding coverage areas 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c can be connected to the core network 3214 through a wired or wireless connection 3215. A first UE 3291 located in the coverage area 3213c is configured to wirelessly connect to or be paged by the corresponding base station 3212c. A second UE 3292 in the coverage area 3213a can be wirelessly connected to the corresponding base station 3212a. Although a plurality of UEs 3291 , 3292 are shown in this example as an example of the wireless device 10 above, the disclosed embodiments are equally applicable where a unique UE is in the coverage area or where a unique UE is connected to a corresponding base station 3212 a situation.

The telecommunications network 3210 itself is connected to a host computer 3230, which may be embodied in the hardware and/or software of a stand-alone server, a cloud-implemented server, a distributed server, or as part of a server farm Process resources. Host computer 3230 may be owned or controlled by a service provider, or operated by or on behalf of a service provider. The connections 3221 and 3222 between the telecommunications network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or through an optional intermediate network 3220. Intermediate network 3220 may be one of a public, private or hosted network, or a combination of more than one of these; intermediate network 3220 (if present) may be a backbone network or the Internet; specific language In addition, the intermediate network 3220 may include two or more subnetworks (not shown).

The communication system of FIG. 14 realizes the connectivity between the connected UEs 3291, 3292 and the host computer 3230 as a whole. Connectivity can be described as an OTT connection 3250. The host computer 3230 and connected UEs 3291, 3292 are configured to communicate data via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate networks 3220 and possibly further infrastructure (not shown) as intermediaries and/or signaling. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of the routing of uplink and downlink communications. For example, base station 3212 may not or need not be informed of the past route of incoming downlink communications with data originating from host computer 3230 to be forwarded (eg, handed over) to a connected UE 3291. Similarly, base station 3212 does not need to know the future routing of outgoing uplink communications from UE 3291 towards one of host computers 3230.

15 shows a host computer communicating with a user equipment through a base station through a portion of a wireless connection, according to some embodiments.

An exemplary implementation of the UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference to FIG. 15, according to an embodiment. In the communication system 3300, the host computer 3310 includes hardware 3315 including a communication interface 3316 that is configured to establish and maintain a wired or wireless connection with an interface of one of the various communication devices of the communication system 3300. The host computer 3310 further includes processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuit 3318 may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further includes software 3311 stored in the host computer 3310 or accessible by the host computer 3310 and executable by the processing circuit 3318. Software 3311 includes host application 3312. Host application 3312 is operable to provide a service to a remote user, such as UE 3330 connected via OTT connection 3350 terminated at UE 3330 and host computer 3310. When providing services to remote users, host application 3312 may provide user data transmitted using OTT connection 3350.

Communication system 3300 further includes base station 3320 provided in a telecommunications system and including hardware 3325 that enables it to communicate with host computer 3310 and UE 3330. The hardware 3325 may include a communication interface 3326 for establishing and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300 and for establishing and maintaining and positioning a coverage area served by the base station 3320 At least the radio interface 3327 of the wireless connection 3370 of the UE 3330 in (not shown in Figure 15). Communication interface 3326 can be configured to facilitate connection 3360 to host computer 3310. The connection 3360 may be direct or it may be through a core network of the telecommunications system (not shown in Figure 15) and/or through one or more intermediate networks external to the telecommunications system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may include one or more programmable processors, application specific integrated circuits, field programmable processors adapted to execute instructions Programmable gate arrays or combinations of these (not shown). The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further comprises the UE 3330 already mentioned. Its hardware 3333 may include a radio interface 3337 configured to establish and maintain a wireless connection 3370 with a base station serving a coverage area currently located by UE 3330. The hardware 3333 of the UE 3330 further includes a processing circuit 3338, which may include one or more programmable processors, application specific integrated circuits, field programmable gate arrays, or the like adapted to execute instructions combination (not shown). The UE 3330 further includes software 3331 stored in the UE 3330 or accessible by the UE 3330 and executable by the processing circuit 3338. The software 3331 includes a client application 3332 . Client application 3332 is operable to provide a service to a human or non-human user via UE 3330 with the support of host computer 3310. In the host computer 3310, an executing host application 3312 can communicate with the executing client application 3332 via the OTT connection 3350 terminated at the UE 3330 and the host computer 3310. In providing services to users, client application 3332 may receive request data from host application 3312 and provide user data in response to the request data. The OTT connection 3350 can transmit both request data and user data. The client application 3332 can interact with the user to generate the user data it provides.

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

In Figure 15, the OTT connection 3350 has been abstractly drawn to illustrate the communication between the host computer 3310 and the UE 3330 via the base station 3320, without explicit reference to any intermediate devices and precise message routing through these devices. The network infrastructure can determine routing, which can be configured to hide from the UE 3330 or the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure can further make decisions by which it can dynamically change the routing (eg, based on network load balancing considerations or reconfiguration).

The wireless connection 3370 between the UE 3330 and the 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 providing OTT services to UE 3330 using OTT connection 3350 (with wireless connection 3370 forming the final segment). More precisely, the teachings of these embodiments may enable handover of, for example, IAB nodes. Thereby, data communications (eg, processing or managing the setup of communications) can be performed in an efficient manner, resulting in improved responsiveness and better battery life.

A measurement procedure may be provided for purposes of monitoring data rate, latency, and other factors as modified by one or more embodiments. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and the UE 3330 in response to changes in measurement results. The measurement procedures and/or network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 and hardware 3315 of the host computer 3310 or in the software 3331 and hardware 3333 of the UE 3330, or both. In an embodiment, a sensor (not shown) may be deployed in or associated with the communication device through which the OTT connection 3350 passes; the sensor may be supplied by supplying the values of the monitored quantities exemplified above or by supplying The software 3311 and 3331 can be used to calculate or estimate the value of other physical quantities of the monitored quantity to participate in the measurement process. The reconfiguration of the OTT connection 3350 may include message formats, retransmission settings, preferred routing, etc.; the reconfiguration need not affect the base station 3320, and it may be unknown or unaware of the base station 3320. Such procedures and functionality may be known and practiced in the art. In some embodiments, the measurements may involve dedicated UE signaling that facilitates the measurement of throughput, propagation time, delay, and the like by the host computer 3310 . Measurements may be implemented wherein software 3311 and 3331 cause the use of OTT connection 3350 to transmit messages (specifically, empty or "dummy" messages) as they monitor propagation times, errors, etc.

16 shows a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments.

16 is a flowchart illustrating a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station, and a UE, which may be the components described with reference to FIGS. 14 and 15 . For the sake of brevity of the present invention, only the schematic reference to FIG. 16 will be included in this section. In step 3410, the host computer provides user data. In sub-step 3411 of step 3410 (which may be optional), the host computer provides user data by executing a host application. In step 3420, the host computer initiates a transmission carrying the user data to the UE. In accordance with the teachings of the embodiments described throughout this disclosure, in step 3430 (which may be optional), the base station transmits to the UE the user data carried in the host computer-initiated transmission. In step 3440 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

17 shows a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments.

17 is a flowchart illustrating a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station, and a UE, which may be the components described with reference to FIGS. 14 and 15 . For the sake of brevity of the present invention, only the schematic reference to FIG. 17 will be included in this section. In step 3510 of the method, the host computer provides user data. In an optional sub-step (not shown), the host computer provides user data by executing a host application. In step 3520, the host computer initiates a transmission that carries the user data to the UE. In accordance with the teachings of the embodiments described throughout this disclosure, transmissions may pass through a base station. In step 3530 (which may be optional), the UE receives the user data carried in the transmission.

18 shows a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments.

18 is a flowchart illustrating a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station, and a UE, which may be the components described with reference to FIGS. 14 and 15 . For the sake of brevity of the present invention, only the schematic reference 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 sub-step 3621 of step 3620 (which may be optional), the UE provides user data by executing a client application. In sub-step 3611 of step 3610 (which may be optional), the UE executes a client application that provides user data in response to received input data provided by the host computer. In providing user data, the executed client application may further consider user input received from the user. Regardless of the particular manner in which the user data is provided, the UE initiates the transfer of the user data to the host computer in sub-step 3630 (which may be optional). In accordance with the teachings of the embodiments described throughout this disclosure, in step 3640 of the method, the host computer receives user data transmitted from the UE.

19 shows a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments.

19 is a flowchart illustrating a method implemented in a communication system according to an embodiment. The communication system includes a host computer, a base station, and a UE, which may be the components described with reference to FIGS. 14 and 15 . For the sake of brevity of the present invention, only the schematic reference to FIG. 19 will be included in this section. In step 3710 (which may be optional), the base station receives user data from the UE in accordance with the teachings of the embodiments described throughout this disclosure. In step 3720 (which may be optional), the base station initiates the 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 suitable steps, methods, features, functions or advantages disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include several of these functional units. These functional units may be implemented through processing circuits (which may include one or more microprocessors or microcontrollers) and other digital hardware (which may include digital signal processors (DSPs)), dedicated digital logic, and the like. Processing circuitry can be configured to execute code stored in memory, which can include one or several types of memory, such as read only memory (ROM), random access memory (RAM), flash Take memory, flash memory devices, optical storage devices, etc. Code stored in memory includes program instructions for implementing one or more telecommunications and/or data communication protocols and instructions for implementing one or more of the techniques described herein. In some implementations, processing circuitry may be used to cause respective functional units to perform corresponding functions in accordance with one or more embodiments of the present invention.

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

Abbreviation Description ACK (positive) approval AUL Autonomous Uplink BLER Block Error Rate BWP Bandwidth Section CAPC Channel Access Priority Class CBG Code Block Group CCA Free Channel Assessment CO Channel occupation COT Channel occupation time CWS Competition window size DL Downlink ED Energy Detection eNB 4G base station gNB 5G base station HARQ Hybrid Automatic Repeat Request IS Synchronization LAA Authorized Auxiliary Access LBT Listen before send MAC Media Access Control MCOT Maximum Channel Occupancy Time NACK Negative recognition NDI New Data Indicator NR 5G radio access technology defined by 3GPP NR-U Unauthorized NR OOS Asynchronous PCell Main District PCI Entity Cell Identification PDCCH 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 Measurement Timing Configuration Based on SSB SpCell Special cell (PCell or PSCell) SPS Semi-permanent scheduling TTI Transmission Time Interval UCI Uplink Control Information UE User Equipment UL Uplink

1: Wireless communication network/action 2: Action 3: Action 4: Action 5: Action 6: Action 7: Action 8: Action 9: Action 10: User Equipment (UE)/Action 12: First Radio Network Node/Action 13: First Intermediate Radio Network Node/Action 14: Second Intermediate Radio Network Node/Action 15: Second Radio Network Node/Action 16: Third Intermediate Radio Network Node 901: Action 902: Action 903: Action 904: Action 905: Action 1001: Action 1002: Action 1003: Action/Transfer 1004: Action/Receive 1005: Action/Process 1101: Action/Receive 1102: Action/Execution 1103: Action/Transmission 1201: Processing Circuits 1202: Transmission unit 1203: Judgment Unit 1204: Receiver unit 1205: Memory 1206: Computer Program Products 1207: Computer-readable storage media 1208: Communication interface 1301: Processing Circuits 1302: Receiver unit 1303: Judgment Unit 1304: Transmission unit 1305: Memory 1306: Computer Program Products 1307: Computer-readable storage media 1308: Communication interface 3210: Telecom Network 3211: access network 3212a to 3212c: Base Stations 3213a to 3213c: Coverage area 3214: Core Network 3215: Wired or wireless connection 3220: Intermediate Network 3221: connect 3222: connect 3230: Host computer 3250: Video streaming platform (OTT) connection 3291: First User Equipment (UE) 3292: Second User Equipment (UE) 3300: Communication Systems 3310: Host computer 3311: Software 3312: Host application 3315: Hardware 3316: Communication interface 3318: Processing Circuits 3320: Base Station 3321: Software 3325: Hardware 3326: Communication interface 3327: Radio Interface 3328: Processing Circuits 3330: User Equipment (UE) 3331: Software 3332: Client application 3337: Radio Interface 3338: Processing Circuits 3350: Video streaming platform (OTT) connection 3360: Connect 3370: Wireless connection 3410: Steps 3411: Substep 3420: Steps 3430: Steps 3440: Steps 3510: Steps 3520: Steps 3530: Steps 3610: Steps 3611: Substep 3620: Steps 3621: Substep 3620: Steps 3710: Steps 3720: Steps 3730: Steps

Embodiments will now be described in more detail with respect to the accompanying drawings, in which: FIG. 1 is a reference diagram depicting one of the IAB architectures; 2 shows a baseline User Plane (UP) protocol stack for one of the IABs in rel-16 according to the prior art; 3 shows a baseline control plane (CP) protocol stack for one of the IABs in rel-16 according to the prior art; 4 shows an example of a functional view of the BAP sublayer according to the prior art; Figure 5 shows an example of different possible cases of IAB node migration according to the prior art; 6 is an intra-IAB CU topology adaptation procedure according to one of the prior art; 7 depicts a schematic overview diagram of a wireless communication network in accordance with embodiments herein; 8 depicts a schematic overview diagram of a wireless communication network in accordance with embodiments herein; 9 is a combined signaling scheme and flow diagram according to one of some embodiments herein; Figure 10 depicts a schematic flow diagram of a method performed by a first radio network node according to embodiments herein; Figure 11 depicts a schematic flow diagram of a method performed by a second radio network node according to embodiments herein; 12 depicts a block diagram of a first radio network node according to embodiments herein; 13 is a block diagram depicting a second radio network node according to embodiments herein; 14 is a telecommunications network connected to a host computer via an intermediate network, according to some embodiments; 15 is a host computer in communication with a user equipment via a base station through a portion of a wireless connection, according to some embodiments; 16 is a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments; 17 is a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments; 18 is a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments; and 19 is a method implemented in a communication system including a host computer, a base station, and a user equipment, according to some embodiments.

1: Wireless communication network

10: User Equipment (UE)

12: First Radio Network Node

13: First Intermediate Radio Network Node

14: Second Intermediate Radio Network Node

15: Second Radio Network Node

16: Third Intermediate Radio Network Node

Claims (34)

A method performed by a first radio network node (12) for handling communications in a wireless communication network, the method comprising transmitting (1003) a message related to handover or cell reselection of a relocation node (13, 14) to a second radio network node (15), wherein the message includes data associated with the relocation node and Data related to one or more other nodes served directly and indirectly by the migrating node. The method of claim 1, wherein the data indicates one or more resources required to serve the migrating node and/or the one or more other nodes. The method of any one of claims 1-2, wherein the data includes the context of the migrating node and/or the one or more other nodes. The method of any one of claims 1 to 2, further comprising An indication of whether to confirm the handover is received (1004) from the second radio network node (15). The method of claim 4, wherein the indication indicates whether the handover or cell reselection has been accepted for the relocated node and/or the one or more other nodes, respectively. The method of claim 4, wherein the received indication is included in a handover request acknowledgment message, and the transmitted message includes a handover request message. The method of claim 4, further comprising A handover procedure of the migrating node (13, 14) and/or one of the one or more other nodes is processed (1005) based on the received indication. The method of any one of claims 1 to 2, wherein the first radio network node (12) is a source integrated access backhaul (IAB) donor central unit, and the second radio network node (15) ) is a target IAB donor central unit. A method performed by a second radio network node (15) for handling communications in a wireless communication network, the method comprising Receive (1101) from a first radio network node (12) a message related to handover or cell reselection of a relocation node (13, 14), wherein the message includes data associated with the relocation node and a Data related to one or more other nodes is served directly and indirectly by the migration node (13, 14). The method of claim 9, wherein the data indicates one or more resources required to serve the migrating node and/or the one or more other nodes. The method of any one of claims 9 to 10, wherein the data includes the context of the migrating node and/or the one or more other nodes. The method of any one of claims 9 to 10, further comprising Admission control is performed (1102) to determine whether to accept the handover or cell reselection for the relocated node and/or the one or more other nodes. The method of any one of claims 9 to 10, further comprising An indication indicating whether the handover is confirmed is transmitted (1103) to the first radio network node (12). The method of claim 13, wherein the transmitted indication indicates whether the handover or cell reselection has been accepted for the relocation node and/or the one or more other nodes, respectively. The method of claim 13, wherein the transmitted indication is included in a handover request acknowledgment message, and the received message includes a handover request message. The method of any one of claims 9 to 10, wherein the first radio network node (12) is a source integrated access backhaul (IAB) donor central unit, and the second radio network node (15) ) is a target IAB donor central unit. A computer program product comprising, when executed on at least one processor, causes the at least one processor to perform as requested by a first radio network node (12) or a second radio network node (15), respectively Instructions for any of the methods 1 to 16. 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 execute as executed by a first radio network node (12) or The second radio network node (15) performs a method as in any of claims 1 to 16. A first radio network node (12) for handling communications in a wireless communication network, wherein the first radio network node (12) is configured to transmitting to a second radio network node (15) a message related to the handover or cell reselection of a relocation node (13, 14), wherein the message includes data associated with the relocation node and information associated with the relocation node The migration nodes (13, 14) directly or indirectly serve data related to one or more other nodes. The first radio network node (12) of claim 19, wherein the data indicates one or more resources required to serve the migrating node and/or the one or more other nodes. The first radio network node ( 12 ) of any one of claims 19 to 20, wherein the data includes the context of the migration node and/or the one or more other nodes. The first radio network node (12) of any one of claims 19 to 20, wherein the first radio network node (12) is configured to An indication is received from the second radio network node (15) indicating whether the handover is confirmed. The first radio network node (12) of claim 22, wherein the indication indicates whether the handover or cell reselection has been accepted for the relocation node and/or the one or more other nodes, respectively. The first radio network node (12) of claim 22, wherein the received indication is included in a handover request acknowledgment message, and the transmitted message includes a handover request message. The first radio network node (12) of claim 22, wherein the first radio network node (12) is configured to Handover procedures for the migrating node and/or the one or more other nodes are processed based on the received indication. The first radio network node (12) of any one of claims 19 to 20, wherein the first radio network node (12) is a source integrated access backhaul (IAB) donor central unit, and the The second radio network node (15) is a target IAB donor central unit. A second radio network node (15) for handling communications in a wireless communication network (1), wherein the second radio network node (15) is configured to Receive from a first radio network node (12) a message related to handover or cell reselection of a relocation node (13, 14), wherein the message includes data associated with the relocation node and information related to the relocation node (13, 14). Nodes (13, 14) directly and indirectly serve data related to one or more other nodes. The second radio network node (15) of claim 27, wherein the data indicates one or more resources required to serve the migrating node and/or the one or more other nodes. The second radio network node (15) of any one of claims 27 to 28, wherein the data includes the context of the migration node and/or the one or more other nodes. The second radio network node (15) of any of claims 27 to 28, wherein the second radio network node (15) is configured to Admission control is performed to determine whether to accept the handover or cell reselection for the relocated node and/or the one or more other nodes. The second radio network node (15) of any of claims 27 to 28, wherein the second radio network node (15) is configured to An indication of whether the handover is confirmed is transmitted to the first radio network node (15). The second radio network node (15) of claim 31, wherein the transmitted indication indicates whether the handover or cell reselection has been accepted for the relocation node and/or the one or more other nodes, respectively. The second radio network node (15) of claim 31, wherein the transmitted indication is included in a handover request acknowledgment message, and the received message includes a handover request message. The second radio network node (15) of any one of claims 27 to 28, wherein the first radio network node (12) is a source integrated access backhaul (IAB) donor central unit, and the first radio network node (12) The two radio network nodes (15) are a target IAB donor central unit.

Images