Handling of XN connectivity for radio access network nodes with wireless backhaul

Abstract

A method is performed by a Wireless Access and Backhaul (WAB)-gNB to remove an Xn connection between the WAB-gNB and a source Backhaul (BH)-gNB. The method includes sending to the source BH-gNB Xn removal signaling indicating a reason for Xn connection removal, and receiving from the source BH-gNB Xn signaling indicating a target BH-gNB. The method further includes setting up an Xn connection towards the target BH- gNB.

Description

HANDLING OF XN CONNECTIVITY FOR RADIO ACCESS NETWORK NODES WITH WIRELESS BACKHAULCROSS REFERENCE TO RELATED APPLICATION

[0001] The present application claims priority to U.S. Provisional Patent Application Serial No. 63 / 550,190, filed on February 6, 2024, the disclosure of which is incorporated herein by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates to wireless access and backhaul operations to remove an Xn connection in a communication system.BACKGROUND

[0003] A background overview is provided for a 3GPP Rel-19 Wireless Access and Backhaul (WAB).

[0004] At the Radio Access Network (RAN)# 102 meeting, a Rel-19 Study Item Description (SID) for the Rel-19 Study on additional topological enhancements for New Radio (NR) in RP-234041 was approved. The study consists of two parts:• Wireless Access Backhaul (WAB), which refers to a mobile gNB.• 5G Femto.

[0005] The justification of the WAB part of the Study Item (SI) includes:The legacy building blocks for 5G RAN topologies should be enhanced to provide a broader range of use cases, such as:• 5G access for UEs onboard aircrafts, cruise ships, helicopters, and vehicles in remote areas with limited sky visibility via an onboard gNB.• Backhauling of NG and Xn via Terrestrial Network (TN) and Non-Terrestrial Network (NTN), including support of NTN <-> TN handover for backhaul.• Support for onboard / on-site Multi-access Edge Computing (MEC) and local services.• Support for backhauling without RAN-sharing or roaming agreements between access public land mobile network(s) (PLMN(s)) and backhaul PLMN(s).• Backhauling for local gNB deployed in public safety or disaster recovery scenarios.

[0006] It is assumed that Wireless Access Backhaul (WAB) is aligned with vehiclemounted relay (VMR) use cases and with the SA2 -endorsed SID on architectural enhancements for Rel-19 VMR. It is expected that single-hop backhauling is sufficient for Wireless Access Backhaul (WAB) and that there is no impact to UEs at this late stage of 5G deployment.

[0007] The objectives from the Study Item Description (SID) related to the WAB study are as follows:• Study the support of WAB including [RAN3, RAN2]:• Study the architecture and protocol stack of supporting a gNB with Mobile Termination (MT) function providing PDU session backhaul.• Study impact of WAB mobility within an existing RAN (e.g., inter-gNB neighbour relations).• Identify necessary inter-gNB- and gNB-to-CN signalling to address the support of WAB.• Study signalling enhancements on resource multiplexing for WAB.NOTE 1: No impact on the UE.NOTE 2: Coordination with other WGs (e.g. SA2) when needed.The WAB study does not preclude any backhaul scenario (e.g. NTN or TN).

[0008] An example WAB architecture in shown in Fig. 1. The example WAB architecture has been discussed in company contributions to the RAN# 102 meeting.

[0009] Some features of the WAB architecture include that a WAB node has a WAB-gNB and a WAB-MT. The WAB-gNB part of an WAB node serves UEs, while the WAB node uses its WAB-MT part to connect with the rest of the mobile network, i.e., to connect to its serving gNB (the leftmost gNB in Fig. 1). In this architecture, the PDU sessions established between the WAB-MT and its serving gNB are used to carry the NGAP and XnAP connections of the WAB-gNB.

[0010] The 5G Core Network (5GC) serving the WAB-gNB with its connected UEs (i.e., the rightmost 5GC in Fig. 1) may be the same as or different from the 5G Core Network (5GC) serving the WAB-MT (i.e., the leftmost 5GC in Fig. 1).

[0011]

[0012] An overview of an XnAP interface is now provided.

[0013] Below is an excerpt from TS 38.422 vl8.0.0, which describes the XnAP (i.e., Xn- C) interface.»»»»»»>Start of excerpt from TS 38.422 vl7.1.0 «««««««4.1 Functions and protocol stackXn-C signalling bearer provides the following functions:- Provision of reliable transfer of XnAP message over Xn-C interface.- Provision of networking and routeing function.- Provision of redundancy in the signalling network.- Support for flow control and congestion control.The protocol stack for Xn-C Signalling Bearer is shown in Fig. 2 and details on each protocol are described in the following clauses.The Transport Network Layer is based on IP transport, comprising SCTP on top of IP.»»»»»»>End of excerpt from TS 38.422 vl7.1.0 «««««<

[0014]

[0015] Potential problems that may arise with these approaches are now explained.

[0016] According to the standardization discussions so far, a WAB node will likely have a WAB-gNB and a WAB-MT (i.e., WAB-UE). The WAB-gNB part of an WAB node serves UEs, while the node uses its WAB-MT part to connect with a mobile network (the BH-gNB in Fig. 1). Packet Data Unit (PDU) Session(s) of the WAB-MT provide IP connectivity for the WAB-gNB to the UPF (and other CN functions) allowing the WAB-gNB to serve UEs. In this architecture, the PDU session(s) established between the WAB-MT and the BH-UPF (see Fi.g 1) are used to provide IP connectivity for NGAP and XnAP connections of the WAB-gNB, as well as to provide connectivity to the Operations And Management (0AM) (e.g., WAB-OAM and / or BH-OAM in Fig. 1). The WAB-gNB may connect to the same AMF and CN functions as the WAB-MT (and BH-gNB), or it may connect to different Access & Mobility Management Function (AMF(s)) and Core Network (CN) functions.

[0017] According to the above, all traffic from the WAB-gNB (including at least the NG, Xn communication for interface management, individual UE signaling, user plane (UP) traffic, and 0AM connection traffic) will be backhauled through the PDU sessions that are established between the WAB-MT and BH-5GC. Consequently, the traffic to / from the UEs served by the WAB-gNB will traverse two wireless links in the downstream:• The first link between the BH-gNB and the WAB-MT, i.e., the backhaul (BH) link (NR BH).• The second link between the WAB-gNB and the UE, i.e., the access link (NR Access).

[0018] In many scenarios, the WAB nodes will be moving most of the time, causing its set of neighbouring gNBs (including the serving gNB of the WAB-MT, i.e., the BH-gNB) to change frequently. Given that the Xn connection is generally established between neighbouring gNBs, this means that the WAB-gNB will need to set up and remove Xn connections often. Specifically, the WAB-gNB should at least have the Xn connection with the BH-gNB, e.g., for coordination in usage of the same radio resources. Once the WAB-MT is handed over to another BH-gNB, the WAB-gNB should be able to know the ID and the “contact details” of this new BH-gNB, for the sake of Xn connection setup.

[0019] As of today, it is undefined how the existing tools for managing Xn connectivity can be used in WAB scenarios.

[0020] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.SUMMARY

[0021] Some embodiments are directed to operationally enabling Wireless Access and Backhaul (WAB) nodes, to support the establishment of a lightweight version of the Xn interface which supports only a small subset of XnAP features that are essential for WAB operation and communication with its neighbours.

[0022] Various embodiments of the present disclosure are directed to one or of the following:• Enhancing the existing XnAP removal procedure, to enable faster Xn connection setup of the WAB-gNB to a set of gNBs in the neighbourhood of the target BH-gNB (including target BH-gNB if WAB-gNB and BH-gNB connect to the same network).• To enable setup of a light weight Xn connection between WAB-gNB and the BH-gNB. The term "lightweight" can mean, according to some embodiments, an Xn design which ignores some or all legacy fields in messages and is only used to exchange messages needed for WAB operation. For example, some generic Xn functionalities, such as handover messages, would then not be a part of this message exchange for setup of a light weight Xn connection.• To enable the BH-gNBs to exchange with the neighbouring BH-gNB the information about surrounding WAB-gNB.• Suspension of the Xn connection of WAB-gNB.• Indicating to the BH-gNB that the WAB-MT and the WAB-gNB are co-located, i.e., a part of the same WAB nodes.• Indicating the cause of Xn setup failure when the setup is attempted between two WAB-gNBs.• Carrying the traffic of Xn connection between the WAB-gNB and a set of gNBs in the neighbourhood of the target BH-gNB (including target BH-gNB if WAB- gNB and BH-gNB connect to the same network), through operation of SRBs.

[0023] Some embodiments disclosed herein are directed to a method performed by a Wireless Access and Backhaul (WAB)-gNB to remove an Xn connection between the WAB- gNB and a source Backhaul (BH)-gNB. The method includes receiving from the WAB-gNB XN removal signaling indicating a reason for Xn connection removal, and sending to the WAB- gNB Xn signaling indicating a target BH-gNB.

[0024] Some related other embodiments are directed to a method performed by a WAB- gNB to suspend and then resume an Xn connection between the WAB-gNB and a source BH- gNB. The method includes sending to the source BH-gNB an Xn SUSPENSION REQUEST message indicating a reason for Xn connection suspension. The method further includes receiving from the source BH-gNB an Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection, and resuming the Xn connection towards the source BH-gNB.

[0025] Some related other embodiments are directed to a method performed by a WAB- gNB to establish an Xn connection between the WAB-gNB and a Backhaul, BH,-gNB. The method includes sending to the BH-gNB an Xn SETUP REQUEST message requesting setup of the Xn connection or receiving from the BH-gNB the Xn SETUP REQUEST message, wherein the Xn SETUP REQUEST message contains an indication that the WAB-gNB is colocated with a WAB-MT. The method further includes receiving from the BH-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection or sending to the BH-gNB the Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

[0026] Some related other embodiments are directed to a method performed by a first WAB-gNB to communicate with a second WAB-gNB. The method includes sending to the second WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection, and receiving from the second WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

[0027] Some related other embodiments are directed to a method performed by a second WAB-gNB to communicate with a first WAB-gNB. The method includes receiving from the first WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection, and sending to the first WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

[0028] Certain embodiments may provide one or more of the following technical advantage(s).

[0029] Operations disclosed herein can perform handling of the Xn connectivity of WAB nodes.

[0030] The operations may enable faster Xn removal and setup. Since WAB node (WAB- gNB and WAB-MT) are moving, the WAB-MT may change the BH-gNB, and, in such case, the existing Xn between WAB-gNB and BH-gNB can be removed more quickly and a new Xn towards a new BH-Gnb can be set up in advance or immediately.

[0031] The operations may be based on the BH-gNB providing the information about its surrounding Xn connectivity to WAB-gNB using existing Xn or via RRC to WAB-MT which then with internal interface communicates to WAB-gNB. This information contains the IP address, gNB ID, cell ID information.

[0032] In accordance with some embodiments, as soon as the WAB-MT changes the cell and moves to new BH-gNB, the WAB-MT informs to WAB-gNB which then removes old Xn and establishes a new Xn.

[0033] The Xn connection may also be suspended and resumed later.

[0034] Operational embodiments may enable improved handling of Xn connectivity between the WAB node and its current set of neighbours, which results in reduction of service interruption for the UEs. The operational embodiments may enable the BH-gNB to be informed that the WAB-MT and WAB-gNB are a part of the same WAB node.

[0035] Other methods and systems according to embodiments of the inventive subject matter will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional methods and systems be included within this description, be within the scope of the present inventive subject matter, and be protected by the accompanying claims. Moreover, it is intended that all embodiments disclosed herein can be implemented individually or combined in any way and / or combination.BRIEF DESCRIPTION OF THE DRAWINGS

[0001] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying drawings. In the drawings:

[0002] Fig. 1 illustrates an example WAB architecture in accordance with some embodiments of the present disclosure;

[0003] Fig. 2 illustrates a protocol stack for Xn-C Signalling Bearer in accordance with some embodiments of the present disclosure;

[0004] Fig. 3 illustrates illustrates communications carrying Xn traffic via SRBs in accordance with some embodiments of the present disclosure;

[0005] Fig. 4 illustrates a flowchart of operations performed by a WAB-gNB to remove an Xn connection between the WAB-gNB and a source BH-gNB in accordance with some embodiments of the present disclosure;

[0006] Fig. 5 illustrates a flowchart of operations performed by a source BH-gNB to remove an Xn connection between a WAB-gNB and the source BH-gNB in accordance with some embodiments of the present disclosure;

[0007] Fig. 6 illustrates a flowchart of operations performed by a WAB-gNB to suspend and then resume an Xn connection between the WAB-gNB and a source BH-gNB in accordance with some embodiments of the present disclosure;

[0008] Fig. 7 illustrates a flowchart of operations performed by a WAB-gNB to establish an Xn connection between the WAB-gNB and a source BH-gNB in accordance with some embodiments of the present disclosure;

[0009] Fig. 8 illustrates a flowchart of operations performed by a first WAB-gNB to communicate with a second WAB-gNB in accordance with some embodiments of the present disclosure;

[0010] Fig. 9 illustrates an example of a communication system configured in accordance with some embodiments;

[0011] Fig. 10 illustrates an example a UE configured in accordance with some embodiments in accordance with some embodiments;

[0012] Fig. 11 illustrates a network node configured in accordance with some embodiments;

[0013] Fig. 12 illustrates a block diagram of a host which may be an embodiment of the host of Fig. 9 in accordance with some embodiments;

[0014] Fig. 13 illustrates a block diagram of a virtualization environment of functions configured in accordance with some embodiments; and

[0015] Fig. 14 illustrates a communication diagram of a host communicating via a network node with a UE over a partially wireless connection in accordance with some embodiments.DETAILED DESCRIPTION

[0036] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. Additional information may also be found in the document(s) provided in the Appendix below.

[0037] Some terms and operations that are disclosed herein are now described before a detailed description is provided for various embodiments of the present disclosure.• Embodiments of the present disclosure are discussed by way of non-limiting examples of WAB nodes, although they can also be applied to any kind of moving RAN node and / or a RAN node with wireless backhaul.• The terms “XnAP connection” and “Xn-C interface instance” are used interchangeably. Moreover, the terms “XnAP connection” and "Xn connection" may be used interchangeably.• The terms “current BH-gNB”, “old BH-gNB” and “source BH-gNB” are used interchangeably and refer to the BH-gNB currently serving the WAB-MT that may thereafter become the source BH-gNB for the WAB-MT handover. In some cases, the term “BH-gNB” applies to source BH-gNB, which can be understood from the context.• The terms “new BH-gNB” and “target BH-gNB” are used interchangeably and refer to the target BH-gNB for the WAB-MT handover.• The terms “CN nodes”, “core network nodes” and “CN functions” are used interchangeably, and they may refer to one or more of the following: AMF, UPF, SMF, or any other 5GC node / fimction.• The operational procedures disclosed may be class- 1 or class-2 procedures, which may be new procedures or enhancements of existing procedures.• The expressions “X served by Y” or “X is connected to Y” mean that there is a logical interface connection between network nodes X and Y. In case X is a UE, this means that node X and the RAN node serving the UE have a logical connection associated to this UE.• Unless stated otherwise, the WAB-MT and the WAB-gNB are co-located, i.e., they are a part of the same WAB node.• The disclosed operations may apply to both single- and dual-connected WAB nodes.• The disclosed operations may apply to both the case when all UEs connected to the WAB-gNB are served by the same AMF, and the case where multiple AMFs serve these UEs. The disclosed operations may apply to the case where the WAB-gNB has an NGAP connection with the AMF serving the WAB-MT, and when it does not.• The term “different core network” may refer to a core network of another PLMN, or it may apply to different part of a core network of the same PLMN (e.g., a different AMF or set of AMFs).• The disclosed operations can apply to NR as well as future RATs such as beyond 3GPP Rel-19.• The terms “OAM” and “0AM system” are used interchangeably.

[0038] All the example embodiments presented herein are non-limiting and may be combined in any manner.

[0039] An example system architecture scenario is now described.

[0040] Operations in accordance with some embodiments of the present disclosure are now described in the context of Fig. 1. As described below, various of the illustrated components of the WAB architecture are configured to operate in accordance with one or more of the embodiments introduced above, such as to enable WAB nodes to support establishment of a lightweight version of the Xn interface.

[0041] In some embodiments, an assumption is made that a WAB node moves, and is about to leave the area of radio coverage of old (source) BH-gNB. The WAB-MT handover (HO) between the source BH-gNB and the target BH-gNB is about to happen. At this time, it may be necessary to remove the XnAP connection(s) of the WAB-gNB towards the old neighbours and gNBs (including old BH-gNB if WAB-gNB and BH-gNB connect to the same network) in its vicinity, and to establish Xn connectivity towards the new neighbours or gNBs (including new BH-gNB if WAB-gNB and new BH-gNB connect to the same network) in its vicinity.

[0042] Another scenario of interest is the one when the authorization status of WAB node changes from “authorized” to “not authorized” (e.g., when the WAB node has moved to arestricted area, or the UEs served by the WAB-gNB no longer need to be served). In this case, the “WAB node not authorized” indication is received by the WAB-gNB, and it may be necessary to remove the XnAP connection(s) of the WAB-gNB.

[0043] The applicability of the proposed solution is not limited to the above scenarios. The solutions may be combined, if applicable.

[0044] The Xn connection supposed to be set up between the WAB-gNB and BH-gNB does not need to fulfd the normal (full) Xn function. It does not need to, for example, support DC, mobility (between WAB-gNB and BH-gNB), and it may not be even needed to set up an Xn-U connection. One the other hand, the Xn connections should support new function, e.g., to provide information to ensure the end-to-end service quality. This is because the BH is a part of the UE-to-CN connection.

[0045] Various embodiments are directed to different aspects of the Xn connection between the WAB-gNB and a set of gNBs in the neighbourhood of the target BH-gNB (including the target BH-gNB if WAB-gNB and BH-gNB connect to the same network) including Stream Control Transmission Protocol (SCTP) layer, XnAP application layer.

[0046] NOTE: the term “BH-gNB” below can represent a set of gNBs close to the WAB- gNB + BH-gNB itself if the BH-gNB and WAB-gNB connect to the same network.

[0047] Some embodiments apply both to the scenarios where the UE-CN and WAB-gNB on one side, and the BH-CN and the BH-gNB on other, are in different PLMNs, and to scenarios where they are all a part of the same PLMN. Depending on the scenario, some or all operational steps described for one scenario may be reused, and additional steps as described herein may need to be executed. The same holds for the other neighbours of the WAB-gNB as well, i.e., they may be in the same PLMN as the WAB-gNB and / or the BH-gNB , or in different PLMNs.

[0048] In the lightweight XnAP solution between WAB-gNB and BH-gNfB, the operational procedure can be focused on transferring necessary gNB information and configuration. The operational procedure may not need to follow the classic XnAP protocol design, such as XnAP on top of STCP on top of IP (hence it is called “Xn-like” connection). The purpose of such Xn-C connection is to be able to transfer information / configuration between the WAB-gNB(s) and BH-gNB(s).

[0049]

[0050] Solution 1-1: XnAP connection removal initiated by the WAB-gNB -

[0051] This solution pertains to the graceful removal of the XnAP connection between the WAB-gNB and the BH-gNB. In the solution, the existing procedure for XnAP connection removal is enhanced. All steps below are optional and may be executed in a different order.

[0052] In some embodiments, the Xn removal is initiated by the WAB-gNB:1. The BH-gNB sends to the WAB-gNB an enhanced existing Xn REMOVAL REQUEST message. Some non-limiting examples of scenarios are when the HO of the WAB-MT is imminent, or when the BH-gNB receives and indication from the core network that the WAB-MT has become unauthorized, meaning that the Xn connection of the WAB-gNB needs to be removed. a. In some embodiments, the Xn REMOVAL REQUEST contains a cause indicating the reason for removal. i. Examples of causes are “WAB-MT handover”, or “WAB-MT handover to be executed soon”, or “WAB-MT handover executed” or “WAB-MT unauthorized”. ii. The cause can be indicated in a newly defined IE, or the enhanced existing XnAP Cause IE can be inserted in this message, with a new codepoint (cause value) indicating that the cause of removal is WAB- MT handover / mobility. iii. In some cases, the new IE is not a cause value, but rather an indication of a certain event, e.g., WAB-MT HO. b. In some embodiments, the BH-gNB inserts in the Xn REMOVAL REQUEST the contact details of the target BH-gNB, as defined in Solution 1-1. c. In some embodiments, the source BH-gNB may also send to the WAB-gNB the contact details of the neighbours of the target BH-gNB. d. In some embodiments, the BH-gNB may send the contact details of the target BH-gNB by means of RRC signalling to the WAB-MT, which then passes the information to the WAB-gNB. Based on this information, the WAB-gNB can find the target BH-gNB quicker and establish Xn connection to it. e. In some variants, the BH-gNB may send to the WAB-gNB an NG-RAN NODE CONFIGURATION UPDATE message containing the contact details of the target BH-gNB (and, optionally of the neighbours of target BH-gNB), so that the WAB-gNB may consider initiating the removal of XnAPconnection towards the BH-gNB. Alternatively, the BH-gNB can send an indication that the WAB-MT has been / is about to / is being handed over. f. The BH-gNB may send the removal request before or during or after the WAB-MT HO. g. In some embodiments, the BH-gNB may send a trigger message (e.g., by using a class-2 procedure) to the WAB-gNB so that the WAB-gNB initiates Xn removal.2. The WAB-gNB responds to the BH-gNB. a. In some embodiments, the WAB-gNB responds immediately, while in some embodiments it responds after setting up Xn connection with the target BH- gNB, and, optionally, its neighbours. New Xn setup may also be done at any time before or after. b. In some embodiments, the WAB-gNB may set up Xn connection towards the target BH-gNB based on the information obtained from an entity different than the source BH-gNB (e.g., based on pre-configured info). c. In some embodiments, the WAB-gNB may send the Xn REMOVAL FAILURE message indicating the cause of removal failure. i. For indicating this, a new dedicated code point, e.g., in the existing Xn Cause IE may be needed. ii. For example, the reason for Xn removal failure sending may be that the WAB-gNB decides to retain the Xn connection with BH-gNB.3. In some embodiments, when the WAB-MT is handed over from a source BH-gNB to a target BH-gNB, the WAB-gNB may decide not to remove Xn connection with the BH-gNB, one reason could be that the BH-gNB will remain a neighbour of WAB- gNB, meaning that the need for maintaining an Xn connection between them remains.4. After receiving the response, the BH-gNB or the WAB-gNB may take actions that result in Xn connection removal.

[0053] Solution 1-1: XnAP connection removal initiated by the WAB-gNB -

[0054] Embodiments of this solution are directed to improvements in removal of theXnAP connection between the WAB-gNB and the BH-gNB. In these embodiments of the solution, the existing procedure for XnAP connection removal is enhanced. All steps below are optional and may be executed in a different order.

[0055] One embodiment is described in the context of Fig. 4, which illustrates a flowchart of operations performed by a Wireless Access and Backhaul (WAB)-gNB to remove an Xn connection between the WAB-gNB and a source Backhaul (BH)-gNB. The operations include sending 400 to the source BH-gNB an Xn REMOVAL REQUEST message indicating a reason for Xn connection removal. The reasons can include WAB mobility or WAB-MT handover. The operations receive 402 from the source BH-gNB an Xn REMOVAL RESPONSE message acknowledging removal of the Xn connection. The operations setup 404 an Xn connection towards a target BH-gNB using information in the message received from the source BH-gNB. This and further embodiments are described below.

[0056] Thus, the method performed by a WAB-gNB to remove an Xn connection between the WAB-gNB and a source Backhaul (BH)-gNB, can include sending to the source BH-gNB an Xn removal signaling indicating a reason for Xn connection removal, and receiving from the source BH-gNB an Xn signaling indicating a target BH-gNB. The method further includes setting up an Xn connection towards the target BH-gNB. The Xn removal signaling may correspond to an XN REMOVAL REQUEST but is not limited thereto. The Xn signaling received from the source BH-gNB may correspond to an Xn REMOVAL RESPONSE but is not limited thereto and may be decoupled from any such response message.

[0057] In some embodiment, the WAB-gNB is able to set up Xn towards target BH-gNB because it received the necessary information about the target BH-gNB from the source BH- gNB. The WAB-gNB receives from the source BH-gNB the information about target BH- gNB and the information about the neighbors BH-gNBs. This information is not necessarily received in XN REMOVAL RESPONSE, but rather via any type of XnAP signalling.

[0058] The information about target BH-gNB and about neighbors of the BH-gNB can include the following, as described above regarding the information which can include contact details of target BH-gNB of one or more of:

[0059] gNB ID or global gNB ID;

[0060] TNL address(es) of target BH-gNB;

[0061] information needed for establishing SCTP connections and TNL associations;

[0062] a pointer, an identifier of, or a reference to, to a database storing the contact details; and

[0063] neighbour relation table (NRT).

[0064] Then, based on this information, the WAB-gNB can establish Xn towards the target BH-gNB and its neighbors.

[0065] As used herein, the term "message" refers to any type of signaling sent or received, and therefore the terms "message" and "signaling" can be used interchangeably.

[0066] In some embodiments, the Xn removal is initiated by the WAB-gNB:1. The WAB-gNB may send to the BH-gNB the existing XN REMOVAL REQUEST message, with enhancements (note: in case of WAB-MT, this current BH-gNB is the source BH-gNB). a. In some embodiments, the Xn removal request contains a cause indicating the reason for removal. i. Some examples of causes for Xn removal are WAB mobility, WAB- MT handover etc. b. The cause can be indicated in a newly defined IE, or the enhanced existing XnAP Cause IE can be inserted in this message, with a new codepoint (cause value) indicating that the cause of removal is WAB mobility. c. In some cases, the new IE is not a cause value, but rather an indication of a certain event, e.g., WAB mobility. d. In some embodiments, the WAB-gNB can receive information from another node (e.g., the BH-gNB) from which it may conclude that it should initiate Xn removal (as proposed in Solution 1-2). e. In some embodiments, the WAB-gNB can infer by itself that it is time to initiate Xn connection removal. i. The WAB-gNB may be preconfigured with which gNB it should connect depending upon the geographical area where WAB-gNB is currently at depending or which cells serve the WAB-MT. The configuration of when the Xn connections should be changed and which new gNBs to connect to depending upon the location (geographical location computed by WAB-MT or WAB-MT serving cell, serving tracking area) can be provisioned by 0AM node in advance.1. For example, WAB-gNB can infer this based on its physical position, or measurement results from its served UEs, or from the WAB-MT.ii. In some embodiments, instead of OAM, the WAB-gNB may send a request message to BH-gNB to provide its neighbour relation table (NRT), along with the IP address, cell IDs of the BH-gNB ’s neighbouring gNBs. This message exchange can happen at every Xn Setup between WAB-gNB and new BH-gNB. f. In some embodiments, the WAB-MT may alert / inform the WAB-gNB when the handover event condition is triggered, i.e., when WAB-MT is about to change cell (e.g.: serving cell is worse and neighbour cell is better for inter- gNB HO cases) g. In some embodiments, the WAB-gNB may send a trigger message (e.g., by using a class-2 procedure) to the BH-gNB so that the BH-gNB initiates Xn removal at suitable time, e.g., immediately or after it has handed over the WAB-MT. The BH-gNB responds by sending the existing enhanced XN REMOVAL RESPONSE message, acknowledging the removal. a. In some embodiments, the response message contains the “contact details” of the target BH-gNB for the WAB-MT HO. This info enables the WAB-gNB to find the target BH-gNB quicker and establish Xn connection to it. Thus, the operations in Fig. 4 can further include obtaining from the Xn REMOVAL RESPONSE contact details of the target BH-gNB towards which the WAB- gNB is to setup the Xn connection. i. Some examples of contact details of target BH-gNB are:1. gNB ID or global gNB ID.2. TNL address(es) of target BH-gNB.3. The information needed for establishing SCTP connections and TNL associations.4. A pointer, an identifier of, or a reference to, to a database storing the contact details.5. Neighbour relation table (NRT) b. In some embodiments, the BH-gNB may also send to the WAB-gNB the contact details of the neighbours of the target BH-gNB, and the WAB-gNB can also set up Xn connection to these nodes. These may, e.g., be the gNBs that are neighbours to both the WAB-gNB and the BH-gNB. Thus, theoperations in Fig. 4 can further include obtaining from the Xn REMOVAL RESPONSE contact details of neighbor BH-gNBs of the target BH-gNB. c. In some embodiments, the BH-gNB may send the contact details of the target BH-gNB by means of RRC signalling to the WAB-MT, which then passes the information to the WAB-gNB. Based on this information, the WAB-gNB can find the target BH-gNB quicker and establish Xn connection to it. d. In some embodiments, the source BH-gNB may wait with the response to the WAB-gNB until the WAB-MT has been handed over. In some embodiments it can respond immediately. In some cases, this may happen before the WAB- MT HO. e. In some embodiments, upon receiving the removal request, or after or before, the current BH-gNB may indicate to the target BH-gNB the contact details of the WAB-gNB so that the target BH-gNB can initiate Xn setup towards the WAB-gNB. i. This indication can be sent, e.g., in the Xn HANDOVER REQUEST message for the WAB-MT or in another new or existing Xn message. a. In some embodiments, the BH-gNB may send the XN REMOVAL FAILURE message indicating the cause of removal failure. Thus, the operations in Fig. 4 can further include, prior to the sending to the source BH-gNB the Xn REMOVAL REQUEST message indicating the reason for Xn connection removal, sending to the source BH-gNB an earlier Xn REMOVAL REQUEST message indicating a reason for Xn connection removal, and receiving from the source BH-gNB an Xn REMOVAL FAILURE message indicating a cause of Xn connection removal failure. ii. For indicating this, a new dedicated code point, e.g., in the existing Xn Cause IE may be needed. iii. For example, the reason for Xn removal failure can be that the WAB- MT will not be handed over, so there is no need to remove the Xn connection due to mobility. After receiving the response, the WAB-gNB may take actions that result in Xn connection removal. a. As said, in some embodiments, the WAB-gNB may set up Xn connection towards the target BH-gNB based on the info obtained from the source BH-gNB. Thus, in the context of Fig. 4, the setting up 404 the Xn connection towards the target BH-gNB, can include setting up the Xn connection towards the target BH-gNB based on information about a target BH-gNB and information about neighbor BBh-gNBs, obtained from the source BH-gNB. b. In some embodiments the WAB-gNB may set up Xn connection based on the information obtained from an entity different than the source BH-gNB (e.g., based on pre-configured info, based on info obtained from 0AM or another network node). Thus, in the context of Fig. 4, the setting up 404 the Xn connection towards the target BH-gNB, can include setting up the Xn connection towards the target BH-gNB based on information obtained from a network node other than the source BH-gNB, wherein the information comprises pre-configured information obtained from the network node and stored in the WAB-gNB before the sending of the Xn REMOVAL REQUEST message to the source BH-gNB. With respect to removal of Xn between the WAB-gNB and other gNBs (non-BH gNBs): a. In some embodiments, if the removal is initiated by the WAB-gNB, the WAB- gNB may also send the Xn removal request to other gNBs (e.g., the gNBs in the vicinity of source BH-gNB) and it may indicate the reason for removal, as defined in step 1 above. Thus, in the context of Fig. 4, the operations can further include sending to at least one other BH-gNB different from the source BH-gNB and the target BH-gNB, the Xn REMOVAL REQUEST message indicating the reason for Xn connection removal, and receiving from the at least one other BH-gNB at least one other Xn REMOVAL RESPONSE message acknowledging removal of the Xn connection by the at least one other BH-gNB. b. In some embodiments, the source BH-gNB can indicate to some or all the neighbours of WAB-gNB (which may also be the neighbours of BH-gNB) that the WAB-MT is handed over elsewhere. Alternatively, it may be an explicit indication that the Xn connection towards the WAB-gNB can be removed. This may trigger the neighbours of WAB-gNB to initiate Xn connection removal towards the WAB-gNB. Thus, in the context of Fig. 4, the operations can further include receiving from at least one other BH-gNB different fromthe source BH-gNB and the target BH-gNB, at least one other Xn REMOVAL RESPONSE message indicating removal of the Xn connection by the at least one other BH-gNB responsive to a message received from the source BH-gNB indicating that a WAB-Mobile Termination, WAB-MT, has been handed over elsewhere from the source BH-gNB, and performing actions related to the Xn connection removal by the at least one other BH-gNB.5. In some cases, when the WAB-MT is handed over from a source BH-gNB to a target BH-gNB, the WAB-gNB may decide not to remove Xn connection with the BH-gNB and / or other gNBs that it was connected with, one reason could be that the BH-gNB will still remain a neighbour of WAB-gNB, meaning that the need for Xn connection between them remains. Thus, in the context of Fig. 4, the operations can further include determining whether to send to the source BH-gNB the Xn REMOVAL REQUEST message based on whether the source BH-gNB will remain a neighbour of the WAB-gNB after the Xn connection is setup toward the target BH-gNB.

[0067] Solution 1-2: XnAP connection removal initiated by the BH-gNB -

[0068] One embodiment is described in the context of Fig. 5, which illustrates a flowchart of operations performed by a source Backhaul (BH)-gNB to remove an Xn connection between a Wireless Access and Backhaul (WAB)-gNB and the source BH-gNB. The operations include receiving 500 from the WAB-gNB XN removal signaling indicating a reason for Xn connection removal, and sending 502 to the WAB-gNB Xn signaling indicating a target BH-gNB.

[0069] In some embodiments, the Xn removal is initiated by the BH-gNB:1. The BH-gNB sends to the WAB-gNB an enhanced existing XN REMOVAL REQUEST message. Some non-limiting examples of scenarios are when the HO of the WAB-MT is imminent, or when the BH-gNB receives and indication from the core network that the WAB-MT has become unauthorized, meaning that the Xn connection of the WAB-gNB needs to be removed. Thus, in the context of Fig. 5, the operations to send 500 to the WAB-gNB of the Xn REMOVAL REQUEST message is performed based on determining that handover of a WAB-Mobile Termination, WAB-MT, is imminent and / or based on determining that the WAB-MT has become unauthorized necessitating removal of the Xn connection. a. In some embodiments, the XN REMOVAL REQUEST contains a cause indicating the reason for removal.i. Examples of causes are “WAB-MT handover”, or “WAB-MT handover to be executed soon”, or “WAB-MT handover executed” or “WAB-MT unauthorized”. ii. The cause can be indicated in a newly defined IE, or the enhanced existing XnAP Cause IE can be inserted in this message, with a new codepoint (cause value) indicating that the cause of removal is WAB- MT handover / mobility. iii. In some cases, the new IE is not a cause value, but rather an indication of a certain event, e.g., WAB-MT HO. b. In some embodiments, the BH-gNB inserts in the XN REMOVAL REQUEST the contact details of the target BH-gNB, as defined in Solution 1-1. Thus, in the context of Fig. 5, the operations can further include inserting in the Xn REMOVAL REQUEST message contact details of a target BH-gNB towards which the WAB-gNB is to setup an Xn connection. c. In some embodiments, the source BH-gNB may also send to the WAB-gNB the contact details of the neighbours of the target BH-gNB. Thus, in the context of Fig. 5, the operations can further include, prior to the sending 500 to the WAB-gNB the Xn REMOVAL REQUEST message, sending to the WAB-gNB an earlier Xn REMOVAL REQUEST message indicating a reason for Xn connection removal, and receiving from the WAB-gNB an Xn REMOVAL FAILURE message indicating a cause of Xn connection removal failure. d. In some embodiments, the BH-gNB may send the contact details of the target BH-gNB by means of RRC signalling to the WAB-MT, which then passes the information to the WAB-gNB. Based on this information, the WAB-gNB can find the target BH-gNB quicker and establish Xn connection to it. e. In some variants, the BH-gNB may send to the WAB-gNB an NG-RAN NODE CONFIGURATION UPDATE message containing the contact details of the target BH-gNB (and, optionally of the neighbours of target BH-gNB), so that the WAB-gNB may consider initiating the removal of XnAP connection towards the BH-gNB. Alternatively, the BH-gNB can send an indication that the WAB-MT has been / is about to / is being handed over.f. The BH-gNB may send the removal request before or during or after the WAB-MT HO. g. In some embodiments, the BH-gNB may send a trigger message (e.g., by using a class-2 procedure) to the WAB-gNB so that the WAB-gNB initiates Xn removal.2. The WAB-gNB responds to the BH-gNB. a. In some embodiments, the WAB-gNB responds immediately, while in some embodiments it responds after setting up Xn connection with the target BH- gNB, and, optionally, its neighbours. New Xn setup may also be done at any time before or after. b. In some embodiments, the WAB-gNB may set up Xn connection towards the target BH-gNB based on the information obtained from an entity different than the source BH-gNB (e.g., based on pre-configured info). c. In some embodiments, the WAB-gNB may send the XN REMOVAL FAILURE message indicating the cause of removal failure. i. For indicating this, a new dedicated code point, e.g., in the existing Xn Cause IE may be needed. ii. For example, the reason for Xn removal failure sending may be that the WAB-gNB decides to retain the Xn connection with BH-gNB.3. In some embodiments, when the WAB-MT is handed over from a source BH-gNB to a target BH-gNB, the WAB-gNB may decide not to remove Xn connection with the BH-gNB, one reason could be that the BH-gNB will remain a neighbour of WAB- gNB, meaning that the need for maintaining an Xn connection between them remains.4. After receiving the response, the BH-gNB or the WAB-gNB may take actions that result in Xn connection removal.

[0070] In the above, the request and the response may constitute a class- 1 procedure (where the recipient of the request replies to the initiating node within some predetermined time frame), or each of them may be a class-2 procedure (where the recipient of the request executes certain actions (setup of new Xn connection) before sending a class-2 message to the initiating node, to confirm the removal).

[0071]

[0072] Solution 2: XnAP connection suspension and resumption

[0073] In embodiments of this solution, instead of being removed, an XnAP connection between the WAB-gNB and the BH-gNB is suspended, and, if and when needed, resumed.

[0074] One embodiment is described in the context of Fig. 6, which illustrates a flowchart of operations performed by a Wireless Access and Backhaul (WAB)-gNB, to suspend and then resume an Xn connection between the WAB-gNB and a source Backhaul (BH)-gNB. The operations include sending 600 to the source BH-gNB an Xn SUSPENSION REQUEST message indicating a reason for Xn connection suspension. The operations further include receiving 602 from the source BH-gNB an Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection. The operations further include resuming 604 the Xn connection towards the source BH-gNB.

[0075] All steps below are optional and may be executed in a different order.

[0076] The steps defined for Solution 1-1 and Solution 1-2 can be reused, with some differences:• The references to Xn removal are to be replaced with references to Xn suspension.• In case of suspension, all application-level data related to the suspended Xn connection is to be kept both at the WAB-gNB and the BH-gNB. Thus, in the context of Fig. 6, the operations can further include, based on receiving the Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection, storing application-level data related to the suspended Xn connection at the WAB-gNB.• In case of suspension, the Xn suspension request message may contain the length of the suspension period, whereas one of the possible values may be “indefinite suspension”, which may, in some cases, be the default value. Thus, in the context of Fig. 6, the operations can further include inserting in the Xn SUSPENSION RESPONSE message an indication of length of a suspension period. o Other types of assistance information for the suspension are possible, e.g., an indication of the area of suspension, the triggering conditions for resumption etc.• In addition to Xn suspension procedure described above, an Xn resumption procedure needs to be defined.

[0077] The Xn resumption procedure can be described as follows:The Xn resumption procedure is initiated by sending an Xn resumption request. It may be initiated by the WAB-gNB or by the BH-gNB that previously maintained the suspended connection, regardless of which one of them initiated the suspension. Thus, in the context of Fig. 6, the operation to resume 604 the Xn connection towards the source BH-gNB, can include sending an Xn resumption request to the source BH- gNB or receiving an Xn resumption request from the source BH-gNB. a. The resumption request may be sent by the WAB-gNB. i. The request may also contain some or all the information included in the existing XN SETUP REQUEST. ii. This request may be sent by the WAB-gNB upon fulfilling one or more of the triggers as specified in the Xn suspension request. b. The resumption request may be sent by the BH-gNB. i. For example, if the BH-gNB realizes that an incoming WAB-MT has previously been served by the BH-gNB, it may decide to request the resumption of the NGAP connection. The node receiving the request may respond by Xn resumption response (confirming the resumption), or by sending an Xn resumption failure message. A failure cause could be defined in the message indicating the reason why the failure was triggered. The failure cause may comprise: insufficient resources, the suspended connection is not needed anymore, etc. Thus, in the context of Fig. 6, the operations can further include sending an Xn RESUMPTION RESPONSE message confirming resumption of the Xn connection towards the source BH-gNB. The operations can further include sending an Xn RESUMPTION FAILURE message indicating a cause of failure of resumption of the Xn connection towards the source BH-gNB. In case of successful resumption, the application-level data related to the suspended Xn connection is reactivated in both involved nodes. Thus, in the context of Fig. 6, the operations can further include, based on the resuming of the Xn connection towards the source BH-gNB, reactivating for use the application-level data stored at the WAB-gNB. When the suspend and resume frequency is settled and can be predicted, (e.g., when BH is using NTN, or WAB-gNB moves in circle or along a circular route or along repetitive route), such configuration are exchanged between WAB-gNB and BH-gNB and the resume process is per automatic. Thus, in the context of Fig. 6, the operationscan further include agreeing on a frequency of suspension and resumption of the Xn connection through configuration communications with the source BH-gNB, and wherein the resuming of the Xn connection towards the source BH-gNB is performed based on the frequency agreed with the source BH-gNB.

[0078] Solution 3 : Establishment of Xn between the WAB-gNB and BH-gNB -

[0079] The assumed scenario is Xn setup between the WAB-gNB and the BH-gNB. The WAB-MT is already connected to the BH-gNB or is connecting to it. This solution is applicable both when the WAB node connects to the network, and at subsequent mobility events, such as WAB-MT handover. All steps below are optional and may be executed in a different order.

[0080] One embodiment is described in the context of Fig. 7, which illustrates a flowchart of operations performed by a Wireless Access and Backhaul (WAB)-gNB, to establish an Xn connection between the WAB-gNB and a Backhaul (BH)-gNB. The operations include sending 700 to the BH-gNB an Xn SETUP REQUEST message requesting setup of the Xn connection or receiving from the BH-gNB the Xn SETUP REQUEST message, wherein the Xn SETUP REQUEST message contains an indication that the WAB- gNB is co-located with a WAB-MT. The operations further include receiving 702 from the BH-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection or sending to the BH-gNB the Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.• In one embodiment, the WAB-gNB initiates the setup of Xn connection with the BH- gNB. o The WAB-gNB may obtain from the 0AM the contact details of BH-gNB for setting up the Xn. Thus, in the context of Fig. 7, the operations can further include obtaining from an Operations And Management node, contact details of the source BH-gNB, and establishing the Xn connection based on the contact details of the source BH-gNB. o The WAB-gNB may obtain the gNB ID of the BH-gNB from the WAB-MT and perform a DNS query or a query to the 0AM, to obtain the contact details of the BH-gNB. Thus, in the context of Fig. 7, the operations can further include obtaining from a WAB-Mobile Termination, WAB-MT, a gNB ID of the source BH-gNB, performing a domain name system, DNS, query based onthe gNB ID to obtain contact details of the source BH-gNB, and establishing the Xn connection based on the contact details of the source BH-gNB.■ The WAB-MT may obtain the gNB ID of the BH-gNB from the NCGI of a cell served by the BH-gNB, where the gNB ID length is obtained from SIB1 and used to extract the gNB ID from the NCGI.■ The WAB-MT may obtain the gNB ID of the BH-gNB from the BH- gNB explicitly.• In the Xn SETUP REQUEST, the WAB-gNB includes an indication that the WAB- gNB is co-located with the WAB-MT, to inform the BH-gNB about the co-location. o The indication can be explicit or implicit.■ For example, the WAB-gNB can send an ID of the WAB-MT known by the BH-gNB or some other indicator. o In some embodiments, another Xn message can be used, e.g., NG-RAN NODE CONFIGURATION UPDATE message. For example, NG-RAN Configuration Update message can be used in case the WAB-gNB realizes that the WAB-MT is being handed over to a gNB that it has an Xn connection with. o In some embodiments, the Xn SETUP REQUEST and / or Xn SETUP RESPONSE may also contain an indication that the sender thereof is a WAB node.• The BH-gNB responds to the request by an acknowledgement or by a failure message.The second approach is described below.• In another embodiment, the BH-gNB initiates the setup of Xn connection towards the WAB-gNB. o The WAB-gNB may obtain from the OAM the contact details of BH-gNB for setting up the Xn. o The BH-gNB may obtain the gNB ID or the contact details of the WAB-gNB from the WAB-MT. If gNB ID is obtained, BH-gNB CAN perform a DNS query or a query to the OAM, to obtain the contact details of the WAB-gNB.• In the Xn SETUP REQUEST, the BH-gNB includes an indication that the WAB-MT is connected to the BH-gNB. o The indication can be explicit or implicit.■ For example, the BH-gNB can send an ID of the WAB-MT known by the WAB-gNB or some other indicator. o The indication may also state what kind of wireless backhaul is used, for example “terrestrial network backhaul” or “non-terrestrial network backhaul”. o In some embodiments, another Xn message can be used, e.g., NG-RAN NODE CONFIGURATION UPDATE message. For example, NG-RAN Configuration Update message can be used after the Xn connection has been set up, e.g., in case the WAB-gNB and BH-gNB had an Xn connection, and the BH-gNB realizes that the incoming WAB-MT is co-located with a gNB that the BH-gNB has an Xn connection with.• The WAB-gNB responds to the request by an acknowledgement or by a failure message.• In another embodiment, a lightweight XnAP concept is introduced based on the fact that many of the existing XnAP functions may not be needed in the WAB-gNB to BH-gNB communication. Refer to Example 3.

[0081] Solution 4: Preventing Xn setup between two WAB nodes -

[0082] Given that WAB nodes are expected to move most of the time, it does not seem justified to establish Xn interface between two WAB nodes. So, in an assumed scenario, WAB nodel (WAB1) sends an XN SETUP REQUEST message to WAB2.

[0083] One embodiment is described in the context of Fig. 8, which illustrates a flowchart of operations performed by a first Wireless Access and Backhaul (WAB)-gNB, to communicate with a second WAB-gNB. The operations include sending 800 to the second WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection, and receiving 802 from the second WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

[0084] Some related other embodiments are directed to a method performed by a second WAB-gNB to communicate with a first WAB-gNB. The method includes receiving 800 from the first WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection, and sending 802 to the first WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

[0085] WAB2 may learn that WAB 1 is a WAB node and not a gNB in one of the following ways:• From the XN SETUP REQUEST send by WAB 1.• By means of UE measurement reports.• By means of WAB-MT measurements.• From the OAM.• By means of Xn signalling with other nodes, for example by means of Neighbor Information NR IE received from another gNB.

[0086] Thus, in the context of Fig. 8, the Xn SETUP REQUEST message may contain an indication that the first WAB-gNB is a WAB node. The operations may further include determining that the second WAB-gNB is a WAB node based on at least one of: an Xn SETUP REQUEST received from the second WAB-gNB; content of a UE measurement report; content of a WAB-Mobile Termination (WAB-MT) measurement report; information received from an OAM node; and Xn signaling with other nodes.

[0087] As said above, a WAB node receiving an XN SETUP REQUEST message from another WAB node may want to reject such a request. In this case, in some embodiments, the WAB node receiving the request inserts into the XN SETUP FAILURE message a new cause value indicating the reason for Xn setup failure is the rejection due to the sender or the receiver of the request, or both, being a WAB node.• In some embodiments, the cause is included into the XnAP Cause IE as a new codepoint, while in some embodiments it is a separate indication.• Non-limiting examples of cause values:• “Xn between WAB nodes not allowed”.• “Sender is a WAB node”.

[0088] Thus, in the context of Fig. 8, the operations may include determining from the Xn Response message a cause value indicating that an Xn between WAB nodes not allowed and / or that the second WAB-gNB is or is not a WAB node. The operations may include obtaining from Xn RESPONSE message indicating failure to setup the Xn connection, a reason for Xn setup failure. The Xn RESPONSE message can be an Xn SETUP FAILURE message. For example, the Xn RESPONSE message may indicate a reason for Xn setup failure as occurring from rejection of the Xn connection setup request by the second WAB- gNB. Example reasons indicated can include that Xn between WAB nodes is not allowed and / or that the sender is a WAB node.

[0089] In some embodiments, any gNB, not necessarily a WAB-gNB may reject Xn setup and send the abovementioned cause value.

[0090]

[0091] Solution 5: Carrying the Xn traffic via SRBs of the WAB-gNB -

[0092] In the case that the Xn-like connection between the WAB-gNB and BH-gNB is to transfer information and configuration, we only need a solution to:• Convey the information over the BH between the BH-gNB and the WAB-MT• Interpret correctly the information at the gNBs.

[0093] One suitable solution is to use SRB (Signaling Radio Bearer) to carry the “Xn-C like messages”. Referring again to the context of Fig. 4, the operations can further include, while the Xn connection is active between the WAB-gNB and the source BH-gNB, transferring messages between the source BH-gNB and a WAB-Mobile Termination (WAB- MT) using signaling radio bearer (SRB).

[0094] A potential advantage compared to using, e.g., DRB to carry such Xn-C like message is that DRB is supposed to carry the user data associated with QoS flows, whereas:• That DRBs cannot achieve the reliability and delay that control plane messages (such as Xn-C messages) require.• That use of DRB complicates implementation, since the Xn control plane s-related content has to be taken out of the user plane packet and forwarded to the control plane entity in the gNB.

[0095] Fig. 3 illustrates communications carrying Xn traffic via SRBs in accordance with some embodiments.

[0096] In one embodiment, the “Xn-C like message” is carried in the existing SRB in WAB-MT <-> BH-gNB. It is specified that WAB-MT will pass it to the high layer, i.e., in this case WAB-gNB.

[0097] The WAB-gNB and BH-gNB reads the message and extracts the useful information about the sending node configuration, e.g.• The Network Energy Saving scheme (e.g., BH-gNB includes the cell DTRX information for the cell(s) that serving the WAB-MT; WAB-gNB includes the cell DTRX information for the cells that serving the UE)• The characterise of the BH link (when the sending node is BH-gNB)• The BH PDU session related information (such as BH QoS setup, BH radio condition, BH UL / DL delay, Jitter)• The neighbour nodes information, for future mobility action• The expected behaviour when the sender is moving around with certain patterns (e.g. when BH-gNB is NTN, or when WAB-gNB is circulating, passing / using certain BH periodically).• The gNB type.

[0098] In another embodiment, a new SRB is introduced.

[0099] In another embodiment, related to security, if the information is exchanged after the RRC security is activated, there should be no security issue.

[0100] The lightweight XnAP message structure may apply in this solution and it is defined over RRC between WAB-MT and BH-gNB.

[0101] In another embodiment, the information related to the WAB-gNB and BH-gNB is carried in lower layer signalling, for example MAC CE (i.e., MAC control element). In another embodiment, between the BH-gNB-CU and gNB-DU, it is specified that the lower layer information (such as BH link condition) are included by gNB-DU, or is sent by gNB- DU to gNB-CU to be included in the RRC.

[0102] Examples of implementation of Solutions 1-1 and 1-2 in TS 38.423 are discussed below. The new parts are underlined and italicized below. The example of encoding and placement of new information elements (IES) is non-limiting. All examples are optional, meaning that different solutions can be constructed from some or all the enhancements proposed below.

[0103] Example 1: Solution 1-1»»»»»»»»»» Start of TS 38.423 implementation example««««««««<9.1.3.13 XN REMOVAL REQUESTThis message is sent by aNG-RAN node to a neighbouring NG-RAN node to initiate the removal of the interface instance.Direction: NG-RAN nodenode 2.92.32 CauseThe purpose of the Cause IE is to indicate the reason for a particular event for the XnAP protocol.The meaning of the different cause values is specified in the following table. In general, "not supported" cause values indicate that the related capability is missing. On the other hand, "not available" cause values indicate that the related capability is present, but insufficient resources were available to perform the requested action.»»»»»»»Unchanged parts are skipped<«««««««<<»»»»»»»»»»End of TS 38.423 implementation example««««««««<

[0104]

[0105] Example 2: Solution 1-2»»»»»»»»»» Start of TS 38.423 implementation example««««««««<9.1.3.13 XN REMOVAL REQUESTThis message is sent by aNG-RAN node to a neighbouring NG-RAN node to initiate the removal of the interface instance.Direction: NG-RAN nodenode 2.»»»»»»»»»»End of TS 38.423 implementation example««««««««<

[0106] Example 3: Solution 3, Lightweight Xn procedures for WAB»»»»»»»»»» Start of TS 38.423 implementation example««««««««<9.1.3.x WAB-XNAP SETUP REQUEST

[0107] »»»»»»»»>End of TS 38.423 implementation example«««««««<

[0108] Further embodiments are now described in the context of Figs. 9 through 14.

[0109] Fig. 9 shows an example of a communication system QQ100 in accordance with some embodiments.

[0110] In the example, the communication system QQ100 includes a telecommunication network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network nodes QQ110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network QQ102 includes one or more Open- RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network QQ102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network QQ102, including one or more network nodes QQ110 and / or core network nodes QQ108.

[0111] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time ornon-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O- RAN Alliance or comparable technologies. The network nodes QQ110 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.

[0112] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0113] The UEs QQ112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes QQ110 and other communication devices. Similarly, the network nodes QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs QQ 112 and / or with other network nodes or equipment in the telecommunication network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network QQ102.

[0114] In the depicted example, the core network QQ106 connects the network nodes QQ110 to one or more hosts, such as host QQ116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network QQ106 includes one more core network nodes (e.g., core network node QQ108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0115] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ 104 and / or the telecommunication network QQ102, and may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0116] As a whole, the communication system QQ100 of Fig. 9 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access(WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0117] In some examples, the telecommunication network QQ102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network QQ102. For example, the telecommunications network QQ102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

[0118] In some examples, the UEs QQ112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. Additionally, a UE may be configured for operating in single- or multi-RAT or multistandard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0119] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and network nodes (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes QQ110, or by executable code, script, process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory informationvia a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0120] The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQ110b. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112c and / or QQ112d), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ 114 is connected to the core network QQ 106 and / or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ 104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wireless connection. In some embodiments, the hub QQ114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to the network node QQ110b. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0121] Fig. 10 shows a UE QQ200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0122] A UE may support device -to-de vice (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-RangeCommunication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle -to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0123] The UE QQ200 includes processing circuitry QQ202 that is operatively coupled via a bus QQ204 to an input / output interface QQ206, a power source QQ208, a memory QQ210, a communication interface QQ212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Fig. 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0124] The processing circuitry QQ202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory QQ210. The processing circuitry QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ202 may include multiple central processing units (CPUs).

[0125] In the example, the input / output interface QQ206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE QQ200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, asmartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0126] In some embodiments, the power source QQ208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source QQ208 may further include power circuitry for delivering power from the power source QQ208 itself, and / or an external power source, to the various parts of the UE QQ200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source QQ208. Power circuitry may perform any formatting, converting, or other modification to the power from the power source QQ208 to make the power suitable for the respective components of the UE QQ200 to which power is supplied.

[0127] The memory QQ210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ216. The memory QQ210 may store, for use by the UE QQ200, any of a variety of various operating systems or combinations of operating systems.

[0128] The memory QQ210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules(SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ210 may allow the UE QQ200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory QQ210, which may be or comprise a device-readable storage medium.

[0129] The processing circuitry QQ202 may be configured to communicate with an access network or other network using the communication interface QQ212. The communication interface QQ212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ218 and receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0130] In the illustrated embodiment, communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / intemet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0131] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface QQ212, via a wireless connection to anetwork node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0132] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0133] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE QQ200 shown in Fig. 10.

[0134] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as anMTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0135] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0136] Fig. 11 shows a network node QQ300 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NRNodeBs (gNBs)), 0-RAN nodes or components of an 0-RAN node (e.g., 0-RU, 0-DU, O-CU).

[0137] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an 0-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0138] Other examples of network nodes include multiple transmission point (multi- TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicastcoordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0139] The network node QQ300 includes a processing circuitry QQ302, a memory QQ304, a communication interface QQ306, and a power source QQ308. The network node QQ300 may be composed of multiple physically separate components (e.g., aNodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node QQ300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node QQ300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory QQ304 for different RATs) and some components may be reused (e.g., a same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node QQ300.

[0140] The processing circuitry QQ302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node QQ300 components, such as the memory QQ304, to provide network node QQ300 functionality.

[0141] In some embodiments, the processing circuitry QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ302 includes one or more of radio frequency (RF) transceiver circuitry QQ312 and baseband processing circuitry QQ314. In some embodiments, the radio frequency (RF) transceiver circuitry QQ312 and the baseband processing circuitry QQ314 may be on separate chips (or sets of chips), boards, orunits, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry QQ312 and baseband processing circuitry QQ314 may be on the same chip or set of chips, boards, or units.

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

[0143] The communication interface QQ306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, the communication interface QQ306 comprises port(s) / terminal(s) QQ316 to send and receive data, for example to and from a network over a wired connection. The communication interface QQ306 also includes radio front-end circuitry QQ318 that may be coupled to, or in certain embodiments a part of, the antenna QQ310. Radio front-end circuitry QQ318 comprises filters QQ320 and amplifiers QQ322. The radio front-end circuitry QQ318 may be connected to an antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ310 and processing circuitry QQ302. The radio front-end circuitry QQ318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry QQ318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters QQ320 and / or amplifiers QQ322. The radio signal may then be transmitted via the antenna QQ310. Similarly, when receiving data, the antenna QQ310 may collect radio signals which are thenconverted into digital data by the radio front-end circuitry QQ318. The digital data may be passed to the processing circuitry QQ302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0144] In certain alternative embodiments, the network node QQ300 does not include separate radio front-end circuitry QQ318, instead, the processing circuitry QQ302 includes radio front-end circuitry and is connected to the antenna QQ310. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ312 is part of the communication interface QQ306. In still other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front-end circuitry QQ318, and the RF transceiver circuitry QQ312, as part of a radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuitry QQ314, which is part of a digital unit (not shown).

[0145] The antenna QQ310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ310 may be coupled to the radio front-end circuitry QQ318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ310 is separate from the network node QQ300 and connectable to the network node QQ300 through an interface or port.

[0146] The antenna QQ310, communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ310, the communication interface QQ306, and / or the processing circuitry QQ302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0147] The power source QQ308 provides power to the various components of network node QQ300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ308 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ300 with power for performing the functionality described herein. For example, the network node QQ300 may be connectable to an external power source (e.g., thepower grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source QQ308. As a further example, the power source QQ308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0148] Embodiments of the network node QQ300 may include additional components beyond those shown in Fig. 11 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, the network node QQ300 may include user interface equipment to allow input of information into the network node QQ300 and to allow output of information from the network node QQ300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ300.

[0149] Fig. 12 is a block diagram of a host QQ400, which may be an embodiment of the host QQ116 of Fig. 9, in accordance with various aspects described herein. As used herein, the host QQ400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host QQ400 may provide one or more services to one or more UEs.

[0150] The host QQ400 includes processing circuitry QQ402 that is operatively coupled via a bus QQ404 to an input / output interface QQ406, a network interface QQ408, a power source QQ410, and a memory QQ412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figs. 10 and 11, such that the descriptions thereof are generally applicable to the corresponding components of host QQ400.

[0151] The memory QQ412 may include one or more computer programs including one or more host application programs QQ414 and data QQ416, which may include user data, e.g., data generated by a UE for the host QQ400 or data generated by the host QQ400 for a UE. Embodiments of the host QQ400 may utilize only a subset or all of the components shown. The host application programs QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) andaudio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs QQ414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host QQ400 may select and / or indicate a different host for over-the-top services for a UE. The host application programs QQ414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0152] Fig. 13 is a block diagram illustrating a virtualization environment QQ500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments QQ500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment QQ500 includes components defined by the 0-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0153] Applications QQ502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0154] Hardware QQ504 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualizationlayers QQ506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs QQ508a and QQ508b (one or more of which may be generally referred to as VMs QQ508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears like networking hardware to the VMs QQ508.

[0155] The VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer QQ506. Different embodiments of the instance of a virtual appliance QQ502 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0156] In the context of NFV, a VM QQ508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs QQ508, and that part of hardware QQ504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs QQ508 on top of the hardware QQ504 and corresponds to the application QQ502.

[0157] Hardware QQ504 may be implemented in a standalone network node with generic or specific components. Hardware QQ504 may implement some functions via virtualization. Alternatively, hardware QQ504 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration QQ510, which, among others, oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system QQ512 which may alternatively be used for communication between hardware nodes and radio units.

[0158] Fig. 14 shows a communication diagram of a host QQ602 communicating via a network node QQ604 with a UE QQ606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE QQ112a of Fig. 9 and / or UE QQ200 of Fig. 10), network node (such as network node QQl lOa of Fig. 9 and / or network node QQ300 of Fig. 11), and host (such as host QQ116 of Fig. 9 and / or host QQ400 of Fig. 12) discussed in the preceding paragraphs will now be described with reference to Fig. 14.

[0159] Like host QQ400, embodiments of host QQ602 include hardware, such as a communication interface, processing circuitry, and memory. The host QQ602 also includes software, which is stored in or accessible by the host QQ602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE QQ606 connecting via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and host QQ602. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection QQ650.

[0160] The network node QQ604 includes hardware enabling it to communicate with the host QQ602 and UE QQ606. The connection QQ660 may be direct or pass through a core network (like core network QQ106 of Fig. 9) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0161] The UE QQ606 includes hardware and software, which is stored in or accessible by UE QQ606 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE QQ606 with the support of the host QQ602. In the host QQ602, an executing host application may communicate with the executing client application via the OTT connection QQ650 terminating at the UE QQ606 and host QQ602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection QQ650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection QQ650.

[0162] The OTT connection QQ650 may extend via a connection QQ660 between the host QQ602 and the network node QQ604 and via a wireless connection QQ670 between thenetwork node QQ604 and the UE QQ606 to provide the connection between the host QQ602 and the UE QQ606. The connection QQ660 and wireless connection QQ670, over which the OTT connection QQ650 may be provided, have been drawn abstractly to illustrate the communication between the host QQ602 and the UE QQ606 via the network node QQ604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0163] As an example of transmitting data via the OTT connection QQ650, in step QQ608, the host QQ602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE QQ606. In other embodiments, the user data is associated with a UE QQ606 that shares data with the host QQ602 without explicit human interaction. In step QQ610, the host QQ602 initiates a transmission carrying the user data towards the UE QQ606. The host QQ602 may initiate the transmission responsive to a request transmitted by the UE QQ606. The request may be caused by human interaction with the UE QQ606 or by operation of the client application executing on the UE QQ606. The transmission may pass via the network node QQ604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step QQ612, the network node QQ604 transmits to the UE QQ606 the user data that was carried in the transmission that the host QQ602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step QQ614, the UE QQ606 receives the user data carried in the transmission, which may be performed by a client application executed on the UE QQ606 associated with the host application executed by the host QQ602.

[0164] In some examples, the UE QQ606 executes a client application which provides user data to the host QQ602. The user data may be provided in reaction or response to the data received from the host QQ602. Accordingly, in step QQ616, the UE QQ606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of the UE QQ606. Regardless of the specific manner in which the user data was provided, the UE QQ606 initiates, in step QQ618, transmission of the user data towards the host QQ602 via the network node QQ604. In step QQ620, in accordance with the teachings of the embodiments described throughout this disclosure, the network node QQ604 receives user data from the UE QQ606 and initiates transmission of the received user datatowards the host QQ602. In step QQ622, the host QQ602 receives the user data carried in the transmission initiated by the UE QQ606.

[0165] One or more of the various embodiments improve the performance of OTT services provided to the UE QQ606 using the OTT connection QQ650, in which the wireless connection QQ670 forms the last segment. More precisely, the teachings of these embodiments may improve the responsiveness of communications and efficiency of utilization of communication resources, and thereby provide benefits such as reduced user waiting time for communication latency, relaxed restriction on file size, extended battery lifetime, etc.

[0166] In an example scenario, factory status information may be collected and analyzed by the host QQ602. As another example, the host QQ602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host QQ602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host QQ602 may store surveillance video uploaded by a UE. As another example, the host QQ602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host QQ602 may be used for energy pricing, remote control of non-time critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0167] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection QQ650 between the host QQ602 and UE QQ606, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host QQ602 and / or UE QQ606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection QQ650 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 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection QQ650 may include message format, retransmission settings, preferred routingetc.; the reconfiguring need not directly alter the operation of the network node QQ604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host QQ602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection QQ650 while monitoring propagation times, errors, etc.

[0168] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0169] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of thoseparticular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.A listing of example embodiments follows:Group A Embodiments1. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to remove an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the method comprising: sending (400) to the source BH-gNB an Xn REMOVAL REQUEST message indicating a reason for Xn connection removal; receiving (402) from the source BH-gNB an Xn REMOVAL RESPONSE message acknowledging removal of the Xn connection; and setting up (404) an Xn connection towards a target BH-gNB.2. The method of Embodiment 1, wherein the setting up the Xn connection towards the target BH-gNB, comprises: setting up the Xn connection towards the target BH-gNB based on information obtained from the source BH-gNB.3. The method of any of Embodiments 1 to 2, wherein the setting up the Xn connection towards the target BH-gNB, comprises: setting up the Xn connection towards the target BH-gNB based on information obtained from a network node other than the source BH-gNB, wherein the information comprises preconfigured information obtained from the network node and stored in the WAB-gNB before the sending of the Xn REMOVAL REQUEST message to the source BH-gNB.4. The method of any of Embodiments 1 to 3, further comprising: sending to at least one other BH-gNB different from the source BH-gNB and the target BH-gNB, the Xn REMOVAL REQUEST message indicating the reason for Xn connection removal;receiving from the at least one other BH-gNB at least one other Xn REMOVAL RESPONSE message acknowledging removal of the Xn connection by the at least one other BH-gNB.5. The method of any of Embodiments 1 to 4, further comprising: receiving from at least one other BH-gNB different from the source BH-gNB and the target BH-gNB, at least one other Xn REMOVAL RESPONSE message indicating removal of the Xn connection by the at least one other BH-gNB responsive to a message received from the source BH-gNB indicating that a WAB-Mobile Termination, WAB-MT, has been handed over elsewhere from the source BH-gNB; and performing actions related to the Xn connection removal by the at least one other BH- gNB.6. The method of any of Embodiments 1 to 5, further comprising: determining whether to send to the source BH-gNB the Xn REMOVAL REQUEST message based on whether the source BH-gNB will remain a neighbour of the WAB-gNB after the Xn connection is setup toward the target BH-gNB.7. The method of any of Embodiments 1 to 6, further comprising obtaining from the Xn REMOVAL RESPONSE contact details of the target BH-gNB towards which the WAB-gNB is to setup the Xn connection.8. The method of any of Embodiments 1 to 7, further comprising obtaining from the Xn REMOVAL RESPONSE contact details of neighbor BH-gNBs of the target BH-gNB.9. The method of any of Embodiments 1 to 8, further comprising, prior to the sending to the source BH-gNB the Xn REMOVAL REQUEST message indicating the reason for Xn connection removal, sending to the source BH-gNB an earlier Xn REMOVAL REQUEST message indicating a reason for Xn connection removal, and receiving from the source BH-gNB an Xn REMOVAL FAILURE message indicating a cause of Xn connection removal failure.10. The method of any of Embodiments 1 to 9, further comprising: providing user data; and forwarding the user data to a host via the Xn connection towards the target BH-gNB.Group B Embodiments11. A method performed by a source Backhaul, BH,-gNB to remove an Xn connection between a Wireless Access and Backhaul, WAB,-gNB and the source BH-gNB, the method comprising: sending (500) to the WAB-gNB an Xn REMOVAL REQUEST message indicating a reason for Xn connection removal; and receiving (502) from the WAB-gNB an Xn REMOVAL RESPONSE message acknowledging removal of the Xn connection.12. The method of Embodiment 11, wherein the sending to the WAB-gNB of the Xn REMOVAL REQUEST message is performed based on determining that handover of a WAB- Mobile Termination, WAB-MT, is imminent and / or based on determining that the WAB-MT has become unauthorized necessitating removal of the Xn connection.13. The method of any of Embodiments 11 to 12, further comprising inserting in the Xn REMOVAL REQUEST message contact details of a target BH-gNB towards which the WAB- gNB is to setup an Xn connection.14. The method of any of Embodiments 11 to 13, further comprising, prior to the sending to the WAB-gNB the Xn REMOVAL REQUEST message, sending to the WAB-gNB an earlier Xn REMOVAL REQUEST message indicating a reason for Xn connection removal; and receiving from the WAB-gNB an Xn REMOVAL FAILURE message indicating a cause of Xn connection removal failure.15. The method of any of Embodiments 11 to 14, further comprising: obtaining user data; and forwarding the user data to a host via an Xn connection between the WAB-gNB and a target BH-gNB.Group C Embodiments16. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to suspend and then resume an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the method comprising: sending (600) to the source BH-gNB an Xn SUSPENSION REQUEST message indicating a reason for Xn connection suspension; receiving (602) from the source BH-gNB an Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection; and resuming (604) the Xn connection towards the source BH-gNB.17. The method of Embodiment 16, further comprising: based on receiving the Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection, storing application-level data related to the suspended Xn connection at the WAB-gNB.18. The method of Embodiment 17, further comprising: based on the resuming of the Xn connection towards the source BH-gNB, reactivating for use the application-level data stored at the WAB-gNB.19. The method of any of Embodiments 16 to 18, further comprising: inserting in the Xn SUSPENSION RESPONSE message an indication of length of a suspension period.20. The method of any of Embodiments 16 to 19, wherein resuming the Xn connection towards the source BH-gNB, comprises: sending an Xn resumption request to the source BH-gNB or receiving an Xn resumption request from the source BH-gNB.21. The method of any of Embodiment 20, further comprising: sending an Xn RESUMPTION RESPONSE message confirming resumption of the Xn connection towards the source BH-gNB.22. The method of any of Embodiment 20, further comprising: sending an Xn RESUMPTION FAILURE message indicating a cause of failure of resumption of the Xn connection towards the source BH-gNB.23. The method of any of Embodiments 16 to 22, further comprising: agreeing on a frequency of suspension and resumption of the Xn connection through configuration communications with the source BH-gNB, wherein the resuming of the Xn connection towards the source BH-gNB is performed based on the frequency agreed with the source BH-gNB.24. The method of any of Embodiments 16 to 23, further comprising: providing user data; and forwarding the user data to a host via the Xn connection resumed towards the source BH-gNB.Group D Embodiments25. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to establish an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the method comprising: sending (700) to the source BH-gNB an Xn SETUP REQUEST message requesting setup of the Xn connection or receiving from the source BH-gNB the Xn SETUP REQUEST message, wherein the Xn SETUP REQUEST message contains an indication that the WAB- gNB is co-located with a WAB-MT; and receiving (702) from the source BH-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection or sending to the source BH-gNB the Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.26. The method of Embodiment 25, further comprising: obtaining from an Operations And Management node, contact details of the source BH- gNB; and establishing the Xn connection based on the contact details of the source BH-gNB.27. The method of any of Embodiments 25 to 26, further comprising: obtaining from a WAB-Mobile Termination, WAB-MT, a gNB ID of the source BH- gNB; performing a domain name system, DNS, query based on the gNB ID to obtain contact details of the source BH-gNB; and establishing the Xn connection based on the contact details of the source BH-gNB.28. The method of any of Embodiments 25 to 27, further comprising: providing user data; and forwarding the user data to a host via the Xn connection.Group E Embodiments29. A method by a first Wireless Access and Backhaul, WAB,-gNB to communicate with a second WAB-gNB, the method comprising: sending (800) to the second WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection; and receiving (802) from the second WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.30. The method of Embodiment 29, wherein the Xn SETUP REQUEST message contains an indication that the first WAB-gNB is a WAB node.31. The method of any of Embodiments 29 to 30, further comprising: determining that the second WAB-gNB is a WAB node based on at least one of: an Xn SETUP REQUEST received from the second WAB-gNB; content of a UE measurement report; content of a WAB-Mobile Termination, WAB-MT, measurement report; information received from an 0AM node; and Xn signaling with other nodes.32. The method of any of Embodiments 29 to 31, further comprising: determining from the Xn Response message a cause value indicating that an Xn between WAB nodes not allowed and / or that the second WAB-gNB is or is not a WAB node.33. The method of any of Embodiments 29 to 32, further comprising:obtaining from Xn RESPONSE message indicating failure to setup the Xn connection, a reason for Xn setup failure.34. The method of Embodiment 33, wherein the Xn RESPONSE message indicates a reason for Xn setup failure as occurring from rejection of the Xn connection setup request by the second WAB-gNB.Group F Embodiments35. The method of any of Embodiments 1 to 10, further comprising: while the Xn connection is active between the WAB-gNB and the source BH-gNB, transferring messages between the source BH-gNB and a WAB-Mobile Termination, WAB- MT, using signaling radio bearer, SRB.36. A Wireless Access and Backhaul, WAB,-gNB, for removing an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the WAB-gNB comprising: processing circuitry configured to perform any of the steps of any of the Group A embodiments; and power supply circuitry configured to supply power to the processing circuitry.37. A source Backhaul, BH,-gNB to remove an Xn connection between a Wireless Access and Backhaul, WAB,-gNB and the source BH-gNB, the source BH-gNB comprising: processing circuitry configured to perform any of the steps of any of the Group B embodiments; and power supply circuitry configured to supply power to the processing circuitry.38. A Wireless Access and Backhaul, WAB,-gNB, to suspend and then resume an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the WAB-gNB comprising: processing circuitry configured to perform any of the steps of any of the Group C embodiments; and power supply circuitry configured to supply power to the processing circuitry.39. A Wireless Access and Backhaul, WAB,-gNB, to establish an Xn connection betweenthe WAB-gNB and a source Backhaul, BH,-gNB, the WAB-gNB comprising: processing circuitry configured to perform any of the steps of any of the Group D embodiments; and power supply circuitry configured to supply power to the processing circuitry.40. A first Wireless Access and Backhaul, WAB,-gNB to communicate with a second WAB- gNB, the first WAB-gNB comprising: processing circuitry configured to perform any of the steps of any of the Group E embodiments; and power supply circuitry configured to supply power to the processing circuitry.41. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and a network interface configured to forward the user data via the Xn connection of any of Groups A-F embodiments, in a cellular network for transmission to a user equipment (UE).REFERENCES[1] RP -234041 New SID: Study on additional topological enhancements for NRABBREVIATIONS

[0170] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).AF Application FunctionAMF Access and Mobility Management FunctionAN Access NetworkAPI Application Programming InterfaceAS Access StratumASN.1 Abstract Syntax Notation OneBH BackhaulCA Certificate AuthorityControl ElementCGI Cell Global IdentityCN Core NetworkCP Control Plane cu Central UnitDC Dual ConnectivityDHCP Dynamic Host Configuration ProtocolDNS Domain Name SystemDRB Data Radio BearerDTRX Discontinuous transmission and receptionDU Distributed UnitFQDN Fully Qualified Domain Name gNB Radio base station in NRGNSS Global Navigation Satellite SystemGPS Global Positioning SystemHPLMN Home Public Land Mobile NetworkHSS Home Subscriber ServerIdentifier / IdentityIAB Integrated Access and BackhaulInformation ElementMCC Mobile Country CodeMCG Master Cell GroupMN Master NodeMNC Mobile Network CodeMR-DC Multi-Radio Dual ConnectivityMT Mobile TerminationNAS Non-Access StratumNEF Network Exposure FunctionNG The interface between a gNB and an AMFNGAP NG Application ProtocolNG-RAN NG Radio Access NetworkNR New RadioOAM / O&M Operation and MaintenancePCF Policy Control FunctionPDU Protocol Data UnitPLMN Public Land Mobile NetworkPTM Point to MultipointPTP Point to PointQCI QoS Class IdentifierQFI QoS Flow IdentifierQoS Quality of ServiceRA Registration AuthorityRACH Random Access ChannelRAN Radio Access NetworkRAT Radio Access TechnologyREF Radio Link FailureRRC Radio Resource ControlRSRP Reference Signal Received PowerRSRQ Reference Signal Received QualityRSSI Received Signal Strength IndicatorSCTP Stream Control Transmission ProtocolSeGW Security GatewaySINR Signal to Interference and Noise RatioSMF Session Management FunctionSMO Service Management and OrchestrationSN Secondary NodeTA Terminal AdaptorTE Terminal EquipmentTS Technical SpecificationUDM User Data ManagementUE User EquipmentUPF User Plane FunctionVPLMN Visited Public Land Mobile NetworkWAB Wireless Access and BackhaulIx RTT CDMA2000 lx Radio Transmission Technology3GPP 3rd Generation Partnership Project5G 5th Generation5GCN 5G Core Network5GS 5G System6G 6thGenerationABS Almost Blank SubframeARQ Automatic Repeat RequestAWGN Additive White Gaussian NoiseBCCH Broadcast Control ChannelBCH Broadcast ChannelCA Carrier AggregationCC Carrier ComponentCCCH SDU Common Control Channel SDUCDMA Code Division Multiplexing AccessCGI Cell Global IdentifierCIR Channel Impulse ResponseCP Cyclic PrefixCPICH Common Pilot ChannelCPICH Ec / No CPICH Received energy per chip divided by the power density in the bandCQI Channel Quality informationC-RNTI Cell RNTICSI Channel State InformationDCCH Dedicated Control ChannelDL DownlinkDM DemodulationDMRS Demodulation Reference SignalDRX Discontinuous ReceptionDTX Discontinuous TransmissionDTCH Dedicated Traffic ChannelDUT Device Under TestE-CID Enhanced Cell-ID (positioning method) eMBMS evolved Multimedia Broadcast Multicast ServicesE-SMLC Evolved-Serving Mobile Location CentreECGI Evolved CGI eNB E-UTRAN NodeB ePDCCH Enhanced Physical Downlink Control ChannelE-SMLC Evolved Serving Mobile Location CenterE-UTRA Evolved UTRAE-UTRAN Evolved UTRANFDD Frequency Division DuplexFFS For Further Study gNB Base station in NRGNSS Global Navigation Satellite SystemHARQ Hybrid Automatic Repeat RequestHO HandoverHSPA High Speed Packet AccessHRPD High Rate Packet DataLOS Line of SightLPP LTE Positioning ProtocolLTE Long-Term EvolutionMAC Medium Access ControlMAC Message Authentication CodeMBSFN Multimedia Broadcast multicast service Single Frequency NetworkMBSFN ABS MBSFN Almost Blank SubframeMDT Minimization of Drive TestsMIB Master Information BlockMME Mobility Management EntityMSC Mobile Switching CenterNPDCCH Narrowband Physical Downlink Control ChannelOCNG OFDMA Channel Noise GeneratorOFDM Orthogonal Frequency Division MultiplexingOFDMA Orthogonal Frequency Division Multiple AccessOSS Operations Support SystemOTDOA Observed Time Difference of ArrivalO&M Operation and MaintenancePBCH Physical Broadcast ChannelP-CCPCH Primary Common Control Physical ChannelPCell Primary CellPCFICH Physical Control Format Indicator ChannelPDCCH Physical Downlink Control ChannelPDCP Packet Data Convergence ProtocolPDP Profile Delay ProfilePDSCH Physical Downlink Shared ChannelPGW Packet GatewayPHICH Physical Hybrid-ARQ Indicator ChannelPMI Precoder Matrix IndicatorPRACH Physical Random Access ChannelPRS Positioning Reference SignalPSS Primary Synchronization SignalPUCCH Physical Uplink Control ChannelPUSCH Physical Uplink Shared ChannelQAM Quadrature Amplitude ModulationRAN Radio Access NetworkRFC Radio Uink ControlRLM Radio Uink ManagementRNC Radio Network ControllerRNTI Radio Network Temporary IdentifierRRM Radio Resource ManagementRS Reference SignalRSCP Received Signal Code PowerRSRP Reference Symbol Received Power ORReference Signal Received PowerRSTD Reference Signal Time DifferenceSCH Synchronization ChannelSCell Secondary CellSDAP Service Data Adaptation ProtocolSDU Service Data UnitSFN System Frame NumberSGW Serving GatewaySI System InformationSIB System Information BlockSNR Signal to Noise RatioSON Self Optimized Network ss Synchronization Signal sss Secondary Synchronization SignalTDD Time Division DuplexTDOA Time Difference of ArrivalTOA Time of ArrivalTSS Tertiary Synchronization SignalTTI Transmission Time IntervalUL UplinkUSIM Universal Subscriber Identity ModuleUTDOA Uplink Time Difference of ArrivalWCDMA Wide CDMAWLAN Wide Local Area NetworkAPPENDIXThe following submission document is included in the present disclosure:3GPP TSG RAN Meeting #102 RP-234041Edinburgh, Scotland, December 11-15, 2023 (revision of RP- yyxxxx)Source: AT&T (moderator, RAN VC)Title: New SID: Study on additional topological enhancements for NRDocument for: ApprovalAgenda Item: 9. 1.3.33GPP™ Work Item DescriptionInformation on Work Items can be found at http: / / www.3gpp.org / Work-Items See also the 3GPP Working Procedures, article 39 and the TSG Working Methods in 3GPP TR 21.900Title: Study on additional topological enhancements for NRAcronym: FS_WAB_5GFemto_NRUnique identifier:NOTE: For new WIs / SIs leave the Unique identifier empty and make a proposal for an Acronym.For a revised WI / SI: Take Unique identifier and acronym as shown in 3GPP workplan.If this is a RAN WID including Core and Perf. part, then Title, Acronym and Unique identifier refer to the feature WI.Please tick (X) the applicable box(es) in the table below:Either:or:Potential target Release: Rel-19NOTE: In case of contradiction with the target dates of clause 5, clause 5 determines the target release.1 Impacts2 Classification of the Work Item and linked work items2. 1 Primary classificationThis description is either a . . . X | Study Item | or a>2.2 Parent Work ItemNOTE: RAN agreed some time ago, that it describes the feature WI + Core / Perf. part WI or Testing part WI in one WID. Therefore the table above should include the feature WI data (In case the feature covers Core and Perf. part, please list under Working Group the leading WG of the Core part).2.3 Other related Work Items and dependenciesNOTE: Also related or dependent WIs / SIs in other TSGs shall be indicated here.3 JustificationThe justification for the study on additional topological enhancements for NR will be categorized into a set of justifications for Wireless Access Backhaul (WAB) and a set of justifications for 5G Femto.Wireless Access Backhaul (WAB):The legacy building blocks for 5G RAN topologies should be enhanced to provide a broader range of use cases, such as:- 5G access for UEs onboard aircrafts, cruise ships, helicopters, and vehicles in remote areas with limited sky visibility via an onboard gNB.- Backhauling of NG and Xn via TN and NTN, including support of NTN <-> TN handover for backhaul.- Support for onboard / on-site MEC and local services.- Support for backhauling without RAN-sharing or roaming agreements between access PLMN(s) and backhaul PLMN(s).- Backhauling for local gNB deployed in public safety or disaster recovery scenarios.It is assumed that Wireless Access Backhaul (WAB) is aligned with VMR use cases and with the SA2 -endorsed SID on architectural enhancements for Rel-19 VMR. It is expected that single-hop backhauling is sufficient for Wireless Access Backhaul (WAB) and that there is no impact to UEs at this late stage of 5G deployment.5G Femto:5G Femto is analogous to the LTE concept of HeNB, deployed at e.g. home or at enterprise premises. HeNB has been widely deployed in many LTE markets across multiple regions with great success. It is important to enable 5G Femto use cases to provide NR access at home or at enterprise premises. The motivations for the study objectives are as follows:- 5G Femto offers a cost-effective way to improve 5G indoor coverage, offload macro gNB network traffic, enable better voice quality, and better support for Enterprise mobility.- 5G Femto extends coverage using higher frequency bands, leading to efficient and effective usage of higher frequency spectrum.- High number of mobile sessions are indoor and inside coverage with 5G mid and high-bands is limited. Need for a solution that enables simple end user plug and play and allowing for customized access control.- High bandwidth and throughput with 5G are required at home and at campus locations to enable new immersive applications such as AR / VR / MR gaming, e- sports, UHD 8K video, telepresence, etc.Support for large numbers of 5G Femto should be possible in a scalable manner.Access control for 5G Femto can leverage the CAG concept defined for PNI-NPN. It is expected that there should be no impact to UEs at this late stage of 5G deployment.4 Objective4.1 Objective of SI or Core part WI or Testing part WIThe objectives for the study on additional topological enhancements for NR will be categorized into a set of objectives for Wireless Access Backhaul (WAB) and a set of objectives for 5G Femto.The objectives of the Wireless Access Backhaul (WAB) study are as follows:- Study the support of WAB including [RAN3, RAN2]:- Study the architecture and protocol stack of supporting a gNB with MT function providing PDU session backhaul.- Study impact of WAB mobility within an existing RAN (e.g., inter-gNB neighbour relations).- Identify necessary inter-gNB- and gNB-to-CN signalling to address the support of WAB.- Study signalling enhancements on resource multiplexing for WAB. NOTE 1: No impact on the UE.NOTE 2: Coordination with other WGs (e.g. SA2) when needed.The WAB study does not preclude any backhaul scenario (e.g. NTN or TN). The objectives of the5G Femto study are as follows:- Study the overall RAN architecture and required functional and procedural impacts for supporting 5G Femto deployments [RAN3],- Study how to define the 5G access control mechanism by (re-)using the existing CAG functionality and identify needed enhancements (if any) [RAN3],- Clarify the access to local services from the 5G Femto via collocated local UPF and identify issues, if any [RAN3],NOTE 1: The study involves a gap analysis of existing 5G functionality with HomeNB functionality. NOTE 2: No impact on the UE.NOTE 3: Coordination with other WGs (e.g. SA2) when needed.4.2 Objective of Performance part WINOTE: Leave empty if the WI proposal does not contain a RAN performance part.N / A4.3 RAN time budget request (not applicable to RAN5 WIs / SIs)NOTE: For all new RAN related WIs / SIs which are not led by RAN WG5 the WI / SI rapporteur has to fill out the attached Excel table to request time budgets for corresponding RAN WG meetings.The Excel table has to be filled out for all affected RAN WGs and up to the target date of the WI / SL One time unit (TU) corresponds to ~ 2 hours in the meeting.If no TU is needed, then leave the field empty otherwise enter a number >0 in the field.For revisions of already approved WI / SI descriptions: Please remove the Excel table from the WID / SID's zip file. The time budgets are already recorded. If you want to modify them, then this has to be done via the status report and not via a revised WID / SID. Expected Output and Time scaleNOTE: If this is a RAN WI including Core and Perf. part, then all new Core part specs have to be listed first and then all new Perf. part specs. Indicate "Core part" or "Perf. part" under Remarks for each spec.By default a new specs can only be new for one of both parts.NOTE: If this is a RAN WI including Core and Perf. part, then all new Core part specs have to be listed first and then all new Perf. part specs. Indicate "Core part" or "Perf. part" under Remarks for each spec. If an existing spec is affected by both (Core part and Perf. part), then it has to be listed twice with appropriate approval dates.

Claims

CLAIMS:

1. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to remove an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the method comprising: sending (400) to the source BH-gNB Xn removal signaling indicating a reason for Xn connection removal; receiving (402) from the source BH-gNB Xn signaling indicating a target BH-gNB; and setting up (404) an Xn connection towards the target BH-gNB.

2. The method of Claim 1, wherein the setting up the Xn connection towards the target BH-gNB, comprises: setting up the Xn connection towards the target BH-gNB based on information about the target BH-gNB and information about neighbor BBh-gNBs, obtained from the Xn signaling received from the source BH-gNB.

3. The method of any of Claims 1 to 2, wherein the setting up the Xn connection towards the target BH-gNB, comprises: setting up the Xn connection towards the target BH-gNB based on information obtained from the Xn removal signaling received from the source BH-gNB, wherein the information comprises pre-configured information obtained from the network node and stored in the WAB-gNB before the sending of the Xn removal signaling to the source BH-gNB.

4. The method of any of Claims 1 to 3, further comprising: sending to one other BH-gNB different from the source BH-gNB and the target BH-gNB, Xn removal signaling indicating the reason for Xn connection removal; receiving from the other BH-gNB at least one other Xn signaling .

5. The method of any of Claims 1 to 4, further comprising: receiving from one other BH-gNB different from the source BH-gNB and the target BH-gNB, at least one other Xn signaling indicating removal of the Xn connection by the other BH-gNB responsive to a message received from the source BH-gNB indicating that a WAB-Mobile Termination, WAB-MT, has been handed over elsewhere from the source BH- gNB; andperforming actions related to the Xn connection removal by the at least one other BH- gNB.

6. The method of any of Claims 1 to 5, further comprising: determining whether to send to the source BH-gNB the Xn signaling based on whether the source BH-gNB will remain a neighbour of the WAB-gNB after the Xn connection is setup toward the target BH-gNB.

7. The method of any of Claims 1 to 6, further comprising obtaining from the Xn signaling received from the source BH-gNB contact details of the target BH-gNB towards which the WAB-gNB is to setup the Xn connection, wherein the contact details comprise one of a gNB identifier or global gNB identifier, a TNL address of the target BH-gNB, information to be used for establishing SCTP connections and TNL associations, a reference to a database storing further contact details, and a neighbour relation table.

8. The method of any of Claims 1 to 7, further comprising obtaining from the Xn signaling received from the source BH-gNB contact details of neighbor BH-gNBs of the target BH- gNB, wherein the contact details comprise one of a gNB identifier or global gNB identifier, a TNL address of the neighbor BH-gNBs, information to be used for establishing SCTP connections and TNL associations, a reference to a database storing further contact details, and a neighbour relation table.

9. The method of any of Claims 1 to 8, further comprising, prior to the sending to the source BH-gNB the Xn removal signaling indicating the reason for Xn connection removal, sending to the source BH-gNB an earlier Xn removal signaling indicating a reason for Xn connection removal, and receiving from the source BH-gNB an Xn REMOVAL FAILURE message indicating a cause of Xn connection removal failure.

10. The method of any of Claims 1 to 9, wherein the sending (400) to the source BH-gNB of the XN removal signaling is performed based on determining that a WAB-Mobile Termination, WAB-MT, has become unauthorized necessitating removal of the Xn connection.

11. A method performed by a source Backhaul, BH,-gNB to remove an Xn connection between a Wireless Access and Backhaul, WAB,-gNB and the source BH-gNB, the method comprising: receiving (500) from the WAB-gNB XN removal signaling indicating a reason for Xn connection removal; and sending (502) to the WAB-gNB Xn signaling indicating a target BH-gNB.

12. The method of Claim 11, wherein the receiving from the WAB-gNB of the XN removal signaling is based on when handover of a WAB-Mobile Termination, WAB-MT, is imminent and / or based on when the WAB-MT has become unauthorized necessitating removal of the Xn connection.

13. The method of any of Claims 11 to 12, further comprising inserting in the Xn signaling contact details of the target BH-gNB towards which the WAB-gNB is to setup an Xn connection, wherein the contact details comprise one of a gNB identifier or global gNB identifier, a TNL address of the target BH-gNB, information to be used for establishing SCTP connections and TNL associations, a reference to a database storing further contact details, and a neighbour relation table.

14. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to suspend and then resume an Xn connection between the WAB-gNB and a source Backhaul, BH,-gNB, the method comprising: sending (600) to the source BH-gNB an Xn SUSPENSION REQUEST message indicating a reason for Xn connection suspension; receiving (602) from the source BH-gNB an Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection; and resuming (604) the Xn connection towards the source BH-gNB.

15. The method of Claim 14, further comprising: based on receiving the Xn SUSPENSION RESPONSE message acknowledging suspension of the Xn connection, storing application-level data related to the suspended Xn connection at the WAB-gNB.

16. The method of Claim 15, further comprising: based on the resuming of the Xn connection towards the source BH-gNB, reactivating for use the application-level data stored at the WAB-gNB.

17. The method of any of Claims 14 to 16, further comprising: inserting in the Xn SUSPENSION RESPONSE message an indication of length of a suspension period.

18. The method of any of Claims 14 to 19, wherein resuming the Xn connection towards the source BH-gNB, comprises: sending an Xn resumption request to the source BH-gNB or receiving an Xn resumption request from the source BH-gNB.

19. The method of any of Claim 18, further comprising: sending an Xn RESUMPTION RESPONSE message confirming resumption of the Xn connection towards the source BH-gNB.

20. The method of any of Claim 18, further comprising: sending an Xn RESUMPTION FAILURE message indicating a cause of failure of resumption of the Xn connection towards the source BH-gNB.

21. The method of any of Claims 14 to 20, further comprising: agreeing on a frequency of suspension and resumption of the Xn connection through configuration communications with the source BH-gNB, wherein the resuming of the Xn connection towards the source BH-gNB is performed based on the frequency agreed with the source BH-gNB.

22. The method of any of Claims 14 to 21, further comprising: providing user data; and forwarding the user data to a host via the Xn connection resumed towards the source BH-gNB.

23. A method performed by a Wireless Access and Backhaul, WAB,-gNB, to establish anXn connection between the WAB-gNB and a Backhaul, BH,-gNB, the method comprising: sending (700) to the BH-gNB an Xn SETUP REQUEST message requesting setup of the Xn connection or receiving from the BH-gNB the Xn SETUP REQUEST message, wherein the Xn SETUP REQUEST message contains an indication that the WAB-gNB is colocated with a WAB-MT; and receiving (702) from the BH-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection or sending to the BH-gNB the Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

24. The method of Claim 23, further comprising: obtaining from an Operations And Management node, contact details of the BH-gNB; and establishing the Xn connection based on the contact details of the BH-gNB.

25. The method of any of Claims 23 to 24, further comprising: obtaining from a WAB-Mobile Termination, WAB-MT, a gNB ID of the BH-gNB; performing a domain name system, DNS, query based on the gNB ID to obtain contact details of the BH-gNB; and establishing the Xn connection based on the contact details of the BH-gNB.

26. The method of any of Claims 23 to 25, further comprising: providing user data; and forwarding the user data to a host via the Xn connection.

27. A method by a first Wireless Access and Backhaul, WAB,-gNB to communicate with a second WAB-gNB, the method comprising: sending (800) to the second WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection; and receiving (802) from the second WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

28. The method of Claim 27, wherein the Xn SETUP REQUEST message contains anindication that the first WAB-gNB is a WAB-gNB.

29. The method of any of Claims 27 to 28, further comprising: determining from the Xn Response message a cause value indicating that an Xn between WAB nodes not allowed and / or that the second WAB-gNB is or is not a WAB node.

30. The method of any of Claims 27 to 29, wherein the Xn RESPONSE message comprises an Xn SETUP FAILURE message.

31. The method of Claim 30, wherein the Xn RESPONSE message comprises an XN SETUP FAILURE that indicates a reason for Xn setup failure as occurring from rejection of the Xn connection setup request by the second WAB-gNB.

32. A method by a second Wireless Access and Backhaul, WAB,-gNB to communicate with a first WAB-gNB, the method comprising: receiving (800) from the first WAB-gNB an Xn SETUP REQUEST message requesting setup of an Xn connection; and sending (802) to the first WAB-gNB an Xn RESPONSE message indicating setup of the Xn connection or indicating failure to setup the Xn connection.

33. The method of Claim 32, further comprising: determining that the first WAB-gNB is a WAB node based on at least one of: an Xn SETUP REQUEST received from the first WAB-gNB; content of a UE measurement report; content of a WAB-Mobile Termination, WAB-MT, measurement report; information received from an 0AM node; and Xn signaling with other nodes.

Images