Managing network connectivity in a wireless communication system

Abstract

A method for use in managing connectivity in a wireless network including a plurality of Radio Access Network, RAN, nodes, an Xn connection being established between a source RAN node and a target RAN

Description

The present disclosure generally relates to managing network connectivity in a wireless communication system. Particularly, the present disclosure relates to managing network connectivity in a wireless communication system including at least one Wireless Access Backhaul, WAB, node. In an example, the wireless communication system includes at least one mobile Wireless Access Backhaul, 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. 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, in recent 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 characterized by a high density of users along with the presence of a significant number of vehicles (e.g., public / private passenger 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 IAB, 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 of the existing wireless access backhauling, WAB, systems and architecture are further considered by 3GPP for Release 19. Such enhancements 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 Next Generation Node B (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 mobile WAB (MWAB) 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. A WAB node is made of a Mobile Termination, WAB-MT, part used for connecting to some fixed existing infrastructure and used to provide backhauling connectivity as previously discussed. The WAB node also embeds a base station or gNB, WAB-gNB, (also referred to as a gNB part) to serve UEs. WAB nodes may be referred to as mobile Wireless Access Backhaul (MWAB) nodes. This disclosure relates to WAB nodes and MWAB nodes and thus, references to MWAB nodes should be taken to refer to WAB nodes and vice versa. 3GPP TS 38.423 defines the Xn interface, which is a logical interface between two NG-RAN network nodes, or base stations, providing means for interconnecting these two NG-RAN nodes. For instance, the Xn interface provides means for managing resource multiplexing between NG-RAN network nodes, or base stations, allowing NG-RAN network nodes (i.e., base stations, or gNBs) in proximity to coordinate their radio resources utilization so as to prevent the NG-RAN network nodes to mutually interfere. A need for resource multiplexing management also applies when considering a WAB-gNB and the NG-RAN network node serving the WAB-MT of the WAB node the WAB-gNB belongs to, as the WAB-gNB and the serving NG-RAN network node are likely to be close enough to interfere. Thus, having an Xn connection between the WAB-gNB of a WAB node and the NG-RAN network node serving the WAB-MT of the WAB node is desirable as it would at least facilitate managing resource multiplexing to avoid or minimize interference between the WAB-gNB and the serving NG-RAN network node. Xn connection may also allow for faster UE handover process between a WAB-gNB and a surrounding NG-RAN network node (including the NG-RAN network node serving the WAB-MT collocated with the WAB-gNB), compared to an NG-level handover process, which is performed through the 5G core network, as defined in 3GPP TS 23.502 with N2 based handover. Having faster handover may be particularly interesting when performed between two WAB-gNBs which respective WAB nodes are bound to a same vehicle, i.e., a train or cruise ship, in order to ensure service continuity at UE level. In this latter case, having a Xn connection would not only account for faster handover but would also allow for faster load balancing coordination between the several bound WAB nodes. Therefore, it is desirable to provide solutions to address at least some of the aforementioned issues and address other issues not discussed. Summary In accordance with an aspect of the present disclosure, there is provided a method for use in managing connectivity in a wireless network including a plurality of Radio Access Network, RAN, nodes, an Xn connection being established between a source RAN node and a target RAN node of the plurality of RAN nodes, the method at the source RAN node comprising sending, to the target RAN node, an unsolicited User Equipment, UE, context of a UE served by the source RAN node. In another aspect of the present disclosure, there is provided a method for use in managing connectivity in a wireless network including a plurality of Radio Access Network, RAN, nodes, an Xn connection being established between a source RAN node and a target RAN node of the plurality of RAN nodes, the method at the target RAN node comprising receiving, from the source RAN node, an unsolicited User Equipment, UE, context of a UE served by the source RAN node. The disclosure provides mean to allow target RAN nodes to quickly and efficiently take over serving UEs from a source RAN node. The disclosure limits the complexity of the processing performed at NG-RAN nodes. Additionally, it reduces latency that would result from such processing, especially latency experienced by user of UEs. The disclosure is particularly but not exclusively beneficial for WAB nodes. As a WAB node is likely to move while the Xn connection between said WAB node and another RAN node is operated over a wireless link, an Xn connection may become useless or not ideal after being established, especially in a case the WAB node is moving away from the RAN node at a fast pace. Moreover, the Xn wireless link connecting a WAB-gNB to another RAN node may be subject to some radio link degradation, which may lead to the removal of the Xn connection. The disclosure is beneficial because a WAB node may, at some point, decide to turn a served UE to the INACTIVE, or RRC INACTIVE, state, for instance to save some battery power when the UE is not involved in any communication. The UE in RRC1XACTIVE state may further move on its own and eventually camp on a new cell managed by a new NG-RAN node different from the WAB node that turned it inactive. In order to perform reconnection to the network, a UE in INACTIVE state may perform some connection resume procedure with the new NG-RAN node. Typically the procedure would require the new NG-RAN node to retrieve some context information from the WAB node that turned the UE to inactive. Such UE context information retrieval may be processed through the Xn connection, as discussed in 3GPP TS 38.423. However, the disclosure ensures that the New NG-RAN node has the context information already and does not need to solicit (retrieve) the context information from the WAB node. Additionally, in the case where the new NG-RAN is unable to solicit (retrieve) the context information, for example, in a case where the Xn connection between the WAB node and the new NG-RAN node was removed before the UE initiates the connection resume procedure, the disclosure ensures that the new NG-RAN node has the context information and there would be no failure of the connection resume procedure. The unsolicited sending of context information, i.e. sending without receiving a prior request to retrieve the information, is beneficial for at least some of the above reasons. It provides for a reduction in the complexity in handing over UEs between RAN nodes, reduces the number of messages, etc. Sending of the unsolicited UE context of the UE served by the source RAN node may be performed in a case where the Xn connection is or will become not sufficient (insufficient) or not adequate (inadequate). A not sufficient (or insufficient or inadequate connection) may be any connection which is not beneficial or relevant, for example because the radio connection is weak or will become weak, or there is an unacceptable level of service (for example data loss, unacceptable message delay etc), or which requires significant number of retransmissions, or is likely to fail within a short period of time etc. Put another way, sending of the unsolicited UE context of the UE served by the source RAN node may be performed in a case where the benefit, or relevance, of the Xn connection is, or will become, not sufficient (insufficient), or not adequate (inadequate). The source RAN node may determine whether a benefit (or relevance) of an Xn connection is sufficient or adequate. Whether the benefit (or relevance) of a Xn connection is sufficient (or adequate) or not may be based on a benefit value. The benefit parameter value may be a Xn benefit parameter, the value of the Xn benefit parameter representing a benefit of the connection between the source RAN node and the Target RAN node. The determination may be done for both maintaining or establishing an Xn connection. The benefit value may be used in determinations for both maintaining an Xn connection or establishing an Xn connection. Put another way, the determined benefit value is used to inform the process of whether to prune an existing Xn connection and / or establish a new Xn connection. The benefit (or relevance) of an Xn connection may be not sufficient (insufficient, not adequate, insufficient) based on the benefit value being equal to or less than a predetermined threshold. That is to say a benefit of an Xn connection may be determined to be not sufficient based on the benefit value being equal to or less than a predetermined threshold. The benefit (or relevance) of the Xn connection may be sufficient (adequate) based on the benefit value being greater than a predetermined threshold. That is to say the benefit of a Xn connection may be determined to be sufficient based on the benefit value being greater than a predetermined threshold. The Xn connection may be not sufficient based on at least one of served UE connectivity criteria; RAN connectivity criteria; geographical criteria; mobility criteria; Xn neighborhood criteria; and WAB-MT connectivity criteria. The benefit value may be based on at least one of: served UE connectivity criteria; RAN connectivity criteria; geographical criteria; mobility criteria; Xn neighborhood criteria; and WAB-MT connectivity criteria. The benefit parameter value may be a value based on at least one of: served UE connectivity criteria; RAN connectivity criteria; geographical criteria; mobility criteria; Xn neighborhood criteria; and WAB-MT connectivity criteria. The served UE connectivity criteria may be based on at least one of the following: an ability of the UE served by the source RAN node to connect to the target RAN node; a radio link quality between the served UE and a cell managed by the target RAN node; the number of served UEs that are able to connect to the target RAN node, or a ratio of the UEs served by the source RAN node to the UEs served by the source RAN node that are able to connect to the target RAN node; and an ability of the UE served by the source RAN node to connect to, and remain connected to, the target RAN node for at least a minimum time period. The RAN connectivity criteria may be based on an ability for the mobile termination of the source RAN node to connect to the target RAN node. The geographical criteria may be based on a location of one or both of the source RAN node and the target RAN node. The geographical criteria may be any one of a RAN-based Notification Area, RNA, a Tracking Area, TA, or a group of NR cells. The mobility criteria may represent the mobility of one or both of the source RAN node and the target RAN node. A mobility profile of one or both of the source RAN node and the target RAN node may provide the mobility criteria. The mobility criteria may be based on at least one of: a minimum speed capability, an average speed capability of one or both of the source RAN node and target RAN node, a maximum speed capability of one or both of the source RAN node and target RAN node, range capability information of one or both of the source RAN node and target RAN node, static period information indicating a duration of one or more time periods during which one or both of the source RAN node and target RAN node are expected to be stationary, and itinerary information indicating a sequence of time periods and further indicating whether one or both of the source RAN node and target RAN node are expected to be in motion or stationary during the respective indicated time periods. The range capability information may comprise at least one of: information indicating an area in which of one or both of the source RAN node and target RAN node may move, information indicating the size of the area in which of one or both of the source RAN node and target RAN node may move, a distance that the one or both of the source RAN node and target RAN node may move, and one or more cell Identifiers, IDs, corresponding to one or more cells that one or both of the source RAN node and target RAN node may be in range of or has been in range of previously. The static period information may include information indicating at least one of: a minimum static period duration of one or both of the source RAN node and target RAN node, an average static period duration of one or both of the source RAN node and target RAN node, a maximum static period duration of one or both of the source RAN node and target RAN node, and static position information indicating one or more locations at which one or both of the source RAN node and target RAN node are expected to be stationary. The itinerary information may include information indicating, for each of the time periods of the sequence of time periods, at least one of: the duration of the time period, the speed of the source RAN node if the source RAN node is expected to be in motion during the time period, the location at which the source RAN node is expected to be stationary if the source RAN node is expected to be stationary during the time period,, the speed of the target RAN node if the target RAN node is expected to be in motion during the time period, and the location at which the target RAN node is expected to be stationary if the target RAN node is expected to be stationary during the time period. The Xn neighborhood criteria may be representative of the target RAN node being present in a neighborhood of a further RAN node, the further RAN node being connected to the source RAN node via an Xn connection. The source RAN node may be a gNB component of a Wireless Access Backhaul, WAB, node comprising a Mobile Termination, MT, component, and the gNB component; wherein the WAB-MT connectivity criteria being representative of the ability of the MT component of the source WAB node to connect to the target RAN node. The WAB-MT connectivity criteria may be representative of the ability of the MT component of the source WAB node to connect to, and remain connected to, the target RAN node for at least a minimum time period. Preferably, in a case where the Xn connection is to be removed, sending of the unsolicited UE context of the UE served by the source RAN node may be prior to removing the Xn connection. The Xn connection may be removed in the case where the Xn connection is not sufficient, i.e. the benefit or relevance of maintaining the Xn connection is not sufficient (insufficient) or adequate (inadequate). The removal of the Xn connection may be initiated by one of the source RAN node or the target RAN node. The connection being established between the source RAN node and target RAN node may be based on a benefit (or relevance) of establishing a Xn connection, for example one that is sufficient or adequate. The benefit of establishing a Xn connection may be based on the benefit value. The benefit value of establishing the connection may be based on the same consideration as the benefit values discussed above, i.e. it may be a benefit parameter, the value of the benefit parameter representing a benefit of establishing a connection between the source RAN node and the Target RAN node. Preferably, in a case where the benefit of establishing a Xn connection is sufficient or adequate, one of: a CONNECTION SETUP REQUEST message, a CONNECTION SETUP RESPONSE message, or a CONTEXT INDICATION message comprises the UE context. Preferably, sending the unsolicited UE context of the UE served by the source RAN node is performed in a case where the UE served by the source RAN node is to be set to an inactive state. The inactive state may be RRC INACTIVE state as defined in 3GPP TS 38.304 and TS 38.331. Preferably, sending the unsolicited UE context of the UE served by the RAN node may be performed prior to setting the inactive state. Preferably, sending the unsolicited UE context of the UE served by the RAN node is performed subsequent to setting the inactive state. More preferably, it is performed after a predetermined time period has been met or elapsed. The predetermined time period may be set by one of the source RAN node, target RAN node, an AMF entity serving the source RAN node, and an 0AM procedure may set the predetermined time period. Preferably, the unsolicited UE context of the UE served by the RAN node may be performed concurrently with setting the inactive state. Preferably, the methods may further comprise releasing a connection to the UE served by the source RAN node in the case where the UE served by the source RAN node is to be set to the inactive state. Releasing the connection to the UE served by the source RAN node may comprise sending, by the source RAN node to the served UE, a CONNECTION RELEASE message. Preferably, the released connection may be the RRC connection. Sending, to the target RAN node, the unsolicited UE context of the UE served by the source RAN node may be via the Xn connection. A message may comprise the UE context. The message comprising the UE context may be any one of: a CONTEXT INDICATION message, a CONNECTION REMOVAL REQUEST message or a CONNECTION REMOVAL RESPONSE. Preferably, the CONTEXT INDICATION message may be a NG-RAN NODE CONFIGURATION UPDATE message as defined in 3GPP TS 38.423. Preferably, the UE context comprises UE context information. The UE context information may comprise dynamic context information and semi-static context information. Preferably, sending the unsolicited UE context comprises sending a subset of UE context information from the whole context information associated with the UE served by the source RAN node. Preferably, the UE context information sent comprises at least a part of semistatic information of the context information. That is to say that the sent unsolicited UE context information may only comprises at least part of the semi-static information. Preferably, a plurality of target RAN nodes may be provided. The source RAN node may send the unsolicited UE context to each of the target RAN nodes of the plurality of RAN nodes. The source RAN node may determine which of the target RAN nodes of the plurality of RAN nodes to send the unsolicited UE context. Preferably, the determination of which target RAN node may be based on various factors, for example the benefit value discussed above. Preferably, a plurality of UEs may be associated with the source RAN node. The source RAN node may send unsolicited UE context for each UE of the plurality of UEs associated with the source RAN node. The source RAN node may send only unsolicited UE context for some UEs, e.g. a subset, of the plurality of UEs. Sending the UE context of the UE served by the source RAN node may be performed immediately upon the Xn connection being established between the source RAN node and the target RAN node. Sending the UE context of the UE served by the source RAN node may be performed after a minimum predetermined time period after the Xn connection is established between the source RAN node and the target RAN node. Preferably, one of the source RAN node, target RAN node, an AMF entity serving the source RAN node, and an 0AM procedure may set the predetermined time period. Preferably the method may further comprise discarding the received unsolicited UE context after expiration of a predetermined time period. The predetermined time period may start upon receiving the unsolicited UE context. The unsolicited UE context comprises UE context information. Preferably the UE context information comprises dynamic context information and semi-static context information. Preferably, some of the received unsolicited UE context information is discarded, more preferably, the dynamic context information is discarded. Preferably, all of the received unsolicited UE context information is discarded. A message may comprise the unsolicited UE context. Preferably the message comprising the unsolicited UE context is one of: a CONTEXT INDICATION message, a CONNECTION SETUP REQUEST message, A CONNECTION SETUP RESPONSE message, a CONNECTION REMOVAL REQUEST, or a CONNECTION REMOVAL RESPONSE message. Another aspect of the disclosure is provided by an apparatus for a Radio Access Network, RAN, node, the apparatus comprising one or more processing unit configured to perform a method according to any aspect of the disclosure. An aspect of the disclosure is provided by a computer program comprising instructions which, when the program is executed by at least one processing unit, causes the at least one processing unit to carry out any aspect of the disclosure. The source RAN node may set an inactive UE device served by the source RAN node to an active state. In such cases, the source RAN node may notify the target RAN node that the inactive UE device is to be set as active, i.e. will be set to an RCC CONNECTED state. The source RAN node may use a connection resume procedure. The notification may be a message. The source RAN node may send a message to target RAN node, the message notifying the target RAN node that the source RAN node will set a served UE that is inactive to active. The message may comprise information which indicates that change of state will occur or has occurred. The received message may be a state change message or comprise information which indicates that a state change will occur. The message may be sent immediately after the state has been change or it may be sent after a predetermined time period has been met or elapsed. The source RAN node may send a notification to the target RAN node, wherein the notification indicates that the received unsolicited UE context information may be discarded. That is to say the source RAN node may inform the target RAN node that previous received unsolicited UE context may be discarded. The notification may be indicated by a message or information within a message. The source RAN node may send updated UE context to the target RAN node. That is to say the source RAN node may update UE context previously sent. The updated UE context may also be sent unsolicited. A further aspect of the disclosure is provided by a computer-readable medium carrying a computer program according to an aspect of the disclosure. Any feature in one aspect of the disclosure may be applied to other aspects of the disclosure, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa. It will be understood that 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 disclosure, 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. The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of aspects of the subject matter described herein. Accordingly, the above-described features should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Moreover, the above and / or proceeding examples may be combined in any suitable combination to provide further examples, except where such a combination is clearly impermissible or expressly avoided. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings. Brief Description of the Drawings Different aspects of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram illustrating an example wireless communication system in which the present disclosure may be implemented according to one or more embodiments; Figure 2 is a block schematic diagram illustrating an example wireless communication system (or Wireless Access Backhaul system) in which the present disclosure may be implemented according to one or more embodiments; Figure 3 is a block schematic diagram illustrating an example wireless communication system (or Wireless Access Backhaul system) in which the present disclosure may be implemented according to one or more embodiments; Figure 4 shows a block schematic representation of an example network node in accordance with one or more embodiments of the present disclosure; Figure 5 is a block schematic diagram illustrating an example arrangement of a wireless communication system (or Wireless Access Backhaul system) in which the present disclosure may be implemented according to one or more embodiments; Figure 6 and Figure 7 are schematic and simplified diagrams illustrating example message flows for use in managing network connectivity in a wireless communication system including at least one Wireless Access Backhaul, WAB, node in accordance with one or more embodiments of the present disclosure and which may be used for managing network device context sharing between two NG-RAN nodes; Figure 8 is a flowchart of an example method for managing the sharing of network device context between a WAB-gNB and an NG-RAN network node according to one or more embodiments of the present disclosure; Figure 9 is a flowchart of an example method for managing the sharing of network device context between a WAB-gNB and an NG-RAN network node according to one or more embodiments of the present disclosure; Figure 10 is a flowchart of an example method for managing the sharing of network device context between a WAB-gNB and an NG-RAN network node according to one or more embodiments of the present disclosure; Figure 11 is a flowchart of an example method for managing the storage of network device context at an NG-RAN network node according to one or more embodiments of the present disclosure; Figure 12 is a flowchart of an example method for determining the benefit of an Xn connection between two NG-RAN network nodes according to one or more embodiments of the present disclosure; and Figures 13A and 13B are flowchart of example method for managing the sharing of network device context, with Figure 13 A showing the sending of network device context form a source node and Figure 13B showing the receiving of network device context by a target node. Detailed Description Figure 1 illustrates an example communication system 100 in which the present disclosure 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 disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is necessarily limited to 5G NR systems and may be used in any wireless communication systems having 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 Wireless Access Backhaul (WAB) nodes, also referred to as mobile wireless access backhaul (MW AB) devices: such as MW AB node 110 (mounted on plane 161), MW AB nodes 120a and 120b (mounted on train 162), WAB node 130 (or Home gNB, mounted on a house 163), MW AB node 140 (mounted on a Unmanned Aerial Vehicle (UAV) 164) and MW AB node 150 (mounted on a backpack 165 or other carrier that can be carried by a user (e.g., in a disaster zone)). In more general terms, the MW AB 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 center building, etc..) and / or a portable carrier that can be carried by a user, for example, in a disaster zone or for public safety (such as a backpack, bag, etc), and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). In an example where the MW AB node is implemented in a 5G femto network, the MW AB 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 center building, etc..) and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). In some cases, particularly but not exclusively when a MW AB node 130 is mounted to a fixed structure, e.g., when the MW AB node is functioning as a 5G femto node, the MW AB node 130 may be considered a WAB node, which also may be referred to as a Home gNB, and is based on the same architecture as the MW AB node, i.e. the Home gNB comprising the Mobile Termination and gNB required to be a Wireless Access Backhaul node. Some examples of UEs include smartphones / tablets (such as UEs 111, 123, 134, 142, 152), extended Reality (XR) headsets (such as UEs 112, 122, 132), cameras (such as UEs 131, 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, other smart devices 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 some implementations, base stations 102, 103 and 104 are 5G NR base stations (referred to as a gNB), as defined in 3GPP TS 38.300 V18.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 180, 190. That is to say, the satellite dish 110 is connected to one or more of the wired link infrastructures 180, 190. While infrastructure 180 and 190 are referred to as separate, it should be understood that it may be the same infrastructure. In order to extend the network coverage of base stations 102, 103 and 104 and reach the remoteUEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, MW AB nodes, or MWAB-nodes, 110, 120a, 120b, 130, 140 and 150, have been installed on vehicles / mobile equipment / building 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 toMWAB node 150). The base stations 102, 103 and 104, the MWAB 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 forms the Radio Access Network (RAN) or as referred to with respect to 5G, Next Generation (NG) RAN. The WAB network forms 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 wireless 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, D 1041b, D1031, D1022, D1021), or split into two radio links in the case of satellite relaying (radio links D1601a and D160lb). Although a single logical hop is shown in figure 1, it will be appreciated that the MW AB nodes could be wireless 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 unit or part which is referred to as a MWAB / WAB gNB or MWAB / W AB-gNB, or also referred to as a MW AB base station, and a Mobile Termination (MT) component or unit or part which is referred to as an MWAB / WAB-MT, MWAB / WAB MT or MWAB / WAB-Mobile Termination. The MW AB-gNB functionality on an MWAB-node allows or enables the connection to a UE. 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 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 similar appropriate vehicle may be parked, for example 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. Figure 2 is a simplified schematic diagram of a 5G system 200 in which the present disclosure may be implemented according to one or more 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. 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 201 and 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 Wireless Access Backhaul (WAB) node (or a MW AB node), and in which the present disclosure may be implemented according to one or more example embodiments. This figure first represents a User Equipment (UE) 301 served by a WAB node 310 through the Uu interface. The WAB node 310 is composed of or includes a MT or WAB-MT or MWAB-MT unit / component / entity 311 (also called WAB-UE), and a gNB or RAN node or WAB-gNB, or MWAB-gNB unit / component / entity 312. Through the WAB-gNB 312, a WAB 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 WAB node 310 (e.g. on entering / leaving the vehicle). In other words, the WAB-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 WAB 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 WAB-MT 311 via a gNB 320, which can be called a backhaul RAN node or BH RAN node, backhaul base station, backhaul gNB or BH gNB. Acting as a legacy UE, the WAB-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 WAB 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 WAB 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 WAB node 310 includes a UPF 313, the WAB node can connect to one or more local servers (e.g. mounted at the same entity as the WAB 310) enabling a UE served by the WAB access to local services provided by the local servers with no traffic required outside of the WAB node / server environment. The BH gNB 320 provides N3 and N2 interfaces so that the WAB-MT 311 can access to the functions of its 5G core network 330. Indeed, a WAB-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 320, and may then have access to the corresponding 5G core network 330. In particular the WAB-MT 311 interacts with the AMF 332, which can be called the WAB AMF, and establishes PDU session(s) with the UPF 331, which can be called the WAB UPF. The WAB UPF 331 is controlled by the SMF 333 (through N4 interface), which can be called the WAB SMF, and which also interacts with the WAB AMF 332 (through Nil interface). There may be one or several intermediate UPFs between the BH gNB 320 and the WAB UPF 331 as mentioned in the Figure 2. An interface internal to the WAB node 310 exists between the WAB-gNB 312 and the WAB-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 WAB-MT 311 has established a PDU session with the WAB UPF 331, the WAB node is ready to serve UEs and the WAB-gNB 312 can start operating as a legacy gNB. The WAB-gNB may support various PLMNs and the UE 301 connects to one PLMN, e.g. PLMN2, which may be different from the PLMN1 the WAB-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 N11 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 WAB UPF 331, the WAB AMF 332, and the WAB SMF 333 belong to the same 5G core network 350. In addition, the UE UPF 341 and the WAB UPF 331 may be the same UPF, the UE AMF 342 and the WAB AMF 332 may be the same AMF, the UE SMF 343 and the WAB 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 WAB UPF 331, and thanks to the N6 interface between the WAB UPF 331 and the UE AMF 342. These N6 interfaces enable the establishment of N2 interface between the WAB-gNB 312 and the UE AMF 342, and the establishment of N3 interface between the WAB-gNB 312 and the UE UPF 341, which allows the UE 301 to access the Data Network 360. In case the WAB-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 WAB 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 WAB-MT 311 connects to the 5G network in a roaming manner corresponding to the local breakout option, then the PLMN 1 is the visited PLMN and the WAB UPF 331 directly connects to the UE UPF 341 and the UE AMF 342 through N6 interfaces as shown in the Figure 3. Finally, the WAB-gNB 312 may use the backhaul link between the WAB-MT 311 and the BH-gNB 320 and a PDU session established by the WAB-MT 311 to setup a Xn connection with another RAN node. In another embodiment, the WAB-gNB 312 may use a dedicated network interface to directly connect to another RAN node (e.g. the network interface 432 of figure 4). For instance, a Xn connection may be established between the WAB-gNB 312 and the BH-gNB 320. Figure 4 is a block schematic diagram of an example RAN node or network node or base station 400, such as base stations or gNBs or MW AB nodes shown in Figure 1 or WAB nodes, in accordance with one or more embodiments of the disclosure. Each of a MW AB node 110, 120a, 120b, 130, 140, or 150 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 disclosure. 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 stations of the Radio Access Network (RAN), all defined by the 3 GPP 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 / or 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 D1041b between base station 104 and the MT / UE unit of MW AB node 120b, or link D1202 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 disclosure. 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 further include information associated with the mobile WAB node, such as information elements 420 related to a MW AB node, including MW AB information. The information elements may be static information elements and / or dynamic information elements. The information elements 420 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 or entity when necessary. The information elements 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 or entity. Other nodes or entities described, such as the gNB, AMF and UPF, may comprise information elements stored in their own respective memories. These information elements being related to a MW AB node (including WAB-MT connection information, WAB connection information, WAB neighbouring information, neighbour WAB cells list information, femto capability information, WAB co-location information, WAB group information, etc. as discussed below) or their capability to serve a MW AB node. Specific program elements / sub-routines stored in program memory may include one or more of the following: elements for performing connection setup to establish a Xn connection between the gNB component of a WAB node and a RAN node (e.g. neighbour RAN node) based on information shared between the WAB node and the RAN node. The information shared may include information for identifying a relationship between the WAB node and the RAN node: such a relationship may be a connection has been established between the MT component of the WAB node and the RAN node or in the case where the RAN node is another WAB node, the WAB node and the other WAB node belong or are part of the same group of WAB nodes. The elements may include one or more of: an element for sending a request to initiate establishment of a Xn connection between the gNB component of the WAB node and the RAN node; an element for receiving a response to the request; and / or an element for receiving a request to initiate establishment of a Xn connection between the gNB component of the WAB node and the RAN node; an element for sending a response to the request. Other elements that may be included will be apparent from the description of the example message flows and example methods set out below. 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 disclosure. In other words, the apparatus may be capable of performing one or more functions of the base station including performing the methods in accordance with one or more embodiments of the disclosure by means of the one or more processing units. For example, the one or more processing units use software to implement the one or more embodiments of the disclosure 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 structures 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, according to some embodiments. The WAB network or WAB network system may be considered a mobile WAB network or a mobile WAB network system. 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 or comprises three base stations 501, 502 and 503, also referred to as Backhaul base stations, or backhaul gNBs (also referred to as BH-gNB) or backhaul RAN node (also referred to as BH RAN node), two core networks 510 and 520, with the respective AMF entities 511a and 511b (for Core Network 510) and AMF entities 521a and 521b (for Core Network 520) and the respective UPF entities 512a and 512b (for Core Network 510) and UPF entities 522a and 522b (for Core Network 520), and two WAB 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 WAB node comprises a Mobile Termination (MT) part or unit or component (WAB-MT 531 for WAB node 530 and WAB-MT 541 for WAB node 540) and a base station part or unit or component (WAB-gNB 532 for WAB node 530 and WAB-gNB 542 for WAB node 540). WAB node 530 and WAB node 540 may also embed a UPF entity, respectively UPF entity 533 and UPF 543, as previously discussed in relation to figure 3, allowing WAB-node 530 to provide UEs 551 and 552 with at least 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. The UPF entity 543 in WAB node 540 may provide the same functions to UE 561. In some implementations, the UPF entity of the WAB node may be configured for one or more local services. WAB node 530 is connected to the serving backhaul base station BH-BS1, also referred to as BH-gNBl, 501 through BH link 5011. WAB node 540 may be connected to the serving backhaul base station referred to as BH-gNB2 (BH-BS2), 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 (BH-BS3), 503 through BH link 5031. WAB-gNB 532 of WAB 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, WAB-gNB 542 of WAB node 540 is also connected to UE 561 through communication link or radio link 5401. Although Figure 5 shows only one UE 561 connected to WAB node 540, it will be appreciated that there may be a plurality of UEs connected to WAB nodes of the wireless communication system. Similarly, Figure 5 shows a plurality of two UEs 551, 552, connected to WAB node 530 but it will be appreciated that there may be one UE connected or a plurality of more than two. WAB-gNB 532 and WAB-MT 531 may be connected to a same AMF entity (e.g., AMF 51 la) or to different AMF 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 entities may be implementing WAB-specific features for managing a WAB node (e.g., advanced mobility features). Some AMF entities may not implement such features but may still be capable of serving a WAB node with a limited set of basic features. Some AMF entities may not be capable of serving a WAB node. Processes or methods for managing one or more network connections in a wireless communication system including one or more WAB (WAB) nodes, including managing the setup of an Xn communication or connection between a WAB-gNB and a RAN node such as a base station or gNB, or another WAB-gNB of another WAB node, will now be described according to one or more examples of embodiments of the present disclosure. Figure 8 is a flowchart of an example method 800, performed by an NG-RAN network node, for managing the sharing of network device context between a second RAN node, for example an WAB-gNB (in this case a target RAN node) and a first RAN node, for example another NG-RAN network node (in this case a source RAN node), according to one or more embodiments of the present disclosure. In one embodiment, the first RAN node is a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be the same type or different to the first RAN node. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 800 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 800 as shown in and described with respect to Figure 8 may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 8 being performed by one or more processing units, such as the processing unit 402. Briefly, in a first step 801, when turning a served network device (such as User Equipment, UE), or served UE device, to RRCINACTIVE state, as defined in 3GPP TS 38.304 and 3GPP TS 38.331, a first RAN node may send some context information associated to the served network device to one or more RAN nodes. In one embodiment, the first RAN node (source RAN node) may send the network device context information to all or some of the other RAN nodes (target RAN nodes) which have an active Xn connection with the first RAN node. That is to say that there may be one or more other RAN nodes, i.e. a second RAN node, third RAN node etc, which have an active Xn connection with the first RAN node, and the first RAN node may send the network device (such as User Equipment, UE) context information to one or more of the other RAN nodes. In one embodiment, the first (source) RAN node may send the network device (such as User Equipment, UE) context information to a second (target) RAN node for which the benefit of the Xn connection between the first and second (other) RAN nodes is considered as not sufficient (inadequate, insufficient, weakest). The first RAN node may determine that the Xn connection is not sufficient. A not sufficient (inadequate, insufficient) Xn connection may be understood to be one that may not be appropriate as it provides a weak connection, has an unacceptable level of data loss, message delay etc. In some embodiments, the first RAN node may be informed, for example by receiving information, a notification or similar from the other RAN node(s) having an Xn connection with the first RAN node, that the benefit of the XN connection is not sufficient. In one embodiment, the first (source) RAN node may send the network device context information to all or some of the other (target) RAN nodes for which the benefit of the Xn connection with the first RAN node is considered as not sufficient by the first RAN Node. In one example, the benefit of the Xn connection with the first RAN node is considered as not sufficient by the first RAN Node if this benefit value is less than a predefined Xn benefit threshold. In one example, the benefit of the Xn connection is determined by the RAN by performing the method 1200 of Figure 12. By selecting the RAN nodes having the weakest Xn link, i.e., the ones for which the Xn connection is not sufficient, e.g. the ones for which the Xn link benefit is the lowest, to perform network device context information sharing with, method 800 may allow optimizing the radio resources usage by avoiding unnecessary information sharing between the RAN nodes of the WAB system. In one example, the context information sent to the second (target) RAN node may be a subset of the whole context information associated with the served network device (such as User Equipment, UE), as stored by the first (source) RAN node. In one example, the context information sent to the second RAN node may be all or part of the semi-static information of the context information associated with the served network device, as stored by the first RAN node. By doing so, the RAN node(s) may optimize the use of radio resources at WAB system level while optimizing the storage memory resources at RAN node level. In one embodiment, the first (source) RAN node may turn a served network device to RRC INAC1IVE state by releasing the connection, or RRC connection, with the served network device. The first RAN node may release the RRC connection with the served network device by sending a connection release message, such as CONNECTION RELEASE message 602 of Figure 6, to the served network device. In one embodiment, the action of turning the served network device to RRC INACTIVE state by the first RAN node may trigger the sending, by the first RAN node, of the network device context information to the second RAN node. In one example, the first RAN node may send the network device context information to a second RAN node immediately after turning the served network device to RRCINACTIVE state, for instance by sending a message, such as a CONNECTION RELEASE message, to the served network device. In one example, the first RAN node may wait for a minimum time period after turning the served network device to RRC INACTIVE state, for instance by sending a message, such as the CONNECTION RELEASE message, to the served network device, before sending the network device context information to a second RAN node. This minimum time period may be configured by a BH RAN node, in case the first RAN node is a WAB node, or by the AMF serving the first RAN node, or through an Operations, Administration and Maintenance (0AM) procedure. In one example, the first RAN node may send the network device context information to a second RAN node through the CONTEXT INDICATION message 601 of Figure 6. By performing method 800, a first (source) RAN node may allow a second (target) RAN node to further perform RRC Resume procedure for a network device which has been turned to RRC INACTIVE state by the first RAN node, even though the Xn connection between first and second RAN nodes have been removed at the time of performing this procedure. The first RAN node may allow one of the other (target) RAN nodes to further perform RRC Resume procedure for a network device which has been turned to RRC INACTIVE state by the first RAN node, even though the Xn connection between first and said one of the other RAN nodes has been removed at the time of performing this procedure. Method 800 allows limiting the sharing of network device (such as User Equipment, UE) context information to the network device which have actually been turned inactive only, hence avoiding some systematic network device context information sharing (i.e., sharing by a first (source) RAN node with a second (target) RAN node the context information of all the network devices served by the first RAN node) between a first RAN node and one or more second (other) RAN nodes, which would consume unnecessary radio resources at WAB system level while consuming unnecessary computing and storage memory resources at second RAN node level. In a step 802, in a first step 801, when turning a network device (such as User Equipment, UE), or UE device, back from RRC1XACTIVE state to RRCCOXXECTED state, as defined in 3GPP TS 38.304 and 3GPP TS 38.331, a first RAN node notifying this change of state to a second RAN node. In one example, the first RAN node may notify this change of state to a second RAN node for which it has previously sent network device context information associated to the network device which has been turned back from RRCINACTIVE state to RRCCONNECTED state by the first RAN node. In one embodiment, the first (source) RAN node may turn a served network device back from RRC INACTIVE state to RRC CONNECTED state by resuming the connection, or RRC connection, with the network device. The first RAN node may resume the RRC connection with the network device by sending a connection resume message, such as CONNECTION RESUME message 604 of Figure 6, to the network device. In one embodiment, the action of turning the served network device back from RRC INACTIVE state to RRCCOXXECTED state by the first RAN node may trigger the sending, by the first RAN node, of some connection state change notification to the second RAN node. In one example, the first RAN node may send connection state change notification to a second RAN node immediately after turning the served network device back from RRCIXACTIVE state to RRCCOXXECTED state, for instance by sending a message, such as a CONNECTION RESUME message, to the served network device. In one example, the first RAN node may wait for a minimum time period after turning the served network device back from RRC INACTIVE state to RRC CONNECTED state, for instance by sending a message, such as the CONNECTION RESUME message, to the served network device, before sending the connection state change notification to a second RAN node. This minimum time period may be configured by a BH RAN node, in case the first RAN node is a WAB node, or by the AMF serving the first RAN node, or through an Operations, Administration and Maintenance (0AM) procedure. In one example, the first RAN node may send the connection state change notification to a second RAN node through the CONTEXT INDICATION message 601 of Figure 6. In one embodiment, the first RAN node may use the connection state change notification to request the second RAN node to delete some network device context information previously sent by the first RAN node to second RAN node at step 801. Figure 9 is a flowchart of an example method 900, performed by an NG-RAN network node, for managing the sharing of network device context between a second RAN node, for example an WAB-gNB (in this case a target RAN node) and a first RAN node, for example another NG-RAN network node (in this case a source RAN node) according to one or more embodiments of the present disclosure; In one embodiment, the first RAN node is a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be the same type or different to the first RAN node. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 900 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 900 as shown in and described with respect to Figure 9 may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4, with the method being performed by one or more processing units, such as processing unit 402. The method, or parts of the method, in Figure 9 may be performed with the method, or parts of the method, as shown in and described with respect to Figure 8 and both method may be performed by one or more processing units, such as the processing unit 402, of the communication device 400 shown in and described with reference to Figure 4. Briefly, in a first step 901, when performing the removal of an Xn connection with a second (target) RAN node, a first (source) RAN node may send some context information associated with all or some of the network devices (UEs) it is currently serving to the second RAN node. That is to say that first RAN node may send all or some of the context information for one, all or some of the network devices it is current serving to the second RAN node. In one example, the network device context information may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network context information may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the context information may be all or part of the semi-static information of the UE Context information associated to the served network device. In one embodiment, the removal of the Xn connection is initiated by the first (source) RAN node. In one embodiment, the removal of the Xn connection is initiated by second (target) RAN node. In one embodiment, the first (source) RAN node may initiate the removal of an Xn connection with a second (target or other) RAN node when the benefit of the Xn connection with the first RAN node is considered as not sufficient (inadequate, insufficient) by the first RAN Node. In one example, the benefit of the Xn connection with the first RAN node is considered as not sufficient by the first RAN Node if this benefit value is less than a predefined Xn benefit threshold. In one example, the benefit of the Xn connection is determined by the RAN by performing the method 1200 of Figure 12. A not sufficient (inadequate, insufficient) Xn connection may be understood to be one that may not be appropriate as it provides a weak connection, has an unacceptable level of service (for example data loss, message delay), or which requires a significant number of retransmissions, or is likely to fail within a short period of time, etc In one example, the first RAN node or the second RAN node may initiate the removal of the Xn connection between the first and second RAN node by sending an Xn connection removal request message to the RAN node not initiating the removal. That is to say that either the first or second RAN nodes may initiate the removal of the Xn connection therebetween by sending an Xn connection removal request message to other of the first or second RAN nodes. In one example, a RAN node receiving an Xn connection removal request message from another RAN node may respond to this request by sending an Xn connection removal response message. In one embodiment, when the first RAN node initiates the removal of the Xn connection, the first RAN node may add the network device context information to the Xn connection removal request message. In one example, the Xn connection removal request message is the CONNECTION REMOVAL REQUEST message 703 of Figure 7. In one embodiment, when the second RAN node initiates the removal of the Xn connection, the first RAN node may add the network device context information to the Xn connection removal response message. In one example, the Xn connection removal response message is the CONNECTION REMOVAL RESPONSE message 704 of Figure 7. Method 900 allows limiting the sharing of network device context information with the RAN nodes which are about to lose their Xn connection with a first RAN node only, hence avoiding some systematic network device context information sharing (i.e., sharing network device information with all the RAN nodes for which an Xn connection is existing), which would consume unnecessary radio resources at WAB system level while consuming unnecessary computing and storage memory resources at the receiving RAN node(s) level. Figure 10 is a flowchart of an example method 1000, performed by an NG-RAN network node, for managing the sharing of network device context between a second RAN node, for example an WAB-gNB (in this case a target RAN node), and a first RAN node, for example another NG-RAN network node, according to one or more embodiments of the present disclosure. In one embodiment, the first network node is a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be the same type or different to the first RAN node. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 1000 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 1000 as shown in and described with respect to Figure 10 may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 10 being performed by one or more processing units, such as the processing unit 402. In some embodiments, the method, or parts of the method, shown and described in reference to Figure 10 may be performed with the method, or parts of the method, shown in and described with reference to Figure 8 and / or Figure 9. Briefly, in a first step 1001, a first (source) RAN node may decide to send some context information associated to (or with) a served network device (such as User Equipment, UE) to a second (target) RAN node. The first RAN node may send some or all the context information unsolicited, that is to say, that the first RAN node may send the context information without receive a request for the context information. In one example, a first (source) RAN node may decide to send some updated context information associated to (or with) a served network device (such as User Equipment, UE) to a second (target) RAN node, in case the first (source) RAN node had previously sent to the second (target) RAN node some initial context information associated to (or with) a served network device (such as User Equipment, UE). The first RAN node may send some or all the updated context information unsolicited, that is to say, that the first RAN node may send the updated context information without receiving a request for the updated context information. In one example, the network device context information may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network context information may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the context information may be all or part of the semi-static information of the UE Context information associated to the served network device. In one example, the sending by the first RAN node of the network device context information to a second RAN node may be triggered by one of the following events: The connection between the first RAN node and the served network device has been established. In one example, the first RAN node may send the network device context information to the second RAN node immediately after the connection between the first RAN node and the served network device has been established. In one example, the first RAN node may wait for a minimum time period after the connection between the first RAN node and the served network device has been established before sending the network device context information to a second RAN node. This minimum time period may be configured by a BH RAN node, in case the first RAN node is a WAB node, or by the AMF serving the first RAN node, or through an Operations, Administration and Maintenance (0AM) procedure. The Xn connection between the first RAN node and second RAN node has been established. In one example, the first RAN node may send the network device context information to the second RAN node immediately after the establishment of the Xn connection between the first RAN node and the second RAN node has been completed. In one example, the first RAN node may wait for a minimum time period after the connection between the first RAN node and the served network device has been established before sending the network device context information to the second RAN node. This minimum time period may be configured by a BH RAN node, in case the first RAN node is a WAB node, or by the AMF serving the first RAN node, or through an Operations, Administration and Maintenance (0AM) procedure. The first RAN node has updated the network device context information associated to network device for which it has previously sent some network device context information to the second RAN node. In one embodiment, in addition to any of the above triggers, the sending by first RAN node of some context information associated to a served network device to a second RAN node may be conditioned by the benefit of maintaining the Xn connection between the first RAN node and the second RAN node. In one example, in addition to any of the above triggers, the first RAN node may initiate the sending of the context information associated to a served network device to a second RAN node when the benefit of the Xn connection between the first RAN node and the second RAN node is considered as not sufficient by the first RAN Node. In one example, the benefit of the Xn connection with the first RAN node is considered as not sufficient by the first RAN Node if this benefit value is less than a predefined Xn benefit threshold. In one example, the benefit of the Xn connection is determined by the RAN by performing the method 1200 of Figure 12. In one example, the first RAN node may send the network device context information to a second RAN through the CONTEXT INDICATION message 601 of Figure 6. In one example where the sending by first RAN node of some network device context information to a second RAN node is triggered by the establishment of the Xn connection between the first RAN node and the second RAN node, the first RAN node may add the network device context information to the Xn connection setup request message when the first RAN node initiates the establishment of the Xn connection, or to the Xn connection setup request message when the second RAN node initiates the establishment of the Xn connection. In one example, the Xn connection setup request message is the CONNECTION SETUP REQUEST message 701 of Figure 7. In one example, the Xn connection setup response message is the CONNECTION SETUP RESPONSE message 702 of Figure 7. Figure 11 is a flowchart of an example method 1100, performed by an NG-RAN node, for managing the storage of network device context at an NG-RAN network node according to one or more embodiments of the present disclosure; In one embodiment, the NG-RAN network node may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 1100 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 1100 as shown in and described with respect to Figure 11 may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 11 being performed by one or more processing units, such as the processing unit 402. Briefly, in a first step 1101, a second (target) RAN node may, upon expiry of a context discard timer, delete from his local memory some network device (such as User Equipment, UE) context information previously received from a first (source) RAN node. By applying method 1100, the second RAN node may optimize its local memory resources, by removing useless network device context information. In one embodiment, the second RAN node may receive some network device context information from a first RAN node by performing any of the methods 800, 900 or 1000. In one example, the second RAN node may launch a context discard timer upon reception of some network device context information from a first RAN node. In one example, the context discard timer may be launched upon reception of any one of the following messages including some network device context information: a CONTEXT INDICATION message 601, a CONNECTION SETUP REQUEST message 701, a CONNECTION SETUP RESPONSE message 702, a CONNECTION REMOVAL REQUEST message 703 or a CONNECTION REMOVAL RESPONSE message 704. In one example, the context discard timer may be configured through an Operations, Administration and Maintenance (0AM) procedure. In one example, the second RAN node may only discard a subset of the stored network device context information upon expiry of the context discard timer. In one example, the second RAN node may only discard the dynamic part of the device context information, i.e., the part of the device context information that is not semi-static. Figure 12 is a flowchart of an example method 1200, performed by an NG-RAN network node, for determining the benefit of an Xn connection between two NG-RAN network nodes according to one or more embodiments of the present disclosure. The NG-RAN network node(s) may be a Backhaul RAN node, or a gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The NG-RAN nodes may be of the same or different types. In one embodiment, the NG-RAN node performing method 1200 may be a Wireless Access Backhaul, WAB, node, or a Backhaul RAN node or any NG-RAN node in the network. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 1200 may be the MWA-node 530 of WAB system 500, while a Backhaul RAN node performing the method 1200 may be the NG-RAN node 501 or 502. The method 1200 as shown in and described with respect to Figure 12 may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 12 being performed by one or more processing units, such as the processing unit 402. Briefly, in a first step 1201, a first (source) NG-RAN node may determine the benefit of an Xn connection with a second (target) NG-RAN node. In one embodiment, the NG-RAN node may determine the benefit of an Xn connection which has not been established yet. In one embodiment, the NG-RAN node may determine the benefit of an Xn connection which has already been established. In one example, the benefit of an Xn connection with a second NG-RAN node, as determined by the first NG-RAN node, is a function of at least one of the following criteria: Served UE connectivity criterion. This criterion refers to the ability for one or more UEs served by the first RAN node to connect to the second RAN node. In one example, a UE served by the first RAN node may be able to connect to the second RAN node if the radio link quality resulting from signal strength measurements performed by the UE and associated to a cell managed by the second RAN node is above a predefined threshold the radio link quality. In one example, a UE served by the first RAN node may report to the first RAN node the radio link quality between this UE and the second RAN node by sending to the first RAN node a measurement reporting message, such as the MeasurementReport message, as defined in TS 38.331. In one example, the Served UE connectivity criterion may be related to the number of served UEs that are able to connect to the second RAN node. For instance, the Served UE connectivity criterion may be related to the number of served UEs that are able to connect to the second RAN node compared to a predefined Served UE connectivity threshold. In one example, the Served UE connectivity criterion may be related to the ratio of served UEs that are able to connect to the second RAN node. For instance, the Served UE connectivity criterion may be related to the ratio of served UEs that are able to connect to the second RAN node compared to a predefined Served UE connectivity ratio threshold. In one example, the Served UE connectivity criterion may be related to the ability for one or more UEs served by the first RAN node to connect to the second RAN node for a minimum duration, ox Minimum UE Connectivity Duration threshold. In one example, to assess the Served UE connectivity criterion, the first RAN node may rely on a dedicated timer, ox Minimum UE Connectivity Duration Timer. In one example, the first RAN node may derive a score, or UE connectivity score, from the Served UE connectivity criterion. In one example, this score may be an integer value. WAB-MT connectivity criterion. In case the first NG-RAN node is a WAB node, this criterion refers to the ability for the WAB-MT part of the first RAN node to connect to the second RAN node. In one example, a WAB-MT may be able to connect to the second RAN node if the radio link quality resulting from signal strength measurements performed by the WAB-MT and associated to a cell managed by the second RAN node is above a predefined radio link quality threshold. In one example, the WAB-MTconnectivity criterion may be related to the ability for the WAB-MT of the first RAN node to connect to the second RAN node for a minimum duration, ox Minimum WAB-MT Connectivity Duration threshold. In one example, to assess the WAB-MTconnectivity criterion, the first RAN node may rely on a dedicated timer, ox Minimum WAB-MT Connectivity Duration Timer. In one example, the first RAN node may derive a score, or WAB-MT connectivity! score, from the WAB-MT connectivity criterion. In one example, this score may be an integer value. Direct connectivity criterion. This criterion refers to radio link quality between the first and the second RAN node. This criterion may be related to the signal strength measurements performed by the first RAN node and associated to a cell managed by the second RAN node. In one example, to assess the Direct connectivity criterion, the first RAN node may compare the signal strength measurements to one or more predefined radio link quality thresholds. In one example, the first RAN node may derive a score, or Direct connectivity score, from the Direct connectivity criterion. In one example, this score may be an integer value. - Xn neighborhood criterion. This criterion refers to the presence of the second RAN node in the neighborhood of a third RAN node having Xn connectivity with the first RAN node. In one example, the third RAN node may establish a list of the neighbor cells belonging to RAN nodes neighboring or in the vicinity of the third RAN node. In one example, the third RAN node may share all or part of this list upon Xn connection establishment. In one example, the first RAN node may derive a score, or Xn neighborhood score, from the Xn neighborhood criterion. In one example, this score may be an integer value. Geographical area criterion. This criterion refers to the presence of the first and second RAN nodes in a same geographical area. In one example, the considered geographical area may be any one of: RAN-based Notification Area (RNA), Tracking Area (TA), a group of NR Cells. In one example, the first RAN node may derive a score, or Geographical area score, from the Geographical area criterion. In one example, this score may be an integer value. - Mobility criterion. This criterion refers to impact of the mobility of the first RAN nodes on being present in one same geographical area as the second RAN node. In one example, the Mobility criterion may be based all or part of the following: speed information indicating a speed capability of the first RAN node, range information indicating a mobility area of the first RAN node, static information indicating a duration of one or more static periods the first RAN node may experience, itinerary information indicating a sequence of mobility and static periods for an itinerary the first RAN node may follow. The speed information may include information indicating one or more of a minimum speed capability of the first RAN node, average speed capability of the first RAN node, maximum speed capability of the first RAN node. The range information may include information indicating an area in which the first RAN node may move or range of movement of the first RAN node. For example, the range information may include a type or category of the mobility area in which the first RAN node may move and which can be an indication of the size or nature of the geographical area in which the first RAN node may move. For example, the type (or category) of mobility area may indicate the geographical area is a plane route, or a train route. The range information additionally or alternatively may include a size of the area (i.e., mobility area) in which the first RAN node may move and / or a list of the cell Identifiers (IDs) of the cells that the first RAN node may visit or has visited previously. The range information additionally or alternatively may include a distance by which the first RAN node may move. The static information may include static time information indicating one or more of minimum static period duration, average static period duration or maximum static period duration. The static information may also include static position information indicating the location where the first RAN will be static. The itinerary information may include information indicating, for each of the mobility and static periods, the duration of the period, the speed of the first RAN node during one or more of the mobility periods, the location of the first RAN node during one or more of the static periods. In one example, the first RAN node may derive a score, ox Mobility score, from the Mobility criterion. In one example, this score may be an integer value. According to one embodiment of the disclosure, the aforementioned signal strength measurements may include all or part of the following metrics: - Reference Signal Received Power (RSRP), which provides a measure of the received power of the strongest reference signal from the considered cell. - Reference Signal Received Quality (RSRQ), which provides a measure of the quality of the received reference signal from the considered cell, relative to the interference level in the cell. Signal-to-Noise Ratio (SNR), which provides a measure of the signal quality relative to the noise level in the cell and can be used to determine the strength of the signal from the considered cell. Channel Quality Indicator (CQI), which provides a measure of the quality of a received signal. In addition to the above metrics, other measurements such as cell identity, beamforming quality, and channel state information may also be considered for signal strength measurements. In one embodiment, the first RAN node may derive the benefit of an Xn connection from all or part of the above scores. In one example, the benefit value of an Xn connection may be the average of the considered score values. In one example where some of the above criteria are considered more important than others, the benefit value of an Xn connection may be a weighted average of the considered score values. In one example, the benefit of an Xn connection value may be an integer value (e.g., an integer value ranging from 0 to 8). Referring now also to Figure 6, a schematic and simplified diagram illustrating example message flows for use in managing network connectivity in a wireless communication system including at least one Wireless Access Backhaul, WAB, node in accordance with one or more embodiments of the present disclosure and which may be used for managing network device context sharing between a first RAN node 620 and a second RAN node 630, is shown. In the embodiment shown in Figure 6, RAN node 620 is the source RAN node and RAN node 630 is the target RAN node. In one embodiment, at least one out of the two NG-RAN nodes 620 and 630 may be the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul, WAB, node, while the other NG-RAN node may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul, or any NG-RAN node in the network. In one embodiment, RAN node 620 may perform a connection setup process 603 with network device 610, which may be a UE device, such as UE 561 of Figure 5. In one example, this connection setup process may be the RRC connection establishment procedure, as defined in 3GPP TS 38.331. In one embodiment, upon completion of the connection setup process with network device 610, RAN node 620 may send a CONTEXT INDICATION message 601 to RAN node 630, where the CONTEXT INDICATION message 601 includes some network device context information associated to the network device 610. In the current example, RAN node 620 is the source RAN node sending the CONTEXT INDICATION Message unsolicited to the source RAN node, i.e. RAN node 630. The sending of network device context information is unsolicited as the target RAN node did not request the context information. In one example, the connection setup process with network device 610 is considered as complete by RAN node 620 upon the reception from network device 610 of a connection setup complete message, which may be, for instance, the RRCSetupComplete message, as defined in 3GPP TS 38.331. In another example, the connection setup process with network device 610 is considered as complete by RAN node 620 upon the transmission to the network device 610 of a connection setup message, which may be, for instance, the RRCSetup message, as defined in 3GPPTS 38.331. In one example, RAN node 620 may send the CONTEXT INDICATION message 601 to RAN node 630 immediately after completing the connection setup process with network device 610. In one example, RAN node 620 may wait for a minimum time period after completing the connection setup process with network device 610 before sending the CONTEXT INDICATION message 601 to RAN node 630. This minimum time period may be configured by a BH RAN node, in case RAN node 620 is a WAB node, or by the AMF serving RAN node 620, or through an Operations, Administration and Maintenance (0AM) procedure. In one embodiment, RAN node 620 may, at some point, turn the served network device 610 to RRC INACTIVE state. RAN node 620 may do so by releasing the connection, or RRC connection, with the served network device 601. In one example, RAN node 620 may release the RRC connection with the served network device by sending a CONNECTION RELEASE message 602 to the served network device 601. In one example, the CONNECTION RELEASE message 602 is the RRCRelease message, as defined in 3GPP TS 38.331. In one embodiment, once RAN node 620 has sent the CONNECTION RELEASE message 602 to network device 610, hence turning network device 610 to RRC INACTIVE state, RAN node 620 may send a CONTEXT INDICATION message 601 to RAN node 630, where the CONTEXT INDICATION message 601 includes some network device context information associated to the network device 610. In one embodiment, RAN node 620 may, at some point, turn a network device 610 back from RRCINACTIVE state to RRCCONNECTED state. RAN node 620 may do so by resuming the connection, or RRC connection, with the served network device 601, e.g., by performing the RRC connection resume procedure, as defined in 3GPP TS 38.331, with the network device. In one example, RAN node 620 may complete the resume of the RRC connection with the network device 610 by sending a CONNECTION RESUME message 604 to the network device 601. In one example, the CONNECTION RESUME message 604 is the RRCSetup message, as defined in 3GPP TS 38.331. In one embodiment, once RAN node 620 has sent the CONNECTION RESUME message 604 to network device 610, hence turning network device 610 back from RRC INACTIVE state to RRC CONNECTED state, RAN node 620 may send a CONTEXT INDICATION message 601 to RAN node 630, where the CONTEXT INDICATION message 601 includes some network device context information associated to the network device 610 and / or some indication on the change of connection status for network device 610. In one example, the CONTEXT INDICATION message 601 may be the NG-RAN NODE CONFIGURATION UPDATE message, as defined in 3GPP TS 38.423. In one example, the CONTEXT INDICATION message 601 may be a new UE CONTEXT INDICATION message. In one example, RAN node 620 may send the CONTEXT INDICATION message 601 to RAN node 630 immediately after sending the CONNECTION RELEASE message 602 or the CONNECTION RESUME message 604 to the network device 610. In one example, RAN node 620 may wait for a minimum time period after sending the CONNECTION RELEASE message 602 or the CONNECTION RESUME message 604 to the network device 610 before sending the CONTEXT INDICATION message 601 to RAN node 630. This minimum time period may be configured by a BH RAN node, in case RAN node 620 is a WAB node, or by the AMF serving RAN node 620, or through an Operations, Administration and Maintenance (0AM) procedure. In one embodiment, discussed in relation to Figure 6 but applicable to any other embodiment, in case RAN node 620 has determined that the benefit of the Xn connection between RAN node 620 and RAN node 630 is sufficient enough, it may not send the CONTEXT INDICATION message 601 to RAN node 630, as RAN node 620 may consider that the Xn connection is likely to last and that, in case the network device 610 in RRC-INACTIVE state further attempts to resume its connection through RAN node 630 (for instance using the RRC resume procedure, as defined in TS 38.331), RAN node 630 may rely on the Xn connection between RAN node 620 and RAN node 630 to retrieve network device’s 601 UE context from RAN node 620 and complete the RRC resume procedure. In one example, RAN node 620 may determine the benefit of the Xn link with RAN node 630 before sending the CONNECTION RELEASE message 602 to network device 610. In one example, RAN node 620 may determine the benefit of the Xn link with RAN node 630 after sending the CONNECTION RELEASE message 602 to network device 610. In one example, RAN node 620 may determine the benefit of the Xn link with RAN node 630 by performing the method 1200 of Figure 12. In one example, in relation with any of the embodiments in relation with Figure 6, the network device context information included in the CONTEXT INDICATION message 601 may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network device context information included in the CONTEXT INDICATION message 601 may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device 610. In one example, the context information sent to RAN node 630 may be all or part of the semi-static information of the UE Context information associated to the served network device 610. In one embodiment, in relation with any of the embodiments in relation with Figure 6, the CONTEXT INDICATION message 601 may include network device context information associated to network device 610 only. In another example, the CONTEXT INDICATION message 601 may include network device context information associated to network device 610 and to other network devices served by RAN node 620. In one embodiment, the CONTEXT INDICATION message 601 sent by RAN node 620 to RAN node 630 may include all or part of the following information: UE Context to Add List information. This information includes network device context information associated to one or more network devices, such as network device 610, served RAN node 620, in accordance with any of the above embodiments. UE Context to Update List information. This information includes network device context information associated to one or more network devices, such as network device 610, for which all or part of the network device context information, as previously sent by RAN node 620 through a UE Context to Add List information, has been updated by RAN node 620, in accordance with any of the above embodiments. UE Context to Remove List information. This information is used by RAN node 620 to indicate a list of one or more network devices, such as network device 610, for which RAN node 630 may delete, or discard, some network device context information previously received through the UE Context to Add List information or the UE Context to Update List information, e.g., network devices which have been turned back from RRCINACTIVE to RRCCONNECTED state by RAN node 620, in accordance with any of the above embodiments. UE connection state change List information. This information is used by RAN node 620 to indicate to RAN node 630 a list of one or more network devices (for which it has previously sent network device context information through the UE Context to Add List information or the UE Context to Update List information) for which the connection status has changed, e.g., network devices which have been turned back from RRC INACTIVE state to RRC CONNECTED state by RAN node 620, or a list of one or more network devices which have been turned from RRC CONNECTED state to RRC INACTIVE state by RAN node 620, in accordance with any of the above embodiments. In one example, upon reception of some UE connection state change List information, the second RAN node may decide to delete, or discard, the network device context information associated to the network devices associated to the UE connection state change List information. Referring now also to Figure 7, which is a schematic and simplified diagram illustrating example message flows for use in managing network connectivity in a wireless communication system including at least one Wireless Access Backhaul, WAB, node in accordance with one or more embodiments of the present disclosure and which may be used for managing network device context sharing between two NG-RAN nodes. In one embodiment, RAN node 720 may initiate a connection setup process to establish a Xn connection with the RAN node 730 by sending a CONNECTION SETUP REQUEST message 701 to the RAN node 730. In one example, this connection setup process may be the Xn Setup procedure, as defined in 3GPP TS 38.423 and the CONNECTION SETUP REQUEST message 701 may be the XN SETUP REQUEST message, as specified in 3GPP TS 38.423. The RAN node 730 may further respond to the CONNECTION SETUP REQUEST message 701 by sending a CONNECTION SETUP RESPONSE message 702 to the RAN node 720. In one example, the CONNECTION SETUP RESPONSE message 702 may be the XN SETUP RESPONSE message, as specified in 3GPP TS 38.423. In one embodiment of the disclosure, where RAN node 720 is initiating the setup of the Xn connection with RAN node 730, RAN node 720 may add to the CONNECTION SETUP REQUEST message 701 some context information associated to one or more served network devices. In one example, the network device context information included in the CONNECTION SETUP REQUEST message 701 may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network device context information included in the CONNECTION SETUP REQUEST message 701 may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to one or more network devices it is currently serving. In one example, the context information included in the CONNECTION SETUP REQUEST message 701 may be all or part of the semi-static information of the UE Context information associated to the one or more served network devices. In one embodiment of the disclosure, where RAN node 720 is initiating the setup of the Xn connection with RAN node 730, RAN node 730 may add to the CONNECTION SETUP RESPONSE message 702 some context information associated to one or more network devices it is currently serving. In one example, the network device context information included in the CONNECTION SETUP RESPONSE message 702 may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network device context information included in the CONNECTION SETUP RESPONSE message 702 may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to one or more network devices it is currently serving. In one example, the network device context information included in the CONNECTION SETUP RESPONSE message 702 may be all or part of the semi-static information of the UE Context information associated to the one or more served network devices. In one embodiment, RAN node 720 may initiate a connection removal process to remove a Xn connection with the RAN node 730 by sending a CONNECTION REMOVAL REQUEST message 703 to the RAN node 730. In one embodiment, RAN node 720 may initiate a connection removal process in case RAN node 720 has determined that the benefit of the Xn connection between RAN node 720 and RAN node 730 is not sufficient. In one example, RAN node 720 may determine the benefit of the Xn link with RAN node 730 by performing the method 1200 of Figure 12. In one example, the connection removal process may be the Xn Removal procedure, as defined in 3GPP TS 38.423 and the CONNECTION REMOVAL REQUEST message 703 may be the XN REMOVAL REQUEST message, as specified in 3GPP TS 38.423. RAN node 730 may further respond to the CONNECTION REMOVAL REQUEST message 703 by sending a CONNECTION REMOVAL RESPONSE message 704 to the RAN node 720. In one example, the CONNECTION SETUP RESPONSE message 704 may be the XN REMOVAL RESPONSE message, as specified in 3GPP TS 38.423. In one embodiment of the disclosure, where RAN node 720 is initiating the removal of the Xn connection with RAN node 730, RAN node 720 may add to the CONNECTION REMOVAL REQUEST message 703 some context information associated to one or more served network devices. In one example, the network device context information included in the CONNECTION SETUP REQUEST message 703 may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network device context information included in the CONNECTION REMOVAL REQUEST message 703 may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to one or more network devices RAN node 720 is currently serving. In one example, the context information included in the CONNECTION REMOVAL REQUEST message 703 may be all or part of the semi-static information of the UE Context information associated to the one or more served network devices. In one embodiment of the disclosure, where RAN node 720 is initiating the setup of the Xn connection with RAN node 730, RAN node 730 may add to the CONNECTION REMOVAL RESPONSE message 704 some context information associated to one or more network devices it is currently serving. In one example, the network device context information included in the CONNECTION SETUP RESPONSE message 704 may be the UE Context information, as defined in 3GPP TS 38.331, associated to the served network device. In one example, the network device context information included in the CONNECTION SETUP RESPONSE message 704 may be a subset of the UE Context information, as defined in 3GPP TS 38.331, associated to one or more network devices RAN node 730 is currently serving. In one example, the context information included in the CONNECTION SETUP RESPONSE message 704 may be all or part of the semi-static information of the UE Context information associated to the one or more served network devices. Figure 13A is a flowchart of an example method 1300, performed by an NG-RAN network node, for managing the sharing of network device context between a second RAN node, for example an WAB-gNB (in this case a target RAN node) and a first RAN node, for example another NG-RAN network node (in this case a source RAN node), according to one or more embodiments of the present disclosure. In one embodiment, the first RAN node is a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be the same type or different to the first RAN node. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 1300 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 1300 as shown in and described with respect to Figure 13A may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 13 A being performed by one or more processing units, such as the processing unit 402. In one embodiment, the first RAN node will send 1301 network device (such as User Equipment, UE) context inform to a second RAN node which has an active Xn connection with the first RAN node. The first RAN node will send the context information unsolicited to the second RAN node, that is to say that the second RAN node will not request (solicit) the context information. Put another way there is no request which explicitly requests the context information. The sending of the context information may be because the Xn connection has just been or has recently been established or because of a trigger event, such as the Xn connection being not sufficient or the setting of a UE to inactive state or the sending or receiving of a message, or any other reason discussed above in relation to one or more other embodiments. Figure 13B is a flowchart of an example method 1302, performed by an NG-RAN network node, for managing the sharing of network device context between a second RAN node, for example an WAB-gNB (in this case a target RAN node) and a first RAN node, for example another NG-RAN network node (in this case a source RAN node), according to one or more embodiments of the present disclosure. Figure 13B shows and briefly discussed the counterpart to Figure 13 A, that is to say it shows and discusses the second RAN node receiving the unsolicited context information. In one embodiment, the first RAN node is a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be a NG-RAN network node which may be a Backhaul RAN node, or the gNB component (or part or unit), or WAB-gNB, of a Wireless Access Backhaul. The second RAN node may be the same type or different to the first RAN node. For example, with reference to the wireless communication system shown in and described with respect to Figure 5, a WAB node performing the method 1302 may be the MWA-node 530, which comprises MWAB-MT 531 and MWAB-gNB 532, of WAB system 500, while a Backhaul RAN node performing the disclosure may be the NG-RAN node 501 or 502. The method 1302 as shown in and described with respect to Figure 13B may be performed by software elements and / or hardware elements. The NG-RAN node performing the disclosure may be implemented in a communication device 400 as shown in and described with reference to Figure 4 with the method as shown in and described with respect to Figure 13 A being performed by one or more processing units, such as the processing unit 402. In one embodiment, the second RAN node will receive 1303 network device (such as User Equipment, UE) context inform from a first RAN node which has an active Xn connection therebetween. The second RAN node will receive the context information unsolicited, that is to say that the second RAN not will not have requested (solicited) the context information. The first RAN node may have sent the context information because the Xn connection has just been or has recently been established or because of a trigger event, such as the Xn connection being not sufficient or the setting of a UE to inactive state, or any other reason discussed above in relation to one or more other embodiments. In some embodiments, the second RAN node may have initiated some process (as discussed further above), such as an Xn removal request or a connection request, through sending a message to the first RAN node, however, the message sent from the second RAN node does not request (solicit) context information. In a case where the second RAN node initiates some process, the first RAN node will send the context information despite there being no request for the context information. In the embodiments and example described the network device context information, especially the UE context information, is sent unsolicited. For example, it is sent without receiving a request for the context information. Put another way the source RAN node does not receive a request for context information from the target RAN node prior to sending the context information. An event may trigger the sending of the context information unsolicited as said event is not a request for context information. Reference to MW AB node / device, or mobile WAB node / device, throughout the description should be considered to also refer to WAB node / device. Typically, a WAB node may be understood to refer particularly but not exclusively to the node / device being non-mobile, i.e., disposed to a fixed, i.e., static, structure, for example, MW AB node 130 may be considered a WAB node 130 because it is mounted to a building. In most cases, as is understood from the forgoing, mobile may be understood to mean capable of moving, i.e., capable of changing geographical location, and still operating. For example, by being attached to a vehicle or person which is capable of moving. While the present disclosure has been described with reference to examples and embodiments, it is to be understood that the disclosure 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 disclosure, 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 description, 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 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 non-transient, 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 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 in a wireless network including a plurality of Radio Access Network, RAN, nodes, an Xn connection being established between a source RAN node and a target RAN node of the plurality of RAN nodes, the method at the source RAN node comprising:sending, to the target RAN node, an unsolicited User Equipment, UE, context of a UE served by the source RAN node.

2. A method according to claim 1, wherein, in a case where the benefit of maintaining the Xn connection is not sufficient, sending of the unsolicited UE context of the UE served by the source RAN node.

3. A method according to claim 2, wherein the benefit of maintaining the Xn connection is not sufficient based on a benefit value.

4. A method according to claim 3, wherein the benefit value is a Xn benefit parameter, the value of the Xn benefit parameter representing a benefit of the connection between the source RAN node and the Target RAN node.

5. A method according to claim 3 or claim 4, wherein the benefit of maintaining the Xn connection is not sufficient based on the benefit value being equal to or less than a predetermined threshold.

6. A method according to any one of claims 2 to 5, wherein the benefit of maintaining the Xn connection is not sufficient based on at least one of:served UE connectivity criteria;RAN connectivity criteria;geographical criteria;mobility criteria;Xn neighborhood criteria; andWAB-MT connectivity criteria.

7. A method according to claim 6, wherein the served UE connectivity criteria is based on at least one of the following:an ability of the UE served by the source RAN node to connect to the target RAN node; a radio link quality between the served UE and a cell managed by the target RAN node; the number of served UEs that are able to connect to the target RAN node, or a ratio of the UEs served by the source RAN node to the UEs served by the source RAN node that are able to connect to the target RAN node;an ability of the UE served by the source RAN node to connect to, and remain connected to, the target RAN node for at least a minimum time period.

8. A method according to claim 6 or claim 7, wherein the RAN connectivity criteria is based on an ability for the mobile termination of the source RAN node to connect to the target RAN node.

9. A method according to any one of claims 6 to 8, wherein the geographical criteria is based on a location of one or both of the source RAN node and the target RAN node.

10. A method according to claim 9, wherein the geographical criteria is any one of a RAN-based Notification Area, RNA, a Tracking Area, TA, or a group of NR cells.

11. A method according to any one of claims 6 to 10, wherein the mobility criteria represents the mobility of one or both of the source RAN node and the target RAN node.

12. A method according to claim 11, wherein a mobility profile of one or both of the source RAN node and the target RAN node provides the mobility criteria.

13. A method according to claim 11 or claim 12, wherein the mobility criteria is based on at least one of: a minimum speed capability, an average speed capability of one or both of the source RAN node and target RAN node, a maximum speed capability of one or both of the source RAN node and target RAN node, range capability information of one or both of the source RAN node and target RAN node, static period information indicating a duration of one or more time periods during which one or both of the source RAN node and target RAN node are expected to be stationary, and itinerary information indicating a sequence of time periods and further indicating whether one or both of the source RAN node and target RAN node are expected to be in motion or stationary during the respective indicated time periods.

14. A method according to claim 13, wherein the range capability information comprises at least one of: information indicating an area in which of one or both of the source RAN node and target RAN node may move, information indicating the size of the area in which of one or both of the source RAN node and target RAN node may move, a distance that the of one or both of the source RAN node and target RAN node may move, and one or more cell Identifiers, IDs, corresponding to one or more cells that one or both of the source RAN node and target RAN node may be in range of or has been in range of previously.

15. A method according to claim 13 or claim 14, wherein the static period information includes information indicating at least one of: a minimum static period duration of one or both of the source RAN node and target RAN node, an average static period duration of one or both of the source RAN node and target RAN node, a maximum static period duration of one or both of the source RAN node and target RAN node, and static position information indicating one or more locations at which one or both of the source RAN node and target RAN node are expected to be stationary.

16. A method according to any one of claims 13 to 15, wherein the itinerary information includes information indicating, for each of the time periods of the sequence of time periods, at least one of: the duration of the time period, the speed of the source RAN node if the source RAN node is expected to be in motion during the time period, the location at which the source RAN node is expected to be stationary if the source RAN node is expected to be stationary during the time period,, the speed of the target RAN node if the target RAN node is expected to be in motion during the time period, and the location at which the target RAN node is expected to be stationary if the target RAN node is expected to be stationary during the time period.

17. A method according to any one of claims 6 to 16, wherein the Xn neighborhood criteria is representative of the target RAN node being present in a neighborhood of a further RAN node, the further RAN node being connected to the source RAN node via an Xn connection.

18. A method according to any one of claims 6 to 17, wherein the source RAN node is a gNB component of a Wireless Access Backhaul, WAB, node comprising a Mobile Termination, MT, component, and the gNB component; wherein the WAB-MT connectivitycriteria being representative of the ability of the MT component of the source WAB node to connect to the target RAN node.

19. A method according to claim 18, wherein the WAB-MT connectivity criteria is representative of the ability of the MT component of the source WAB node to connect to, and remain connected to, the target RAN node for at least a minimum time period.

20. A method according to any preceding claim, wherein, in a case where the Xn connection is to be removed, sending of the unsolicited UE context of the UE served by the source RAN node prior to removing the Xn connection.

21. A method according to claim 20, when dependent upon any one of claims 2 to 19, wherein the Xn connection is to be removed in the case where the benefit of maintaining the Xn connection is not sufficient.

22. A method according to claim 20 or claim 21, wherein one of the source RAN node or the target RAN node initiate the removal of the Xn connection.

23. A method according to any preceding claim, wherein the connection being established between the source RAN node and target RAN node is based on a benefit of establishing a Xn connection.

24. A method according to claim 23, wherein the benefit of establishing a Xn connection is based on a benefit value.

25. A method according to claim 24, wherein the benefit value is a Xn benefit parameter, the value of the Xn benefit parameter representing a benefit of establishing a connection between the source RAN node and the Target RAN node.

26. A method according to claim 25, wherein the Xn benefit parameter for establishing a Xn connection is based on at least one of the criteria of claims 6 to 19.

27. A method according to any one of claims 23 to 26, wherein, in a case where the benefit of establishing a Xn connection is sufficient, one of: a CONNECTION SETUP REQUEST message, a CONNECTION SETUP RESPONSE message, or a CONTEXT INDICATION message comprises the UE context.

28. A method according to any preceding claim, wherein, in a case where the UE served by the source RAN node is to be set to an inactive state, sending the unsolicited UE context of the UE served by the source RAN node.

29. A method according to claim 28, wherein sending the unsolicited UE context of the UE served by the RAN node is performed prior to setting the inactive state.

30. A method according to claim 28, wherein sending the unsolicited UE context of the UE served by the RAN node is performed subsequent to setting the inactive state.

31. A method according to claims 30, wherein sending the unsolicited UE context of the UE served by the RAN node is performed after a predetermined time period has been met or elapsed.

32. A method according to claim 31, wherein one of the source RAN node, target RAN node, an AMF entity serving the source RAN node, and an 0AM procedure may set the predetermined time period.

33. A method according to claim 28, wherein the sending of the unsolicited UE context of the UE served by the RAN node is performed concurrently with setting the inactive state.

34. A method according to any one of claims 28 to 33, wherein the inactive state may be RRC INACTIVE state as defined in 3GPP TS 38.304 and TS 38.331.

35. A method according to any one of claims 28 to 34, further comprising notifying the target RAN node of the inactive state of UE served by the source RAN node.

36. A method according to any one of claims 28 to 35, further comprising releasing a connection to the UE served by the source RAN node in the case where the UE served by the source RAN node is to be set to the inactive state.

37. A method according to claim 36, wherein releasing the connection to the UE served by the source RAN node comprises sending, by the source RAN node to the served UE, a CONNECTION RELEASE message.

38. A method according to claim 36 or claim 37, wherein the connection is the RRC connection.

39. A method according to any one of claims 28 to 38, further comprising, in a case where the UE served by the source RAN node is to be set to an active state, after being set in the inactive state, notifying the target RAN node that the inactive served UE is to be set to an active state.

40. A method according to claim 39, wherein an active state is an RCC CONNECTED state.

41. A method according to claim 39 or claim 40, wherein the source RAN node is to set the active states according to a connection resume procedure as defined in 3GPP TS 38.331.

42. A method according to any one of claims 39 to 41, further comprising sending, by the source RAN node to the UE served by the source RAN node, a CONNECTION RESUME message.

43. A method according to any one of claims 39 to 42, wherein notifying the target RAN node comprises sending, from the source node to the target RAN node, information notifying a state change.

44. A method according to 43, wherein a CONTEXT INDICATION message comprises information notifying a state change.

45. A method according to any one of claims 39 to 44, wherein notifying the target RAN node that the served UE is to be set to an active state is performed either immediately after the UE served by the source RAN node is set to the active state or a predetermined time period after the UE served by the source RAN node is set to the active state.

46. A method according to claim 45, when dependent upon claim 42, wherein notifying the target RAN node that the served UE is to be set to an active state is performed a predetermined time period after the CONNECTION RESUME message has been sent.

47. A method according to any one of claims 39 to 46, further comprising, in a case where the UE served by the source RAN node is to be set to an active state, after being set in theinactive state, notifying the target RAN node that received unsolicited UE context associated with the served UE which is to set to be the active state can be discarded.

48. A method according to any preceding claim, wherein sending, to the target RAN node, the unsolicited UE context of the UE served by the source RAN node is via the Xn connection.

49. A method according to any preceding claim, wherein a message comprises the UE context.

50. A method according to claim 49, wherein the message comprising the UE context is any one of: a CONTEXT INDICATION message, a CONNECTION REMOVAL REQUEST message or a CONNECTION REMOVAL RESPONSE.

51. A method according to claim 50, wherein the CONTEXT INDICATION message is a NG-RAN NODE CONFIGURATION UPDATE message as defined in 3GPP TS 38.423.

52. A method according to any preceding claim, wherein the UE context comprises UE context information.

53. A method according to claim 52, wherein the UE context information comprises dynamic context information and semi-static context information.

54. A method according to claim 52 or claim 53, wherein sending an unsolicited UE context comprises sending a subset of UE context information from the whole context information associated with the UE served by the source RAN node.

55. A method according to claim 54, wherein the UE context information comprises at least a part of semi-static information of the context information.

56. A method according to any preceding claim, wherein a plurality of target RAN nodes are provided.

57. A method according to any preceding claim, wherein a plurality of UEs may be associated with the source RAN node.

58. A method according to any preceding claim, wherein sending the UE context of the UE served by the source RAN node is performed immediately upon the Xn connection being established between the source RAN node and the target RAN node.

59. A method according to any preceding claim, wherein sending the UE context of the UE served by the source RAN node is performed after a minimum predetermined time period after the Xn connection is established between the source RAN node and the target RAN node.

60. A method according to claim 59, wherein one of the source RAN node, target RAN node, an AMF entity serving the source RAN node, and an 0AM procedure may set the predetermined time period.

61. A method according to any preceding claim, further comprising sending unsolicited, to the target RAN node which previously received the UE context of the UE served by the source RAN node, updated UE context.

62. A method for use in managing connectivity in a wireless network including a plurality of Radio Access Network, RAN, nodes, an Xn connection being established between a source RAN node and a target RAN node of the plurality of RAN nodes, the method at the target RAN node comprising:receiving, from the source RAN node, an unsolicited User Equipment, UE, context of a UE served by the source RAN node.

63. A method according to claim 62, further comprising discarding the received unsolicited UE context after expiration of a predetermined time period.

64. A method according to claim 63, wherein the predetermined time period starts upon receiving the unsolicited UE context.

65. A method according to any one of claims 62 to 64, further comprising receiving, from the source RAN node, a notification indicating associated with the received unsolicited UE context.

66. A method according to claim 65, further comprising discarding the received unsolicited UE context based on received notification.

67. A method according to any one of claims 63 to 66, wherein the UE context comprises UE context information, and some or all of the context information is discarded.

68. A method according to claim 67, wherein the UE context information comprises dynamic context information and semi-static context information, and the dynamic context information is discarded.

69. A method according to any one of claims 62 to 68, wherein a message comprises the unsolicited UE context.

70. A method according to claim 69, wherein the message is one of: a CONTEXT INDICATION message, a CONNECTION SETUP REQUEST message, A CONNECTION SETUP RESPONSE message, a CONNECTION REMOVAL REQUEST, or a CONNECTION REMOVAL RESPONSE message.

71. An apparatus for a Radio Access Network, RAN, node, the apparatus comprising one or more processing units configured to perform a method according to any preceding claim.

72. A computer program comprising instructions which, when the program is executed by at least one processing unit, causes the at least one processing unit to carry out a method according to any one of claims 1 to 70.

73. A computer-readable medium carrying a computer program according to claim 72.

Images