Managing connectivity of a mobile wireless access and backhaul node

Abstract

A method for use in managing connectivity of a mobile wireless access backhaul, WAB, node, the mobile WAB node being or having last been served by a cell controlled by a first backhaul gNB and to be connected to a second backhaul gNB, the method at the second backhaul gNB comprising: receiving a request for serving a mobile WAB node; receiving information associated with the mobile WAB node; accepting or rejecting the request for serving the mobile WAB node based on the received information, wherein the information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node; status information associated with the mobile WAB node. The status information associated with the mobile WAB node may include at least one of: information for indicating the expected trajectory of the mobile WAB node; information for indicating a current speed of the mobile WAB node; information for indicating a priority level to give to the mobile WAB node; information for indicating an authorization status of the mobile WAB node.

Description

The present invention generally relates to methods for use in managing connectivity of a mobile Wireless Access Backhaul (WAB) node of a wireless communication system. For example, the disclosure relates to methods for use in a process for managing the mobility of nodes of a wireless communication system involving at least one mobile WAB node. BACKGROUND Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations (gNBs). The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH). Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi. The demand for network densification increases due to the rising number of users and higher throughput requirement. Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, from release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs). IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations. IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public / private passengers transportation, goods delivery, food trucks ...). The speed of some of the vehicles may be pretty low or at least similar to pedestrian speed and some of these vehicles may even be temporarily stationary. Some of these vehicles (e.g. buses, trains or trams), may have predictable routes and / or limited mobility areas (e.g. some vehicles, such as food trucks or promotional vehicles, may be located outside stadiums or show venues) while others may have predictable stationary locations (e.g. taxis). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as relays. These relays would rely on 5G wireless backhaul (typically 1AB, or Integrated Access &Backhaul) for connecting to a fixed donor device. Thus, based upon the fixed IAB foundations set out in Releases 16 and 17, 3GPP is now considering Mobile IAB systems and architecture, as a part of the Release 18 framework, in order to address scenarios focusing on mobile lAB-nodes mounted on vehicles (for example, a bus, a train, a taxi). In such scenarios, mobile lAB-nodes can also be referred to as Vehicle Mounted Relays (VMR), providing 5G coverage / capacity to on-board and / or surrounding UEs. The technical benefits of using vehicle relays include, among others, the ability of the relay vehicle to get better coverage than the nearby UE, thanks to better RF / antenna capabilities, thus providing the UE with a better link to the macro network. Additionally, a vehicle relay is expected to have less stringent power / battery constraints than the UEs. Some enhancements further considered by 3GPP for Release 19, consider the need for 5G access for UEs onboard aircrafts, cruise ships, helicopters and vehicles in remote areas with limited sky visibility (e.g. where terrestrial cellular coverage or Wi-Fi coverage is not available), support for onboard / on-site mobile edge computing (MEC), local services, and direct local inter-UE communications, or local gNB deployment in public safety or disaster recovery scenarios. The backhauling links for the base stations providing the 5G access in such scenarios would then be operated over either a terrestrial network (TN), or a non-terrestrial network (NTN), with a possibility to handover communications from a terrestrial network to a non-terrestrial network and vice-versa. Such base stations can be referred to as Wireless Access Backhaul (WAB) nodes, or WAB nodes, or mobile WAB nodes, or MW AB nodes. As part of these wireless backhauling enhancements, 3GPP is also considering some evolution to the former LTE-based Femto framework, including a new 5G Femto or 5G Femtocell that would offer 5G indoor coverage improvement while allowing high bandwidth and throughput at home for new immersive applications such as AR / VR / MR gaming, e-sports, UHD 8K video, telepresence, etc. It can be noted that a MW AB node may deploy 5G Femto cells to serve UEs inside vehicles. While moving, a MW AB node may lose the backhaul connectivity with the serving base station (which may be terrestrial or non-terrestrial), the MW AB node may experience a radio link failure (RLF), and as a result, the MW AB node may then perform a reestablishment procedure with a new base station. To prevent situations with radio link failure, when the backhaul link is becoming weak with a serving base station, the MW AB node may be handed over from the serving (source) base station to a target base station. Prior to the handover procedure, dual-connectivity may be setup for a MW AB node, so that it will be served by two base stations at the same time, with one master base station and a secondary base station. Such actions (reestablishment, handover, dualconnection) would preserve the connectivity of the UEs served by the MW AB node, and so guarantee service continuity at the UEs. As a MW AB node may serve numerous UEs, a rejection of a request for MW AB node handover, dual-connectivity, or reestablishment, would have an impact on many users, and this should be avoided as much as possible. Thus, a target base station should not reject a MW AB node as a new served node when the target base station has the capacity to accept it. The target base station should give priority to such a request. On the other hand, a target base station that has not the capacity to accommodate the traffic associated with a MW AB node serving many UEs, should not accept a request for reestablishment, handover, dual-connection. It is therefore desirable to provide solutions to manage connectivity of a mobile WAB node (MW AB node) to facilitate service continuity at the UEs served by the MW AB node. SUMMARY In accordance with an aspect of the invention, there is provided a method for use in managing connectivity of a mobile wireless access backhaul, WAB, node. The mobile WAB node, for example, is being or has last been served by a cell controlled by a first backhaul gNB. The mobile WAB node is to be connected to a second backhaul gNB. The method at the second backhaul gNB comprises: receiving a request for serving a mobile WAB node; receiving information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node); accepting or rejecting the request for serving the mobile WAB node based on the received information. The information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node); status information (or current status information) associated with the mobile WAB node. In accordance with an aspect of the invention, there is provided a method for use in managing connectivity of a mobile wireless access backhaul, WAB, node. The mobile WAB node is being served by a cell controlled by a first backhaul gNB. The method at the first backhaul gNB comprises: sending a request for a second backhaul gNB to serve a mobile WAB node. The request includes information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node). The information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node); status information (or current status information) associated with the mobile WAB node. In accordance with an aspect of the invention, there is provided a method for use in managing connectivity of a mobile wireless access backhaul, WAB, node. The mobile WAB node has been last served by a cell controlled by a first backhaul gNB and is to be connected to a second backhaul gNB. The method at the mobile WAB node comprises: sending, to the second backhaul gNB, a request for serving the mobile WAB node. The request includes information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node). The information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node); status information (or current status information) associated with the mobile WAB node. In accordance with an aspect of the invention, there is provided a method for use in managing connectivity of a mobile wireless access backhaul, WAB, node. The mobile WAB node has been last served by a cell controlled by a first backhaul gNB and is to be connected to a second backhaul gNB. The method at the first backhaul gNB comprises: receiving, from the second backhaul gNB, a request to provide information related to the mobile WAB node; sending, to the second backhaul gNB, a response. The response includes information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node). The information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node); status information (or current status information) associated with the mobile WAB node. One or more of the information for indicating the mobile WAB node supports local services, the information for indicating maximum supported load at the mobile WAB node, the information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node), may be considered as information indicating the capability of the mobile WAB node. Thus, for each of the above methods, the information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node) may include at least one of: information indicating the capability of the mobile WAB node (which capability information may include at least one of information for indicating the mobile WAB node supports local services, information for indicating maximum supported load at the mobile WAB node, the information for identifying a gNB component of the mobile WAB node (e.g. the gNB component co-located with a MT component of the mobile WAB node)); status information (or current status information) associated with the mobile WAB node. The information associated with the mobile WAB node may additionally (or alternatively to one or more of the following: the information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component of the mobile WAB node; status information (or current status information) associated with the mobile WAB node) include information for indicating the node is a MW AB node (which may also be referred to as MW AB indication information). The MW AB indication information may be at least one slice identifier, such as at least one S-NSSAI, or a list of one or more slice identifiers (S-NSSAIs) or may be a MW AB indication IE or UE capability IE which is part of the UE capabilities. In accordance with an aspect of the present invention, there is provided an apparatus for a backhaul gNB as recited in claim 59 of the accompanying claims. In accordance with an aspect of the present invention, there is provided an apparatus for a mobile WAB node as recited in claim 60 of the accompanying claims. By providing information associated with the mobile WAB node to the second backhaul gNB (e.g. target / secondary / new gNB), the second backhaul gNB can know that the node related to a request to serve the node is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the request to serve the mobile WAB node. Thus, the decision to accept or to reject such a request shall be based on relevant information elements related to the MW AB node. In a scenario, it may be preferable to not allow a WAB topology with multiple hops where a MW AB node is served by another MW AB node: for instance to avoid the likely increase in the transmission latency to transfer data between UEs and a core network if such a multi hop WAB topology was set up. For this purpose, a target base station which is a MW AB node should not normally accept a request for reestablishment, handover, dual-connection from another MW AB node. Thus, in the case where the second backhaul gNB (e.g. target base station) is a MW AB node and / or is configured to not allow or to avoid WAB topology with multiple hops, by providing the relevant information related to the MW AB node to the second backhaul gNB (e.g. the target RAN node), the second backhaul gNB can determine that the MW AB node is a WAB node and so can reject the request to serve the mobile WAB node and avoid establishing a WAB topology with multiple hops. Thus, when the second backhaul gNB determines that the MW AB node is a WAB node, the second backhaul gNB may send a response indicating the request is rejected in one of the following cases: the case where the second backhaul gNB is a WAB node; the case where the second gNB is configured to not serve other WAB nodes; the case where the second backhaul gNB is a WAB node and is configured to not serve other WAB nodes. The response may include cause information for indicating the reason for the rejection. In an example, the cause information indicates any one of: “WAB multi-hop avoidance” or “WAB multi-hop not allowed” or “WAB multi-hop prevention” or “target is a WAB node” or “target is not configured to serve WAB nodes”. In the following description and claims some new mechanisms are described to provide relevant information elements for the decision at the second backhaul gNB (e.g. target / secondary / new gNB) to accept or to reject to serve a MW AB node. The invention in general relates to signaling that a reestablishment, dual connectivity or handover request involves a MW AB node so that the decision to accept or to accept the request can be taken accordingly. Optionally, to assist the decision, the signaling may comprise information regarding the traffic involved by serving the MW AB node. This has particular relevance to a mobile communications network (e.g. 5G) utilizing MW AB nodes. Other applications include other wireless communication networks such as WiFi where a mobile base station, or relay, or access point may be utilized. In the example of a mobile communications network such as 5G, the messages are exchanged between gNBs (specifically their central units), or exchanged between a gNB and the core network. Other wireless networks may have equivalent nodes and the invention may equally apply to these. Further example features of the invention are described in other independent and dependent claims. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program. BRIEF DESCRIPTION OF THE DRAWINGS Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more example embodiments; Figure 2 is a simplified schematic diagram of a 5G system in which the present invention may be implemented according to one or more example embodiments; Figure 3 is a simplified schematic diagram of a 5G system involving a Mobile Wireless Access Backhaul (MWAB) node, and in which the present invention may be implemented according to one or more example embodiments; Figure 4 is a block schematic diagram of an example network node or base station in accordance with one or more embodiments of the invention; Figure 5 is a simplified schematic diagram showing an example of a WAB network or WAB network system; Figure 6 is a schematic and simplified diagram showing an example message flow for performing a Xn handover of a MW AB node, in accordance with one or more embodiments of the invention; Figure 7 is a schematic and simplified diagram showing an example message flow for performing a NG handover of a MW AB node, in accordance with one or more embodiments of the invention; Figure 8 is a schematic and simplified diagram showing an example message flow for establishing dual-connectivity at a MW AB node, in accordance with one or more embodiments of the invention; Figure 9 is a schematic and simplified diagram showing an example message flow for connection reestablishment of a MW AB node, in accordance with one or more embodiments of the invention; Figure 10a is a flowchart of an example method for managing at a first gNB (source gNB or master gNB) the handover or the dual-connection for a MW AB node in accordance with one or more embodiments of the invention; Figure 10b is a flowchart of an example method for managing at a MW AB node the connection reestablishment following a Radio Link Failure (RLF) in accordance with one or more embodiments of the invention; Figure 10c is a flowchart of an example method for managing at a second gNB (target gNB or secondary gNB or new gNB) the handover, dual-connection, or connection reestablishment of a MW AB node in accordance with one or more embodiments of the invention; Figure lOd is a flowchart of an example method for managing at a first gNB the request to retrieve UE context related to a MW AB node in accordance with one or more embodiments of the invention; Figure 11 is a schematic and simplified diagram showing another example message flow for performing a Xn handover of a MW AB node, in accordance with one or more embodiments of the invention. DETAILED DESCRIPTION Figure 1 illustrates an example communication system 100 in which the present invention may be implemented according to one or more embodiments. As depicted, the example system 100 is a wireless communication system, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a Wireless Access Backhaul (WAB) communication system or network. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having an integrated access and backhaul communication system which shares radio resources for wireless access links and wireless backhaul links. The system 100 comprises a plurality ofUEs (User Equipment) 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, a communication satellite 160, a satellite dish 101, a remote core network 170, three fixed Base Stations 102, 103 and 104, a plurality of Mobile Wireless Access Backhaul (MWAB) nodes 110 (mounted on plane 161), 120a and 120b (mounted on train 162), 140 (mounted on Unmanned Aerial Vehicle (UAV) 164) and 150 (mounted 8 on backpack 165 or other carrier that can be carried by a user (e.g. in a disaster zone)), and a Wireless Access Backhaul (WAB) node 130 (or Home gNB, mounted in house 163) which is fixed but based on the same architecture as a MW AB node. In more general terms, a WAB node may be mounted on or in a vehicle (such as a train, bus, taxi, tram, etc.) and / or an aircraft or flying vehicle (such as a plane, UAV, helicopter, etc. ) and / or a building (such as a house, enterprise / company / office building, hotel building, airport building, sports / event buildings, shopping centre building, etc..) and / or a portable carrier that can be carried by a user (such as a backpack, bag, etc), for example, in a disaster zone or for public safety or for emergency services, and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). In an example where the WAB node is implemented in a 5G femto network, the WAB node functions as a 5G femto node and may be mounted at a building (such as a house, enterprise / company / office building, hotel building, airport building, sports / event buildings, shopping centre building, etc..) and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). When it is a mobile base station, a WAB node is also referred to as a Mobile WAB (MWAB) node. Some examples of UEs include smartphones / tablets (such as UEs 111, 123, 134, 142, 152), XR headsets (such as UEs 112, 122, 132), cameras (such as UEs 141 and 151), fixed video cameras (such as UEs 113, 121, 133, 153) or mobile / wearable video cameras (such as UEs 143 and 154). In general, the UE may be any portable or handheld or mobile telephone, a smartphone, a tablet, a portable or fixed computer, fixed or mobile camera, portable television or other similar wireless communication device. In the following description, the term UE will be used and it is not intended to limit the description to any particular type of wireless communication device. Base stations 102, 103 and 104 are interconnected through a wired link infrastructure 180, preferably based on optical fiber or any other wired means. Base stations 102, 103 and 104 are also connected to the core network 170 through a wired link infrastructure 190, preferably based on optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, base stations 102, 103 and 104 are 5GNR base stations (referred to as a gNB), as defined in 3GPP TS 38.300 v 18.0.0 specification document. Satellite dish 101 (e.g. satellite gateway) is also connected to wired link infrastructure 180 or 190, or to both infrastructures. Besides infrastructures 180 and 190 may be the same infrastructure. In one example, a part of a base station is embedded in the satellite 160 while the other part is embedded in the gateway 101, meaning that the base station is split between the satellite 160 and the gateway 101. In another example, a full base station is embedded in the satellite 160 and the gateway 101 connects the base station 160 with the infrastructure 180 or 190. In order to extend the network coverage of base stations 102,103 and 104 and reach the remote UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154,mobile WAB nodes or MW AB nodes, or MWAB-nodes, 110, 120a, 120b, 130, 140 and 150, have been installed on vehicles / mobile equipment 161, 162, 163, 164 and 165. By acting as relaying nodes between the base stations 102, 103 and 104 and the UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, MWAB-nodes 110, 120a, 120b, 130, 140 and 150 allow overcoming the reachability issue resulting from limited sky visibility while ensuring support for onboard / on-site mobile edge computing (MEC), local services, and direct local inter-UE communications. This allows further communication between base stations 102, 103 and 104 and the UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154 and / or communications between the UEs served by a same MWAB-node (e.g., UEs 151, 152, 153 and 154 connected to MW AB node 150). The base stations 102, 103 and 104, the MW AB nodes 110, 120a, 120b, 130, 140 and 150, the satellite 160, the satellite dish 101 are thus forming a backhaul network or WAB network (also referred to as WAB topology), or MW AB network (also referred to as MW AB topology), which accommodates UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154. The terms WAB network, MW AB network, WAB topology and MW AB topology will be used interchangeably in the following. The WAB network is part of the Radio Access Network (RAN) or as referred to with respect to 5G, the Next Generation (NG) RAN. The base stations 102, 103 and 104, the MW AB nodes 110, 120a, 120b, 130, 140 and 150, the satellite 160, the satellite dish 101, and the core network 170 are thus forming a WAB system, or MW AB system, which accommodates UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154. The terms WAB system and MW AB system will be used interchangeably in the following. A base station, or gNB, such as base station 102, 103 or 104, is a logical node that provides the NR-connectivity, hosting both higher layer protocols, such as PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) protocols, and lower layer protocols, such as the RLC (Radio Link Control), MAC (Medium Access Control) and physical layer protocols. The MW AB nodes 110, 120a, 120b, 130, 140 and 150, which may serve multiple radio sectors, are wirelessly backhauled to the base station 102, 103 or 104, via a single logical hop associated to a single radio link (i.e., radio links D1041a, D1041b, D1031, D1022, D1021), or split into two radio links in the case of satellite relaying (radio links D1601a and D1601b). Although a single logical hop is shown in figure 1, it will be appreciated that, if allowed, the MW AB nodes could be wirelessly backhauled to the base station over multiple logical hops (for example, similar to the multiple hops provided in an IAB network). Each MW AB node consists of a gNB or RAN node or base station component or entity which is referred to as MWAB-gNB, or MW AB base station, and a Mobile Termination (MT) component or entity which is referred to as an MWAB-MT, or MWAB-Mobile Termination. The MWAB-gNB functionality on an MWAB-node allows or enables the MW AB node to serve UEs. The MWAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non-Access Stratum (NAS) functionalities and allows or enables connection to a fixed base station, or gNB, such as base station 102, 103 or 104. MW AB nodes 110, 120a, 120b, 140 and 150 are intended to be mobile devices that will move along with the vehicle they are mounted on. However, these MW AB nodes may remain at a fixed location for a significant duration when their associated vehicle is remaining still (e.g., a train may stop at a railway station, a plane may be parked at an airport for a while, a car / truck / fire engine or any other emergency vehicle may be parked nearby a disaster area). MW AB node 130 is likely to remain at fixed location and may be a 5G Femto node, which provides NR access at home or at enterprise premises. In such case, the 5G Femto node 130 may have a direct connection DI700 to the Core Network 170 through the wired link infrastructure 190, which is preferably based on optical fiber or any other wired means Regarding WAB scope and terminology, it can be noted that to facilitate the introduction of WAB in 5G system, there is an interest that the gNB serving the MT (Mobile Termination) of a WAB node (WAB-MT) can be a legacy gNB. In this case, the WAB-MT would appear as a legacy UE for the gNB, and this should not preclude the WAB-gNB (gNB of the WAB node) to serve UEs through PDU sessions at WAB-MT. Coexisting with legacy gNBs, some gNBs can be enhanced with WAB support, so as to optimize the handling of such particular WAB nodes, for instance for coordination with the WAB-gNB for resource multiplexing (i.e. to limit the interference by avoiding simultaneous transmissions at the WAB-gNB and at the gNB serving the WAB-MT). Thus, A WAB-MT may be served either by a legacy gNB or by gNBs enhanced with WAB support. As a result, the name of a gNB serving the MT should be a generic name, avoiding the term donor which may suggest that the gNB is a very specific RAN node. The term backhaul gNB, which can be abbreviated with BH gNB, seems then appropriate. The name of a gNB serving a WAB-MT is referred to as backhaul gNB or BH gNB. As an alternative wording, a base station serving a MT of a WAB node may be called a backhaul RAN node, which can be abbreviated with BH RAN node. To support coordination for resource multiplexing between a WAB node and a BH gNB supporting WAB, it seems preferable to establish a Xn connection (as defined in TS 38.423 with the XnAP protocol) between the WAB-gNB and a BH gNB. Then, if Xn connection can be established between WAB-gNB and BH gNB, it is also possible to establish Xn connection between the WAB-gNB and other gNBs in the neighbourhood. One interest would be to speed up the massive UE handovers that may happen when onboard UEs are leaving a vehicle equipped with the WAB node. Moreover, the Xn connection may also be established between the WAB-gNB and legacy gNBs. Thus, Xn connection between WAB-gNB and BH gNB, and between WAB-gNB and surrounding gNBs should be enabled. Besides, to take benefit of potential enhancements at gNBs, a gNB that supports WAB should advertise its WAB support in RAN. For instance, a WAB support indication may be included in SIB1 to indicate whether the cell can be considered by a WAB node as a preferred candidate for cell selection or cell reselection. SIB 1 is System Information Block message 1, defined TS 38.331. Thus, a gNB supporting WAB should advertise its WAB support in RAN. Figure 2 is a simplified schematic diagram of a 5G system 200 in which the present invention may be implemented according to one or more example embodiments. This figure illustrates the possible standardized interfaces between the various elements composing the system. First, it represents a User Equipment (UE) 201 having a Uu interface with the New Generation (NG) Radio Access Network (RAN or NG-RAN) 202, and a N1 interface with an Access and Mobility management Function (AMF) entity or AMF 212 in a 5G core network (5GC) 210. Each base station composing the RAN 202 has a N2 interface with one or more Access and Mobility management Function (AMF) entity or AMF, like AMF 212, and a N3 interface with one or more User Plane Function (UPF) entity or UPF, like UPF 211. The N1 interface is used to convey Non-Access Stratum (NAS) protocol messages between a UE 201 and an AMF 212. NAS messages are used for the signaling between the UE and the core network for various procedures such as registration, session establishment, security, and mobility management. Actually, NAS messages are conveyed through the Uu interface between the UE 201 and the RAN 202, and the N2 interface between the RAN 202 and the AMF 212. An AMF 212 is responsible for handling registration, authentication, connection and mobility management tasks for a UE. For a WAB node, the AMF may apply the procedures defined in NAS protocol specifications (TS 24.502 section 5), considering the WAB node is a Mobile Base Station Relay (MBSR) introduced in Release 18. There may be several AMFs in a 5G core network, a standardized interface N14 enables the communications between AMFs. When a UE registers to the network through a serving base station, the serving base station will connect to an AMF suitable to handle the UE. When the UE 201 is registered, one or more Protocol Data Unit (PDU) session(s) can be set up to transfer data flows between the UE 201 and the Data Network (DN) 220 providing internet access. A PDU session is established between a UE 201 and a User Plane Function (UPF) 211 in the 5G core network 210. In the user plane, the UPF 211 connects to the Data Network (DN) 220 through the interface N6, and it is responsible for data packets routing with the required Quality of Service (QoS). There may be several UPFs on the data path with a N9 interface between UPFs. The user data between a UE 20land the Data Network 220 are thus conveyed through interfaces Uu, N3, N6 and potentially N9. In the control plane, the setup of PDU sessions is handled through NAS messages involving the Session Management Function (SMF) entity or SMF 213 in the 5G core network 210. The NAS messages are still exchanged between the UE 201 and the AMF 212 through the N1 interface, but an additional interface Nil between an AMF 212 and the SMF 213 is used to reach the SMF 213. In a 5G core network, the SMF is responsible for the setup, modification, and release of PDU sessions for a UE, as well as the Internet Protocol (IP) address allocation for the UE. To manage a PDU session, the SMF 213 controls the UPF 211 (configuration) based on QoS policy defined for the PDU session. For this purpose, a N4 interface exists between the SMF 213 and the UPF 211. A base station in RAN 202 operating in a first Public Land Mobile Network (PLMN) may serve a UE having a subscription for a second PLMN (called home PLMN) different from the first PLMN (called visited PLMN). In such a roaming case, there are two options to provide the UE 201 with an access to the Data Network 220. In a first option called home routed, the UPF and its controlling SMF to access the Data Network 220 are located in the 5G core network for the home PLMN. However, the SMF of the visited PLMN controls the intermediate UPF(s) of the visited PLMN, and interacts with the SMF of the home PLMN. In a second option called local breakout, the UPF and its controlling SMF to access the Data Network 220 are located in the 5G core network for the visited PLMN. However, the SMF interacts with the home 5G core network to get QoS policies associated with the UE’s PDU session(s). Figure 3 is a simplified schematic diagram of a 5G system 300 involving a Mobile Wireless Access Backhaul (MWAB) node, and in which the present invention may be implemented according to one or more example embodiments. This figure first represents a User Equipment (UE) 301 served by a MW AB node 310 through the Uu interface. The MW AB node 310 is composed of or includes a MT or MWAB-MT unit / component / entity 311 (also called MW AB-UE), and a gNB or MWAB-gNB unit / component / entity 312. Through the MWAB-gNB 312, a MW AB node acts as a gNB for UEs providing access to the 5G network, i.e. providing a NR access link to the UEs that can be located inside or outside the entity, such as a vehicle, equipped with the MW AB node 310( e.g. on entering / leaving the vehicle). In other words, the MWAB-gNB 312 includes full base station or gNB function (including both Central Unit (CU) and distributed unit (DU)) and MT function, where the gNB function is used to communicate with UEs for access service and the MT function is used to communicate with another gNB for backhauling purpose. The MW AB node 310 wirelessly connects to the 5G Core Network (using NR Uu interface) through an IP connectivity provided by PDU session(s) established by the MWAB-MT 311 via a gNB 320, which can be called a backhaul base station, backhaul gNB, backhaul RAN node or BH gNB. Acting as a legacy UE, the MWAB-MT 311 connects via a NG-RAN cell of the BH gNB 320, through a backhaul link that may be a direct link or via a satellite (e.g. when the MW AB node 310 is embedded in an airplane). Thus, a PDU session is provided either by a Terrestrial Network (TN) or by a Non-Terrestrial Network (NTN). In addition, the MW AB node 310 may embed some core network functions, like a UPF 313, to enable local services to the served UEs. The traffic associated to these local services does not need to use the links to / from the core network via the BH gNB 320, which has the advantages to reduce the load on these links and to run applications having very low latency requirements. For example, where the MW AB node 310 includes a UPF 313, the MW AB node can connect to one or more local servers (e.g. mounted at the same entity as the MW AB 310) enabling a UE served by the MW AB access to local services provided by the local servers with no traffic required outside of the MW AB node / server environment. The BH gNB 320 provides N3 and N2 interfaces so that the MWAB-MT 311 can access the functions of its 5G core network 330. Indeed, a MWAB-MT 311 may have access to some or several PLMNs through the appropriate subscriptions, and it may connect in a non-roaming manner to one PLMN, e.g. PLMN1 supported by the BH gNB (or BH RAN node) 320, and may then have access to the corresponding 5G core network 330. In particular the MWAB-MT 311 interacts with the AMF 332, which can be called the MW AB AMF or BH AMF, and establishes PDU session(s) with the UPF 331, which can be called the MW AB UPF or BH UPF. The MW AB UPF 331 is controlled by the SMF 333 (through N4 interface), which can be called the MW AB SMF or BH SMF, and which also interacts with the MW AB AMF 332 (through Nil interface). There may be one or several intermediate UPFs between the BH gNB 320 and the MW AB UPF 331 as mentioned in the Figure 2. An interface internal to the MW AB node 310 exists between the MWAB-gNB 312 and the MWAB-MT 311, which may be implemented on different or the same hardware resources. For instance, these two functions are implemented on the same processing unit 402 of Figure 4, and interactions exist between the two functions. Once the MWAB-MT 311 has established a PDU session with the MW AB UPF 331, the MW AB node is ready to serve UEs and the MWAB-gNB 312 can start operating as a legacy gNB. The MWAB-gNB may support various PLMNs and the UE 301 connects to one PLMN, e.g. PLMN2, which may be different from the PLMN1 the MWAB-MT 311 connects to. In the case where PLMN1 and PLMN2 are different, the UE 301 connects to the 5G core network 340, including a UPF 341, which can be called the UE UPF, an AMF 342, which can be called the UE AMF, and a SMF 343, which can be called the UE SMF. The UE SMF 343 interacts with the UE AMF 342 (through Nil interface) and the UE UPF 341 (through N4 interface). In the case where the PLMN1 and the PLMN2 are the same, the UE UPF 341, the UE AMF 342, the UE SMF 343, the MW AB UPF 331, the MW AB AMF 332, and the MW AB SMF 333 belong to the same 5G core network 350. In addition, the UE UPF 341 and the MWAB UPF 331 may be the same UPF, the UE AMF 342 and the MWAB AMF 332 may be the same AMF, the UE SMF 343 and the MWAB SMF 333 may be the same SMF. The connections between the UE 301 to the UE UPF 341 and to the UE AMF 342 are possible thanks to the N6 interface between the UE UPF 341 and the MWAB UPF 331, and thanks to the N6 interface between the MWAB UPF 331 and the UE AMF 342. These N6 interfaces enable the establishment of N2 interface between the MWAB-gNB 312 and the UE AMF 342, and the establishment of N3 interface between the MWAB-gNB 312 and the UE UPF 341, which allows the UE 301 to access the Data Network 360. In case the MWAB-MT 311 connects to the 5G network in a roaming manner corresponding to the home routed option, then the PLMN1 is the visited PLMN and the MWAB UPF 331 connects to another UPF not represented in the Figure 3 in the home PLMN through a N9 interface. It is this other UPF that provides the connection to the UE UPF 341 and the UE AMF 342 through N6 interfaces. In case the MWAB-MT 311 connects to the 5G network in a roaming manner corresponding to the local breakout option, then the PLMN1 is the visited PLMN and the MWAB UPF 331 directly connects to the UE UPF 341 and the UE AMF 342 through N6 interfaces as shown in the Figure 3. Figure 4 is a block schematic diagram of an example network node or RAN node or base station 400, such as base stations or gNBs or WAB nodes shown in Figure 1, in accordance with one or more embodiments of the invention. Each of a WAB node 110, 120a, 120b, 130, 140, or 150 of figure 1 may comprise the elements of the base station of figure 4. Also, the satellite 160 of figure 1 may comprise the elements of the base station of figure 4. In the following description, the network node 400 will be referred to generally as a base station. As will be apparent to a skilled person, Figure 4 is a simplified schematic diagram and shows only some of the functional components of an example base station 400 for use in describing the one or more embodiments of the invention. The base station 400 includes components for transmitting and receiving communications. As shown in Figure 4, the base station 400 includes a processing unit 402, a wireless interface 404, one or more antennas 410, a network interface 432, and memory 418. The network interface 432 manages communications of the base station 400 with the core network, other base stations, local network functions (like UPF), or local servers. It may provide a standardized interface, wired (e.g. fiber) or wireless, to support these communications. Through this network interface 432, the base station 400 may implement the standardized interfaces N2 (based on NGAP protocol) and N3 (based on GPRS tunneling protocol) with the core network, and the standardized interface Xn (based on XnAP protocol) with other base station of the Radio Access Network (RAN), all defined by the 3GPP standard. The network interface 432 may not be present or active in case the base station 400 is a MW AB node that does not support local services, that is not used as a legacy base station like base station 102, 104 in Figure 1, and that is not used as a home base station providing Femto cells like base station 130 in Figure 1. The wireless interface 404 is configured to provide wireless communication via communication links (414) with other wireless devices, such as one or more UEs, e.g. link 1041b between base station 104 and the MT / UE unit of MW AB node 120b, or link 1202 between the gNB unit of MW AB node 120b and the UE 122. In case of MW AB node, the wireless interface 410 may then be used both for the wireless backhaul link(s) with backhaul base station(s) and for the wireless link(s) with the UE(s) served by the MW AB node. The wireless interface 404 may be compliant with a fifth-generation (5G) New Radio (NR) system and thus implementing the Uu interface defined by 3GPP standard, or with other wireless communication system. The wireless interface 404 is coupled to the processing unit 402 and typically includes one or more antennas (such as the antenna 410), a receiving unit 406 and a transmitting unit 408. The configuration of the wireless interface 404 may be limited to connect to one antenna, but preferably several antennas are used, in order to provide beamforming capability. Although not shown in Figure 4, the receiving unit 406 typically includes elements such as a receiver, demodulator, decoder, and the transmitting unit 408 typically includes elements such as a transmitter, modulator, coder. The receiving unit 406 and transmitting unit 408 may together be referred to as a transceiver. The processing unit 402 is configured to carrying out processing for operation of the base station 400. The processing unit 402 may be a single processor (e.g. Central Processing Unit) or may comprise two or more processors. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person. The base station 400 includes memory 418 for storing data and computer programs containing instructions for the operation of the base station 400. Memory 418 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Memory 418 includes a program memory in which are stored programs containing processor instructions for operation of the base station 400 and for implementing the methods in accordance with one or more embodiments of the invention. The programs may contain a number of different program elements or sub-routines containing processor instructions for a variety of different tasks, for example, for: establishing, controlling and releasing communications with the UEs (e.g. implementing the Uu interface); processing data and signalling received at the receiving unit 406; processing signalling (e.g., paging messages, System Information Blocks) and data for transmission by the transmitting unit 408. Memory 418 may further include memory (e.g. RAM) for storing information. For example, information stored in memory 418 may include information associated with the mobile WAB node, such as static information elements 420 related to a MW AB node, dynamic information elements 422 related to the MW AB node. The static and dynamic information elements 420 and 422 may be associated to the base station 400 (when the base station is a MW AB node), and may be communicated to any network node when necessary. They may also be related to a MW AB node (which is not the base station 400), and stored after reception from the MW AB node or from another network node The operation of the static and dynamic information elements 420, 422 will be described in more detail below. Specific program elements / sub-routines stored in program memory may include one or more of the following: elements for sending a request for a backhaul RAN node to serve a mobile WAB node, the request including information associated with the mobile WAB node, elements for receiving a request for serving a mobile WAB node and for receiving information associated with the mobile WAB node, an element for accepting or rejecting the request for serving the mobile WAB node based on the received information, an element for receiving a request to provide information related to the mobile WAB node, an element for sending a response to the request to provide information, the response including information associated with the mobile WAB node (see, for example, the methods described below with reference to figures 6-9 and 10a-lOd). In an example arrangement, a communication bus 424 provides communication and interoperability between the various elements included in the base station 400 or connected to it. The representation of the bus is not limiting and in particular, the processing unit 402 is operable to communicate instructions to any element of the base station 400 directly or by means of another element of the base station 400. In an example implementation, the base station 400 may be or may include an apparatus comprising one or more processing units or processors for performing or implementing the methods in accordance with one or more embodiments of the invention. In other words, the apparatus is capable of performing one or more functions of the base station including performing the methods in accordance with one or more embodiments of the invention by means of the one or more processing units. For example, the one or more processing units uses software to implement the one or more embodiments of the invention as described above with reference to the processing unit 402 of Figure 4. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, a CPU of a microcontroller Unit (MCU), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated (e.g. on an Integrated Circuit) or discrete logic circuitry. However, alternatively, the one or more processing units for performing or implementing the methods may be implemented in hardware: for example, in the form of an Application Specific Integrated Circuit or ASIC or other hardware comprising logic element (s). Accordingly, the term “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. Figure 5 illustrates an example of a wireless communication system 500, including a WAB network or WAB network system, in which embodiments and examples of embodiments of the present invention may be implemented. A WAB network will also be referred to as a WAB network system, WAB topology, WAB system, topology or system and so in this application, the terms WAB network system, WAB network, WAB topology, WAB system, topology or system will be used interchangeably. The WAB network system of Figure 5, is composed of three base stations 501, 502 and 503, also referred to as Backhaul base stations, orbackhaul gNBs (also referred to as BH-gNB), two core networks 510 and 520, with the respective AMF entities 511a and 511b (for Core Network 510) and 521a and 521b (for Core Network 520) and the respective UPF entities 512a and 512b (for Core Network 510) and 522a and 522b (for Core Network 520), and two MW AB nodes 530 and 540. A wired backhaul IP network 590 interconnects the base stations 501, 502 and 503 and the Core Networks 510 and 520. For instance, this wired link consists of optical fiber cable(s). As discussed above, each MW AB node comprises a Mobile Termination (MT) part or unit or component (MWAB-MT 531 for MW AB node 530 and MWAB-MT 541 for MWAB node 540) and a base station / gNB part or unit or component (MWAB-gNB 532 for MWAB node 530 and MWAB-MT 542 for MWAB node 540). MW AB node 530 and MW AB node 540 may also embed a UPF entity, respectively UPF entity 533 and UPF 543, as previously discussed in figure 3, allowing MWAB-node 530 to provide UEs 551, 552 and 561 with some local services, such as for instance inter-UE communication where the user data exchanged between the two UEs would be routed through UPF entity 533 instead of being routed through a UPF entity belonging to Core Network 510 or 520. MW AB node 530 is connected to the serving backhaul base station referred to as BH-gNBl, 501 through BH link 5011. MW AB node 540 may be connected to the serving backhaul base station referred to as BH-gNB2, 502 through BH link 5021 or to the serving backhaul base station referred to as BH-gNB3, 503 through BH link 5031 or, in case of dual connectivity, to both the serving backhaul base station BH-gNB2, 502 through BH link 5021 and the serving backhaul base station BH-gNB3, 503 through BH link 5031. MWAB-gNB 532 of MW AB node 530 is also connected to UE 551 through communication link or radio link 5301 and to UE 552 through communication link or radio link 5302. Similarly, MWAB-gNB 542 of MW AB node 540 is also connected to UE 561 through communication link or radio link 5401. Although Figure 5 shows only UE 561 connected to MW AB node 540, it will be appreciated that there will be a plurality of UEs connected to MW AB nodes of the wireless communication system. MWAB-gNB 532 and MWAB-MT 531 may be connected to a same AMF function or entity (e.g., AMF 511a) or to different AMF functions or entities belonging to the same Core Network (e.g., AMF 511a and AMF 511b) or to different Core Networks (e.g., AMF 511a and AMF 521a). Some AMF functions may be implementing MWAB-specific features for managing a MW AB node (e.g., advanced mobility features). Some AMF functions may not implement such features but may still be capable of serving a MW AB node with a limited set of basic features. Some AMF functions may not be capable of serving a MW AB node. The processes and arrangements for managing one or more network connections in a wireless communication system including one or more mobile WAB (MWAB) nodes to facilitate service continuity for UE(s) served by the one or more mobile WAB nodes will now be described according to some embodiments of the present invention. Several scenarios are possible according for the MW AB nodes 530 and 540. Such scenarios may arise due to mobility of the MW AB nodes 530, 540. As a first scenario, and taking the example of MW AB node 540, a dual-connectivity configuration may be applied to the MWAB-MT 541, initially connected to BH-gNB2 502 only through the link 5021. Indeed, the MWAB-MT 541 periodically performs a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal). The MWAB-node may report to BH-gNB2 502 the presence of a new cell, for instance one cell managed by the BH-gNB3 503, through a measurement report. Based on the analysis of the measurement report, the BH-gNB2 502 may request to the BH-gNB3 503 the establishment of a dual connectivity for the MWAB-MT 541 with an additional connection through the link 5031. The BH-gNB3 503 may accept the request and proceed to the connection of the MWAB-MT 541 according to the procedure described in TS 37.340 section 10.2.2. As a result, the MWAB-MT 541, and thus the MW AB node 540 is dual-connected. The BH-gNB2 502 may take benefit of the dual connectivity of MW AB node 540 to balance the traffic load by offloading some traffic (data / user traffic or control traffic) initially planned to be transmitted through the link 5021. Some or all the traffic associated to the MW AB node 540 (i.e. control data related to the MW AB node, and control and user data related to the UEs served by the MW AB node 540) may be transmitted through the link 5031 and through the IP connectivity between BH-gNB2 502 and BH-gNB3 503. Dual-connectivity configuration is however transparent for the MMWAB-gNB 542 and for the UEs served by the MWAB-gNB 542. Such dual-connectivity procedure is further described below with reference to figure 8. As a second scenario, the radio link 5021 may experience radio link deficiency due to some unexpected interference or shadowing phenomena. For such reasons, the MWAB-MT 541 may lose the connection with the BH-gNB2 502 and declare a Radio Link Failure (RLF). Then, the MWAB-MT 541 will try to reestablish the connection in the same or a different cell controlled by BH gNB2 502 or by another gNB. Thus, the MWAB-MT 541 may try to connect to a cell controlled by BH gNB3 503 by requesting the establishment of the link 5031. In this case, the reestablishment procedure described in TS 38.300 section 9.2.3.3 may be applied, which enables a UE to maintain the RRC connection. With such procedure, the BH gNB3 503 sends to the BH gNB2 502 a request to retrieve the context of the MWAB-MT 541. Based on the response from the BH gNB2 502, the BH gNB3 503 may accept the connection of the MWAB-MT 541. Then, all the traffic related to the MW AB node 540 (and the served UEs) will now transit through the BH gNB 503. The reestablishment procedure does not involve the MWAB-gNB 542 and its served UEs. If the reestablishment is rapidly performed after RLF, the service interruption at the UE 561 may be avoided or limited. Such reestablishment procedure is further described below with reference to figure 9. As a third scenario, the MWAB-MT 541 may be handed over from the current serving cell to a new cell. Indeed, based on the measurement reports provided by the MWAB-MT 541, the BH- gNB2 502 may detect that the MWAB-MT 541 would have a better connection through a cell managed by the BH gNB3 503. Then, the BH-gNB2 502 may trigger a handover procedure described in TS 38.300 section 9.2.3.2. In this procedure, the BH-gNB2 502 sends a handover request to the BH gNB3 503 along with information related to the MWAB-MT 541. Based on this information, the BH gNB3 503 may accept the handover request and proceed to the admission of the MWAB-MT 541. Then, all the traffic related to the MW AB node 540 (and the served UEs) will now transit through the BH gNB 503. The handover procedure does not involve the MWAB-gNB 542 and its served UEs, and it may be transparent for MWAB-gNB and the served UEs (no interruption of service). Such handover procedure is further described below with reference to figure 6 and figure 7. In the scenarios discussed above, the target / secondary / new gNB decides whether to accept or reject a request for serving a MW AB node. As discussed in the introduction, the target / secondary / new gNB should not reject a MW AB node as a new served node when the target base station has the capacity to support the MW AB node and its served UEs. Furthermore, the target / secondary / new gNB should give priority to such a request. On the other hand, a target / secondary / new gNB that does not have the capacity to accommodate the traffic associated with a MW AB node serving many UEs, should not accept a request for serving the MW AB node (e g. a request for reestablishment, handover, dual-connection). Also, it may be preferable to not allow a WAB topology with multiple hops where a MW AB node is served by another MW AB node: for instance to avoid the likely increase in the transmission latency to transfer data between UEs and a core network if such a multi hop WAB topology was used. For this purpose, a target base station which is a MW AB node should not normally accept a request for reestablishment, handover, dual-connection of another MW AB node. In order to make the decision to accept or reject such a request, it is advantageous for the target / secondary / new gNB to make such a decision based on relevant information associated with the MW AB node. In the following description of figures 6-9 and lOa-lOd, details of information associated with the MW AB node that can be provided to the target / secondary / new gNB to help the target / secondary / new gNB make the decision is disclosed along with mechanisms that can be used to provide such information. Figure 6 is a schematic and simplified diagram illustrating an example message flow for performing Xn handover of a MW AB node according to embodiments of the invention. This figure shows a source base station or gNB 602 (or source backhaul gNB, or source BH gNB, or source BH RAN node) like the BH-gNB 502 of figure 5, a target base station or gNB 603 (or target backhaul gNB, or target BH gNB, or target BH RAN node) like the BH-gNB 503, a MW AB node 610 composed of or including the MWAB-gNB unit 611 and the MWAB-MT unit 612 (or MWAB-UE), and the AMF 604 of the MWAB-MT 612 (MW AB AMF or BH AMF) like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. At the beginning of the message flow, the MW AB node 610 is served by the gNB 602 through a cell (i.e. the serving or source cell) controlled by this gNB 602. The gNB 602 may be called source backhaul gNB or source BH gNB, or source BH RAN node. The MW AB node may serve one or several UEs (not represented in the Figure 6). The user data in downlink are provided by the 5GC to the source BH gNB 602 through a UPF (not represented in the Figure 6), then the user data are transmitted to the MWAB-MT 612. Once transferred to MWAB-gNB 611 through the internal interface between the MWAB-MT 612 and the MWAB-gNB 611, the user data are transmitted to the UE(s) through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC. The source BH gNB 602 may have some information related to or associated with the MW AB node 610 (which may be referred to as context information associated with the mobile WAB node), for instance because it was informed, by the MW AB node 610, at the RRC connection of the MW AB node 610 to the BH gNB 602, with the message RRC setup complete, specified in TS 38.331, which information may include an Information Element (IE) indicating the RRC connection is related to the MT of a MW AB node, and not a legacy UE (e.g. MW AB indication or information indicating the node is a MW AB node). Additional or alternative static TEs (eg. information in the static TEs does not change) may be provided with this RRC connection message sent by the MWAB-MT 312. For dynamic IEs that may change over time (e.g. information in the dynamic IEs changes over time), the MWAB-MT 612 may send UE assistance information including updated information associated with the MW AB node 610, which is a RRC message also defined in TS 38.331. Such updated information may be sent periodically or in response to a particular change (e.g. a large increase in the number of UEs served by the mobile WAB node). In one example, the MW AB indication information (e.g. information for indicating the mobile WAB node is a mobile WAB node) may be at least one slice identifier (e.g. at least one S-NSSAI, such as at least one S-NSSAI dedicated or assigned to WAB operation) indicating the mobile WAB node is a mobile WAB node or a list of one or more slice identifiers, or S-NSSAIs, as defined in 3GPP TS 38.423. A Single Network Slice Selection Assistance Information (S-NSSAI), as described in TS 38.423 section 9.2.3.21 is indicated for each PDU session resource to be setup by the target BH-gNB 603. The information element for the list of PDU session resources to be setup is defined in TS 38.423 section 9.2.1.1. At least one S-NSSAI may be dedicated to WAB operation (e g., as part of the subscription information for the MWAB-MT 612), and this indicates that the handover is related to a MWAB node. Network slicing is further described in TS 23.501 section 5.15. The additional static IEs related to a MW AB node and transmitted by a MWAB-MT may include one or more of the following information: - Local services support indication, to inform the MW AB node can provide local services onboard. For example, such local services support indication may include information indicating the MW AB node supports local services (e.g. for the served UEs); - Maximum supported load, to inform on the load the MW AB node may handle when serving UEs. This IE may indicate the maximum number of UEs the MWAB-gNB is capable of serving, and / or a maximum throughput the MW AB node is capable of handling, and / or a maximum computation power; The identifier of the MWAB-gNB co-located with MWAB-MT. For example, an IE may include information identifying a gNB or RAN node (e.g. unit or node providing base station, gNB functionality) of the mobile WAB node co-located with a mobile termination (e.g. mobile termination unit) of the mobile WAB node in the case where the mobile WAB node includes a mobile termination (e.g. MWAB-MT unit) and a RAN node (e.g. MWAB-gNB). The identifier or identifying information may be the Global RAN Node ID as specified in TS 38.413 section 9.3.1.5. The dynamic IEs related to a MW AB node and transmitted by a MWAB-MT may include one or more of: QoS or quality information related to or associated with the one or more UEs served by the MW AB node (e.g. served by the MWAB-gNB), this QoS information may include: o The number of served UEs, o The QoS profile associated to the traffic related to the served UEs, In an example, this refers to a list of QoS levels (for instance a list of 5QI, as defined by 3GPP TS 23.501). In another example, this refers to a maximum level of QoS, like for instance a 5QI information as defined in 3GPP TS 23.501, o The average throughput of the traffic related to the served UEs, o The peak throughput of the traffic related to the served UEs; - The expected trajectory (e.g. expected path) of the MW AB node, for instance in the form of a list of cells to connect to along the expected trajectory. The IE in addition may include the expected time the MW AB node is expected to remain connected in each cell; The current speed and / or velocity of the MW AB node; - The priority level to give to the MW AB node. For instance, if a MW AB node operates in a region experiencing natural disaster where emergency services shall be provided, then the priority level of the MW AB node would be high; - The authorization status of the MW AB node to operate as a WAB node (or a gNB). If this IE is a MW AB node authorization status, then this IE may also be used as a MW AB indication (and it is not needed to provide both the MW AB indication and the MW AB authorization status together). The authorization status may refer to the authorization of the MWAB-MT to support backhauling via PDU sessions, to the authorization of the MWAB-gNB to serve UEs, or to both authorization of the MWAB-MT and MWAB-gNB. In most cases, a WAB node is authorized to operate as a WAB node when the WAB-MT of the WAB node is authorized to support backhauling of WAB-gNB’s traffic via PDU sessions, and the WAB-gNB of the WAB node is authorized to serve UEs; The current operation status to inform whether the MW AB node is currently serving UEs. This IE may be completed with timing information, indicating how long the MW AB node is expected to remain in this state. This IE may be completed with information related to the type of operation, for instance for emergency situations like disaster recovery; The identifiers) of AMF(s) to which the co-located MWAB-gNB is connected. The AMF identifier may be the GUAMI as specified in TS 38.413 section 9.3.3.3. One or more of the QoS or quality information, expected trajectory information, the current speed and / or velocity information, the priority level information, the authorization status information and the identifier(s) of the AMF(s) can be considered as status information associated with the mobile WAB node. The static lEs may be considered as the capabilities of the MW AB node (i.e. the MW AB node capability). For example, the information associated with the mobile WAB node may include information indicating the capabilities of the MW AB node, such as one or more of: the information indicating the node is a MW AB node, the local services support indication, information for indicating maximum supported load at the MW AB node, information for identifying a gNB component of the MW AB node), as discussed above. These static lEs related to a MW AB or WAB node may be part of the UE radio access capabilities defined in the 3GPP document TS 38.306. The dynamic lEs may be considered as the current status of the MW AB node (i.e. the MW AB node status). The information associated with the mobile WAB node may include information indicating the current status of the MW AB node, such as one or more of: quality information, expected trajectory information, current speed and / or velocity information, priority level information, authorization status information and identifier(s) of the AMF(s), as discussed above. When served by the source BH gNB 602, the MWAB-MT 612 regularly performs measurement on signals received at the MWAB-MT 612 from the serving cell and one or more target cells (e.g. candidate cells), such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the MWAB-MT 612 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the MWAB-MT 612 may send a measurement report 621 to the source BH gNB 602 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of the MW AB node 610. The identity of each cell is included in the measurement report to allow the source BH gNB 602 to identify the gNB(s) controlling the reported cell(s). Based on the received measurement report, the source BH gNB 602 may detect that the MWAB-MT 612 receives radio signals in a cell controlled by the target gNB (or target backhaul gNB, or target BH gNB) 603 with a better quality than in the current serving cell controlled by the source BH gNB 602. The source BH gNB 602 may then decide at step 620 the handover of the MWAB-MT 612, and thus the handover of the MW AB node 610 to the target gNB (or target backhaul gNB, or target BH gNB) 603. The source BH gNB 602 may execute a Xn handover when there is a Xn interface between the source BH gNB 602 and the target BH gNB 603. To trigger the handover, the source BH gNB 602, sends a handover request message 622 to the selected target BH gNB 603 including the information related to or associated with the MW AB node 610 to be handed over. The handover request message may be the Handover Request message specified in the 3GPP document TS 38.423 section 9.1.1.1, which may in addition include information associated with the MW AB node 610. The information associated with the MW AB node 610 includes at least one of the information described above with respect to the static and dynamic IEs and may also include the MW AB indication IE defined above. The target BH gNB 603 receiving this MW AB indication IE can understand that the handover request is related to the handover of a MW AB node. All or part of the static and dynamic IEs related to MW AB node information and defined above, may also be used by the target BH gNB 603 in the admission control step 630 to decide whether the request is accepted or not. The decision may be based on criteria such as the current load of the target BH gNB 603 (load of the processing resources), and / or the current load on the target cell through which the MWAB-MT 612 would connect to the target BH gNB 603. The target BH gNB 603 may reject the handover request in the case where a connection with the MW AB node may create situations with overload. When the handover request concerns the handover of a MW AB node, the target BH gNB 603 may accept such request, as it may be the only possible option for the MW AB node to continue serving its UEs, taking also into account that the presence of the MW AB node may be temporary as it may not remain a long time in the target cell (e.g. from the expected trajectory information of the MW AB node). Besides, when the target BH gNB 603 is a WAB-gNB (or MWAB-gNB), the handover may be rejected to avoid WAB topology with multiple hops. A WAB-gNB may be configured, for instance by the Operations, Administration and Maintenance (0AM) server of its operating PLMN, to allow or to avoid WAB topology with multiple hops. A WAB-gNB may be configured to never allow multiple hops or to allow multiple hops in some circumstances. For instance, multiple hops may be tolerated when the WAB-gNB collocated with the handed over WAB-MT is currently not serving UEs (e.g. because it is not authorized to served UEs), or because the handed over WAB-node is moving fast and it would not remain connected to the WAB-gNB being the target BH RAN node for a long time, or because the handed over WAB node is currently operating for an emergency situation. Thus, by providing the information associated with the MW AB node to the target BH gNB 603, the target BH gNB 603 can know that the node related to the request is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the handover request. If the target BH gNB 603 has rejected the handover request, it sends a Handover Request Failure message (not represented in the figure 6) as defined in TS 38.423 section 8.2.1.3. Upon reception of this message, the source BH gNB 602 may consider another cell to hand over the MWAB-MT 612 The Handover Request Failure message may include a Cause Information Element (IE) to indicate the reason to reject a handover. The value of the Cause IE may be set to “No Radio Resources Available” as defined in TS 38.423 section 9.2.3.2. In case the target BH gNB 603 has rejected the handover to avoid WAB topology with multiple hops (because the target BH gNB 603 is a WAB-gNB (or MWAB-gNB)), the value of the Cause IE may be set to a new value to indicate “WAB multi-hop avoidance” or “WAB multi-hop not allowed” or “WAB multi-hop prevention” or “target is a WAB node” or “target is not configured to serve WAB nodes”. If the target BH gNB 603 has decided to accept the handover request, the handover procedure can be completed as defined in TS 38.300 section 9.2.3. Briefly, the target BH gNB 603 sends a handover request acknowledge message 623 to the source BH gNB 602. Then, the source BH gNB 602 sends a RRC Reconfiguration message 624 containing the necessary information for the MWAB-MT 612 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source BH gNB 602 from the target BH gNB 603 in the acknowledgment message 623). In case of conditional handover (CHO), the MWAB-MT 612 is configured with a triggering condition to fulfil before switching to the target cell. After switching to the target cell as the new serving cell, the MWAB-MT 612 performs a random-access channel (RACH) procedure 625 towards the target cell to acquire uplink synchronization. Once synchronization is established, the MWAB-MT 612 sends a RRC Reconfiguration Complete message 626 to the target BH gNB 603, which is now the new source or serving gNB for the MWAB-MT 612. In the meantime, the target BH gNB 603 may perform the path switch handshake procedure toward the MW AB AMF 604, with the exchange of Path Switch Request message 627 and Path Switch Request Acknowledge 628. It can be noted that the target BH gNB 603 knows the AMF of the MWAB-MT 612 as the ID of this AMF is included in the Handover Request message 622. Then, the control and user data associated with the MW AB node 610 and its served UEs will transit through the target BH gNB 603 and no more through the source BH gNB 602. Finally, the target BH gNB 603 sends a UE Context Release message 629 to the source BH gNB 602, to indicate that the handover procedure is completed, and that the source BH gNB 602 can delete the stored context information related to the MW AB node 610. In this figure, the messages 622, 623, 629 may correspond to the messages with the same name described in TS 38.423, the messages 621, 624, 626 may correspond to the messages with the same name described in TS 38.331, the messages 627, 628 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 625 may correspond to the RACH procedure described in TS 38.321. The WAB-related static IEs, which may include the MW AB indication IE, may be part of the UE capabilities embedded in the RRC context IE of the standardized handover request message. Figure 7 is a schematic and simplified diagram illustrating an example message flow for performing the NG handover of a MW AB node according to embodiments of the invention. This figure shows a source base station or gNB 702 (or source backhaul gNB, or source BH gNB, or source BH RAN node) like the BH-gNB 502 of figure 5, a target base station or gNB 703 (or target backhaul gNB, or target BH gNB, or target BH RAN node) like the BH-gNB 703, a MW AB node 710 composed of or including the MWAB-gNB unit 711 and the MWAB-MT unit 712 (or MW AB-UE), and the AMF 704 of the MWAB-MT 712 (MWAB AMF or BH AMF) like the AMF 521a, in a 5G core network (5GC) like the core network 520. The beginning of the message flow is similar to the message flow described above with reference to figure 6. The MW AB node 710 is served by the source BH gNB 702 through a cell (serving or source cell) controlled by this gNB. The source BH gNB 602 may have some information related to the MW AB node 710, in particular a part or all of the static and dynamic IEs defined above with reference to figure 6. The MWAB-MT 712 regularly performs measurement on signals received at the MWAB-MT 712 from the serving cell and one or more target cells (e.g. neighbouring candidate cells). Based on the received measurement reports, the source BH gNB 702 may detect that the MWAB-MT 712 receives radio signals in a cell controlled by the target gNB (or target backhaul gNB, or target BH gNB) 703 with a better quality than in the current serving cell controlled by the source BH gNB 702. The source BH gNB 702 may then decide at step 720 the handover of the MWAB-MT 712, and thus the handover of the MW AB node 710. The source BH gNB 702 may execute a NG handover, for instance when there is no Xn interface between the source BH gNB 702 and the target BH gNB 703. To trigger the handover, the source BH gNB 702, sends a handover required message 722 to the MW AB AMF 704 indicating the target cell for the handover (and thus indicating the selected target BH gNB 703). Then the MW AB AMF 704 sends a Handover Request message 723 to the target BH gNB 703 including the information related to or associated with the MW AB node 710 to be handed over. In particular, the information associated with the MW AB node 710 includes at least one of the information described above with respect to the static and dynamic IEs associated with the MW AB node 710 and may also include the MW AB indication IE associated with the MW AB node 710 defined above with reference to figure 6. The information associated with the MW AB node 710 may be included in the message 722 and message 723. The MW AB AMF 704 may already know the static IEs from the registration of the MWAB-MT 712 to the network. The MW AB AMF 704 may already know the dynamic IEs through a NAS protocol message transmitted by the MWAB-MT 712 (for instance through the UL NAS transport message defined in TS 24.501 section 8.2.10). Thus, the Handover Required message 722 may not need to include the IEs related to the MW AB node 710. The target BH gNB 703 receiving the handover request with the information related to the MW AB node performs the admission control step 730, similar to the step 630 of the figure 6, to decide whether the request is accepted or not. Thus, by providing the information associated with the MW AB node to the target BH gNB 703, the target BH gNB 703 can know that the node related to the request is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the handover request. If the target BH gNB 703 has rejected the handover request, it sends a Handover Failure message (not represented in the figure 7) as defined in TS 38.413 section 9.2.3.6. A Cause IE indicates the reason of rejection. Upon reception of this message, the MW AB AMF 704 sends to the source BH gNB 702 a Handover Preparation Failure (not represented in the figure 7) as defined in TS 38.413 section 9.2.3.3, and the source BH gNB 702 may consider another cell to hand over the MWAB-MT 612. The Cause IE in the Handover Preparation Failure message corresponds to the Cause IE in the Handover Failure message. The value of the Cause IE may be set to a value as discussed above with respect to the Handover Request Failure message. If the target BH gNB 703 has decided to accept the handover request, the handover procedure can be completed. Briefly, the target BH gNB 703 sends a handover request acknowledge message 724 to the MW AB AMF 704. Then the MW AB AMF 704 sends a Handover Command message 725 to the source BH gNB 702. Then, the source BH gNB 702 sends a RRC Reconfiguration message 726 containing the necessary information for the MWAB-MT 712 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source BH gNB 702 from the target BH gNB 703 via the acknowledgment message 724 and the Handover Command message 725). In case of conditional handover (CHO), the MWAB-MT 712 is configured with a triggering condition to fulfil before switching to the target cell. After switching to the target cell as the new serving cell, the MWAB-MT 712 performs a random-access channel (RACH) procedure 727 towards the target cell to acquire uplink synchronization. Once synchronization is established, the MWAB-MT 712 sends a RRC Reconfiguration Complete message 728 to the target BH gNB 703, which is now the new source or serving gNB for the MWAB-MT 712. The target BH gNB 703 can then send a Handover Notify message 729 to the MW AB AMF 704 to indicate that the handover procedure is completed. Finally, the MW AB AMF 704 sends a UE Context Release Command message 731 to the source BH gNB 702, to indicate that the handover procedure is completed, and that the source BH gNB 702 can delete the stored context information related to the MW AB node 710. The source BH gNB 702 may send a UE Context Release Complete message 732 to the MW AB AMF 704 to acknowledge this operation. It can be noted that the target BH gNB 703 does not need to execute the path switch handshake procedure toward the MW AB AMF 704, as the MW AB AMF 704 already knows the target BH gNB 703 as the new serving gNB for the MWAB-MT 712. In this figure, the messages 721, 726, 728 may correspond to the messages with the same name described in TS 38.331, the messages 722, 723, 724, 725, 729, 731, 732 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 727 may correspond to the RACH procedure described in TS 38.321. The WAB-related static lEs, which may include the MW AB indication IE, may be part of the UE capabilities embedded in the Target to Source Transparent Container IE of the standardized handover required and handover command messages. Figure 8 is a schematic and simplified diagram illustrating an example message flow for performing dual-connectivity of a MW AB node according to embodiments of the invention. This figure shows a master base station or gNB 802 (or master backhaul gNB or MN BH gNB, or MN BH RAN node) like the BH-gNB 502 of figure 5, a secondary base station or gNB 803 (or secondary backhaul gNB or SN BH gNB, or SN BH RAN node) like the BH-gNB 803, a MW AB node 810 composed of or including the MWAB-gNB unit 811 and the MWAB-MT unit 812 (or MW AB-UE), and the AMI 804 of the MWAB-MT 812 (MW AB AMF or BH AMF) like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. At the beginning of the message flow, the MW AB node 810 is served by the gNB 802 through a cell controlled by this gNB 802. The gNB 802 may be called the master backhaul gNB or MN BH gNB. The MW AB node may serve one or several UEs (not represented in the figure 8). The user data in downlink are provided by the 5GC to the MN BH gNB 802 through a UPF (not represented in the figure 6), then the user data are transmitted to the MWAB-MT 812. Once transferred to MWAB-gNB 811 through the internal interface between the MWAB-MT 812 and the MWAB-gNB 811, the user data are transmitted to the UE(s) through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC. The MN BH gNB 802 may have some information related to or associated with the MW AB node 810, for instance because it was informed, by the MW AB node 810, at the RRC connection of the MW AB node 810, with the message RRC setup complete, specified in TS 38.331, which information may include an Information Element (IE) indicating the RRC connection is related to the MT of a MW AB node, and not a legacy UE. Additional static IEs (e.g. information in the static IEs does not change) may be provided with this RRC connection message sent by the MWAB-MT 812. For dynamic IEs that may change over time (e.g. information in the dynamic IEs changes over time), the MWAB-MT 812 may send UE assistance information including updated information associated with the MW AB node 810, which is a RRC message also defined in TS 38.331. The static and dynamic IEs correspond to the ones described above with reference to figure 6. When served by the MN BH gNB 802, the MWAB-MT 812 regularly performs measurement on signals received at the MWAB-MT 812 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). Once the MWAB-MT 812 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), the MWAB-MT 812 may send a measurement report 821 to the MN BH gNB 802 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of the MW AB node 810. The identity of each cell is included in the measurement report to allow the MN BH gNB 802 to identify the gNB controlling the reported cell. Based on the received measurement reports, the MN BH gNB 802 may detect that the MWAB-MT 812 receives radio signals in a cell controlled by a secondary gNB (or secondary backhaul gNB, or SN BH gNB) 803 with a quality good enough for the MWAB-MT 812 to establish a radio link with the SN BH gNB 803. The MN BH gNB 802 may then decide at step 820 to setup a dual-connectivity configuration at the MWAB-MT 812, and thus to dual-connect the MW AB node 810 with the secondary BH gNB 803. To trigger the dual-connectivity procedure, the MN BH gNB 802, sends a SN Addition Request message 822 to the selected SN BH gNB 803 including information related to or associated with the MW AB node 810 to dual-connect. The SN Addition Request message may be the S-Node Addition Request message specified in the 3GPP document TS 38.423 section 9.1.2.1, which may include at least one of the information associated with MW AB node 810 described above (with reference to figure 6) with respect to the static and dynamic IEs and may also include the MW AB indication IE defined with reference to figure 6. The SN BH gNB 803 receiving this MW AB indication IE can understand that the request is related to a MW AB node. All or part of the static and dynamic IEs related to MW AB node information may also be used by the SN BH gNB 803 in the admission control step 830 to decide whether the request is accepted or not. The decision may be based on the same criteria as for the handover case described with reference to figure 6. Thus, by providing the information associated with the MW AB node to the SN BH gNB 803, the SN BH gNB 803 can know that the node related to the request is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the SN addition request. If the SN BH gNB 803 has rejected the handover request, it sends a S-Node Addition Request Reject message (not represented in the figure 8) as defined in TS 38.423 section 9.1.2.3. Upon reception of this message, the MN BH gNB 802 will stop the dual-connectivity procedure. If the SN BH gNB 803 has decided to accept the request, the procedure can be completed as defined in TS 37.340 section 10.2.2. Briefly, the SN BH gNB 803 sends a SN Addition Request Acknowledge message 823 to the MN BH gNB 802. Then, the MN BH gNB 802 sends a RRC Reconfiguration message 824 containing the necessary information for the MWAB-MT 812 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the MN BH gNB 802 from the SN BH gNB 803 in the acknowledgment message 823). Finally, the MWAB-MT 812 sends a RRC Reconfiguration Complete message 825 to the MN BH gNB 802, which will forward the information to the SN BH gNB 803 through the message SN Reconfiguration Complete 826. In this figure, the messages 821, 824, 825 may correspond to the messages with the same name described in TS 38.331, the message SN Addition Request Acknowledge 823 may be the message S-Node Addition Request Acknowledge described in TS 38.423 section 9.1.2.2, and the message SN Reconfiguration Complete 826 may be the message S-Node Reconfiguration Complete described in TS 38.423 section 9.1.2.4. Figure 9 is a schematic and simplified diagram illustrating an example message flow for performing connection reestablishment at a MW AB node, in accordance with one or more embodiments of the invention. This figure shows a gNB 902 (or old backhaul gNB or old BH gNB, or old BH RAN node) like the BH-gNB 502 of figure 5, a gNB 903 (or new backhaul gNB or new BH gNB, or new BH RAN node) like the BH-gNB 503, a MW AB node 910 composed of or including the MWAB-gNB unit 911 and the MWAB-MT unit 912 (or MW AB-UE), and the AMF 904 of the MWAB-MT 912 (MWAB AMF or BH AMF) like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. At the beginning of the message flow, the MWAB node 910 is served by the gNB 902 through a cell controlled by this gNB 902. The MWAB node 910 may serve one or several UEs (not represented in the Figure 9). The user data in downlink are provided by the 5GC to the gNB 902 through a UPF (not represented in the figure 9), then the user data are transmitted to the MWAB-MT 912. Once transferred to MWAB-gNB 911 through the internal interface between the MWAB-MT 912 and the MWAB-gNB 911, the user data are transmitted to the UE(s) through a radio bearer. The user data in uplink are similarly transmitted in the opposite direction from the UE(s) to the UPF in the 5GC. The gNB 902 may have some information related to or associated with the MWAB node 910, for instance because it was informed, by the MWAB node 910, at the RRC connection of the MWAB node 910, with the message RRC setup complete, specified in TS 38.331, which may include an Information Element (IE) indicating the RRC connection is related to the MT of a MWAB node, and not a legacy UE. Additional static IEs (e.g. information in the static IEs does not change) may be provided with this RRC connection message sent by the MWAB-MT 912. For dynamic IEs that may change over time (e.g. information in the dynamic IEs changes over time), the MWAB-MT 912 may send UE assistance information including updated information associated with the MWAB node 910, which is a RRC message also defined in TS 38.331. The static and dynamic IEs correspond to the ones described above with reference to figure 6. When served by the gNB 902, the MWAB-MT 912 regularly performs measurement on signals received at the MWAB-MT 912 from the serving cell and one or more target cells, such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell). It may happen that the SSB signal in the serving cell meets predefined criteria (for instance a received power that is below a predefined threshold) during a sufficient time to declare, at step 920, a Radio Link Failure (RLF) for the link between the MWAB-MT 912 and the gNB 902. Besides, the MWAB-MT 912 may have detected a SSB signal that meets predefined criteria (for instance a received power that is above a predefined threshold) sufficient to attempt a new connection in the corresponding target cell. In that case, the MWAB-MT 912 triggers a reestablishment procedure as described in TS 38.300 section 9.2.3.3. It first consists in performing a random-access channel (RACH) procedure 921 to obtain uplink resources, and then to transmit a RRC Reestablishment Request message 922 in the target cell. This RRC message is received by gNB 903 controlling the target cell. The RRC Reestablishment Request message 922 includes information to identify the gNB 902 (i.e. the last serving gNB for the MWAB-MT 912), also this message includes information related to or associated with the MW AB node 910. The information includes at least one of the information described above with respect to the static and dynamic IEs and may also include the MW AB indication IE defined above with reference to figure 6. Upon the reception of the RRC Reestablishment Request message 922, and in case this message includes information related to the MW AB node 910, the gNB 903 may execute an admission control step 930 to decide to accept or to reject the connection request. The decision may be based on the same criteria as for the handover case described above with reference to figure 6. If the gNB 903 has rejected the request at step 930, it will not respond to the MWAB-MT 912 and the MW AB 910 will have to find another cell to try another reestablishment procedure. If the gNB 903 has accepted the request or if it has not executed the step 930, the gNB 903 sends a Retrieve UE Context Request message 923 to the gNB 902 to retrieve the context of the requesting MW AB node 910. In response, the gNB 902 sends to the gNB 903 a Retrieve UE Context Response message 924 including the context information related to the MW AB node 910. In the case where the gNB 903 has not executed step 930 (e.g. because gNB 903 has not received the information related to or associated with the MW AB node 910) or in the case where the request does include the information related to or associated with the MW AB node 910, the Retrieve UE Context Response message 924 may include information related to or associated with the MW AB node 910 which includes at least one of the information described above with respect to the static and dynamic IEs and may also include the MW AB indication IE defined above with reference to figure 6. Based on the information related to the MW AB 910, the gNB 903 may execute the admission control step 940 to decide to accept or to reject the connection request. The decision may be based on the same criteria as for the handover case described above with reference to figure 6. Thus, by providing the information associated with the MW AB node to the new BH gNB 903 in a RRC Reestablishment request or in a Retrieve UE Context response, the new BH gNB 903 can know that the node related to the request is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the RRC Reestablishment request. If the gNB 903 has rejected the request at step 940, it will not respond to the MWAB-MT 912 and the MW AB 910 will have to find another cell to try another reestablishment procedure. If the gNB 903 has accepted the request, the gNB 903 performs the path switch handshake procedure toward the MW AB AMF 904, with the exchange of Path Switch Request message 925 and Path Switch Request Acknowledge 926. It can be noted that the gNB 903 knows the AMF of the MWAB-MT 912 as the ID of this AMF is included in the Retrieve UE Context Response message 924. Then, the control and user data associated with the MW AB node 910 and its served UEs will transit through the gNB 603 (considered as the new serving BH gNB) and no more through the gNB 902 (considered as the old serving BH gNB). The gNB 903 may send to the BH gNB 902, an indication of the reconnection of the MW AB node 910 through the UE Context Release message 929. The gNB 902 can then delete the stored context information related to the MW AB node 910. In the meantime, the gNB 903 may send a RRC Reconfiguration message 927 containing the necessary information for the MWAB-MT 912 to be served in the new cell, such as radio bearer(s), measurement configuration. The MWAB-MT 912 then responds with a RRC Reconfiguration Complete message 928 to the gNB 903. In this figure, the messages the messages 922, 927, 928 may correspond to the messages with the same name described in TS 38.331, the messages 923, 924, 929 may correspond to the messages with the same name described in TS 38.423, the messages 925, 926 may correspond to the messages with the same name described in TS 38.423, and the RACH procedure 921 may correspond to the RACH procedure described in TS 38.321. The WAB-related static lEs, which may include the MW AB indication IE, may be part of the UE capabilities embedded in the RRC context IE, which is itself embedded in the UE Context Information - Retrieve UE Context Response IE of the standardized Retrieve UE Context Response message. Figures 10a to lOd are examples of methods for use in managing connectivity of a mobile wireless access backhaul, WAB, node. Briefly, at a first backhaul gNB (e.g. a first backhaul RAN node), a method for use in managing connectivity of a mobile WAB node (which may be implemented in a femto network) which mobile WAB node is being served by a cell controlled by the first backhaul gNB, comprises sending a request for a second backhaul gNB to serve a mobile WAB node, the request including information associated with the mobile WAB node. See, for example, step 1002 of figure 10a. The first backhaul gNB (source or master backhaul gNB) and the second backhaul gNB (target or secondary backhaul gNB) may be backhaul base stations or backhaul RAN nodes. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first backhaul gNB may be the BH-gNB2 502, the mobile WAB node or MW AB node may be the MW AB node 540, and the second backhaul gNB may be the BH-gNB3 503. The method may be performed by software elements and / or hardware elements. The first backhaul gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the first backhaul gNB including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 10a. The request may be sent to the second backhaul gNB 503 as a request for the second backhaul gNB 503 to serve the mobile WAB node 540. The request may be sent after determining a connection between the mobile WAB node 540 and a cell of the second backhaul gNB is to be established (e.g. in handover decision procedure 620 or DC decision 820). As an example see step 1001 of figure 10a. The request may be: a handover request, such as handover request 622 discussed above with respect to figure 6; a SN addition request 822 discussed above with respect to figure 8. In an example, the request for the second backhaul gNB 503 to serve the mobile WAB node 540 may be sent to an AMF entity (such as AMF 521a) to which the mobile WAB node 540 is connected. In this case, the request may be a handover required request 722 discussed above with respect to figure 7. In an example, the first backhaul gNB 502 may receive a response indicating the request for serving the mobile WAB node 540 is accepted: for example, in a handover request ack 623 as described with reference to figure 6, a handover command 725 as described with reference to figure 7, a SN addition request ack 823 as described with reference to figure 8. See, for example, step 1003 of figure 10a. The first backhaul gNB 502 may receive a response indicating the request for serving the mobile WAB node 540 is rejected or if no response is received to the request (e.g. within a certain time period after sending the request), this will also be considered by the first backhaul gNB as a rejection. Briefly, at a mobile WAB node, a method for use in managing connectivity of the mobile WAB node (which may be implemented in a femto network), which mobile WAB node having been last served by a cell controlled by a first backhaul gNB and to be connected to a second backhaul gNB, comprises sending, to the second backhaul gNB, a request for serving a mobile WAB node (see, for example, step 1012 of figure 10b). The first backhaul gNB (e.g. old backhaul gNB) and the second backhaul gNB (e.g. new backhaul gNB) may be backhaul base stations or backhaul RAN nodes. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first backhaul gNB may be the BH-gNB2 502, the mobile WAB node or MW AB node may be the MW AB node 540, and the second backhaul gNB may be the BH-gNB3 503. The method may be performed by software elements and / or hardware elements. The mobile WAB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the mobile WAB node including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 10b. The request may be the RRC Reestablishment Request message 922 as described with reference to figure 9. The method may further comprise receiving, from the second backhaul gNB 503, a response indicating the request for serving the mobile WAB node 540 is accepted (see, for example, step 1013 of figure 10b). The response may be the RRC Reconfiguration message 927 of figure 9. The mobile WAB node 540 may determine that the request has been rejected after not receiving a response to the request (e.g. within a certain time period after sending the request). In an example, the method further comprises determining to reestablish a connection toward the second backhaul gNB 503 (e.g. on detecting RLF as in 920 of figure 9) and sending, to the second backhaul gNB 503, a request for serving a mobile WAB node 540 after determining to reestablish a connection toward the second backhaul gNB 503. See, for example, step 1011 of figure 10b. Briefly, at a second backhaul gNB, a method for use in managing connectivity of a mobile WAB node (which may be implemented in a femto network) comprises receiving a request for serving a mobile WAB node, receiving information associated with the mobile WAB node and accepting or rejecting the request for serving the mobile WAB node based on the received information. The mobile WAB node is being or has last been served by a cell controlled by a first backhaul gNB. See, for example, step 1021 and / or step 1022 and step 1023 of figure 10c. The first backhaul gNB (source or master or old backhaul gNB) and the second backhaul gNB (target or secondary or new backhaul gNB) may be backhaul base stations or backhaul RAN nodes. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first backhaul gNB may be the BH-gNB2 502, the mobile WAB node or MW AB node may be the MW AB node 540, and the second backhaul gNB may be the BH-gNB3 503. The method may be performed by software elements and / or hardware elements. The second backhaul gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the second backhaul gNB including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure 10c. In an example, the information associated with the mobile WAB node 540 is included in the request received at the second backhaul gNB 503. In other words, the receiving the request and receiving the information associated with the mobile WAB node 540 is part of the same step. The information associated with the mobile WAB node may be included only in the request. In an example, the information associated with the mobile WAB node is included in the request and is received separately after receiving the request. For example, the information associated with the mobile WAB node may be included in the request and may also be included in information received after receiving the request (e.g. in a retrieve context response, such as Retrieve UE context response message 924 which is sent in response to a retrieve context request, such as Retrieve UE context response message 923, as shown in step 1022 of figure 10c). In an example, the information associated with the mobile WAB node is included separately after receiving the request. For example, the information associated with the mobile WAB node may not be included in the request and may only be included in information received after receiving the request (e.g. in a retrieve context response, such as Retrieve UE context response message 924 which is sent in response to a retrieve context request, such as Retrieve UE context response message 923,, as shown in step 1022 of figure 10c). For example, in the case where the information associated with the mobile WAB node 540 is included in the request received at the second backhaul gNB 503, the request may be received from the first backhaul gNB 502 serving the mobile WAB node 540 and the request is a request for serving a mobile WAB node 540, such as handover request 622 of figure 6 and SN addition request 822 of figure 8. Additionally or alternatively, the request may be received from an AMF entity (such as AMF 521a) to which the mobile WAB node 540 is connected (e.g. directly or indirectly) and the request is a request for serving a mobile WAB node 540, such as handover request 723 of figure 7. In an example, the request is received from a mobile WAB node 540 and the request is a request for serving a mobile WAB node 540, such as RRC reestablishment 922 of figure 9. In this case, the request may include the information associated with the mobile WAB node. The information associated with the mobile WAB node may, in addition to being included in the request, may also be included in information received after receiving the request (e.g. in a retrieve context response, such as Retrieve UE context response message 924 which is sent in response to a retrieve context request, such as Retrieve UE context response message 923, as shown in step 1022 of figure 10c) or the information associated with the mobile WAB node may only be included in information received after receiving the request (e.g. in a retrieve context response, such as Retrieve UE context response message 924 which is sent in response to a retrieve context request, such as Retrieve UE context response message 923, as shown in step 1022 of figure 10c). The method may further comprise sending a response indicating the request for serving the mobile WAB node 540 is accepted (see, for example, step 1024 of figure 10c). The response may be sent to the first backhaul gNB 502 (e.g. the handover request ACK 623 of figure 6 or the SN addition request ACK 823 of figure 8) or may be sent to the AMF entity 521a to which the mobile WAB node 540 is connected (e.g. the handover request ACK 724 of figure 7) or may be sent to the mobile WAB node 540 (e.g. the RRC Reconfiguration message 927 of figure 9). The second backhaul gNB 503 may send a response indicating the request for serving the mobile WAB node 540 is rejected or the second backhaul gNB 503 may not send a response to the request. Briefly, at a first backhaul gNB, a method for use in managing connectivity of a mobile WAB node (which may be implemented in a femto network) which mobile WAB node has been last served by a cell controlled by the first backhaul gNB and is to be connected to a second backhaul gNB, comprises receiving, from the second backhaul gNB, a request to provide information related to the mobile WAB node; sending, to the second backhaul gNB, a response, the response including information associated with the mobile WAB node. See, for example, steps 1031 and 1032 of figure lOd. The first backhaul gNB (e.g. old backhaul gNB) and the second backhaul gNB (e.g. new backhaul gNB) may be backhaul base stations or backhaul RAN nodes. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first backhaul gNB may be the BH-gNB2 502, the mobile WAB node or MW AB node may be the MW AB node 540, and the second backhaul gNB may be the BH-gNB3 503. The method may be performed by software elements and / or hardware elements. The first backhaul gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the first backhaul gNB including one or more processing units, such as the processing unit 402. More details of the method are described below with reference to the example method described with reference to figure lOd. The request may be a retrieve UE context request 923 of figure 9 and the response may be a retrieve UE context response 924 of figure 9. For all the above methods, the information associated with the mobile WAB node (which may be referred to as context information associated with the mobile WAB node) includes at least one of: information for indicating the mobile WAB node supports local services; information for indicating maximum supported load at the mobile WAB node; information for identifying a gNB component (or part or unit or entity) of the mobile WAB node; status information associated with the mobile WAB node. One or more of the information for indicating the mobile WAB node supports local services, the information for indicating maximum supported load at the mobile WAB node, the information for identifying a gNB component (or part or unit or entity) of the mobile WAB node may be referred to as information indicating the capability of the mobile WAB node (e.g. the capability information may include one or more of the static IEs discussed above with reference to figure 6). The information for indicating the mobile WAB node supports local services may include the local services support indication to inform the MW AB node can provide local services onboard (e.g. for the served UEs) as discussed above. In this case, one or more UPF entities are embedded in the mobile WAB node for communicating data between UEs served by the mobile WAB node and / or between a server coupled to the embedded UPF entity and one or more UEs served by the mobile WAB node. The information indicating maximum supported load at the mobile WAB node may include at least one of: information indicating a maximum number of UEs the gNB component of the mobile WAB node is capable of serving; information indicating a maximum throughput the mobile WAB node is capable of handling; information indicating a maximum computation power of the mobile WAB node. The gNB component of the mobile WAB node may be a gNB component providing full base station / gNB functions at the mobile WAB node. In addition to the gNB component, the mobile WAB node may also include a mobile termination (MT) component (or part or unit or entity). The gNB component is co-located with the MT component of the mobile WAB node. In this case, the information for identifying a gNB component (or part or unit or entity) of the mobile WAB node includes information identifying the gNB component. The information may be an identifier of the MWAB-gNB co-located with the MWAB-MT (e.g. Global RAN NODE ID). The status information associated with the mobile WAB node, may include one or more of the dynamic IEs discussed above with reference to figure 6), and may include at least one of: information indicating the expected (or planned) trajectory or path of the mobile WAB node; information indicating a current speed of the mobile WAB node; information indicating a priority level to give to (or assigned to) the mobile WAB node; information indicating an authorization status of the mobile WAB node, the authorization status being the mobile WAB node is authorized to operate as a gNB (e.g. to operate with the full function of a gNB / base station); information identifying one or more Access and Mobility management Function, AMF, entities to which the mobile WAB node is connected. For example, the information indicating a priority level to give to (or assigned to) the mobile WAB node may be a value (e.g. represented by one or more bits) where one value represents high / higher priority and another value represents low / lower priority and there may be other values representing priority levels in between. The information identifying one or more AMF entities to which the mobile WAB node is connected may be identifier(s) of AMF(s) to which the co-located mobile WAB-gNB is connected and the AMF identifier may be the GUAMI as discussed above. In an example, the information indicating the expected / planned trajectory or path of the mobile WAB node includes a list of cells to which the mobile WAB node is expected to connect. The information indicating the expected trajectory of the mobile WAB node may further include information indicating for each cell in the list of cells the expected time period during which the mobile WAB node is to be connected to the respective cell. The status information associated with the mobile WAB node may include expected speed of the mobile WAB node over each part of the expected / planned trajectory or path of the mobile WAB node. The status information associated with the mobile WAB node may include at least one of: information indicating the number of served UE; quality of service information for indicating the quality of service profile associated to traffic related to the one or more served UE; information for indicating average throughput of traffic related to the one or more served UE; information for indicating peak throughput of traffic related to the one or more served UE. The information associated with the mobile WAB node (e.g. the information indicating the capability of the mobile WAB node) may further include information indicating the mobile WAB node is a mobile WAB node. For example, the information associated with the mobile WAB node includes at least one of the static IEs related to the MW AB node and the dynamic IEs related to the MW AB node as discussed above with reference to figure 6. After the information associated with the mobile WAB node 540 is provided, with the request for serving the mobile WAB node and / or after the request for serving the mobile WAB node is provided (e.g. in a retrieve context response), updated information associated with the mobile WAB node may be sent by the mobile WAB node 540 to the second backhaul gNB 503 (e.g. in a UE assistance information message sent by the mobile termination unit 541 of the mobile WAB node 540). For example, some or all of the information included in the information associated with the mobile WAB node may change over time and updated information associated with the mobile WAB node may be sent by the mobile WAB node 540: e.g. the status information, which may include one or more of the dynamic IEs as discussed with reference to figure 6, may change and updated information associated with the mobile WAB node including all or some of the dynamic IEs that have changed may be sent to the second backhaul gNB. Such updated information may be sent periodically or in response to a particular change (e.g. a large increase in the number of UEs served by the mobile WAB node). By providing information associated with the mobile WAB node to the second backhaul gNB (target / secondary / new gNB), the second backhaul gNB can know that the node related to the request is a MW AB node and can make an informed decision based on the received information as to whether to accept or reject the request to serve the mobile WAB node. Furthermore, as discussed above, the information associated with the mobile WAB node may be provided in existing messages as optional information element(s) which helps to minimise the impact on legacy nodes / devices. Figure 10a is a flowchart of an example method 1000 for managing at a first gNB (source gNB or master gNB) the handover or the dual-connection for a MW AB node. For example, with reference to the communication system 500 shown in and described with respect to figure 5, first gNB (source gNB or master gNB) performing the method 1000 may be the BH-gNB2 502, the MW AB node may be the MW AB node 540, and a second gNB (or target gNB or secondary gNB) may be the BH-gNB3 503. The method 1000 as shown in and described with respect to figure 10a may be performed by software elements and / or hardware elements. The first gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 10a being performed by an apparatus for the first gNB including one or more processing units, such as the processing unit 402. At step 1001, the first gNB 502 decides the handover (or dual-connection) of a served MW AB node 540 toward a second gNB 503. At step 1002, the first gNB 502 sends a handover request to the second gNB 503, such as the handover request message 622 as described above with reference to figure 6 (or a node addition request, such as the SN additional request message 822 as described above with reference to figure 8), the request including MW AB node related information. At step 1003, the first gNB 502 receives a response from the second gNB 503 accepting or rejecting the request. Figure 10b is a flowchart of an example method 1010 for managing at a MW AB node the connection reestablishment following a Radio Link Failure (RLF) in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the MW AB node performing the method 1010 may be the MW AB node 540, a first (old) gNB that was serving the MW AB node 540 at the time of the RLF may be the BH-gNB2 502 and a second (new) gNB serving a new cell selected as the target cell may be the BH-gNB3 503. The method 1010 as shown in and described with respect to figure 10b may be performed by software elements and / or hardware elements. The MW AB node may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 10b being performed by an apparatus for the MW AB node including one or more processing units, such as the processing unit 402. At step 1011, the MW AB node 540 decides to reestablish connection toward a new gNB 503. At step 1012, the MW AB node 540 sends a reestablishment request to the new gNB including MW AB node related information. At step 1013, the MW AB node 540 receives a response from the new gNB 503 accepting the request. The response may be the RRC Reconfiguration message 927 described above with reference to figure 9. Figure 10c is a flowchart of an example method for managing at a second gNB (target gNB or secondary gNB or new gNB) the handover, dual-connection, or connection reestablishment of a MW AB node in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the second (target or secondary or new) gNB performing the method 1020 may be the BH-gNB3 503, the first (source or master or old) gNB may be the BH-gNB2 502, and the MW AB node may be the MW AB node 540. The method 1020 as shown in and described with respect to figure 10c may be performed by software elements and / or hardware elements. The second gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure 10c being performed by an apparatus for the second gNB including one or more processing units, such as the processing unit 402. At step 1021, the second gNB 503 receives a request for handover (or node addition, or reestablishment) from a first gNB 502 or a MW AB node, the request may include information related to a MW AB node 540. For example, the request may be the handover request message 622 of figure 6, the handover request message 723 of figure 7, the SN addition request message 822 of figure 8 or the RRC Reestablishment request message 922 of figure 9. At step 1023, the second gNB 503 decides to accept or to reject the request based on the MW AB node 540 related information. This decision may be preceded by the step 1022 where the second gNB 503 sends a request to the first (old) gNB base station 502 that was serving the MW AB node to retrieve context information related to the MW AB node, and receiving the requested information. For example, the second gNB 503 may receive the information associated with the MW AB node 540 in a retrieve UE context response message 924 in response to a retrieve UE context request message 923 as described with reference to figure 9. At step 1024, the second gNB 503 sends a response to the first gNB 502 indicating the decision to accept or to reject the request, or the second gNB 503 sends a response to the MW AB node indicating the decision to accept the request. For example, the response sent to the first gNB 502 may be the handover request ack message 623 of figure 6, the handover command message 724 of figure 7, the SN addition request ack message 823 of figure 8 or the RRC Reestablishment request message 922 of figure 9. For example, the response sent to the MW AB node 540 may be the RRC Reconfiguration message 927 of figure 9. Figure lOd is a flowchart of an example method for managing at a gNB the request to retrieve UE context related to a MW AB node in accordance with one or more embodiments of the present invention. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the first gNB performing the method 1030 may be the BH-gNB2 502, the MW AB node may be the MW AB node 540, and the second gNB may be the BH-gNB3 503. The method 1030 as shown in and described with respect to figure lOd may be performed by software elements and / or hardware elements. The first gNB may be implemented in a network node or base station 400 as shown in and described with reference to figure 4 with the method as shown in and described with respect to figure lOd being performed by an apparatus for the first gNB including one or more processing units, such as the processing unit 402. At step 1031, a first gNB 502 receives a request from a second gNB 503 to retrieve context information related to a MW AB node 540. At step 1032, the first gNB 502 sends to the second gNB 503 a response including the information related to the MW AB node. For example, the first gNB 502 may receive a request to retrieve context information related to the MW AB node 540 from the second gNB 502 in a retrieve UE context request message 923 and the first gNB 502 may send a response including information associated with the MW AB node 540 in a retrieve UE context response message 924 as described with reference to figure 9. Figure 11 is a schematic and simplified diagram illustrating an example message flow for performing Xn handover of a MW AB node according to embodiments of the invention. This figure shows a source base station or gNB 1102 (or source backhaul gNB, or source BH gNB, or source BH RAN node) like the BH-gNB 502 of figure 5, a target base station or gNB 1103 (or target backhaul gNB, or target BH gNB, or target BH RAN node) like the BH-gNB 503, a MW AB node 1110 composed of or including the MWAB-gNB unit 1111 and the MWAB-MT unit 1112 (or MWAB-UE), and the AMF 1104 of the MWAB-MT 1112 (MWAB AMF or BH AMF) like the AMF 521a, in a 5G core network (5GC) like the core network 520 of figure 5. Also, it is assumed that the source BH gNB 1102 is an enhanced gNB with WAB support or WAB capability. It means that the source BH gNB 1102 is aware of the existence of WAB nodes and can adapt its behaviour to optimize the operation at WAB nodes. In other words, a gNB with WAB support or WAB capability is a gNB that can support or serve a WAB node to provide a connection to the core network and data network by being aware of the existence of WAB nodes and by being able to adapt its behaviour to optimize the operation at WAB nodes. This figure includes the first steps of the procedure to handover the MWAB-MT 1112 as described in the figure 6. The MWAB-MT 1112 regularly sends measurement reports 1121 to the source BH gNB 1102 that is currently serving the MWAB-MT 1112. Based on the received measurement reports, the source BH gNB 1102 may detect that the MWAB-MT 1112 receives radio signals in cells controlled by different gNBs with a better quality than in the current serving cell O J C 1 J iD controlled by the source BH gNB 1102, and that at least one of these reported target cells is controlled by the target BH gNB 1103. The source BH gNB 602 may then decide at step 1120 the handover of the MWAB-MT 1112 to a cell controlled by the target BH gNB 1103. The decision or selection at step 1120 may only be based on the signal strengths reported in the measurement reports like 1121 (e.g. based on the signal strengths from different candidate target cells reported by the MWAB-MT 1112 to the source BH gNB 1102 in measurement reports, the source BH gNB 1102 selects one of the candidate cells and the selected cell is the target cell where the MWAB-MT 1112 receives the highest signal power). However, as the source BH gNB 1102 is enhanced with WAB support, the selection may also take into account the WAB support of target BH gNBs controlling the target cells. For instance, the source BH gNB 1102 may select a cell where the MWAB-MT 1112 receives the highest signal power among the target cells which are controlled by target BH gNBs supporting WAB. In other words, the source BH gNB 1102 selects or prioritises one or more target BH gNBs that support WAB over other target BH gNBs that do not support WAB. The information whether a target BH gNB supports WAB may be known by the source BH gNB 1102 from WAB support or WAB capability provided to the source BH gNB 1102. For example, the WAB support information may be provided by target BH gNB(s), such as during or from the establishment of a Xn connection with the target BH gNB(s). The establishment of a Xn connection between the source BH gNB 1102 and the target BH gNB 1103 is illustrated with the exchange of messages Xn Setup Request 1125 and Xn Setup Response 1126, for instance according to the procedure described in TS 38.423 section 8.4.1. The messages Xn Setup Request 1125 and Xn Setup Response 1126 may both include WAB support information (which may also be referred to as WAB support indication or WAB capability indication or information / IE for indicating the a backhaul gNB supports WAB) used by the sender of the message to indicate whether it supports WAB. For example, Xn Setup Request 1125 and Xn Setup Response 1126 may both include a WAB Support information element used by the sender of the message to indicate whether it supports WAB. It can be noted that the Xn setup may also be initiated by the target BH gNB 1103 with the message Xn Setup Request, and then the source BH gNB responds with the message Xn Setup Response. Besides, the procedure NG-RAN node Configuration Update described in TS 38.423 section 8.4.2, may also be used to transmit WAB support. The WAB support information may then be included in the standardized messages NG-RAN node Configuration Update and NG-RAN node Configuration Update Acknowledge. Lastly, the WAB support information indicating the target BH gNB 1103 supports WAB may be provided to the source BH gNB 1102 by another NG-RAN node having a Xn connection with the source BH gNB 1102, through the information elements Served Cell Information NR and Neighbour Information NR defined in TS 38.423 (sections 9.2.2.11 and 9.2.2.13), which may be present in the Xn protocol messages Xn Setup Request, Xn Setup Response, NG-RAN node Configuration Update, NG-RAN node Configuration Update Acknowledge (all defined in TS 38.423). Thus, the Served Cell Information NR and Neighbour Information NR information elements may be enhanced to include the indication (e.g. WAB support information) whether a cell is controlled by a BH gNB supporting WAB. The WAB support information indicates whether the gNB supports WAB. For example, the source BH gNB 1102 may determine that the target BH gNB 1103 supports WAB when an IE (or WAB support information) indicating the target BH gNB 1103 supports WAB is included in a message (such as the messages 1125, 1126, 1123, 724, 725 and the other messages described above). In another example, the WAB support information or IE can be set with a predetermined value to indicate the backhaul gNB supports WAB or another predetermined value to indicate the backhaul gNB does not support WAB. To trigger the handover of the MWAB-MT 1112, the source BH gNB 1102, sends a handover request message 1122 to the selected target BH gNB 1103 including the information related to or associated with the MW AB node 1110 to be handed over. The handover request message may be the Handover Request message specified in the 3GPP document TS 38.423 section 9.1.1.1, which may in addition include information associated with the MW AB node 1110. The information associated with the MW AB node 1110 includes at least one of the information described above with respect to the static and dynamic IEs and may also include the MW AB indication IE defined above. The target BH gNB 1103 receiving this MW AB indication IE can understand that the handover request is related to the handover of a MW AB node. All or part of the static and dynamic IEs related to MW AB node information and defined above, may also be used by the target BH gNB 1103 in the admission control step 1130 to decide whether the request is accepted or not. If the target BH gNB 1103 has decided to accept the handover request, the handover procedure can be completed as defined in TS 38.300 section 9.2.3, starting with the handover request acknowledge message 1123 sent by the target BH gNB 1103. In case the WAB support information or indication is not shared at Xn setup, the source BH gNB 1102 may not know if the target BH gNB 1103 supports WAB or not. This information or indication of WAB support may be provided by the target BH gNB 1103 within the handover request acknowledge message. For instance, if the target BH gNB 1103 supports WAB, WAB support information or indication indicating the target BH gNB 1103 supports WAB is included in the handover request acknowledge message 1123. If the target BH gNB 1103 does not accept the handover, the target BH gNB 1103 sends the message handover preparation failure (not represented in figure 11) to the source BH gNB 1102. Then, the source BH gNB 1102 aborts the handover procedure and may try another handover toward another target BH gNB. When the source BH gNB 1102 receives the handover request acknowledge message 1123 indicating the target BH gNB 1103 accepts the handover but does not support WAB, the source BH gNB 1102 has the choice to continue the handover procedure, or it may cancel the handover procedure to attempt the handover toward another target BH gNB (e.g. to another target BH gNB that supports WAB). To cancel the handover procedure, the source BH gNB 1102 sends the handover cancel message 1124 to the target BH gNB 1103. The message 1124 may include cause information (e.g. a Cause IE) for providing a reason as to why the handover has been cancelled (e.g. because the target BH gNB does not support WAB). For example, the value of the Cause IE included in the message 1124 may be set to “no WAB support at target”. It can be noted that the WAB support information or indication may be also included in the handover request acknowledge message 724 of figure 24, and thus also in the handover command message 725. In the same manner as with the example of figure 11, the source BH gNB 702 of figure 7 may select the target BH gNB 703 for the handover of MWAB-MT 712 because the target BH gNB 703 supports WAB, and the source BH gNB 702 may cancel the handover procedure for the MWAB-MT 712 because the target BH gNB 703 does not support WAB. In other words and as a summary, there are several situations where a WAB node indication should be provided to a backhaul gNB which is about to serve the MT of a WAB node. First, at WAB node integration to the network, a RRC connection establishment procedure is initiated by the WAB-MT toward a backhaul gNB, and this backhaul gNB has to select an AMF. A WAB node indication provided along with the RRC connection procedure would enable a backhaul gNB supporting WAB to directly select an AMF that is also supporting WAB. Besides, at the handover of a WAB-MT, the target BH gNB receiving a handover request should be informed when the request is related to a WAB node. Indeed, the target BH gNB may use this information to handle the handover request. For instance, the target BH gNB may reject the handover because it does not support WAB or because the admission of a WAB node may lead to overload situations, e.g. on the backhaul link between the WAB-MT and the target BH gNB. As a WAB-gNB may serve many UEs, the aggregate bit rate to support may be constantly very high. In addition, during WAB node handover, a (WAB-aware) target BH RAN node may rely on the presence of a WAB indication in the handover request received from the source BH RAN node to accept or reject the handover request. For multi-hop WAB prevention, a WAB-gNB can reject the handover request based on this WAB indication. In order to allow for multi-hop WAB prevention upon WAB node handover while relying on legacy source BH RAN nodes, the WAB indication carried in the handover request may be based on an existing IE, e.g., UE capability, S-NSSAI. Indeed, the WAB indication may be provided through a new WAB indicator in UE capabilities or through some slice-related information (e.g., a list of S-NSSAIs dedicated to WAB). As a summary: - For preventing multi-hop WAB upon WAB handover, i.e., in case of handover for a WAB-node, the new WAB-node indication is included in the HO (handover) request, then the target BH-RAN node can perform access control for this WAB-node. The new WAB-node indication included in the HO request may be based on UE capabilities or on a list of S-NSSAIs. In a same manner, when a WAB-MT initiates a reestablishment procedure after a failure, the BH gNB receiving the RRC reestablishment request should be informed that this involves a WAB node. Thus, WAB node indication should be provided to a backhaul gNB in case of RRC connection, RRC reestablishment and handover of a WAB-MT toward this backhaul gNB. While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies 5 such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to nontransient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually 10 reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

1. A method for use in managing connectivity of a mobile wireless access backhaul, WAB, node, the mobile WAB node being or having last been served by a cell controlled by a first backhaul gNB and to be connected to a second backhaul gNB, the method at the second backhaul gNB comprising: receiving a request for serving a mobile WAB node;receiving information associated with the mobile WAB node;accepting or rejecting the request for serving the mobile WAB node based on the received information,wherein the information associated with the mobile WAB node includes at least one of: information for indicating the mobile WAB node supports local services;information for indicating maximum supported load at the mobile WAB node;information for identifying a gNB component of the mobile WAB node; status information associated with the mobile WAB node.

2. The method of claim 1, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the expected trajectory of the mobile WAB node;information for indicating a current speed of the mobile WAB node;information for indicating a priority level to give to the mobile WAB node;information for indicating an authorization status of the mobile WAB node, the authorization status being the mobile WAB node is authorized to operate as a WAB node;information for identifying one or more Access and Mobility management Function, AMF, entities to which the mobile WAB node is connected.

3. The method of claim 2, wherein the information for indicating the expected trajectory of the mobile WAB node includes a list of cells to which the mobile WAB node is expected to connect.

4. The method of claim 3, wherein the information for indicating the expected trajectory of the mobile WAB node further includes information for indicating for each cell in the list of cells the expected time period during which the mobile WAB node is to be connected to the respective cell.

5. The method of any one of claims 1 to 4, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the number of served UE;quality of service information for indicating the quality of service profile associated to traffic related to the one or more served UE;information for indicating average throughput of traffic related to the one or more served UE; information for indicating peak throughput of traffic related to the one or more served UE.

6. The method of any one of claims 1 to 5, wherein the information associated with the mobile WAB node further includes information for indicating the mobile WAB node is a mobile WAB node.

7. The method of any one of the preceding claims, wherein receiving the information associated with the mobile WAB includes receiving the information with the receiving the request, the information associated with the mobile WAB node being included in the request received at the second backhaul gNB.

8. The method of claim 7, wherein receiving a request includes receiving, from a first backhaul gNB serving the mobile WAB node, a request for serving a mobile WAB node.

9. The method of claim 7, wherein receiving a request includes receiving, from an Access and Mobility management Function, AMF, entity to which the mobile WAB node is connected, a request for serving a mobile WAB node.

10. The method of claim 8 or claim 9, wherein the request is a handover request.

11. The method of claim 8, wherein the request is a secondary node addition request.

12. The method of claim 7, wherein receiving a request includes receiving, from a mobile WAB node, a request for serving the mobile WAB node.

13. The method of any one of claims 1 to 6, wherein receiving a request includes receiving, from a mobile WAB node, a request for serving the mobile WAB node,wherein receiving information associated with the mobile WAB node comprises receiving, from a first backhaul gNB last serving the mobile WAB node, after receiving the request, the information associated with the mobile WAB node.

14. The method of claim 12 or claim 13, wherein the request is a RRC Reestablishment request.

15. The method of claim 13, further comprising:after receiving the request, sending to a first backhaul gNB last serving the mobile WAB node, a retrieve context request,wherein receiving information associated with the mobile WAB node comprises receiving, from the first backhaul gNB, after sending the retrieve context request, the information associated with the mobile WAB node in a retrieve context response.

16. The method of any one of the preceding claims, wherein the information associated with the mobile WAB node is only included in the request.

17. The method of any one of claims 1 to 6, wherein the information associated with the mobile WAB node is included in the request and / or is received separately after receiving the request.

18. The method of claim 15 and claim 17, wherein the information associated with the mobile WAB node is included in the request and / or is included in the retrieve context response.

19. The method of any one of the preceding claims, further comprising sending a response indicating the request is accepted.

20. The method of claim 19, wherein the response includes information indicating whether the second backhaul gNB supports WAB.

21. The method of any one of the claims 1 to 18, further comprising sending a response indicating the request is rejected in one of the following cases:the case where the second backhaul gNB is a WAB node;the case where the second backhaul gNB is configured to not serve other WAB nodes;the case where the second backhaul gNB is a WAB node and is configured to not serve other WAB nodes.

22. The method of any one of the claims 1 to 18, wherein the second backhaul gNB is a WABnode and is configured to not serve other WAB nodes, the method further comprising sending aresponse indicating the request is rejected in the case where the information associated with the mobile WAB node further includes information for indicating the mobile WAB node is authorised to operate as a WAB node.

23. The method of claim 21 or claim 22, wherein the response includes cause information for indicating the reason for rejection, wherein the cause information indicates WAB multi-hop avoidance.

24. The method of any one of the preceding claims, further comprising receiving, from the mobile WAB node, updated information associated with the mobile WAB node.

25. A method for use in managing connectivity of a mobile wireless access backhaul, WAB, node, the mobile WAB node being served by a cell controlled by a first backhaul gNB, the method at the first backhaul gNB comprising:sending a request for a second backhaul gNB to serve a mobile WAB node, the request including information associated with the mobile WAB node,wherein the information associated with the mobile WAB node includes at least one of:information for indicating the mobile WAB node supports local services;information for indicating maximum supported load at the mobile WAB node;information for identifying a gNB component of the mobile WAB node; status information associated with the mobile WAB node.

26. The method of claim 25, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the expected trajectory of the mobile WAB node;information for indicating a current speed of the mobile WAB node;information for indicating a priority level to give to the mobile WAB node;information for indicating an authorization status of the mobile WAB node, the authorization status being the mobile WAB node is authorized to operate as a gNB;information for identifying one or more Access and Mobility management Function, AMF, entities to which the mobile WAB node is connected.

27. The method of claim 26, wherein the information for indicating the expected trajectory of the mobile WAB node includes a list of cells to which the mobile WAB node is expected to connect.

28. The method of claim 27, wherein the information for indicating the expected trajectory of the mobile WAB node further includes information for indicating for each cell in the list of cells the expected time period during which the mobile WAB node is to be connected to the respective cell.

29. The method of any one of claims 25 to 28, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the number of served UE;quality of service information for indicating the quality of service profile associated to traffic related to the one or more served UE;information for indicating average throughput of traffic related to the one or more served UE; information for indicating peak throughput of traffic related to the one or more served UE.

30. The method of any one of claims 25 to 29, wherein the information associated with the mobile WAB node further includes information for indicating the mobile WAB node is a mobile WAB node.

31. The method of any one of claims 25 to 30, wherein the first backhaul gNB selects the second backhaul gNB based at least on the second backhaul gNB supporting WAB.

32. The method of claim 31, further comprising receiving, from the second backhaul gNB during establishment of a Xn connection between the first backhaul gNB and the second backhaul gNB, WAB support information indicating whether the second backhaul gNB supports WAB.

33. The method according to any one of claims 25 to 32, further comprising receiving, a response indicating the second backhaul gNB has accepted the request for serving the mobile WAB node.

34. The method of claim 33, wherein the response includes information indicating whether the second backhaul gNB supports WAB.

35. The method of claim 34, wherein when the response includes information indicating the second backhaul gNB does not support WAB, the first backhaul gNB cancels the request for the second backhaul gNB to serve the mobile WAB node.

36. The method of any one of the claims 25 to 32, further comprising receiving a response indicating the request is rejected.

37. The method of claim 36, wherein the response includes cause information for indicating the reason for rejection, wherein the cause information indicates WAB multi-hop avoidance.

38. The method of any one of claims 25 to 37, wherein sending a request comprises sending, to the second backhaul gNB, a request for the second backhaul gNB to serve the mobile WAB node.

39. The method according to any one of claims 25 to 37, wherein sending a request comprises sending, to the second backhaul gNB, a request for the second backhaul gNB to serve the mobile WAB node after determining a connection between the mobile WAB node and a cell of the second backhaul gNB is to be established.

40. The method of any one of claims 25 to 37, wherein sending a request comprises sending, to an Access and Mobility management Function, AMF, entity to which the mobile WAB node is connected, a request for the second backhaul gNB to serve the mobile WAB node.

41. A method for use in managing connectivity of a mobile wireless access backhaul, WAB, node, the mobile WAB node having been last served by a cell controlled by a first backhaul gNB and to be connected to a second backhaul gNB, the method at the mobile WAB node comprising:sending, to the second backhaul gNB, a request for serving the mobile WAB node, the request including information associated with the mobile WAB node,wherein the information associated with the mobile WAB node includes at least one of:information for indicating the mobile WAB node supports local services;information for indicating maximum supported load at the mobile WAB node;information for identifying a gNB component of the mobile WAB node; status information associated with the mobile WAB node.

42. The method of claim 41, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the expected trajectory of the mobile WAB node;information for indicating a current speed of the mobile WAB node;information for indicating a priority level to give to the mobile WAB node;information for indicating an authorization status of the mobile WAB node, the authorization status being the mobile WAB node is authorized to operate as a gNB;information for identifying one or more Access and Mobility management Function, AMF, entities to which the mobile WAB node is connected.

43. The method of claim 42, wherein the information for indicating the expected trajectory of the mobile WAB node includes a list of cells to which the mobile WAB node is expected to connect.

44. The method of claim 43, wherein the information for indicating the expected trajectory of the mobile WAB node further includes information indicating for each cell in the list of cells the expected time period during which the mobile WAB node is to be connected to the respective cell.

45. The method of any one of claims 41 to 44, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the number of served UE;quality of service information for indicating the quality of service profile associated to traffic related to the one or more served UE;information for indicating average throughput of traffic related to the one or more served UE; information for indicating peak throughput of traffic related to the one or more served UE.

46. The method of any one of claims 41 to 45, wherein the information associated with the mobile WAB node further includes information for indicating the mobile WAB node is a mobile WAB node.

47. The method according to any one of claims 41 to 46, further comprising receiving, from the second backhaul gNB, a response indicating the request for serving the mobile WAB node is accepted.

48. The method according to any one of claims 41 to 46, further comprising determining the request for serving the mobile WAB node is rejected after not receiving a response.

49. The method according to any one of claims 41 to 48, wherein sending a request, comprises sending, to the second backhaul gNB, a request for serving a mobile WAB node after determining to reestablish a connection toward the second backhaul gNB.

50. The method of any one of claims 41 to 49, further comprising sending, to the second backhaul gNB, updated information associated with the mobile WAB node.

51. A method for use in managing connectivity of a mobile wireless access backhaul, WAB, node, the mobile WAB node having been last served by a cell controlled by a first backhaul gNB and to be connected to a second backhaul gNB, the method at the first backhaul gNB comprising:receiving, from the second backhaul gNB, a request to provide information related to the mobile WAB node;sending, to the second backhaul gNB, a response, the response including information associated with the mobile WAB node,wherein the information associated with the mobile WAB node includes at least one of:information for indicating the mobile WAB node supports local services;information for indicating maximum supported load at the mobile WAB node;information for identifying a gNB component of the mobile WAB node;status information associated with the mobile WAB node.

52. The method of claim 51, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the expected trajectory of the mobile WAB node;information for indicating a current speed of the mobile WAB node;information for indicating a priority level to give to the mobile WAB node;information for indicating an authorization status of the mobile WAB node, the authorization status being the mobile WAB node is authorized to operate as a gNB;information for identifying one or more Access and Mobility management Function, AMF, entities to which the mobile WAB node is connected.

53. The method of claim 52, wherein the information for indicating the expected trajectory of the mobile WAB node includes a list of cells to which the mobile WAB node is expected to connect.

54. The method of claim 53, wherein the information for indicating the expected trajectory of the mobile WAB node further includes information indicating for each cell in the list of cells the expected time period during which the mobile WAB node is to be connected to the respective cell.

55. The method of any one of claims 51 to 54, wherein the status information associated with the mobile WAB node includes at least one of:information for indicating the number of served UE;quality of service information for indicating the quality of service profile associated to traffic related to the one or more served UE;information for indicating average throughput of traffic related to the one or more served UE; information for indicating peak throughput of traffic related to the one or more served UE.

56. The method of any one of claims 51 to 55, wherein the information associated with the mobile WAB node further includes information indicating the mobile WAB node is a mobile WAB node.

57. A computer program comprising instructions which, when the program is executed by at least one processor unit, cause the at least one processing unit to carry out the method according to any one of claims 1 to 56.

58. A computer-readable medium carrying a computer program according to claim 57.

59. An apparatus for a backhaul gNB, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 1 to 40, claims 51 to 56.

60. An apparatus for a mobile Wireless Access Backhaul, WAB, node, the apparatus comprising: one or more processing units configured to perform the method as recited in any one of claims 41 to 50.

Images