WO2022216215A1 - Procédés et nœuds de réseau radio pour la gestion de communication - Google Patents

Procédés et nœuds de réseau radio pour la gestion de communication Download PDF

Info

Publication number
WO2022216215A1
WO2022216215A1 PCT/SE2022/050354 SE2022050354W WO2022216215A1 WO 2022216215 A1 WO2022216215 A1 WO 2022216215A1 SE 2022050354 W SE2022050354 W SE 2022050354W WO 2022216215 A1 WO2022216215 A1 WO 2022216215A1
Authority
WO
WIPO (PCT)
Prior art keywords
radio network
network node
node
iab
donor
Prior art date
Application number
PCT/SE2022/050354
Other languages
English (en)
Inventor
Ritesh SHREEVASTAV
Filip BARAC
Marco BELLESCHI
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to EP22785073.2A priority Critical patent/EP4320917A1/fr
Publication of WO2022216215A1 publication Critical patent/WO2022216215A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/086—Load balancing or load distribution among access entities
    • H04W28/0861—Load balancing or load distribution among access entities between base stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0827—Triggering entity
    • H04W28/0835—Access entity, e.g. eNB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0858—Load balancing or load distribution among entities in the uplink
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0958—Management thereof based on metrics or performance parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off

Definitions

  • Embodiments herein relate to a first radio network node, a second radio network node, and methods performed therein regarding wireless communication. Furthermore, a computer program and a computer readable storage medium are also provided herein. In particular, embodiments herein relate to handling communication, such as controlling/managing load sharing or transferring for relay network nodes, in a wireless communications network.
  • UE user equipment
  • STA mobile stations, stations
  • CN core networks
  • the RAN covers a geographical area which is divided into service areas or cell areas, with each service area or cell area being served by radio network node such as an access node, e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be called, for example, a NodeB, a gNodeB, or an eNodeB.
  • RBS radio base station
  • the service area or cell area is a geographical area where radio coverage is provided by the radio network node.
  • the radio network node operates on radio frequencies to communicate over an air interface with the UEs within range of the radio network node.
  • the radio network node communicates over a downlink (DL) to the UE and the UE communicates over an uplink (UL) to the radio network node.
  • DL downlink
  • UL uplink
  • a Universal Mobile Telecommunications System is a third generation telecommunication network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM).
  • the UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High-Speed Packet Access (HSPA) for communication with user equipment.
  • WCDMA wideband code division multiple access
  • HSPA High-Speed Packet Access
  • 3GPP Third Generation Partnership Project
  • telecommunications suppliers propose and agree upon standards for present and future generation networks and UTRAN specifically, and investigate enhanced data rate and radio capacity.
  • 3GPP Third Generation Partnership Project
  • radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto.
  • RNC radio network controller
  • BSC base station controller
  • the RNCs are typically connected to one or more core networks.
  • the Evolved Packet System comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long-Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network.
  • E-UTRAN also known as the Long-Term Evolution (LTE) radio access network
  • EPC also known as System Architecture Evolution (SAE) core network.
  • E-UTRAN/LTE is a 3GPP radio access technology wherein the radio network nodes are directly connected to the EPC core network.
  • the Radio Access Network (RAN) of an EPS has an essentially “flat” architecture comprising radio network nodes connected directly to one or more core networks.
  • Transmit-side beamforming means that the transmitter can amplify the transmitted signals in a selected direction or directions, while suppressing the transmitted signals in other directions.
  • a receiver can amplify signals from a selected direction or directions, while suppressing unwanted signals from other directions.
  • the 3GPP has completed the integrated access and wireless access backhaul or Integrated Access Backhaul (IAB) in NR Rel-16 and is currently standardizing the IAB Rel-17.
  • IAB Integrated Access Backhaul
  • the usage of short range mmWave spectrum in NR creates a need for densified deployment with multi-hop backhauling.
  • optical fiber to every base station will be too costly and sometimes not even possible, e.g., historical sites.
  • the main IAB principle is the use of wireless links for the backhaul, instead of fiber, to enable flexible and very dense deployment of cells without the need for densifying the transport network.
  • Use case scenarios for IAB can include coverage extension, deployment of massive number of small cells and fixed wireless access (FWA), e.g., to residential/office buildings.
  • FWA fixed wireless access
  • the larger bandwidth available for NR in mmWave spectrum provides opportunity for self- backhauling, without limiting the spectrum to be used for the access links.
  • the inherent multi-beam and multiple input multiple output (MIMO) support in NR reduce cross-link interference between backhaul and access links allowing higher densification.
  • MIMO multiple input multiple output
  • summary of the study item can be found in the technical report TR 38.874 v.16.5.0, it has been agreed to adopt a solution that leverages a Central Unit (CU) and Distributed Unit (DU) split architecture of NR, where the IAB node will be hosting a DU part that is controlled by a central unit.
  • the IAB nodes also have a Mobile Termination (MT) part that they use to communicate with their parent nodes.
  • MT Mobile Termination
  • IAB The specifications for IAB strives to reuse existing functions and interfaces defined in NR.
  • MT, gNB-DU, gNB-CU, user plane function (UPF), access and mobility management function (AMF) and session management function (SMF) as well as the corresponding interfaces NR Uu, between MT and gNB, F1, NG, X2 and N4 are used as baseline for the IAB architectures.
  • UPF user plane function
  • AMF access and mobility management function
  • SMF session management function
  • Modifications or enhancements to these functions and interfaces for the support of IAB will be explained in the context of the architecture discussion. Additional functionality such as multi-hop forwarding is included in the architecture discussion as it is necessary for the understanding of IAB operation and since certain aspects may require standardization.
  • the MT function has been defined as a component of the IAB node.
  • MT is referred to as a function residing on an IAB-node that terminates the radio interface layers of the backhaul Uu interface toward the IAB-donor or other IAB- nodes.
  • Fig. 1 shows a reference diagram for IAB in standalone mode, which contains one IAB-donor and multiple IAB-nodes.
  • the IAB-donor is treated as a single logical node that comprises a set of functions such as gNB-distributed unit (DU), gNB-central unit-control plane (CU-CP), gNB-central unit-user plane (CU-UP) and potentially other functions.
  • the IAB-donor can be split according to these functions, which can all be either collocated or non-col located as allowed by 3GPP NG-RAN architecture. IAB-related aspects may arise when such split is exercised.
  • some of the functions presently associated with the IAB-donor may eventually be moved outside of the donor in case it becomes evident that they do not perform IAB-specific tasks.
  • Fig. 1 shows a high- level architectural view of an IAB network.
  • the baseline user plane and control plane protocol stacks for IAB are shown in Figs. 2 and 3.
  • the chosen protocol stacks reuse the current CU-DU split specification in Rel-15, where the full user plane F1-U (GTP-U/U DP/IP) is terminated at the IAB node (like a normal DU) and the full control plane F1-C (F1-AP/SCTP/IP) is also terminated at the IAB node (like a normal DU).
  • NDS Network Domain Security
  • UP user plane
  • CP control plane
  • IPsec IPsec
  • DTLS Datagram Transport Layer Security
  • IPsec may also be used for the CP protection instead of DTLS (in this case no DTLS layer would be used).
  • BAP Backhaul Adaptation Protocol
  • IAB nodes A new protocol layer called Backhaul Adaptation Protocol (BAP) has been introduced in the IAB nodes and the IAB donor, which is used for routing of packets to the appropriate downstream/upstream node and also mapping the UE bearer data to the proper backhaul RLC channel, and also between ingress and egress backhaul (BH) radio link control (RLC) channels in intermediate IAB nodes, to satisfy the end to end quality of service (QoS) requirements of bearers.
  • the BAP layer is in charge of handling the BH RLC channel, e.g. to map an ingress BH RLC channel from a parent/child IAB node to an egress BH RLC channel in the link towards a child/parent IAB node.
  • one BH RLC channel may convey end-user traffic for several DRBs and for different UEs which could be connected to different IAB nodes in the network.
  • 3GPP two possible configuration of BH RLC channel has been provided, i.e. a 1:1 mapping between BH RLC channel and a specific user ' s data radio bearer (DRB), a N: 1 bearer mapping where N DRBs possibly associated to different UEs are mapped to 1 BH RLC channel.
  • DRB data radio bearer
  • this type of 1:1 configuration is not easily scalable in case an IAB node is serving many UEs/DRBs.
  • the N:1 configuration is more flexible/scalable, but ensuring fairness across the various served BH RLC channels might be trickier, because the amount of DRBs/UEs served by a given BH RLC channel might be different from the amount of DRBs/UEs served by another BH RLC channel.
  • the BAP sublayer contains one BAP entity at the MT function and a separate co-located BAP entity at the DU function.
  • the BAP sublayer contains only one BAP entity.
  • Each BAP entity has a transmitting part and a receiving part. The transmitting part of the BAP entity has a corresponding receiving part of a BAP entity at the IAB-node or IAB-donor-DU across the backhaul link.
  • Fig. 4 shows one example of the functional view of the BAP sublayer. This functional view should not restrict implementation. The figure is based on the radio interface protocol architecture defined in TS 38. 300 v.16.5.0.
  • the receiving part on the BAP entity delivers BAP protocol data units (PDU) to the transmitting part on the collocated BAP entity.
  • the receiving part may deliver BAP service data units (SDU) to the collocated transmitting part.
  • PDU BAP protocol data units
  • SDU BAP service data units
  • Passing BAP SDUs in this manner is therefore functionally equivalent to passing BAP PDUs, in implementation.
  • the following service is provided by the BAP sublayer to upper layers: data transfer.
  • a BAP sublayer expects the following services from lower layers per RLC entity, for a detailed description see TS 38.322 v16.2.0: acknowledged data transfer service; unacknowledged data transfer service.
  • the BAP sublayer supports the following functions:
  • the BAP layer is fundamental to determine how to route a received packet. For the downstream that implies determining whether the packet has reached its final destination, in which case the packet will be transmitted to UEs that are connected to this IAB node as access node, or to forward it to another IAB node in the right path.
  • the BAP layer passes the packet to higher layers in the IAB node which are in charge of mapping the packet to the various QoS flows and hence DRBs which are included in the packet.
  • the BAP layer determines the proper egress BH RLC channel on the basis of the BAP destination, path IDs and ingress BH RLC channel. Same as the above applies also to the upstream, with the only difference that the final destination is always one specific donor DU/CU.
  • the BAP layer of the IAB node has to be configured with a routing table mapping ingress RLC channels to egress RLC channels which may be different depending on the specific BAP destination and path of the packet.
  • the BAP destination and path ID are included in the header of the BAP packet so that the BAP layer can determine where to forward the packet.
  • the BAP layer has an important role in the hop-by-hop flow control.
  • a child node may inform a parent node about possible congestions experienced locally at the child node, so that the parent node can throttle the traffic towards the child node.
  • the parent node can also use the BAP layer to inform the child node in case of radio link failure (RLF) issues experienced by the parent, so that the child can possibly reestablish its connection to another parent node.
  • RLF radio link failure
  • Topology adaptation in IAB networks may be needed for various reasons, e.g. changes in the radio conditions, changes to the load under the serving CU, radio link failures, etc.
  • an IAB topology adaptation could be that an IAB node is migrated, i.e. , handed over, to a new parent, which may be controlled by the same or different CU, or that some traffic currently served by such IAB node is offloaded via a new route, which can be controlled by the same or different CU. If the new parent of the IAB node is under the same CU or a different CU, the migration is intra-donor and inter-donor one, respectively, herein also referred to as the intra-CU and inter-CU migration.
  • Fig. 5 shows an example of some possible IAB-node migration, i.e., topology adaptation, cases listed in the order of complexity, i.e., examples of different possible scenarios for IAB topology adaptation.
  • Intra-CU Case (A) In this case the IAB-node E along with it serving UEs is moved to a new parent node, IAB-node B, under the same donor-DU (1).
  • the successful intra donor DU migration requires establishing UE context setup for the IAB-node E MT in the DU of the new parent node, IAB-node B, updating routing tables of IAB nodes along the path to IAB-node E and allocating resources on the new path.
  • the IP address for IAB- node (e) will not change, while the F1-U tunnel or connection between donor-CU (1) and IAB-node E DU will be redirected through IAB-node B.
  • Intra-CU Case (B) The procedural requirements/complexity of this case is the same as that of Case (A). Also, since the new IAB-donor DU (i.e., 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 (i.e. DU2) will need to inform the network using IAB- node E L2 address in order to get/keep the same IP address for IAB-node E by employing some mechanism such as Address Resolution Protocol (ARP).
  • ARP Address Resolution Protocol
  • Intra-CU Case (C) This case is more complex than Case (A) as it also needs allocation of new IP address for IAB-node E.
  • IPsec is used for securing the F1-U tunnel/connection between the Donor-CU (1) and IAB-node E DU, then it might be possible to use existing IP address along the path segment between the Donor-CU (1) and SeGW, and new IP address for the IPsec tunnel between SeGW and IAB-node E DU.
  • Inter-CU Case (D) This is the most complicated case in terms of procedural requirements and may need new specification procedures (such as enhancement of radio resource control (RRC), F1AP, XnAP, Ng signalling) that are beyond the scope of 3GPP Rel-16.
  • RRC radio resource control
  • F1AP F1AP
  • XnAP XnAP
  • Ng signalling Ng signalling
  • Inter- CU migration requires new signalling procedures between source and target CU in order to migrate the IAB node contexts and its traffic to the target CU, such that the IAB node operations can continue in the target CU and the QoS is not degraded. Inter-CU migration will be specified in the context of 3GPP Rel17.
  • both the source and the target parent node are served by the same IAB-donor-CU.
  • the target parent node may use a different IAB-donor-DU than the source parent node.
  • the source path may further have common nodes with the target path.
  • Fig. 6 shows an example of the topology adaptation procedure, where the target parent node uses a different IAB-donor-DU than the source parent node.
  • the migrating IAB-MT sends a MeasurementReport message to the source parent node IAB-DU. This report is based on a Measurement Configuration the migrating IAB-MT received from the IAB-donor-CU before.
  • the source parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received MeasurementReport.
  • the IAB-donor-CU sends a UE CONTEXT SETUP REQUEST message to the target parent node IAB-DU to create the UE context for the migrating IAB-MT and set up one or more bearers. These bearers can be used by the migrating IAB-MT for its own signalling, and, optionally, data traffic.
  • the target parent node IAB-DU responds to the IAB-donor-CU with a UE CONTEXT SETUP RESPONSE message.
  • the IAB-donor-CU sends a UE CONTEXT MODIFICATION REQUEST message to the source parent node IAB-DU, which includes a generated RRCRecon figuration message.
  • the RRCRecon figuration message includes a default BH RLC channel and a default BAP Routing ID configuration for UL F1-C/non-F1 traffic mapping on the target path. It may include additional BH RLC channels. This step may also include allocation of TNL address(es) that is (are) routable via the target IAB-donor- DU.
  • the new TNL address(es) may be included in the RRCRecon figuration message as a replacement for the TNL address(es) that is (are) routable via the source IAB-donor-DU.
  • the allocated TNL address is outer IP address.
  • the TNL address replacement is not necessary if the source and target paths use the same IAB- donor-DU.
  • the Transmission Action Indicator in the UE CONTEXT MODIFICATION REQUEST message indicates to stop the data transmission to the migrating IAB- node.
  • the source parent node IAB-DU forwards the received RRCRecon figuration message to the migrating IAB-MT.
  • the source parent node IAB-DU responds to the IAB-donor-CU with the UE CONTEXT MODIFICATION RESPONSE message.
  • a Random Access procedure is performed at the target parent node IAB-DU.
  • the migrating IAB-MT responds to the target parent node IAB-DU with an RRCReconfigurationComplete message.
  • the target parent node IAB-DU sends an UL RRC MESSAGE TRANSFER message to the IAB-donor-CU to convey the received
  • uplink packets can be sent from the migrating IAB-MT, which are forwarded to the IAB-donor-CU through the target parent node IAB-DU. These UL packets belong to the IAB-MT’s own signalling and, optionally, data traffic.
  • the IAB-donor-CU configures BH RLC channels and BAP-sublayer routing entries on the target path between the target parent IAB-node and target IAB-donor-DU as well as DL mappings on the target IAB-donor-DU for the migrating IAB-node’s target path. These configurations may be performed at an earlier stage, e.g. immediately after step 3.
  • the IAB-donor-CU may establish additional BH RLC channels to the migrating IAB-MT via RRC message.
  • IAB-donor-CU updates the UL BH information associated to each GTP-tunnel to migrating IAB-node. This step may also update UL FTEID and DL FTEID associated to each GTP-tunnel. All F1-U tunnels are switched to use the migrating IAB-node’s new TNL address(es). This step may use non-UE associated signalling in E1 and/or F1 interface to provide updated UP configuration for F1-U tunnels of multiple connected UEs or child IAB-MTs.
  • the IAB-donor-CU may also update the UL BH information associated with non-UP traffic. Implementation must ensure the avoidance of potential race conditions, i.e. no conflicting configurations are concurrently performed using UE-associated and non-U E-associated procedures.
  • the IAB-donor-CU sends a UE CONTEXT RELEASE COMMAND message to the source parent node IAB-DU.
  • the source parent node IAB-DU releases the migrating IAB-MTs context and responds to the IAB-donor-CU with a UE CONTEXT RELEASE COMPLETE message.
  • the IAB-donor-CU releases BH RLC channels and BAP-sublayer routing entries on the source path between source parent IAB-node and source IAB-donor-DU.
  • Steps 11, 12 and 15 should also be performed for the migrating IAB-node’s descendant nodes, as follows:
  • the IAB-donor-CU may allocate new TNL address(es) that is (are) routable via the target IAB-donor-DU to the descendent nodes via RRCReconfiguration message.
  • the IAB-donor-CU may also provide a new default UL mapping which includes a default BH RLC channel and a default BAP Routing ID for UL F1- C/non-F1 traffic on the target path, to the descendant nodes via RRCReconfiguration message.
  • the IAB-donor-CU configures BH RLC channels, BAP-sublayer routing entries on the target path for the descendant nodes and the BH RLC channel mappings on the descendant nodes in the same manner as described for the migrating IAB-node in step 11.
  • the descendant nodes switch their F1-C connections and F1-U tunnels to new TNL addresses that are anchored at the new IAB-donor-DU, in the same manner as described for the migrating IAB-node in step 12.
  • these steps can be performed after or in parallel with the handover of the migrating IAB-node.
  • In-flight downlink data in the source path may be discarded, up to implementation via the NR user plane protocol (TS 38.425 [24]).
  • the IAB-donor-CU can determine the unsuccessfully transmitted downlink data over the backhaul link by implementation.
  • 3GPP Rel-16 has standardized only intra-CU topology adaptation procedure. Considering that inter-CU migration will be an important feature of IAB Rel-17 work item (Wl), enhancements to existing procedure are required for reducing service interruption, due to IAB-node migration, and signalling load.
  • inter-donor topology adaptation also known as inter-CU migration
  • inter-CU migration The use cases for inter-donor topology adaptation, also known as inter-CU migration, are:
  • Inter-donor load balancing One possible scenario is that a link between an IAB node and its parent becomes congested.
  • the traffic of an entire network branch, below and including said IAB node herein referred to as a top- level IAB node serving one or more descendant nodes and/or UEs, may be redirected to reach the top-level node via another route. If the new route for the offloaded traffic includes traversing the network under another donor before reaching the top-level node, the scenario is an inter-donor routing one.
  • the offloaded traffic may include both the traffic terminated at the top-level IAB node and its served UEs, or the traffic traversing the top-level IAB node, and terminated at its descendant IAB nodes and UEs.
  • the MT of the top-level IAB node i.e., top-level IAB-MT, may establish an RRC connection to another donor, thus releasing its RRC connection to the old donor, and the traffic towards this node and its descendant devices is now sent via the new donor.
  • Inter-donor RLF recovery where an IAB node experiencing an RLF on its parent link attempts RRC reestablishment towards a new parent under another donor, this node may also be referred to as the top-level IAB node.
  • the top-level IAB node According to 3GPP agreements, if the descendant IAB nodes and UEs of the top-level node “follow” to the new donor, the parent-child relations are retained after the top-level node connects to another donor.
  • top-level node’s IAB-MT may connect to only one donor at a time.
  • Rel17 work will also consider the case where the top-level IAB-MT may simultaneously connect to two donors, in which case:
  • the traffic reaching the top-level IAB node via one leg may be offloaded to reach the top-level IAB node, and, potentially, its descendant nodes, via the other leg that the node established to another donor.
  • the traffic reaching the top-level IAB node via the broken leg may be redirected to reach the node via the “good” leg, towards the other donor.
  • the 3GPP Rel17 specifications will allow two alternatives:
  • Proxy-based solution - assuming that top-level IAB-MT is capable of connecting to only one donor at a time, the top-level IAB-MT migrates to a new donor, while the F1 and RRC connections of its collocated IAB-DU and all the descendant IAB- MTs, lAB-DUs and UEs remain anchored at the old donor.
  • Proxy-based solution is also applicable in case when top-level IAB-MT is simultaneously connected to two donors. In this case, some or all of the traffic traversing/terminating at the top-level node is offloaded via the leg towards the ‘other’ donor.
  • proxy-based solution for inter-CU migration One drawback of the full migration-based solution for inter-CU migration is that a new F1 connection is set up from IAB-node E to the new CU, i.e., CU(2), and the old F1 connection to the old CU, i.e., CU(1), is released.
  • any reconfiguration of the descendant nodes of the top-level node herein, the term top-level node is also used, is avoided. This means that the descendant nodes should preferably be unaware of the fact that the traffic is proxied via CU2.
  • a proxy-based mechanism has been proposed where the inter-CU migration is done without handing over the UEs or IAB nodes directly or indirectly being served by the top-level IAB node, thereby making the handover of the directly and indirectly served UEs transparent to the target CU.
  • the target CU serves as the proxy for these F1 and RRC connections that are kept at the source CU.
  • the target CU just needs to ensure that the ancestor node of the top-level IAB node are properly configured to handle the traffic from the top-level node to the target donor, and from the target donor to the top-level node. Meanwhile, the configuration of the descendant IAB node of said top-level node are still under the control of the source donor. Hence, in this case the target donor does not need to know the network topology and the CoS requirements or the configuration of the descendant IAB nodes and UEs.
  • Fig. 7 illustrates the signalling connections when the F1 connections are maintained in the CU-1
  • Fig. 8 highlights how the F1-U is tunnelled over the Xn and then transparently forwarded to the IAB donor-DU-2 after the IAB node is migrated to the target donor CU, i.e., CU2.
  • Fig. 9 shows an example of inter-donor load balancing scenario, involving IAB3 and its descendant node IAB4 and the UEs that these two IAB nodes are serving.
  • IAB3-MT changes its RRC connection, i.e., association, from CU_1 to CU_2.
  • IAB3 top-level IAB node
  • IAB4 top-level IAB node
  • the assumption is that direct routing between CU_1 and Donor DU_2 is applied, i.e., CU_1 - Donor DU_1 - and so on...., rather than the indirect routing case CU_1 - CU_2 - Donor DU_1 - and so on....
  • the direct routing can, e.g., be supported via IP routing between (source donor) CU_1 and donor DU2 (target donor DU) or via an Xn connection between the two.
  • indirect routing data can be sent between CU_1 and CU_2 via Xn interface, and between CU_2 and Donor DU_2 via F1 or via IP routing. Both direct and indirect routing are applicable herein.
  • the advantage of direct routing is that the latency is likely to be smaller.
  • the traffic terminated at or traversing an IAB node may be subject to load balancing, where the underlying causes of load balancing may be e.g.:
  • the traffic of an entire network branch including the traffic towards an IAB node, herein referred to as the top-level IAB node, and a number of its descendant IAB nodes and UEs may be redirected to reach the top-level node via another route.
  • the new route for the offloaded traffic includes traversing the network under another donor before reaching the top-level node, the scenario is an inter-donor routing one.
  • the MT of the top-level IAB node i.e. , top-level IAB-MT, may establish an RRC connection to another donor, thus releasing its RRC connection to the old donor, and the traffic towards this node and its descendant devices is now sent via the new donor.
  • Proxy-based solution - assuming that top-level IAB-MT is capable of connecting to only one donor at a time, the top-level IAB-MT migrates to a new donor, while the F1 and RRC connections of its collocated IAB-DU and all the descendant IAB- MTs, lAB-DUs and UEs remain anchored at the old donor.
  • Proxy-based solution is also applicable in case when top-level IAB-MT is simultaneously connected to two donors. In this case, some or all of the traffic traversing/terminating at the top-level node is offloaded via the leg towards the ‘other’ donor.
  • An object herein is to provide a mechanism to enable communication, e.g. handle or manage communication of PDUs, to improve the performance of the wireless communications network in an efficient manner.
  • the object is achieved, according to embodiments herein, by providing a method performed by a first radio network node for handling communication in the wireless communications network.
  • the first radio network node queries one or more second radio network nodes, whether respective second radio network node comprises one or more resources to perform load sharing with.
  • the first radio network node receives a response from the second radio network node indicating confirmation or rejection of load sharing.
  • the first radio network node then performs an action based on the response.
  • the object is achieved, according to embodiments herein, by providing a method performed by a second radio network node such as an IAB donor node, for handling or managing communication in a wireless communications network.
  • the second network node receives a query from a first radio network node whether the second radio network node comprises one or more resources available to perform load sharing with the first radio network node.
  • the second radio network node determines one or more available resources for supporting one or more UEs and/or network nodes taking the query into account.
  • the second radio network node then transmits a response to the first radio network node confirming or rejecting said request taking the determination of the one or more available resources into account, for example, by comparing requested resources with available resources.
  • the object is achieved, according to embodiments herein, by providing a first radio network node and a second radio network node configured to perform the methods herein, respectively.
  • a first radio network node such as an IAB donor node, for handling communication in the wireless communications network.
  • the first radio network node is configured to query one or more second radio network nodes, whether respective second radio network node comprises one or more resources to perform load sharing with.
  • the first radio network node is further configured to receive a response from the second radio network node indicating confirmation or rejection of load sharing and is configured to perform an action based on the response.
  • a second radio network node such as an IAB donor node, for handling or managing communication in a wireless communications network.
  • the second network node is configured to receive a query from a first radio network node whether the second radio network node comprises one or more resources available to perform load sharing with the first radio network node.
  • the second radio network node is further configured to determine one or more available resources for supporting one or more UEs and/or network nodes taking the query into account.
  • the second radio network node is configured to transmit a response to the first radio network node confirming or rejecting said request taking the determination of the one or more available resources into account.
  • a computer program product comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out the method above, as performed by the first radio network node, and the second radio network node, respectively.
  • a computer-readable storage medium having stored thereon a computer program product comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method above, as performed by the first radio network node, and the radio second network node, respectively.
  • Embodiments herein provide one or more radio network nodes such as an IAB node to perform load sharing by migrating network nodes such as IAB nodes and/or UEs, and/or traffic related to such network nodes. Migration may be dictated by load balancing, radio link failure (RLF), radio measurements, mobility etc.
  • Embodiments herein relate to a scenario whether the first radio network node, such as an IAB node, being, for example, a serving central unit, may determine initiation for topology adaptation.
  • the first radio network node queries the second radio network node by, for example, sending a message to the second radio network node such as a target CU with resource requirements.
  • the first radio network node further obtains one or more responses from target CU(s) and takes different actions as per response received.
  • a reliable communication e.g., handle or manage load sharing, in an efficient manner in a wireless communications network.
  • Fig. 1 shows a Reference diagram for IAB-architectures (TR 38.874)
  • Fig. 2 shows protocol stacks according to prior art
  • Fig. 3 shows protocol stacks according to prior art
  • Fig. 4 shows an example of a functional view of a BAP sublayer according to prior art
  • Fig. 5 shows examples of different possible scenarios for IAB topology adaptation
  • Fig. 6 shows an IAB intra-CU topology adaptation procedure
  • Fig. 7 shows an example of signal flow before IAB-node 3 migration
  • Fig. 8 shows an example of signal flow after IAB-node 3 migration
  • Fig. 9 shows an example of inter-donor load balancing scenario, involving IAB3 and its descendant node IAB4 and the UEs that these two IAB nodes are serving;
  • Fig. 10 shows an overview depicting a wireless communications network according to embodiments herein;
  • Fig. 11 shows an example where IAB Node, IAB3, is migrated to IAB Node 5, IAB5, (Inter CU migration);
  • Fig. 12a shows a flowchart depicting a method performed by a first radio network node according to embodiments herein;
  • Fig. 12b shows a flowchart depicting a method performed by a second radio network node according to embodiments herein;
  • Fig. 13 shows a flowchart depicting an interaction between CUs for migrating a node according to embodiments herein;
  • Fig. 14 shows an overview depicting RLF Type Indication to parent CU according to embodiments herein;
  • Fig. 15 shows an overview depicting a migration according to embodiments herein;
  • Fig. 16 shows a block diagram depicting embodiments of a first radio network node according to embodiments herein;
  • Fig. 17 shows a block diagram depicting embodiments of a second radio network node according to embodiments herein;
  • Fig. 18 schematically illustrates a telecommunication network connected via an intermediate network to a host computer
  • Fig. 19 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection;
  • Figs. 20-23 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment.
  • Embodiments herein relate to wireless communications networks in general.
  • Fig. 10 is a schematic overview depicting a wireless communications network 1.
  • the wireless communications network 1 comprises one or more RANs and one or more CNs.
  • the wireless communications network 1 may use one or a number of different technologies.
  • Embodiments herein relate to recent technology trends that are of particular interest in a New Radio (NR) context, however, embodiments are also applicable in further development of existing wireless communications systems such as e.g. LTE or Wideband Code Division Multiple Access (WCDMA).
  • NR New Radio
  • WCDMA Wideband Code Division Multiple Access
  • a user equipment (UE) 10 such as a mobile station, a wireless device, a non-access point (non-AP) STA, a STA, and/or a wireless terminal, is comprised communicating via e.g. one or more Access Networks (AN), e.g. RAN, to one or more core networks (CN).
  • AN Access Networks
  • CN core networks
  • UE is a non-limiting term which means any terminal, wireless communications terminal, user equipment, Internet of things (NB-loT) device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a small base station capable of communicating using radio communication with a radio network node within an area served by the radio network node.
  • NB-loT Internet of things
  • MTC Machine Type Communication
  • D2D Device to Device
  • the wireless communications network 1 comprises a first radio network node 12 e.g. an IAB node such as an IAB-donor node or an IAB-CU, baseband unit (BBU), an access node, an access controller, a base station, e.g.
  • a radio network node 12 e.g. an IAB node such as an IAB-donor node or an IAB-CU, baseband unit (BBU), an access node, an access controller, a base station, e.g.
  • an IAB node such as an IAB-donor node or an IAB-CU, baseband unit (BBU), an access node, an access controller, a base station, e.g.
  • BBU baseband unit
  • a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wreless Local Area Network (WLAN) access point or an Access Point Station (AP STA), MME, AMF, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a first radio access technology and terminology used.
  • the first radio network node 12 may also be referred to as serving or source node or RAN node. It should be noted that a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.
  • the wireless communications network 1 further comprises a first intermediate radio network node 13 connected in-between the first radio network node 12 and the UE 10.
  • the first intermediate radio network node 13 may be an IAB node such as an IAB-DU e.g. a radio remote unit (RRU), an access node, antenna unit, radio unit of e.g.
  • IAB-DU e.g. a radio remote unit (RRU)
  • RRU radio remote unit
  • antenna unit e.g.
  • a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wireless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a first radio access technology and terminology used.
  • the wireless communications network further comprises a second intermediate radio network node, being an example of a first network node 14 according to embodiments herein, connected in-between the first radio network node 12 and the UE 10.
  • the first network node 14 may be connected to the UE 10 directly and may be an egress/ingress point.
  • the first network node 14 may be an IAB node e.g. a radio remote unit (RRU), an access node, antenna unit, radio unit of e.g.
  • RRU radio remote unit
  • a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wreless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used.
  • a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.
  • the wireless communications network 1 may further comprise a third intermediate radio network node, being an example of a second network node 15, connected to the first network node 14, other network nodes, and/or to served UEs.
  • the second network node 15 may be an IAB node e.g. a radio remote unit (RRU) such as an access node, antenna unit, radio unit of e.g.
  • RRU radio remote unit
  • a radio base station such as a gNodeB (gNB), an evolved Node B (eNB, eNode B), a NodeB, a base transceiver station, a radio remote unit, an Access Point Base Station, a base station router, a Wreless Local Area Network (WLAN) access point or an Access Point Station (AP STA), a transmission arrangement of a radio base station, a stand-alone access point or any other network unit or node capable of communicating with a wireless device within a service area served by the radio network node depending e.g. on a radio access technology and terminology used.
  • a service area may be denoted as cell, beam, beam group or similar to define an area of radio coverage.
  • the wireless communications network 1 may further comprise a second radio network node 16 being a second donor IAB node.
  • Embodiments herein relate to a scenario wherein the first radio network node 12 queries the second radio network node 16 to participate in load sharing and requests one or more resources to support migration of, for example, the second network node 15 served by the first radio network node 12.
  • Load sharing herein meaning migrating one or more network nodes or moving traffic related to the one or more network nodes.
  • the first radio network node 12 for example, being a serving central unit, may determine to initiate a topology adaptation such as determines or detect an occurrence of a congestion at the second network node 15 and may initiate a load balancing procedure between the central units.
  • the first radio network node 12 may select network nodes to query based on prioritizing rules, for example:
  • the first radio network node 12 selects best CU/Cell to Perform Load
  • Fig. 11 shows a scenario wherein the second network node 15 is exemplified as IAB3 and is migrated to IAB5 being an example of the second radio network node 16 (Inter CU migration).
  • Embodiments herein are applicable to both the case when an IAB- MT of top-level node is capable of connecting to only one donor node at a time, as well as for the case where it is capable of connecting to two donor nodes simultaneously.
  • the former case is exemplified in Fig. 11, where the connections of a top-level node IAB3 to the source and target donor are shown by the full and dashed line, respectively.
  • the first radio network node 12 exemplified as Source donor CU_1 in Fig. 11 , queries one or more potential target donors, i.e., CU_2 in Fig. 11 is a potential target donor, about whether the target donor CU_2 can provide a necessary amount of resources.
  • Resource information about necessary resources may be included in the resource information and may comprise one or more of the following: ingress and/or egress, also referred to as downlink and/or uplink, BH RLC throughput requirements, capacity requirements, offloading of traffic requirements, quality of service (QoS) Requirements, Packet Delay Budget requirements, a potential candidate cell list where a congested IAB node can be migrated.
  • the second radio network node 16 exemplified as the potential target donor CU_2 considers the query and reply affirmatively or negatively. In case of negative reply, the target donor CU_2 may indicate one or more resources, also referred to an amount of resources, that it is able to support.
  • the potential target donor CU_2 may indicate a time duration for which the CU_2 is able to commit to the resources for offloading. iii. Based on the response, or request and response, the source donor CU_1 may select the best target donor. For example, select CU indicating most available resources.
  • Embodiments herein may further describe enhancements of Xn signalling that may be needed to achieve this.
  • Embodiments herein may ensure that traffic offloading or migration to another donor is successful, by enabling the source donor such as the first radio network node 12 to offload and/or migrate only to a donor node for which it knows in advance that it has enough resources to accept the offloaded traffic. Furthermore, embodiments herein may enable the source donor CU_1 to send a request and receive confirmation from multiple new parent candidate IAB nodes, such as a plurality of second radio network nodes, resulting in a better decision. Embodiments herein may further enable the source donor CU_1 to realize that intra-donor offloading, i.e. , finding a new parent node for the top-level node, whereas this new parent node is under the same donor, may be more reasonable than inter-donor migration.
  • intra-donor offloading i.e. , finding a new parent node for the top-level node, whereas this new parent node is under the same donor, may be more reasonable than inter-donor migration.
  • gNB-CU and “Donor-CU”, and “CU” are used interchangeably.
  • gNB applies to all variants therein, e.g. “gNB”, “en-gNB” etc.
  • IAB donor refers to a gNB that provides network access to UEs via a network of backhaul and access links.
  • intermediate IAB node refers to an IAB node with one or more ingress BH RLC channels and one or more egress BH RLC channels
  • IAB Access node refers to an IAB node that provides an access link to UEs for a certain BAP PDU.
  • IAB node refers to any of “IAB donor”, “Intermediate IAB node”, “IAB Access node”.
  • dispatchant node may refer to both the child node and the child of the child and so on.
  • Donor DIM source donor DU
  • old donor DU old donor DU
  • Donor DU_2 target donor DU
  • new donor DU new donor DU
  • Embodiments herein apply to both the proxy-based alternative and the full migration-based alternative, described above.
  • the terms “migrating IAB node” and “top-level IAB node” are used interchangeably, and they may refer to: 1) in case of proxy-based alternative described above, to the IAB-MT of this node (e.g. IAB3-MT in Fig. 11), because the collocated IAB-DU of the top-level node may not migrate (it maintains the F1 connection to the source donor); 2) in case of full migration-based alternative, they may refer to the entire IAB node.
  • such top-level IAB node may be an IAB, where the traffic carried to/from/via this node (or part of this traffic) is taken over by (i.e. proxied) a target donor (load balancing), i.e. the source donor off-loads the traffic pertaining to certain ingress/egress BH RLC channels between said IAB node and its parent node to the target donor.
  • a target donor load balancing
  • the term “migration” is unambiguously used to represent the scenario in which a top-level/migrating IAB-MT is subject to a migration to the target donor, or the scenario in which the ingress/egress traffic (or a portion of it) of the top- level/migrating IAB node is off-loaded by the source donor to the target donor (load balancing).
  • the migration may be executed as a consequence of a handover to the target donor.
  • the top-level IAB-MT may maintain connectivity with both source and target donor, i.e., a dual protocol stack (DAPS) or dual connectivity (DC) is configured at the top-level IAB-MT to maintain both connections.
  • DAPS dual protocol stack
  • DC dual connectivity
  • Top-level IAB node consists of top-level IAB-MT and its collocated IAB-DU, sometimes referred to as the “collocated DU” or the “top-level DU”.
  • the top-level IAB-MT may migrate to target donor or establish dual connectivity to both source and target donor, while its collocated IAB-DU always maintains its F1 connection with the source donor.
  • RRC/F1 connections of descendant devices refers to the RRC connections of descendant IAB-MTs and UEs with the donor (source donor in this case), and the F1 connections of the top-level IAB-DU and IAB-DUs of descendant IAB nodes of the top-level IAB node.
  • top-level node refers to the node in its entirety, unless specifically stated to which of its parts it is referred to (top-level IAB-DU or top- level IAB-MT).
  • Traffic between the CU_1 and the top-level IAB node and/or its descendant nodes refers to the traffic between the CU_1 and:
  • Embodiments herein are applicable regardless of whether the CU has an integrated security gateway, or these are two different entities.
  • IP security IPsec
  • transport mode IP security
  • the assumption is that direct routing between CU_1 and Donor DU_2 is applied, i.e., CU_1 - Donor DU_2 - and so on...., rather than the indirect routing case, where the traffic goes first to CU_2, i.e. CU_1 - CU_2 - Donor DU_2 - and so on....
  • the direct routing can e.g. be supported via IP routing between, source donor, CU_1 and donor DU2, target donor DU, or via an Xn connection between the two.
  • indirect routing data can be sent between CU_1 and CU_2 via Xn interface, and between CU_2 and Donor DU_2 via F1 or via IP routing. Both direct and indirect routing are applicable in embodiments herein.
  • the advantage of direct routing is that the latency is likely smaller.
  • both user plane (UP) and control plane (CP) traffic are sent by means of direct and indirect routing.
  • the term “destination is IAB-DU”, comprises both the traffic whose final destination is either said IAB-DU or a UE or IAB-MT served by said IAB-DU, and that includes top-level IAB-DU as well.
  • data refers to both user plane, control plane traffic and non-F1 traffic.
  • top-level IAB-MT is served by two gNBs, out of which one is an IAB donor and the other one is a legacy gNB, whereas either of the two serving nodes can be a master or a secondary node for the IAB-MT of the top-level node.
  • the method actions performed by the first radio network node 12, such as a first donor node or a first donor CU, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 12a.
  • the actions do not have to be taken in the order stated below, but may be taken in any suitable order.
  • Dashed boxes indicate optional features.
  • the first radio network node 12 may trigger an initiation of an adaption of a topology of network nodes and/or UEs in the wireless communications network for performing the load sharing.
  • the first radio network node 12 may trigger the initiation by determining an occurrence of a congestion in communication associated with the first radio network node 12, such as detecting a congestion at the second network node 15 being served by the first radio network node 12.
  • the adaption of the topology of network nodes and/or UEs is for load sharing and may be triggered by radio link failure (RLF), load balancing/congestion, mobility, etc..
  • RLF radio link failure
  • the first radio network node 12 may then identify one or more second radio network nodes 16 for querying to perform load sharing with based on one or more measurement results, previous history of statistics for successful migration, or an operation, administration, and maintenance, OAM, configuration.
  • the one or more second radio network nodes 16 may also referred to as potential radio network nodes for performing load sharing with.
  • the first radio network node 12 queries the one or more second radio network nodes 16 whether the respective second radio network node 16 comprises or has one or more resources to perform load sharing with.
  • Load sharing is for topology adaptation in IAB networks that may be needed for various reasons, e.g., changes in the radio conditions, changes to the load under the serving CU, radio link failures, etc.
  • the consequence of an IAB topology adaptation could be that an IAB node is migrated, i.e., handed over, to a new parent, which can be controlled by the same or different CU, or that some traffic currently served by such IAB node is offloaded via a new route, which can be controlled by the same or different CU.
  • the first radio network node 12 may thus request a potential radio network node whether the potential radio network node has the necessary amount of resources.
  • the first radio network node 12 may, for example, transmit resource information, to the one or more second radio network nodes 16, for example, requesting necessary resources for load sharing.
  • the transmitted resource information may comprise one or more of the following: downlink and/or uplink throughput requirements of an ingress and/or egress BH RLC channels that should be migrated; capacity requirements of the ingress and/or egress BH RLC channels that should be migrated; quality of service requirements of the ingress and/or egress BH RLC channels that should be migrated; Packet Delay Budget requirements of the ingress and/or egress BH RLC channels that should be migrated; a potential candidate cell list where a congested IAB node can be migrated, and/or a time duration for providing the one or more resources.
  • the requested resources may be to serve an IAB node and its descendant nodes, e.g., for handling RLF of this IAB node, or load balancing of traffic passing through this IAB node.
  • the requested resources may be to serve an IAB node and its descendant nodes, e.g., for handling RLF of this IAB node, or load balancing of traffic passing through this IAB node.
  • all the channels are migrated, but in case of load balancing only some of the channels may be migrated.
  • the first radio network node 12 may just indicate to the second radio network node 16 the requirements of those BH RLC channels that need to be migrated.
  • the first radio network node 12 receives a response from at least one second radio network node 16 indicating confirmation or rejection of load sharing.
  • the response indicating confirmation or rejection may comprise an indication of one or more resources that the at least one second radio network node 16 is able to support or may be a response indicating rejection of the load sharing.
  • the second radio network node may indicate a time duration for which the at least one second radio network node 16 is able to commit to the one or more resources for offloading.
  • the first radio network node 12 then performs an action based on the response, for example, initiate offloading of the second network node 15 based on the response.
  • the first radio network node 12 may, based on the received response, select the at least one second radio network node 16 or another radio network node to perform load sharing with.
  • the first radio network node 12 may select any other radio network node or one that it has sent the query to.
  • the first radio network node 12 may initiate an offloading by requesting another radio network node to perform load sharing with, or re querying the at least one second radio network node 16 with an updated query or request.
  • Embodiments herein further describe enhancements of Xn signalling that may be needed to achieve this.
  • the method actions performed by the second radio network node 16, such as an IAB donor node or a donor CU node, for handling communication in the wireless communications network 1 according to embodiments herein will now be described with reference to a flowchart depicted in Fig. 12b.
  • the actions do not have to be taken in the order stated below, but may be taken in any suitable order.
  • Dashed boxes indicate optional features.
  • the second radio network node 16 receives the query or a request from the first radio network node 12 whether the second radio network node 16 comprises one or more, also referred to as an amount of, resources available to perform load sharing with the first radio network node 12. For example, requesting resources available for supporting migrating UEs/network nodes.
  • the query or request may for example comprise the resource information for load sharing, such as resource information about necessary resources for load sharing.
  • the information may comprise one or more of the following: downlink and/or uplink throughput requirements of the ingress and/or egress BH RLC channels that should be migrated; capacity requirements of the ingress and/or egress BH RLC channels that should be migrated; quality of service requirements of the ingress and/or egress BH RLC channels that should be migrated; Packet Delay Budget requirements of the ingress and/or egress BH RLC channels that should be migrated; the potential candidate cell list where the congested IAB node can be migrated, and/or the time duration for providing the one or more resources.
  • the second radio network node 16 determines one or more available resources for supporting one or more UEs and/or network nodes taking the query into account. For example, the second radio network node may determine whether it comprises enough available resources to participate in the load sharing with the first radio network node 12. The second network node 16 may determine amount of resources available for supporting UEs/network nodes taking the query or request into account. The second radio network node 16 may determine whether the second radio network node has an IAB node, i.e. , serving an IAB node, which has capacity to be a new parent of a migrating IAB node, for example, associated with the first radio network node 12.
  • IAB node i.e. , serving an IAB node, which has capacity to be a new parent of a migrating IAB node, for example, associated with the first radio network node 12.
  • the second radio network node 16 may determine whether the second radio network node 16 has the IAB node based on the received query and current traffic volume in one or more potential target cells or current traffic handled by one or more target IAB nodes of the second radio network node 16. Thus, the second radio network node 16 may determine whether it has an IAB node which has capacity to be a new parent of a migrating top-level IAB node based upon source CU signalling information. The decision may be based upon capacity request, time duration and current traffic volume in the potential target cells or target IAB nodes.
  • the second radio network node 16 then transmits the response to the first radio network node 12 confirming or rejecting said request taking the determination of the one or more available resources into account.
  • the response confirming or rejecting said query may comprises the indication of one or more resources that the second radio network node 16 is able to support.
  • the second radio network node 16 may indicate the amount of resources that it is able to support.
  • the second radio network node 16 may indicate the time duration for which it is able to commit to the resources for offloading.
  • the response may indicate the time duration for which the second radio network node is able to commit to the one or more resources for offloading.
  • a donor CU such as the first radio network node 12, herein referred to as the serving CU, source CU or old CU, may identify that a link between an IAB Node such as the second network node 15 and its parent node such as the first network node 14, both of whom the CU serves, is congested, action 1201. For example, throughput between the nodes is below a threshold for a set duration of time. If so, the donor CU realizes the need to migrate said IAB node and its descendant devices or offload their traffic to another donor, e.g., load balance.
  • the donor CU may ask IAB Node such as the second network node 15, and/or the first network node 14 to perform measurement for load balancing purposes such as potential migration, load balancing etc.
  • IAB Node such as the second network node 15, and/or the first network node 14 to perform measurement for load balancing purposes such as potential migration, load balancing etc.
  • the potential target cells for the migration can be indicated in e.g., the neighbor relation table in the donor node and/or the donor CU or configured to the IAB node/donor CU via operation, administration and maintenance (OAM).
  • OAM operation, administration and maintenance
  • the donor CU identifies the CU(s) and identities (ID) of the cells to which said congested IAB Node can be migrated based upon the measurement result, above a certain reference signal received power (RSRP) threshold for instance, or based upon previous history of statistics for successful migration or OAM configuration(s).
  • RSRP reference signal received power
  • the first radio network node 12 queries one or more potential target donors about whether the potential target donor may provide the necessary amount of resources.
  • the resource information about necessary resources may include the resource information exemplified above.
  • the second radio network node 16 may reply affirmatively or negatively. In case of negative reply, the second radio network node 16 may indicate the amount of resources that it is able to support. For both types of replies, potential target donors may indicate the time duration for which they are able to commit to the resources for offloading.
  • the first radio network node 12 may select the best potential target donor and triggers topology adaptation.
  • Serving i.e. , source, CU, such as the first radio network node 12
  • CU such as the first radio network node 12
  • Xn message may contain the resource information about the resource requirements for load balancing.
  • the resource information may include:
  • An implicit/explicit indication of a purpose e.g. indication whether the load sharing request is because of potential radio link failure (RLF) issues or load balancing and may further indicate one or more reasons for load balancing such as cannot meet delay requirements or capacity requirements.
  • RLF radio link failure
  • the Rel163GPP specifications define Control Plane Traffic Types for indicating the priority of the BH RLC channel in question.
  • the value 1 corresponds to the highest priority.
  • the source CU may indicate to the potential target CU the number of control plane BH RLC channels for each priority, i.e., the Control Plane Traffic type.
  • RSRP/reference signal received quality • Potential Target cell IDs based upon configuration by OAM for load balancing purpose or based upon ranking from the measured radio measurement results, RSRP/reference signal received quality (RSRQ).
  • the source CU uses the above parameters to indicate an estimate of resources necessary for offloading, rather than the amount of resources that are currently being used and are subject to offloading.
  • the second radio network node 16 may consider the query received and may reply with the Xn message, either:
  • the second radio network node 16 may also indicate for how long it will be able to provide the resources requested.
  • the second radio network node 16 may indicate that it is not able to provide the resources, by sending an NACK type of message; the first radio network node 12 may try to identify the reason and may try with another candidate or perform reconfiguration, such as release low QoS traffic group.
  • the second radio network node 16 may provide a cause value, indicating the reason for not being able to provide the resources, e.g., “too much resources requested”, “resources requested for too long” etc..
  • the first radio network node 12 may identify another potential target CU based on the replies received from other CUs, and, if applicable, triggers the migration procedure.
  • a new XnAP Migration Request Message, polling message to check if target has the resource to support migration/load balancing, can be specified for this purpose or existing XnAP Handover message can be reused.
  • target CU When existing handover (HO) message is reused with the specific Migration Request Message then target CU should not consider this assuming HO has been triggered but should be considered as polling/probing message to understand if target CU has any cell/IAB Node which can be parent of this congested IAB node, which requires migration.
  • HO handover
  • the requirements can be indicated by source CU either via below or combination as shown in the example tabular format • Aggregated traffic capacity, delay requirements
  • the throughput requirements, capacity requirements for offloading or load balancing, may also be expressed with respect to bit rate IE existing in F1AP protocol as below TS 38.473.
  • Bit Rate IE existing in F1AP protocol
  • This IE indicates the number of bits delivered by NG-RAN in UL or to NG-RAN in DL within a period of time, divided by the duration of the period. It is used, for example, to indicate the maximum or guaranteed bit rate for a GBR QoS flow, or an aggregated maximum bit rate.
  • the below table can be part of a new XnAP message; example IAB Migration Information Acknowledge or can be accommodated as part of Handover Request Acknowledge.
  • the example below shows positive acknowledgement when target has accepted the request and in the acknowledgement it provides the target Cell ID where the IAB node should connect to for load balancing purpose and needed IP address allocations where by source CU can reach to the IAB node for F1AP connections; for example.
  • source CU It is up to source CU to request sequentially or to multiple CUs in parallel. It can also indicate that in it’s polling/request message. In such case the target CU may simply respond ACK/NACK without any details such as cell ID or IP address. In such case, if source CU happens to get positive response from multiple CUs then it would select the best in terms of IAB MT’s measurement result (RSRP/RSRQ).
  • the migration or handover procedure (handover request) would be triggered and the target CU then replies with detailed information with regards to cell ID and other resource or IP termination related information.
  • CU1 Failure handling, negative-acknowledgement (NACK) response, see Fig. 13.
  • the request made by CU1, action 1301 may not be accepted by CU2.
  • the potential target donor node e.g., CU2 provides the cause code, action 1302.
  • the cause code For example, whether the failure is because the CU2 did not find any candidate cell (parent IAB node) because the requested traffic load was high, the requested time duration for migration was high, the packet delay budget requirement could not be met etc.
  • the CU1 may take some action and may retry, see actions 1303 and 1304.
  • Fig. 13 shows Interaction between CUs for Migrating a Node.
  • the cause code (reason) for rejection can be insufficient capacity, i.e. , “not enough capacity available”, or “resources requested for too long”; the source CU 1 may release some of the low QoS traffic and attempt again.
  • the measurement object can be configured such that UE reports RSRP above certain threshold level or an indication can be sent to the UE that this is for the purpose of load balancing.
  • IAB Node MT
  • the measurement object can be configured such that UE reports RSRP above certain threshold level or an indication can be sent to the UE that this is for the purpose of load balancing.
  • MeasObjectNR :: SEQUENCE ⁇ ssbFrequency ARFCN-ValueNR
  • OPTIONAL - Need R nrofSS-BlocksToAverage INTEGER (2..maxNrofSS-BlocksToAverage) OPTIONAL, - Need R nrofCSI-RS-ResourcesToAverage INTEGER (2..maxNrofCSI-RS-
  • RangeElement OPTIONAL -- Need N whiteCellsToRemoveList PCI-RangelndexList
  • OPTIONAL, - Need R measCycleSCell ENUMERATED ⁇ sf160, sf256, sf320, sf512, sf640, sf1024, sf1280 ⁇ OPTIONAL - Need R
  • ASN Abstract Syntax Notation
  • the above explained IE would also be applicable for the case of dual connectivity of the top-level IAB-MT.
  • the IAB node instead of migrating an IAB node such as the second network node 15, the IAB node would have dual connectivity which would allow certain percentage of traffic to be offloaded to the other leg i.e. to the second radio network node 16.
  • the source CU will identify potential target CU where dual connectivity can be set up or is already configured with and request with such message.
  • either the new XnAP message for load balancing (migration) request can be defined or the message applicable for dual connectivity S-NODE ADDITION REQUEST can be used, with the purpose of establishing the dual connectivity which the top-level node can use for load balancing.
  • the S-NODE MODIFICATION REQUEST and S- NODE MODIFICATION REQUEST ACKNOWLEDGE can be used.
  • the tabular format as shown above can be reused here.
  • RLF detected parent node
  • CHO Conditional Handover
  • the type2 notification or the existing type 4 notification (parent has suffered RLF and can’t recover) would be instead be sent to the CU such as the first radio network node 12.
  • the CU would then start the load balancing or migration.
  • the trigger that would be used to inquire the target about the available resources would be “type 2 RLF” or “type 4 RLF”.
  • the link between IAB Donor and IAB node 1 suffers from RLF; in such case IAB Node 1 notifies CU1 that it has suffered from RLF and in that case the CU1 may initiate migration of either IAB node 1 or any of the child IAB nodes to the IAB node 1.
  • the IAB node migration may follow certain prioritizing rule(s) such that for load balancing the source CU, i.e. the first radio network node 12 may aim to retain the IAB node within the same donor DU. However, if the donor DU is also congested then a different DU under the same CU should be tried. Then in case that is not possible, an inter CU migration process according to embodiments herein may be performed. This is primarily to reduce the signalling overhead and to solve the problem by local means before going for other option such as Inter-CU migration.
  • these rules may be overwritten by another network node such as an OAM or provided by OAM as what steps should a CU take. Further, the first radio network node 12 may learn from previous migration and record those to be used for future purpose.
  • the method may comprise sending a signal from source CU to target CUs, such as CU A and CU C comprising an Information Element or a multitude thereof, which IE specifies the capacity requirements for the target CU taking over the traffic traversing and/or terminating at the migrating top-level IAB node.
  • the indication of required capacity may contain for example: • Data volume, throughput, percentage of traffic that requires offload, QoS requirements for the migrating IAB node, total PDB requirements, number and priority of BH RLC channels carrying control plane traffic etc.
  • the above capacity requirement refers to the traffic that is offloaded from the top-level AIB-MTs leg towards source donor to the leg towards the target donor.
  • the signal from source CU to target CU may comprise an Information Element which specifies the desired time duration until the migration or offloading and making decisions based upon that.
  • the method comprising sending the signal from source CU to target CU may comprise an Information Element which specifies the list of ranked cell IDs of target CU based upon preference from source CU.
  • the preference/ranking can be done based upon statistics of previous successful migration or measurement results or OAM configurations.
  • Embodiments herein may also disclose a method performed by the target CU i.e. the second radio network node 16 to determine whether it has an IAB node, i.e. serving an IAB node, which has capacity to be the new parent of the migrating top-level IAB node based upon source CU signalling information. The decision may be based upon capacity request, time duration and current traffic volume in the potential target cells or target IAB nodes.
  • the target CU may send acknowledgment (ACK) that it can accept the congested node in its network by providing, e.g., the target Cell ID.
  • ACK acknowledgment
  • the second radio network node 16 may for example optimize signalling for providing the IP addresses depending upon the flag whether the IP addresses can be same or different.
  • Source CU It is furthermore herein disclosed a method performed by Source CU to prioritize which migration to initiate based upon previous successful attempt or received indication from OAM.
  • a method herein is further performed by an IAB MT node such as the second network node to perform measurements for identifying best target cell or parent node for the load balancing purpose.
  • the first radio network node 12 may configure measurements to be performed by the IAB node for identifying best target cell or parent node for the load balancing purpose.
  • Fig. 16 is a block diagram depicting the first radio network node 12 such as a first donor node or a first donor central unit for handling communication in a wireless communications network 1 according to embodiments herein.
  • the first radio network node 12 may comprise processing circuitry 2001, e.g. one or more processors, configured to perform the methods herein.
  • the first radio network node 12 may comprise a querying unit 2002, e.g. a transmitter or a transceiver.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 is configured to query the one or more second radio network nodes 16 whether respective second radio network node 16 comprises one or more resources to perform load sharing with.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to query a potential radio network node whether the potential radio network node have the necessary amount of resources.
  • the first radio network node 12 may for example transmit information about necessary resources for load sharing.
  • the information may comprise one or more of the following: downlink and/or uplink throughput requirements of the ingress and/or egress BH RLC channels that should be migrated; capacity requirements of the ingress and/or egress BH RLC channels that should be migrated; quality of service requirements of the ingress and/or egress BH RLC channels that should be migrated; Packet Delay Budget requirements of the ingress and/or egress BH RLC channels that should be migrated; the potential candidate cell list where the congested IAB node can be migrated.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to initiate a topology of network nodes/UEs adaptation. E.g.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to identify the one or more second radio network nodes for querying to perform load sharing with based on one or more measurement results, previous history of statistics for successful migration, or an OAM configuration.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to query the one or more second radio network nodes 16 by transmitting, to the one or more second radio network nodes 16, resource information for load sharing.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to trigger the initiation of the adaption of the topology of network nodes and/or UEs in the wireless communications network for performing the load sharing.
  • the first radio network node 12, the processing circuitry 2001, and/or the querying unit 2002 may be configured to trigger the initiation of the adaption by determining the occurrence of the congestion in communication associated with the first radio network node 12.
  • the first radio network node 12 may comprise a receiving unit 2003, e.g. a receiver or a transceiver.
  • the first radio network node 12, the processing circuitry 2001, and/or the receiving unit 2003 is configured to receive the response from at least one second radio network node 16 indicating confirmation or rejection of load sharing, for example, receive response from the potential radio network node such as the second radio network node 16.
  • the response may comprise amount of resources that the second radio network node 16 is able to support or may be a response indicating rejection of load sharing.
  • the potential radio network node may indicate the time duration for which it is able to commit to the resources for offloading.
  • the transmitted resource information may comprise one or more of the following: downlink and/or uplink BH RLC throughput requirements; capacity requirements; quality of service requirements; Packet Delay Budget requirements; a potential candidate cell list where a congested IAB node can be migrated, and/or a time duration for providing the one or more resources.
  • the response may thus indicate confirmation or rejection and may comprises the indication of the one or more resources that the at least one second radio network node 16 is able to support.
  • the response may further indicate the time duration for which the at least one second radio network node 16 is able to commit to the one or more resources for offloading.
  • the first radio network node 12 may comprise a handling unit 2004.
  • the first radio network node 12, the processing circuitry 2001, and/or the handling unit 2004 is configured to perform the action based on the response, e.g., operate based on the response. The action may be performed also based on the query sent.
  • the first radio network node 12, the processing circuitry 2001, and/or the handling unit 2004 may be configured to perform the action by selecting, based on the received response, the at least one second radio network node 16 or another radio network node to perform load sharing with.
  • the first radio network node 12, the processing circuitry 2001, and/or the handling unit 2004 may be configured to perform the action by initiating an offloading comprising requesting another radio network node to perform load sharing with or re querying the at least one second radio network node 16 with an updated query or request.
  • the first radio network node 12, the processing circuitry 2001, and/or the handling unit 2004 may be configured to identify a potential radio network node for load sharing with e.g. based on the response, select the potential radio network node or another radio network node to perform load sharing with.
  • the first radio network node 12 further comprises a memory 2005.
  • the memory 2005 comprises one or more units to be used to store data on, such as indications, headers, destination address, signal measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar.
  • the first network node 14 may comprise a communication interface 2006 such as comprising a transmitter, a receiver and/or a transceiver, and/or one or more antennas.
  • the methods according to the embodiments described herein for the first radio network node 12 are respectively implemented by means of e.g. a computer program product 2007 or a computer program, comprising instructions, i.e. , software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first radio network node 12.
  • the computer program product 2007 may be stored on a computer- readable storage medium 2008, e.g. a disc, a universal serial bus (USB) stick or similar.
  • the computer-readable storage medium 2008, having stored thereon the computer program product may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first radio network node 12.
  • the computer- readable storage medium may be a transitory or a non-transitory computer-readable storage medium.
  • embodiments herein may disclose a first radio network node 12 for handling communication in a wireless communications network, wherein the first radio network node 12 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said first radio network node 12 is operative to perform any of the methods herein.
  • Fig. 17 is a block diagram depicting the second radio network node 16 such as a IAB donor node or donor CU, for handling communication in a wireless communications network 1 according to embodiments herein.
  • the second radio network node 16 may comprise processing circuitry 2101, e.g. one or more processors, configured to perform the methods herein.
  • processing circuitry 2101 e.g. one or more processors, configured to perform the methods herein.
  • the second radio network node 16 may comprise a receiving unit 2102, e.g. a receiver or a transceiver.
  • the second radio network node 16, the processing circuitry 2101 , and/or the receiving unit 2102 is configured to receive the query from the first radio network node 12 whether the second radio network node 16 comprises one or more resources available to perform load sharing with the first radio network node 12.
  • the 2102 may be configured to receive from the first radio network node 12 the query or request whether the second radio network node 16 has an amount of resources for supporting UEs/network nodes.
  • the query may comprise resource information for load sharing.
  • the resource information may comprise one or more of the following: downlink and/or uplink throughput requirements of the ingress and/or egress BH RLC channels that should be migrated; capacity requirements of the ingress and/or egress BH RLC channels that should be migrated; quality of service requirements of the ingress and/or egress BH RLC channels that should be migrated; Packet Delay Budget requirements of the ingress and/or egress BH RLC channels that should be migrated; the potential candidate cell list where the congested IAB node can be migrated, and/or a time duration for providing the one or more resources.
  • the query or request may for example comprise the information about necessary resources for load sharing.
  • the information may comprise: ingress/egress (downlink/uplink) BH RLC Throughput requirements; capacity requirements; offloading of traffic requirements; QoS Requirements; Packet Delay Budget requirements; the potential candidate cell list where the congested IAB node can be migrated.
  • the second radio network node 16 may comprise a determining unit 2103.
  • the second radio network node 16, the processing circuitry 2101, and/or the determining unit 2103 may be configured to determine amount of resources available for supporting UEs/network nodes taking the query or request into account.
  • the second radio network node 16, the processing circuitry 2101 , and/or the determining unit 2103 may be configured to determine whether the second radio network node has the IAB node which has capacity to be a new parent of a migrating IAB node or traffic relating to the migrating IAB node.
  • Determining whether the second radio network node has the IAB node may be based on the received query and current traffic volume in one or more potential target cells or current traffic handled by one or more target IAB nodes of the second radio network node 16.
  • the second radio network node 16, the processing circuitry 2101, and/or the determining unit 2103 may be configured to determine whether it has an IAB node which has capacity to be a new parent of a migrating top-level IAB node based upon source CU signalling information. The decision may be based upon the request and time duration and current traffic volume in the potential target cells or target IAB nodes.
  • the second radio network node 16 may comprise a transmitting unit 2104, e.g. a transmitter or a transceiver.
  • the second radio network node 16, the processing circuitry 2101, and/or the transmitting unit 2104 is configured to transmit the response to the first radio network node 12 confirming or rejecting said query taking the determination of the one or more available resources into account.
  • the second radio network node 16, the processing circuitry 2101, and/or the transmitting unit 2104 may be configured transmit the response to the first radio network node confirming or rejecting said request.
  • the second radio network node 16 may indicate the amount of resources that it is able to support.
  • the second radio network node 16, the processing circuitry 2101, and/or the transmitting unit 2104 may be configured to indicate the time duration for which it is able to commit to the resources for offloading.
  • the response confirming or rejecting said query may comprises an indication of one or more resources that the second radio network node 16 is able to support.
  • the response may indicate a time duration for which the second radio network node is able to commit to the one or more resources for offloading.
  • the second radio network node 16 further comprises a memory 2105.
  • the memory 2105 comprises one or more units to be used to store data on, such as indications, contexts, available resources, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar.
  • the second radio network node 16 may comprise a communication interface 2108 such as comprising a transmitter, a receiver and/or a transceiver, and/or one or more antennas.
  • the methods according to the embodiments described herein for the second radio network node 16 are respectively implemented by means of e.g. a computer program product 2106 or a computer program, comprising instructions, i.e. , software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second radio network node 16.
  • the computer program product 2106 may be stored on a computer- readable storage medium 2107, e.g. a disc, a universal serial bus (USB) stick or similar.
  • the computer-readable storage medium 2107, having stored thereon the computer program product may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second radio network node 16.
  • the computer- readable storage medium may be a transitory or a non-transitory computer-readable storage medium.
  • embodiments herein may disclose a second radio network node 16 for handling communication in a wireless communications network, wherein the second radio network node 16 comprises processing circuitry and a memory, said memory comprising instructions executable by said processing circuitry whereby said second radio network node 16 is operative to perform any of the methods herein.
  • radio network node can correspond to any type of radio-network node or any network node, which communicates with a wireless device and/or with another network node.
  • network nodes are NodeB, MeNB, SeNB, a network node belonging to Master cell group (MCG) or Secondary cell group (SCG), base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, network controller, radio-network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), access point (AP), transmission points, transmission nodes, Remote radio Unit (RRU), Remote Radio Head (RRH), nodes in distributed antenna system (DAS), etc.
  • MCG Master cell group
  • SCG Secondary cell group
  • MSR multi-standard radio
  • wireless device or user equipment refers to any type of wireless device communicating with a network node and/or with another wireless device in a cellular or mobile communication system.
  • UE user equipment
  • loT capable device target device, device to device (D2D) UE, proximity capable UE (aka ProSe UE), machine type UE or UE capable of machine to machine (M2M) communication, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), USB dongles etc.
  • Embodiments are applicable to any RAT or multi-RAT systems, where the wireless device receives and/or transmit signals (e.g. data) e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.
  • signals e.g. New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.
  • ASIC application-specific integrated circuit
  • processors or “controller” as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware and/or program or application data. Other hardware, conventional and/or custom, may also be included. Designers of communications devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.
  • DSP digital signal processor
  • a communication system includes telecommunication network 3210, such as a 3GPP-type cellular network, which comprises access network 3211, such as a radio access network, and core network 3214.
  • Access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points being examples of the radio network node 12 above, each defining a corresponding coverage area 3213a, 3213b, 3213c.
  • Each base station 3212a, 3212b, 3212c is connectable to core network 3214 over a wired or wireless connection 3215.
  • a first UE 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c.
  • a second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291, 3292 are illustrated in this example being examples of the wireless device 10 above, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.
  • Telecommunication network 3210 is itself connected to host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud- implemented server, a distributed server or as processing resources in a server farm.
  • Host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 3221 and 3222 between telecommunication network 3210 and host computer 3230 may extend directly from core network 3214 to host computer 3230 or may go via an optional intermediate network 3220.
  • Intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; intermediate network 3220, if any, may be a backbone network or the Internet; in particular, intermediate network 3220 may comprise two or more sub-networks (not shown).
  • the communication system of Figure 18 as a whole enables connectivity between the connected UEs 3291, 3292 and host computer 3230.
  • the connectivity may be described as an over-the-top (OTT) connection 3250.
  • Host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signalling via OTT connection 3250, using access network 3211, core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries.
  • OTT connection 3250 may be transparent in the sense that the participating communication devices through which OTT connection 3250 passes are unaware of routing of uplink and downlink communications.
  • base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.
  • Fig. 19 shows a host computer communicating via a base station and with a user equipment over a partially wireless connection in accordance with some embodiments
  • host computer 3310 comprises hardware 3315 including communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of communication system 3300.
  • Host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities.
  • processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • Host computer 3310 further comprises software 3311, which is stored in or accessible by host computer 3310 and executable by processing circuitry 3318.
  • Software 3311 includes host application 3312.
  • Host application 3312 may be operable to provide a service to a remote user, such as UE 3330 connecting via OTT connection 3350 terminating at UE 3330 and host computer 3310. In providing the service to the remote user, host application 3312 may provide user data which is transmitted using OTT connection 3350.
  • Communication system 3300 further includes base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with host computer 3310 and with UE 3330.
  • Hardware 3325 may include communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of communication system 3300, as well as radio interface 3327 for setting up and maintaining at least wireless connection 3370 with UE 3330 located in a coverage area (not shown in Fig. 19) served by base station 3320.
  • Communication interface 3326 may be configured to facilitate connection 3360 to host computer 3310. Connection 3360 may be direct or it may pass through a core network (not shown in Fig 19) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system.
  • hardware 3325 of base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • Base station 3320 further has software 3321 stored internally or accessible via an external connection.
  • Communication system 3300 further includes UE 3330 already referred to. It’s hardware 3333 may include radio interface 3337 configured to set up and maintain wireless connection 3370 with a base station serving a coverage area in which UE 3330 is currently located. Hardware 3333 of UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. UE 3330 further comprises software 3331, which is stored in or accessible by UE 3330 and executable by processing circuitry 3338.
  • Software 3331 includes client application 3332.
  • Client application 3332 may be operable to provide a service to a human or non-human user via UE 3330, with the support of host computer 3310.
  • an executing host application 3312 may communicate with the executing client application 3332 via OTT connection 3350 terminating at UE 3330 and host computer 3310.
  • client application 3332 may receive request data from host application 3312 and provide user data in response to the request data.
  • OTT connection 3350 may transfer both the request data and the user data.
  • Client application 3332 may interact with the user to generate the user data that it provides. It is noted that host computer 3310, base station 3320 and UE 3330 illustrated in Fig.
  • Fig. 19 may be similar or identical to host computer 3230, one of base stations 3212a, 3212b, 3212c and one of UEs 3291, 3292 of Fig. 18, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 19 and independently, the surrounding network topology may be that of Fig. 18.
  • OTT connection 3350 has been drawn abstractly to illustrate the communication between host computer 3310 and UE 3330 via base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices.
  • Network infrastructure may determine the routing, which it may be configured to hide from UE 3330 or from the service provider operating host computer
  • OTT connection 3350 While OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).
  • Wireless connection 3370 between UE 3330 and base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure.
  • One or more of the various embodiments improve the performance of OTT services provided to UE 3330 using OTT connection 3350, in which wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments make it possible for handling or managing handover of IAB nodes when performing topology adaptation resulting in a reduced delay of packet transmissions and a quick responsiveness.
  • a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve.
  • the measurement procedure and/or the network functionality for reconfiguring OTT connection 3350 may be implemented in software 3311 and hardware 3315 of host computer 3310 or in software 3331 and hardware 3333 of UE 3330, or both.
  • sensors (not shown) may be deployed in or in association with communication devices through which OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software
  • the reconfiguring of OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect base station 3320, and itmay be unknown or imperceptible to base station 3320. Such procedures and functionalities may be known and practiced in the art.
  • measurements may involve proprietary UE signalling facilitating host computer 3310’s measurements of throughput, propagation times, latency and the like.
  • the measurements may be implemented in that software 3311 and 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using OTT connection 3350 while it monitors propagation times, errors etc.
  • Fig. 20 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.
  • Fig. 20 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Fig.
  • step 3410 the host computer provides user data.
  • substep 3411 (which may be optional) of step 3410, the host computer provides the user data by executing a host application.
  • step 3420 the host computer initiates a transmission carrying the user data to the UE.
  • step 3430 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure.
  • step 3440 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.
  • Fig. 21 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.
  • Fig. 21 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Fig.
  • the host computer provides user data.
  • the host computer provides the user data by executing a host application.
  • the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure.
  • step 3530 the UE receives the user data carried in the transmission.
  • Fig. 22 shows methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.
  • Fig. 22 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 18 and Fig. 19. For simplicity of the present disclosure, only drawing references to Fig. 22 will be included in this section.
  • step 3610 the UE receives input data provided by the host computer. Additionally or alternatively, in step 3620, the UE provides user data.
  • substep 3621 (which may be optional) of step 3620, the UE provides the user data by executing a client application.
  • substep 3611 (which may be optional) of step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer.
  • the executed client application may further consider user input received from the user.
  • the UE initiates, in substep 3630 (which may be optional), transmission of the user data to the host computer.
  • step 3640 of the method the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.
  • Fig. 23 show methods implemented in a communication system including a host computer, a base station and a user equipment in accordance with some embodiments.
  • Fig. 23 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 18 and Fig. 19. For simplicity of the present disclosure, only drawing references to Fig. 23 will be included in this section.
  • the base station receives user data from the UE.
  • the base station initiates transmission of the received user data to the host computer.
  • step 3730 (which may be optional)
  • the host computer receives the user data carried in the transmission initiated by the base station.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
  • PDCCH A downlink control channel

Abstract

Selon des modes de réalisation, la présente invention concerne, par exemple, un procédé exécuté par un premier nœud de réseau radio (12) pour gérer une communication dans un réseau de communications sans fil. Le premier nœud de réseau radio (12) interroge un ou plusieurs seconds nœuds de réseau radio (16) pour savoir si un second nœud de réseau radio (16) respectif comprend une ou plusieurs ressources avec qui effectuer un partage de charge. Le premier nœud de réseau radio (12) reçoit une réponse d'au moins un second nœud de réseau radio (16) indiquant une confirmation ou un rejet de partage de charge ; et effectue une action sur la base de la réponse.
PCT/SE2022/050354 2021-04-07 2022-04-07 Procédés et nœuds de réseau radio pour la gestion de communication WO2022216215A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22785073.2A EP4320917A1 (fr) 2021-04-07 2022-04-07 Procédés et noeuds de réseau radio pour la gestion de communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163171647P 2021-04-07 2021-04-07
US63/171,647 2021-04-07

Publications (1)

Publication Number Publication Date
WO2022216215A1 true WO2022216215A1 (fr) 2022-10-13

Family

ID=83546615

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2022/050354 WO2022216215A1 (fr) 2021-04-07 2022-04-07 Procédés et nœuds de réseau radio pour la gestion de communication

Country Status (2)

Country Link
EP (1) EP4320917A1 (fr)
WO (1) WO2022216215A1 (fr)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2416605A1 (fr) * 2009-04-23 2012-02-08 Huawei Technologies Co., Ltd. Procédé de partage de charge, dispositif et système associés
US20140211698A1 (en) * 2013-01-28 2014-07-31 Verizon Patent And Licensing Inc. Method and system for application-aware load balancing
US20140378148A1 (en) * 2013-06-25 2014-12-25 Public Wireless, Inc. Systems and methods for optimizing wireless networks
US20160095038A1 (en) * 2014-09-29 2016-03-31 Hitachi, Ltd. Radio communication system, load sharing method, and base station
EP3174327A1 (fr) * 2014-07-25 2017-05-31 Samsung Electronics Co., Ltd. Procédé et appareil de commande de flux adaptatif dans un système de communication sans fil
WO2020063404A1 (fr) * 2018-09-29 2020-04-02 华为技术有限公司 Procédé et dispositif d'équilibrage de charge
WO2020165280A1 (fr) * 2019-02-13 2020-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Échange d'informations de chemin de remplacement pour une meilleure planification et une reprise sur incident de réseau de collecte dans des réseaux d'amenée à accès intégrés
US20200275316A1 (en) * 2017-09-29 2020-08-27 Nokia Solutions And Networks System Technology (Beijing) Co., Ltd. Method and apparatus for load balancing

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2416605A1 (fr) * 2009-04-23 2012-02-08 Huawei Technologies Co., Ltd. Procédé de partage de charge, dispositif et système associés
US20140211698A1 (en) * 2013-01-28 2014-07-31 Verizon Patent And Licensing Inc. Method and system for application-aware load balancing
US20140378148A1 (en) * 2013-06-25 2014-12-25 Public Wireless, Inc. Systems and methods for optimizing wireless networks
EP3174327A1 (fr) * 2014-07-25 2017-05-31 Samsung Electronics Co., Ltd. Procédé et appareil de commande de flux adaptatif dans un système de communication sans fil
US20160095038A1 (en) * 2014-09-29 2016-03-31 Hitachi, Ltd. Radio communication system, load sharing method, and base station
US20200275316A1 (en) * 2017-09-29 2020-08-27 Nokia Solutions And Networks System Technology (Beijing) Co., Ltd. Method and apparatus for load balancing
WO2020063404A1 (fr) * 2018-09-29 2020-04-02 华为技术有限公司 Procédé et dispositif d'équilibrage de charge
WO2020165280A1 (fr) * 2019-02-13 2020-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Échange d'informations de chemin de remplacement pour une meilleure planification et une reprise sur incident de réseau de collecte dans des réseaux d'amenée à accès intégrés

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; NR; Study on Integrated Access and Backhaul; (Release 16)", 3GPP STANDARD; TECHNICAL REPORT; 3GPP TR 38.874, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V16.0.0, 10 January 2019 (2019-01-10), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , pages 1 - 111, XP051591643 *

Also Published As

Publication number Publication date
EP4320917A1 (fr) 2024-02-14

Similar Documents

Publication Publication Date Title
US20220151006A1 (en) Alternate path information exchange for better scheduling and backhaul failure recovery in integrated access backhaul networks
US20230239754A1 (en) Enhanced XN Handover Messages for IAB Inter-CU Migration
WO2016159841A1 (fr) Continuité de service
US11956665B2 (en) Detecting congestion at an intermediate IAB node
EP4118876B1 (fr) Noeud maître, noeud secondaire, équipement d'utilisateur et procédés mis en oeuvre dans un réseau de communication
US20230110446A1 (en) Radio network node, user equipment, and handover methods performed in a communication network
WO2020204770A1 (fr) Nœud de réseau radio, nœud de réseau et procédés exécutés dans ces nœuds pour commander une transmission
WO2022235197A1 (fr) Premier nœud, second nœud et procédés mis en œuvre pour gérer la migration d'un nœud
WO2022216215A1 (fr) Procédés et nœuds de réseau radio pour la gestion de communication
WO2020171750A1 (fr) Nœuds de réseau radio, dispositif sans fil et procédés mis en œuvre dans ceux-ci
US20240073779A1 (en) Methods and network nodes for handling communication
US20230143694A1 (en) Preventing reestablishment at descendant nodes with no alternative paths in integrated access backhaul
US20230189096A1 (en) Methods and Radio Network Nodes for Handling Communication
EP4320924A1 (fr) Procédés, noeuds de réseau radio pour le traitement de communication
WO2022071869A1 (fr) Procédés et nœuds de réseau pour gérer une communication
TW202207734A (zh) 用於處理通信之方法及無線電網路節點
EP4241491A1 (fr) Procédés et noeuds de réseau pour gérer une congestion associée à un plan de commande
WO2023219546A1 (fr) Détermination, au niveau d'un second nœud de réseau, de si un rapport shr (reçu au niveau d'un premier nœud de réseau en provenance d'un ue) et un rapport rlf (reçu par la suite au niveau dudit premier nœud de réseau) sont de fait associés au même transfert intercellulaire
WO2021225513A1 (fr) Procédés, nœud de réseau, premier nœud de réseau radio pour gérer une communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22785073

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022785073

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022785073

Country of ref document: EP

Effective date: 20231107