Methods and apparatus for a wireless communication system

Abstract

A first network entity sends a first message to a second network entity as part of a signalling procedure of Xn application protocol or NG application protocol. The second network entity receives the

Description

FIELD OF THE INVENTION The present invention generally relates to methods and apparatus for a wireless communication system. In particular, the disclosure relates to methods for use in managing or improving reliability in wireless networks or wireless communication systems. For example, the disclosure relates to methods for use in managing acknowledgement of messages or communications sent as part of a signalling procedure of the Xn or NG application protocol in a wireless communication system involving a NG-RAN node, such as a Wireless Access Backhaul, WAB, node, so as to improve the reliability of communications to or from the NG-RAN node. BACKGROUND Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging ...) over a radio access network (RAN) through one or more base stations (gNBs). The base stations are conventionally wired-connected (e.g. through fiber) to a core network, forming an intermediate network, named backhaul (BH). Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourth-generation (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems-based IEEE 802.11 standards, such as WiFi. The demand for network densification increases due to the rising number of users and higher throughput requirement. Facing the issues of high deployment costs and time of the wired backhaul networks with network densification, 3GPP has proposed, from release 16 for 5G NR, a wireless backhaul, also known as Integrated Access and Backhaul, IAB, where part of the wireless (i.e. radio) spectrum is used for the backhaul connection of base stations instead of fiber. The wireless backhaul communications (between base stations) may use the same radio resources as access communications (between a base station and UEs). IAB turns out to be a competitive alternative to the fiber-based backhauling in dense areas or areas difficult to cover, as it allows scalable and rapid installations without the burden of cabling the base stations. IAB is most likely to operate in the millimeter wave (mmWave) band to achieve the required Gbps (gigabits per second) data rate. Urban environments are usually characterised by a high density of users along with the presence of a significant number of vehicles (e.g. public / private passengers transportation, goods delivery, food trucks ...). The speed of some of the vehicles may be pretty low or at least similar to pedestrian speed and some of these vehicles may even be temporarily stationary. Some of these vehicles (e.g. buses, trains or trams), may have predictable routes and / or limited mobility areas (e.g. some vehicles, such as food trucks or promotional vehicles, may be located outside stadiums or show venues) while others may have predictable stationary locations (e.g. taxis). 3GPP is considering that such vehicles could offer an opportunity to increase network coverage and connectivity to the UEs inside the vehicles, or even to UEs in proximity to the vehicles, by installing on these vehicles on-board base stations (or base station elements) that would act as relays. These relays would rely on 5G wireless backhaul (typically 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 further considered by 3GPP for Release 19, consider the need for 5G access for UEs onboard aircrafts, cruise ships, helicopters and vehicles in remote areas with limited sky visibility (e.g. where terrestrial cellular coverage or Wi-Fi coverage is not available), support for onboard / on-site mobile edge computing (MEC), local services, and direct local inter-UE communications, or local gNB deployment in public safety or disaster recovery scenarios. The backhauling links for the base stations providing the 5G access in such scenarios would then be operated over either a terrestrial network (TN), or a non-terrestrial network (NTN), with a possibility to handover communications from a terrestrial network to a non-terrestrial network and vice-versa. Such base stations can be referred to as Wireless Access Backhaul (WAB) nodes, or mobile WAB nodes, or WAB nodes. As part of these wireless backhauling enhancements, 3GPP is also considering some evolution to the former LTE-based Femto framework, including a new 5G Femto or 5G Femtocell that would offer 5G indoor coverage improvement while allowing high bandwidth and throughput at home for new immersive applications such as AR / VR / MR gaming, e-sports, UHD 8K video, telepresence, etc. It can be noted that a WAB node may deploy 5G Femto cells to serve UEs inside vehicles. WAB nodes serving UEs use backhaul links to exchange data (in the user plane and the control plane) and these backhaul links are wireless in the context of WAB networks. It means that the NG protocol messages exchanged between the base station of a WAB node and the core network, and the Xn protocol messages exchanged between the base station of a WAB node and other base stations of the Radio Access Network, are transmitted through a wireless link. Actually, NG and Xn protocols are designed for wired networks, meaning that these protocols assumed that the medium used for the transmission of messages is reliable. When applied to communication through wireless links, these protocols are not resilient to degradation of the wireless link quality. As a consequence, some NG and Xn procedures may fail in the context of WAB networks because of poor radio conditions and / or high load (congestion) on the wireless backhaul link. This situation may lead to system failure and interruption of service at the UEs served by a WAB node. More generally, when NG and Xn application protocols are applied to communication through links that can become degraded (e.g. including wired links, such as a wired link between a NG-RAN node and an access and mobility function, AMF, entity, of the core network, as well as wireless links), some NG and Xn signalling procedures may fail, because of degradation of the link quality, which may lead to system failure and interruption of service. There is therefore a need to improve the management of the transmissions of Xn and NG protocol messages over a links in a wireless communication system, and particularly for wireless backhaul link in networks including a WAB node. SUMMARY In accordance with an aspect of the present invention, there is provided a method for use in a wireless communication system including a network entity, the method at the network entity including: after receiving a first message as part of a signalling procedure of Xn application protocol or NG application protocol, sending a second message acknowledging the network entity has received the first message. In accordance with another aspect of the present invention, there is provided a method for use in a wireless communication system including a network entity, the method at the network entity including: sending a first message, to another network entity as part of a signalling procedure of Xn application protocol or NG application protocol; receiving, from the other network entity, a second message acknowledging the other network entity has received the first message. In accordance with another aspect of the present invention, there is provided an apparatus for a network entity for a wireless communication system as recited in claim 55 of the accompanying claims. The network entity may be an AMF entity or a NG-RAN node, such as a backhaul NG-RAN node, a WAB node or a gNB component of a WAB node (e.g. WAB-gNB). By sending a second message acknowledging receipt of the first message, the network entity (second or receiving network entity) can indicate to the sender of the first message (e.g. another network entity or first sending network entity associated with a Xn or NG connection or path between the first and second network entities) that the first message has been received (e.g. successfully received) and the signalling procedure of the Xn or NG protocol can be continued as required (e.g. as normal) to maintain service (e.g. at the UEs served by a WAB node). When the first network entity does not receive a second message from the second network entity indicating the first message has been received at the second network entity, the first network entity can detect or determine that the first message has not been received at the second network entity and that there is an issue (e.g. due to degradation of a link in the Xn or NG connection or path) and can take appropriate action to avoid system failure and interruption of service. Further example features of the invention are described in other independent and dependent claims. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus / device / unit aspects, and vice versa. Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other aspects of the invention, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any aspect or example described above and a computer readable storage medium carrying the computer program. BRIEF DESCRIPTION OF THE DRAWINGS Different aspects of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 is a schematic diagram of a communication system in which the present invention may be implemented according to one or more example embodiments; Figure 2 is a simplified schematic diagram of a 5G system in which the present invention may be implemented according to one or more example embodiments; Figure 3 is a simplified schematic diagram of a 5G system involving a Wireless Access Backhaul (WAB) node, and in which the present invention may be implemented according to one or more example embodiments. Figure 4 is a block schematic diagram of an example network node or base station in accordance with one or more embodiments of the invention; Figure 5 is a simplified schematic diagram showing an example of a wireless communication system, including a WAB network or WAB network system, in which embodiments and examples of embodiments of the present invention may be implemented; Figure 6a is a schematic diagram illustrating the protocol stack associated to the NG or Xn interface in the user plane (NG-U or Xn-U); Figure 6b is a schematic diagram illustrating the protocol stack associated to the NG or Xn interface in the control plane (NG-C or Xn-C); Figure 7a is a schematic diagram showing first example message flows for acknowledging NG protocol messages; Figure 7b is a schematic diagram showing first example message flows for acknowledging Xn protocol messages; Figure 8a is a schematic diagram showing second example message flows for acknowledging NG protocol messages; Figure 8b is a schematic diagram showing second example message flows for acknowledging Xn protocol messages; Figure 9a is a schematic diagram showing an example message flow for indicating the support of a NG acknowledged mode; Figure 9b is a schematic diagram showing an example message flow for indicating the support of a Xn acknowledged mode; Figure 10a is a schematic diagram showing a first example message flow for activating or deactivating a NG acknowledged mode by a NG-RAN node; Figure 10b is a schematic diagram showing a second example message flow for activating or deactivating a NG acknowledged mode by an AMF; Figure 10c is a schematic diagram showing an example message flow for activating or deactivating a Xn acknowledged mode by a NG-RAN node; Figure 11 is a flowchart of an example method for managing at an AMF or at a NG-RAN node a NG or Xn acknowledged mode. DETAILED DESCRIPTION Figure 1 illustrates an example communication system 100 in which the present invention may be implemented according to one or more embodiments. As depicted, the example system 100 is a wireless communication system, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system including a Wireless Access Backhaul (WAB) communication system or network. Although in the following description, embodiments and examples of embodiments of the present invention will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present invention is limited to 5G NR systems and may be used in any wireless communication systems having an integrated access and backhaul communication system which shares radio resources for wireless access links and wireless backhaul links. The system 100 comprises a plurality ofUEs (User Equipment) 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, a communication satellite 160, a satellite dish 101, a remote core network 170, three fixed Base Stations 102, 103 and 104, a plurality of Wireless Access Backhaul (WAB) nodes 110 (mounted on plane 161), 120a and 120b (mounted on train 162), 140 (mounted on Unmanned Aerial Vehicle (UAV) UAV 164) and 150 (mounted on backpack 165 or other carrier that can be carried by a user (e.g. in a disaster zone)), and a Wireless Access Backhaul node 130 (or Home gNB, mounted in house 163) which is fixed but based on the same architecture as a WAB node. In more general terms, the WAB node may be mounted on or in a vehicle (such as a train, bus, taxi, tram, etc.) and / or an aircraft or flying vehicle (such as a plane, UAV, helicopter, etc. ) and / or a building (such as a house, enterprise / company / office building, hotel building, airport building, sports / event buildings, shopping centre building, etc..) and / or a portable carrier that can be carried by a user (such as a backpack, bag, etc), for example, in a disaster zone or for public safety or for emergency services, and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). In an example where the WAB node is implemented in a Femto network, the WAB node functions as a 5G Femto node and may be mounted at a building (such as a house, enterprise / company / office building, hotel building, airport building, sports / event buildings, shopping centre building, etc..) and / or public infrastructure elements or units (such as lamp posts, traffic lights, etc.). When it is a mobile base station, a WAB node is also referred to as a Mobile WAB (MWAB) node. Some examples ofUEs include smartphones / tablets (such as UEs 111, 123, 134, 142, 152), XR headsets (such as UEs 112, 122, 132), cameras (such as UEs 141 and 151), fixed video cameras (such as UEs 113, 121, 133, 153) or mobile / wearable video cameras (such as UEs 143 and 154). In general, the UE may be any portable or handheld or mobile telephone, a smartphone, a tablet, a portable or fixed computer, fixed or mobile camera, portable television or other similar wireless communication device. In the following description, the term UE will be used and it is not intended to limit the description to any particular type of wireless communication device. Base stations 102, 103 and 104 are interconnected through a wired link infrastructure 180, preferably based on optical fiber or any other wired means. Base stations 102, 103 and 104 are also connected to the core network 170 through a wired link infrastructure 190, preferably based on optical fiber or any other wired means. In embodiments and examples of embodiments of the invention, base stations 102, 103 and 104 are 5G NR base stations (referred to as a gNB), as defined in 3GPP TS 38.300 vl8.0.0 specification document. Satellite dish 101 (e.g. satellite gateway) is also connected to wired link infrastructure 180 or 190, or to both infrastructures. Besides infrastructures 180 and 190 may be the same infrastructure. In one example, a part of a base station is embedded in the satellite 160 while the other part is embedded in the gateway 101, meaning that the base station is split between the satellite 160 and the gateway 101. In another example, a full base station is embedded in the satellite 160 and the gateway 101 connects the base station 160 with the infrastructure 180 or 190. In case of non-geostationary satellite, the satellite 160 may connect to different gateways, like the gateway 101, while the satellite 160 is moving around the earth. In order to extend the network coverage of base stations 102,103 and 104 and reach the remote UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, mobile WAB nodes or WAB nodes, or WAB-nodes, 110, 120a, 120b, 130, 140 and 150, have been installed on vehicles / mobile equipment 161, 162, 163, 164 and 165. By acting as relaying nodes between the base stations 102, 103 and 104 and the UEs 111, 112, 113, 121, 122, 123, 131, 132, 133, 134, 141, 142, 143, 151, 152, 153 and 154, WAB-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 WAB-node (e.g., UEs 151, 152, 153 and 154 connected to WAB node 150). The base stations 102, 103 and 104, the WAB 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 WAB network (also referred to as WAB 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, WAB network, WAB topology and WAB topology will be used interchangeably in the following. The WAB network is part of the Radio Access Network (RAN) or as referred to with respect to 5G, the Next Generation (NG) RAN. The base stations 102, 103 and 104, the WAB 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 WAB 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 WAB 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 WAB 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, D1041b, D1031, D1022, D1021), or split into two radio links in the case of satellite relaying (radio links DI60la and DI60lb). Although a single logical hop is shown in figure 1, it will be appreciated that the WAB nodes could be wirelessly backhauled to the base station over multiple logical hops (for example, similar to the multiple hops provided in an IAB network). Each WAB node consists of or includes a gNB or RAN node or base station component or entity which is referred to as a WAB-gNB, or WAB base station, and Mobile Termination (MT) component or entity which is referred to as an IAB-MT, or WAB-Mobile Termination. The WAB-gNB functionality on an WAB-node allows or enables the WAB-node to serve UEs. The WAB-MT functionality includes, e.g., physical layer, layer-2, RRC and Non-Access Stratum (NAS) functionalities and allows or enables the WAB-MT to connect to a fixed base station, or gNB, such as base station 102, 103 or 104 and to support backhauling of traffic related to the WAB-gNB of the WAB node. The WAB-gNB may also be referred to as a NG-RAN node (of a WAB node) and the WAB-MT may also be referred to as a UE (of a WAB node). WAB 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 WAB nodes may remain at a fixed location for a significant duration when their associated vehicle is remaining still (e.g., a train may stop at a railway station, a plane may be parked at an airport for a while, a car / truck / fire engine or any other emergency vehicle may be parked nearby a disaster area). WAB 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 invention may be implemented according to one or more example embodiments. This figure illustrates the possible standardized interfaces between the various elements composing the system. First, it represents a User Equipment (UE) 201 having a Uu interface with the New Generation (NG) Radio Access Network (RAN or NG-RAN) 202, and a N1 interface with an Access and Mobility management Function (AMF) entity or AMF 212 in a 5G core network (5GC) 210. Each base station composing the RAN 202 has a N2 interface with one or more Access and Mobility management Function (AMF) entity or AMF, like AMF 212, and a N3 interface with one or more User Plane Function (UPF) entity or UPF, like UPF 211. The N1 interface is used to convey Non-Access Stratum (NAS) protocol messages between a UE 201 and an AMF 212. NAS messages are used for the signaling between the UE and the core network for various procedures such as registration, session establishment, security, and mobility management. Actually, NAS messages are conveyed through the Uu interface between the UE 201 and the RAN 202, and the N2 interface between the RAN 202 and the AMF 212. An AMF 212 is responsible for handling registration, authentication, connection and mobility management tasks for a UE. For a WAB node, the AMF may apply the procedures defined in NAS protocol specifications (TS 24.502 section 5), considering the WAB node is a Mobile Base Station Relay (MBSR) introduced in Release 18. There may be several AMFs in a 5G core network, a standardized interface N14 enables the communications between AMFs. When a UE registers to the network through a serving base station, the serving base station will connect to an AMF suitable to handle the UE. When the UE 201 is registered, one or more Protocol Data Unit (PDU) session(s) can be set up to transfer data flows between the UE 201 and the Data Network (DN) 220 providing internet access. A PDU session is established between a UE 201 and a User Plane Function (UPF) 211 in the 5G core network 210. In the user plane, the UPF 211 connects to the Data Network (DN) 220 through the interface N6, and it is responsible for data packets routing with the required Quality of Service (QoS). There may be several UPFs on the data path with a N9 interface between UPFs. The user data between a UE 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 N11 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). Nl, N2, N3, N4, N6, N9, Nil, N14 may also be called reference points as defined in TS 23.501. 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 invention 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 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, 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 (e.g. a wireless 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 the functions of its 5G core network 330 (or backhaul 5GC or BH 5GC). 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 or backhaul AMF or BH AMF, and establishes PDU session(s) with the UPF 331, which can be called the WAB UPF or backhaul UPF or BH UPF. The WAB UPF 331 is controlled by the SMF 333 (through N4 interface), which can be called the WAB SMF or backhaul SMF of BH SMF, and which also interacts with the WAB AMF 332 (through N11 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 PLMN 1 the WAB-MT 311 connects to. In the case where PLMN 1 and PLMN2 are different, the UE 301 connects to the 5G core network 340 (or UE 5GC), 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 PLMN1 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. Figure 4 is a block schematic diagram of an example network node or RAN node or base station 400, such as base stations or gNBs or WAB nodes shown in Figure 1, in accordance with one or more embodiments of the invention. Each of a WAB node 110, 120a, 120b, 130, 140, or 150 of figure 1 may comprise the elements of the base station of figure 4. Also, the satellite 160 of figure 1 may comprise the elements of the base station of figure 4. In the following description, the network node 400 will be referred to generally as a base station. As will be apparent to a skilled person, Figure 4 is a simplified schematic diagram and shows only some of the functional components of an example base station 400 for use in describing the one or more embodiments of the invention. The base station 400 includes components for transmitting and receiving communications. As shown in Figure 4, the base station 400 includes a processing unit 402, a wireless interface 404, one or more antennas 410, a network interface 432, and memory 418. The network interface 432 manages communications of the base station 400 with the core network, other base stations, local network functions (like UPF), or local servers. It may provide a standardized interface, wired (e.g. fiber) or wireless, to support these communications. Through this network interface 432, the base station 400 may implement the standardized interfaces N2 (based on NGAP protocol) and N3 (based on GPRS tunneling protocol) with the core network, and the standardized interface Xn (based on XnAP protocol) with other base station of the Radio Access Network (RAN), all defined by the 3GPP standard. The network interface 432 may not be present or active in case the base station 400 is a WAB node that does not support local services, that is not used as a legacy base station like base station 102, 104 in Figure 1, and that is not used as a home base station providing Femto cells like base station 130 in Figure 1. The wireless interface 404 is configured to provide wireless communication via communication links (414) with other wireless devices, such as one or more UEs, e.g. link D1041b between base station 104 and the MT / UE unit of WAB node 120b, or link D1202 between the gNB unit of WAB node 120b and the UE 122. In case of WAB node, the wireless interface 404 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 WAB 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 to one or more antennas (such as the antenna 410). The wireless interface 404 typically includes a receiving unit 406 and a transmitting unit 408. The configuration of the wireless interface 404 may be limited to connect to one antenna, but preferably several antennas are used, in order to provide beamforming capability. Although not shown in Figure 4, the receiving unit 406 typically includes elements such as a receiver, demodulator, decoder, and the transmitting unit 408 typically includes elements such as a transmitter, modulator, coder. The receiving unit 406 and transmitting unit 408 may together be referred to as a transceiver. The processing unit 402 is configured to carrying out processing for operation of the base station 400. The processing unit 402 may be a single processor (e.g. Central Processing Unit) or may comprise two or more processors. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person. The base station 400 includes memory 418 for storing data and computer programs containing instructions for the operation of the base station 400. Memory 418 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Memory 418 includes a program memory in which are stored programs containing processor instructions for operation of the base station 400 and for implementing the methods in accordance with one or more embodiments of the invention. The programs may contain a number of different program elements or sub-routines (represented by element 420 in memory 418) containing processor instructions for a variety of different tasks, for example, an element for sending a message acknowledging receipt of a message sent as part of a Xn or NG protocol procedure, an element for sending a message as part of a Xn or NG protocol procedure, an element for receiving a message acknowledging receipt of a message sent as part of a Xn or NG protocol procedure, an element for determining the status of a communication link (radio conditions, congestion...), an element for determining the need to activate or deactivate an acknowledged mode to improve the reliability of protocol messages transmitted over the communication link, an element for determining the need to acknowledge a protocol message received over the communication link. Memory 418 may further include memory (e.g. RAM) for storing information such as, communication link status (e.g. information indicating link status of a wireless backhaul link), list of supported acknowledged mode(s), list of connected device(s), list of acknowledged mode(s) activated for each connected device. The operation of the program elements or sub-routines 420 will be described in more detail 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 invention. In other words, the apparatus is capable of performing one or more functions of the base station including performing the methods in accordance with one or more embodiments of the invention by means of the one or more processing units. For example, the one or more processing units uses software to implement the one or more embodiments of the invention as described above with reference to the processing unit 402 of Figure 4. Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, a CPU of a microcontroller Unit (MCU), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other equivalent integrated (e.g. on an Integrated Circuit) or discrete logic circuitry. However, alternatively, the one or more processing units for performing or implementing the methods may be implemented in hardware: for example, in the form of an Application Specific Integrated Circuit or ASIC or other hardware comprising logic element (s). Accordingly, the term “processing unit” as used herein may refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described herein. In a 5G core network, an AMF (Access and Mobility management Function) like the WAB AMF 332 or the UE AMF 342, may be implemented with the apparatus described in the Figure 4 where the Wireless Interface 404 and the antenna 410 is not present. Figure 5 illustrates an example of a wireless communication system 500, including a WAB network or WAB network system, in which embodiments and examples of embodiments of the present invention may be implemented. A WAB network will also be referred to as a WAB network system, WAB topology, WAB system, topology or system and so in this application, the terms WAB network system, WAB network, WAB topology, WAB system, topology or system will be used interchangeably. The WAB network system of Figure 5, is composed of three base stations 501, 502 and 503, also referred to as Backhaul base stations, or backhaul RAN nodes (also referred to as BH RAN nodes), or backhaul gNBs (also referred to as BH-gNB), two core networks 510 and 520, with the respective AMF entities 511a and 511b (for Core Network 510) and 521a and 521b (for Core Network 520) and the respective UPF entities 512a and 512b (for Core Network 510) and 522a and 522b (for Core Network 520), and two 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) component or part or unit (WAB-MT 531 for WAB node 530 and WAB-MT 541 for WAB node 540) and a RAN node or base station or gNB component or part or unit (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 figure 3, allowing WAB-node 530 to provide UEs 551, 552 and 561 with some local services, such as for instance inter-UE communication where the user data exchanged between the two UEs would be routed through UPF entity 533 / 543 instead of being routed through a UPF entity belonging to Core Network 510 or 520. WAB node 530 is connected to the serving backhaul base station referred to as BH-gNB 1, 501 through the wireless backhaul (BH) link 5011. WAB node 540 may be connected to the serving backhaul base station referred to as BH-gNB2, 502 through the wireless backhaul (BH) link 5021 or to the serving backhaul base station referred to as BH-gNB3, 503 through wireless backhaul (BH) link 5031 or, in case of dual connectivity, to both the serving backhaul base station BH-gNB2, 502 through BH link 5021 and the serving backhaul base station BH-gNB3, 503 through BH link 5031. 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 UE 561 connected to WAB node 540, it will be appreciated that there will be a plurality of UEs connected to WAB nodes of the wireless communication system. WAB-gNB 532 and WAB-MT 531 may be connected to a same AMF function or entity (e.g., AMF 511a) or to different AMF functions or entities belonging to the same Core Network (e.g., AMF 511a and AMF 51 lb) or to different Core Network (e.g., AMF 511a and AMF 521a). Some AMF functions may be implementing WAB-specific features for managing a WAB node (e.g., advanced mobility features). Some AMF functions may not implement such features but may still be capable of serving a WAB node with a limited set of basic features. Some AMF functions may not be capable of serving a WAB node. The processes and arrangements for use in managing communications in a wireless communication system, such as managing acknowledgement of messages or communications sent as part of Xn or NG protocol procedures in a wireless communication system will now be described according to one or more embodiments of the present invention. In the following description, as an example, reference is made to a wireless communication system including one or more WAB nodes, and where acknowledgement of messages or communications are sent as part of Xn or NG application protocol over a wireless link (e.g. wireless backhaul link). However, it is not intended that the invention is limited to acknowledging messages sent as part of a signalling procedure of the Xn or NG application protocol over wireless links and may also apply to acknowledging messages sent as part of a signalling procedure of the Xn or NG application protocol over wired links (e.g. between aNG-RAN node and the core network) so as to improve reliability in case the link is subject to degradation.Several scenarios are possible according to the mobility of WAB nodes 530 and 540. As a first scenario, and taking the example of WAB node 540, a dual-connectivity configuration may be applied to the WAB-MT 541, initially connected to BH-gNB2 502 only through the link 5021. Indeed, the WAB-MT 541 periodically performs a cell search procedure, as defined in 3GPP TS 38.300, trying to detect PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal). The WAB-node may report to BH-gNB2 502 the presence of a new cell, for instance one cell managed by the BH-gNB3 503, through a measurement report. Based on the analysis of the measurement report, the BH-gNB2 502 may request to the BH-gNB3 503 the establishment of a dual connectivity for the WAB-MT 541 with an additional connection through the link 5031. The BH-gNB3 503 may accept the request and proceed to the connection of the WAB-MT 541 according to the procedure described in TS 37.340 section 10.2.2. As a result, the WAB-MT 541, and thus the WAB node 540 is dual-connected. The BH-gNB2 502 may take benefit of the dual connectivity of WAB node 540 to balance the traffic load by offloading some traffic (data / user traffic or control traffic) initially planned to be transmitted through the link 5021. Some or all the traffic associated to the WAB node 540 (i.e. control data related to the WAB node, and control and user data related to the UEs served by the WAB node 540) may be transmitted through the link 5031 and through the IP connectivity between BH-gNB2 502 and BH-gNB3 503. Dual-connectivity configuration is however transparent for the WAB-gNB 542 and for the UEs served by the WAB-gNB 542. As a second scenario, the radio link 5021 may experience radio link deficiency due to some unexpected interference or shadowing phenomena. For such reasons, the WAB-MT 541 may lose the connection with the BH-gNB2 502 and declare a Radio Link Failure (RLF). Then, the WAB-MT 541 will try to reestablish the connection in the same or a different cell controlled by BH gNB2 502 or by another gNB. Thus, the WAB-MT 541 may try to connect to a cell controlled by BH-gNB3 503 by requesting the establishment of the link 5031. In this case, the reestablishment procedure described in TS 38.300 section 9.2.3.3 may be applied, which enables a UE to maintain the RRC connection. With such procedure, the BH gNB3 503 sends to the BH gNB2 502 a request to retrieve the context of the WAB-MT 541. Based on the response from the BH gNB2 502, the BH gNB3 503 may accept the connection of the WAB-MT 541. Then, all the traffic related to the WAB node 540 (and the served UEs) will now transit through the BH gNB 503. The reestablishment procedure does not involve the WAB-gNB 542 and its served UEs. If the reestablishment is rapidly performed after RLF, the service interruption at the UE 561 may be avoided or limited. As a third scenario, the WAB-MT 541 may be handed over from the current serving cell to a new cell. Indeed, based on the measurement reports provided by the WAB-MT 541, the BH-gNB2 502 may detect that the WAB-MT 541 would have a better connection through a cell managed by the BH gNB3 503. Then, the BH-gNB2 502 may trigger a handover procedure described in TS 38.300 section 9.2.3.2. In this procedure, the BH-gNB2 502 sends a handover request to the BH gNB3 503 along with information related to the WAB-MT 541. Based on this information, the BH gNB3 503 may accept the handover request and proceed to the admission of the WAB-MT 541. Then, all the traffic related to the WAB node 540 (and the served UEs) will now transit through the BH gNB 503. The handover procedure does not involve the WAB-gNB 542 and its served UEs, and it may be transparent for the WAB-gNB and the served UEs (no interruption of service). The three situations described above may happen because the backhaul link 5021 between the WAB-MT 541 and the BH gNB2 502 is wireless and subject to degradation, not only because the WAB-node 540 may be mobile, but also because the radio conditions may be changing leading to poor link budget. Moreover, in case of high throughput demand from applications running in UEs served by a WAB node (e.g. UEs 551 and 552 served by the WAB-gNB 532), the wireless backhaul link between the WAB node and the serving backhaul RAN node (e.g. link 5011 between WAB-MT 531 and BH-gNB 501) may be congested even if the radio quality is very good. When the quality of a wireless link is degraded, there may be no solution of handover at that time. Taking the example of the WAB node 530, if the quality of the wireless backhaul link 5011 decreases (because of congestion or bad radio conditions), it may not be possible to handover the WAB-MT 531 to another cell, as the WAB-MT 531 may not be located in a place covered by another cell. In case of quality degradation of a communications link (whether wired or wireless), some messages transmitted through this link may be delayed or lost. This situation may alter the user applications, but also the procedures to manage the system in the control plane. In particular for a WAB system, a NG or Xn procedure may fail due to the quality degradation of the wireless backhaul link supporting the transmission of NG and Xn protocol messages. For instance, as described in TS 38.413 section 8.7.7, the NG procedure overload start is a procedure composed of a single message OVERLOAD START sent by an AMF to an NG-RAN node. If this message is not received at the NG-RAN node, the NG-RAN node will not understand it may reduce the signalling towards the concerned AMF, and the AMF will not be aware of this situation (e.g. that that the message has not been received at the NG-RAN node and so the NG-RAN node has not been informed that it is to reduce the signalling load towards the AMF). Still for NG protocol, as defined in TS 38.413 section 8.4.1, the Handover Preparation procedure is composed of two messages: the HANDOVER REQUIRED message from a NG-RAN node to an AMF, and a response message HANDOVER COMMAND from the AMF to the NG-RAN node. If this second message HANDOVER COMMAND is not received at the NG-RAN node or is received too late because of a delay, the NG-RAN node will not continue the handover procedure of a UE while the AMF is still considering the handover procedure is being executed normally. Also, as defined in TS 38.423 section 8.2.5, the Xn procedure RAN Paging is composed of a single message RAN PAGING sent by a first NG-RAN node to a second NG-RAN node, for instance to trigger the resumption of RRC connection of a UE to send data to this UE via the second NG-RAN node. If the RAN PAGING message is not received at the second NG-RAN node, the second NG-RAN node will not be able to page the UE. If this UE is actually camping in a cell of the second NG-RAN node, the connection of the UE cannot be resumed and the UE will not receive its data. Thus, enhancements of NG and Xn procedures are introduced to avoid such failure situations, as described with the help of figures 7a, 7b, 8a, 8b, 9a, 9b, 10a, 10b, 10c, 11 which relate to one or more embodiments of the present invention. Figure 6a is a schematic diagram 600 illustrating the protocol stack associated to the NG or Xn interface in the user plane, referred to as NG-U or Xn-U. The NG-U interface and the associated Transport Network Layer (TNL) protocol stack are described in the following 3GPP specifications: TS 38.410, TS 38.411, TS 38.414. The Xn-U interface and the associated TNL protocol stack are described in the following 3GPP specifications: TS 38.420, TS 38.421, TS 38.424 The NG user plane interface (NG-U) is defined between a NG-RAN node and a UPF. The Xn user plane interface (Xn-U) is defined between two NG-RAN nodes. Both interfaces are built on IP (Internet Protocol) transport. GTP-U (GPRS (General Packet Radio Service) Tunnelling Protocol for User Plane) 601 is used on top of UDP (User Datagram Protocol) 602 and IP 603 to carry the user plane PDUs between the NG-RAN node and the UPF (for NG-U), or user plane PDUs between two NG-RAN nodes (for Xn-U). GTP-U 601 is defined in TS 29.281, while UDP 602 is defined in IETF RFC 768, and IP 603 is defined in IETF RFC 8200 (for IPv6) and IETF RFC 791 (for IPv4). Any data link layer 604 and physical layer 605 that fulfil the requirements toward the upper layers 601, 602, 603 may be used. For instance, they can be implemented with Ethernet protocol over fiber cables. Figure 6b is a schematic diagram 610 illustrating the protocol stack associated to the NG or Xn interface in the control plane, referred to as NG-C or Xn-C. The NG-C interface and the associated Transport Network Layer (TNL) protocol stack are described in the following 3GPP specifications: TS 38.410, TS 38.411, TS 38.412, TS 38.413. The Xn-C interface and the associated TNL protocol stack are described in the following 3GPP specifications: TS 38.420, TS 38.421, TS 38.422, TS 38.423. The NG control plane interface (NG-C) is defined between a NG-RAN node and an AMF. The NG control plane interface may also be called or provides the N2 interface discussed above. The Xn control plane interface (Xn-C) is defined between two NG-RAN nodes. Both interfaces are built on IP (Internet Protocol) transport. NGAP (Next Generation Application Protocol) 611 is used on top of SCTP (Stream Control Transmission Protocol) 612 and IP 613 to carry the control plane data between the NG-RAN node and the AMF (for NG-C), or between two NG-RAN nodes (for Xn-C). NGAP 611 is defined in TS 38.413, XnAP 611 is defined in TS 38.423, while SCTP 612 is defined in IETF RFC 4960, IP 603 is defined in IETF RFC 8200 (for IPv6) and IETF RFC 791 (for IPv4). Any data link layer 614 and physical layer 615 that fulfil the requirements toward the upper layers 611, 612, 613 may be used. For instance, they can be implemented with Ethernet protocol over fiber cables. Details of example NGAP procedures are set out in section 8 of TS 38.413, V.18.3.0. NGAP procedures may also be referred to as NG protocol procedures or signalling procedures of NG application protocol. Several NGAP elementary procedures to manage a NG-C interface are specified in TS 38.413. Details of example XnAP procedures are set out in section 8 of TS 38.423, V.18.3.0. XnAP procedures may also be referred to as Xn protocol procedures or signalling procedures of Xn application protocol. First a NG setup procedure (described in TS 38.413 section 8.7.1) enables the establishment of a NG interface between a NG-RAN node (like WAB-gNB 542) and an AMF (like AMF 521a). This procedure may be the first NGAP procedure triggered after the TNL association (TNLA) has become operational. For this purpose, the NG-RAN node and the AMF need to determine their IP addresses, through for instance, DNS (Domain Name System) resolution. This first TNL association may be reserved for the NGAP elementary procedures that utilize non-UE associated signalling (i.e for generic procedures not associated to a UE). The AMF Configuration Update procedure (described in TS 38.413 section 8.7.3) enables an AMF to provide updated configuration data to the NG-RAN node. In particular, the AMF may use it to establish additional TNL association(s), TNLA(s), between the NG-RAN node and the AMF, or to release additional TNLA(s). Indeed, configurations with multiple SCTP endpoints per NG-RAN node / AMF pair may be supported. When configurations with multiple SCTP associations are supported, the AMF may request to dynamically add / remove SCTP associations between the NG-RAN node / AMF pair. Within the set of SCTP associations established between one AMF and NG-RAN node pair, the AMF may request the NG-RAN node to restrict the usage of SCTP association for certain types of NG-C signalling. The RAN Configuration Update procedure (described in TS 38.413 section 8.7.2) enables a NG-RAN node to provide updated configuration data to the AMF. In particular, the AMF may use it to request the release of additional TNLA(s) between the NG-RAN node and the AMF. Error Indication, AMF Status Indication, Overload Start, Overload Stop are procedures descripted in TS 38.413 respectively in sections 8.7.5, 8.7.6, 8.7.7 and 8.7.9. They allow an AMF to report information related to the current conditions of the NG interface between a NG-RAN node and the AMF. NG Reset procedure (described in TS 38.413 section 8.7.4) can be initiated either by a NG-RAN node or by an AMF to initialise or re-initialise a NG-C interface between a NG-RAN node and an AMF. In addition, to the above non-UE associated procedures, the UE TNLA Binding Release procedure (described in TS 38.413 section 8.13.1) enables an AMF to request anNG-RAN to release existing NGAP UE TNLA binding(s). A UE TNLA binding is the association of a UE served by the NG-RAN node and connected to the AMF, with an existing TNL association between the AMF and the NG-RAN node. It means that every NAS message exchanged between the UE and the AMF will be conveyed through a NGAP message between the NG-RAN node and the AMF using the selected TNLA. This NGAP UE TNLA binding is performed at the registration of the UE to the AMF as described in TS 23.502 section 4.2.7.2. Referring now to figure 7a which is a schematic diagram showing first example message flows 700 for acknowledging NG protocol messages (e.g. which NG protocol message are sent as part of the NG application protocol or NG protocol procedure which may also be referred to as a NGAP procedure or NG protocol signalling procedure) in accordance with one or more embodiments of the present invention. This figure shows a NG-RAN node 701 like WAB-gNB 532 of figure 5, and an AMF 702 like the AMF 51 la of figure 5 in a 5G core network (5GC) like the core network 510 of figure 5. The NG-RAN node 701 may also be embedded in a satellite, like the satellite 160 of figure 1. It is assumed that a NG connection has been previously established between the NG-RAN node 701 and the AMF 702. As discussed above, the example message flows 700 may also apply for the wired link between BH-gNBl 501 of figure 5 and the AMF 511a. This figure illustrates an example method to improve the reliability of a NG protocol (e.g. a NG application protocol) with the acknowledgment of the reception of NG protocol messages in accordance with one or more embodiments of the present invention. When the NG-RAN node 701 sends a NG protocol message Ml 703 to the AMF 702, the AMF 702 notifies the successful reception of the message Ml 703 (e.g. when the message has been received and decoded and data included in the message has been passed for further processing the message is deemed to have been successfully received) by sending the Ml ACKNOWLEDGE message 705 to the NG-RAN node 701. In such a case, the message Ml 703 has been successfully sent. After the transmission of message Ml 703, the NG-RAN node 701 may start a timer. In case the Ml ACKNOWLEDGE message 705 is not received at the expiry of the timer, the NG-RAN node 701 understands that the message Ml 703 has not been received (or has not been received correctly or successfully, such as in the case where errors arise in the decoding of the received message) at the AMF 702, or / and that the Ml ACKNOWLEDGE message 705 is lost. In such a case, the NG-RAN node 701 can resend the message Ml 703 to the AMF 702. In case the message Ml 703 has not been successfully sent to the AMF 702 after a predefined maximum number of retries (e.g. in the case where the NG-RAN node 701 does not receive a Ml ACKNOWLEDGE message 705 from the AMF 702 after a predefined maximum number of attempts re-sending the message Ml 703), the NG-RAN node 701 may consider that the AMF 702 is no more reachable and it may consider the NG connection with the AMF 702 as released or removed. Similarly, when the AMF 702 sends a NG protocol message M2 704 to the NG-RAN node 701, the NG-RAN node 701 notifies the successful reception of the message M2 704 by sending the M2 ACKNOWLEDGE message 706 to the AMF 702. For instance, the message Ml 703 may correspond to the message ERROR INDICATION of procedure Error Indication, which is a class 2 procedure (i.e. without response) defined in TS 38.413 section 8.7.5. In the case of the Error Indication procedure, the message Ml ACKNOWLEDGE 705 is a new NG protocol message, which may be called ERROR INDICATION ACKNOWLEDGE or by another name, and added to secure this Error Indication procedure. It is noted that, in general, a class 2 procedure is a procedure without response, such as a procedure or signalling procedure that involves a message being sent without requiring a response (e.g. a response indicating success and / or failure is not required). By contrast, a class 1 procedure is a procedure with response, such as a procedure or signalling procedure that involves a message being sent and requiring a response (e.g. a response indicating success and / or failure is required). In another example, the message M2 704 may correspond to the message OVERLOAD START of the class 2 procedure Overload Start defined in TS 38.413 section 8.7.7. Then, the message M2 ACKNOWLEDGE 706 is a new NG protocol message, which may be called OVERLOAD START ACKNOWLEDGE or by another name, and added to secure this procedure. In another example, the messages Ml 703 and M2 704 may respectively correspond to the messages HANDOVER REQUIRED and HANDOVER COMMAND of the procedure Handover Preparation, which is a class 1 procedure (i.e. with response) defined in TS 38.413 section 8.4.1. Then, the messages 705 and 706 are new NG protocol messages, which may be called HANDOVER REQUIRED ACKNOWLEDGE and HANDOVER COMMAND ACKNOWLEDGE or by other names, and added to secure this procedure. It can be noted, that for a class 1 procedure composed of Ml 703 and M2 704 messages, the Ml ACKNOWLEDGE message 705 may not be necessary as the transmission of message M2 704 implicitly acknowledges the reception of message Ml 703. In summary, a second message (such as Ml ACKNOWLEDGE message 705 or M2 ACKNOWLEDGE message 706) for acknowledging receipt of a first message (such as the Ml message 703 or the M2 message 704) is sent as part of a signalling procedure of NG application protocol to secure or improve the reliability of the NG application protocol to which the messages relate. This is particularly helpful in the case where the NG-RAN node 701 is a WAB node connected to the AMF 702 through or via a wireless link (e.g. a BH link between the WAB node and a BH RAN node) which can be subject to congestion and / or degradation of radio conditions. In the case of the Error Indication procedure, which is an example of an NG protocol procedure, the second message or acknowledge message 705, which may be named ERROR INDICATION ACKNOWLEDGE or by another name, is sent by the AMF for acknowledging receipt of the first message or ERROR INDICATION message 703 to secure or improve the reliability of the Error Indication procedure. In the case of the Overload Start procedure, which is an example of an NG protocol procedure, the second message or acknowledge message 706, which may be named OVERLOAD START ACKNOWLEDGE or by another name, is sent by the NG-RAN node for acknowledging receipt of the first message or OVERLOAD START message 704 to secure or improve the reliability of the Overload Start procedure. In the case of the Handover Preparation procedure, which is an example of an NG protocol procedure, the second or acknowledge message 705, which may be named HANDOVER REQUIRED ACKNOWLEDGE or by another name, may be sent by the AMF for acknowledging receipt of the first message or HANDOVER REQUIRED message 703 and / or the second message or acknowledge message 706, which may be named HANDOVER COMMAND ACKNOWLEDGE or by another name, may be sent by the NG-RAN node for acknowledging receipt of the first message or HANDOVER COMMAND message 704 to secure or improve the reliability of the Handover Preparation procedure. The content of Ml ACKNOWLEDGE message 705 and M2 ACKNOWLEDGE message 706 may be composed of one or more of the following information elements: A Message Type as defined in TS 38.413 section 9.3.1.1, with the Procedure Code value set to the Procedure Code received in the message to acknowledge (e.g. the first message Ml or M2), and the Type of Message value set to a new value, for instance “Acknowledgment”; An identifier of the sender of the message, for instance a Global RAN Node ID, as defined in TS 38.413 section 9.3.1.5 when the sender is the NG-RAN node 701, or a GUAMI as defined in TS 38.413 section 9.3.3.3 when the sender is the AMF 702; For example, a second message sent to acknowledge receipt of a first message may include at least one of: information associated with the first message; identification information for identifying the sender of the second message (e.g. the ID of the AMF 702 in the case of message 705 or the ID of the NG-RAN node 701 in the case of message 706 as discussed above). The information associated with the first message may include identification information of the respective message (e.g. with the Procedure Code value or the Message Type as defined in TS 38.413 section 9.3.1.1 -see above description). The information associated with the first message may include at least one of: information, such as a Procedure Code value as discussed above, associated with the protocol procedure in or for which the first message is sent (and which Procedure Code may be included in the first message); message type information, such as the Type of Message value as discussed above, set to a value indicating the type of the second message, such as the second message is an acknowledgement type of message. According to an example, NG protocol messages are required to be acknowledged by configuration, meaning that AMFs and NG-RAN nodes are configured to acknowledge NG protocol messages. This may concern all NG protocol messages defined in TS 38.413 or a subset of these NG protocol messages. According to another example, the acknowledgment of a NG protocol message is explicitly requested by the sender of the message. In other words, a first message 703 or 704 sent by the sender (e.g. NG-RAN node 701 or AMF 702) may include information (e.g. an IE such as the “ack requested” IE discussed below) indicating the receiving node (e.g. AMF 702 or NG-RAN node 701) is requested or required to send an acknowledgement of the first message such as after receiving the first message (e.g. after receiving successfully the first message), and after the receiving node determines the information requesting the sending of an acknowledgement is included in the first message, the receiving node sends a second message 705, 706 as an acknowledgement message acknowledging receipt of the first message. For instance, if the NG-RAN node 701 requests an acknowledgment of message Ml 703, then a dedicated information element, for instance called “ack requested” is included in the message Ml 703. Upon reception of the message Ml 703, the AMF 702 checks the presence of the “ack requested” information element, and if present, sends the Ml ACKNOWLEDGE message 705 to the NG-RAN node 701. Similarly, if the AMF 702 explicitly requests an acknowledgment of message M2 704, then the information element “ack requested” is included in the message M2 704. Upon reception of the message M2 704, the NG-RAN node 701 checks the presence of the “ack requested” information element, and if present, sends the M2 ACKNOWLEDGE message 706 to the AMF 702. The request for acknowledgment of a message may be based on a trigger or trigger event (or when a certain condition is met). In one case, the trigger may be the detection (directly or through a received notification) of an issue on the wireless backhaul link on which the NG protocol message is to be transmitted. For example, the trigger may be when an issue associated with a wireless link through which the NG-RAN node 701 is connected to the AMF 702 is detected (e.g. in the case where the NG-RAN node 701 is a WAB-gNB of a WAB node and the wireless link is a wireless backhaul link in a path to the AMF 702). The issue may be detected or determined (e.g. by the WAB-gNB 701 or AMF 702), when the quality of the link reaches a certain threshold due to congestion on the link or poor radio conditions or lack of radio resources which may lead to some NG protocol procedures failing. The WAB-gNB 701 of the WAB node may determine there is an issue with a wireless backhaul link via the WAB-MT of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT). The AMF 702 may determine there is an issue with the wireless backhaul link from information provided by the WAB-gNB 701 of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT) and / or by a NG-RAN node connected to the wireless backhaul link (e.g. a backhaul RAN node connected to the WAB-MT of the WAB node by the wireless backhaul link) in the path between the WAB-gNB 701 and the AMF 702 (e.g. from measurements performed at the backhaul RAN node). The request for acknowledgment of a message may also be based on the critical characteristics (such as the priority level) of the message. In other words, in another example the trigger may be when the priority level of the message to be sent reaches a certain threshold indicating the message is critical (e.g. the priority level is high). For instance, if the paging of a UE concerns the transmission of an emergency message (the criticality or priority level will be high), a request for acknowledgment may be transmitted along with the RAN PAGING REQUEST message (RAN Paging Request procedure is defined in TS 38.413 section 8.3.14). For example, information requesting the sending of an acknowledgement may be included in RAN PAGING REQUEST (i.e. the first message) sent by the AMF 702 to the NG-RAN node 701 and on determining such information is included in the first message, the NG-RAN node 701 may send a response acknowledging receipt of the RAN PAGING REQUEST message. Figure 7b is a schematic diagram showing first example message flows 710 for acknowledging Xn protocol messages (e.g. which are sent as part of a signalling procedure of the Xn application protocol which may also be referred to as a XnAP procedure or Xn protocol signalling procedure) in accordance with one or more embodiments of the present invention. This figure shows two NG-RAN nodes 711 and 712 like WAB-gNB 532 and BH-gNBl 501 of figure 5. The NG-RAN nodes 711 and 712 may also be embedded in a satellite, like the satellite 160 of figure 1. It is assumed that a Xn connection has been previously established between the NG-RAN nodes 711 and 712. As discussed above, the example message flows 710 may also apply for the wired link between BH-gNBl 501 andBH-gNB2 502 of figure 5. This figure illustrates an example method to improve the reliability of Xn protocol (e.g. a Xn application protocol) with the acknowledgment of the reception of Xn protocol messages in accordance with one or more embodiments of the present invention. When the NG-RAN node 711 sends a Xn protocol message Ml 713 to the NG-RAN node 712, the NG-RAN node 712 notifies the successful reception of the message Ml 713 (e.g. when the message has been received and decoded and data included in the message has been passed for further processing the message is deemed to have been successfully received) by sending the Ml ACKNOWLEDGE message 715 to the NG-RAN node 711. In such a case, the message Ml 713 has been successfully sent. After the transmission of message Ml 713, the NG-RAN node 711 may start a timer. In case the Ml ACKNOWLEDGE message 715 is not received at the expiry of the timer, the NG-RAN node 711 understands that the message Ml 713 has not been received (or has not been received correctly or successfully) at the NG-RAN node 712, or / and that the Ml ACKNOWLEDGE message 715 is lost. In such a case, the NG-RAN node 711 can resend the message Ml 713 to the NG-RAN node 712. In case the message Ml 713 has not been successfully transmitted to the NG-RAN node 712 after a predefined maximum number of retries (e.g. in the case where the NG-RAN node 711 does not receive a Ml ACKNOWLEDGE message 715 from the NG-RAN node 712 after a predefined maximum number of attempts re-sending the message Ml 713), the NG-RAN node 711 may consider that the NG-RAN 712 node is no more reachable, and it may consider the Xn connection with the NG-RAN node 712 as released or removed. Similarly, when the NG-RAN node 712 sends a Xn protocol message M2 714 to the NG-RAN node 711, the NG-RAN node 711 notifies the successful reception of the message M2 714 by sending the M2 ACKNOWLEDGE message 716 to the NG-RAN node 712. For instance, the message Ml 713 may correspond to the message RAN PAGING of the procedure RAN Paging, which is a class 2 procedure (i.e. without response) defined in TS 38.423 section 8.2.5. Then, the message Ml ACKNOWLEDGE 715 is a new Xn protocol message, which may be called RAN PAGING ACKNOWLEDGE or by another name, and added to secure this procedure. In another example, the messages Ml 713 and M2 714 may respectively correspond to the messages RETRIEVE UE CONTEXT REQUEST and RETRIEVE UE CONTEXT RESPONSE of the procedure Retrieve UE Context, which is a class 1 procedure (i.e. with response) defined in TS 38.423 section 8.2.4. Then, the messages 715 and 716 are new Xn protocol messages, which may be called RETRIEVE UE CONTEXT REQUEST ACKNOWLEDGE and RETRIEVE UE CONTEXT RESPONSE ACKNOWLEDGE or by other names, and added to secure this procedure. It can be noted, that for a class 1 procedure composed of Ml 713 and M2 714 messages, the Ml ACKNOWLEDGE message 715 may not be necessary as the transmission of M2 message 714 implicitly acknowledges the reception of message Ml 713. In summary, a second message (such as Ml ACKNOWLEDGE message 715 or M2 ACKNOWLEDGE message 716) for acknowledging receipt of a first message (such as the Ml message 713 or the M2 message 714) is sent as part of a signalling procedure of the Xn application protocol to secure or improve the reliability of the Xn application protocol to which the messages relate. This is particularly helpful in the case where the NG-RAN node 711 is a WAB node connected to NG-RAN node 712 (such as a BH RAN node) through or via a wireless link (e.g. a BH link between the WAB node and a BH RAN node) which can be subject to congestion and / or degradation of radio conditions. The content of Ml ACKNOWLEDGE message 715 and M2 ACKNOWLEDGE message 716 may be composed of one or more of the following information elements: A Message Type as defined in TS 38.423 section 9.2.3.1, with the Procedure Code value set to the Procedure Code received in the message to acknowledge, and the Type of Message value set to a new value, for instance “Acknowledgment”; An identifier of the sender of the message, for instance a Global NG-RAN Node ID, as defined in TS 38.423 section 9.2.2.3. For example, a second message sent to acknowledge receipt of a first message may include at least one of: information associated with the first message; identification information for identifying the sender of the second message (e.g. the ID of the NG-RAN node 712 in the case of message 715 or the ID of the NG-RAN node 711 in the case of message 716 as discussed above). The information associated with the first message may include identification information of the respective message (e.g. with the Procedure Code value or the Message Type as defined in TS 38.413 section 9.3.1.1 -see above description). The information associated with the first message may include at least one of: information, such as a Procedure Code value as discussed above, associated with the protocol procedure in or for which the first message is sent (and which Procedure Code may be included in the first message); message type information, such as the Type of Message value as discussed above, set to a value indicating the type of the second message, such as the second message is an acknowledgement type of message. According to a first example, Xn protocol messages are required to be acknowledged by configuration, meaning that NG-RAN nodes are configured to acknowledge Xn protocol messages. This may concern all Xn protocol messages defined in TS 38.423 or a subset of these Xn protocol messages. According to a second example, the acknowledgment of a Xn protocol message is explicitly requested by the sender of the message. In other words, a first message 713 or 714 sent by the sender (e.g. NG-RAN node 711 or NG-RAN node 712) may include information (e.g. an IE such as the “ack requested” IE discussed below) indicating the receiving node (e.g. NG-RAN node 712 or NG-RAN node 711) is requested or required to send an acknowledgement of the first message such as after receiving the first message (e.g. after receiving successfully the first message), and after the receiving node determines the information requesting the sending of an acknowledgement is included in the first message, the receiving node sends a second message (715 or 716) as an acknowledgement message acknowledging receipt of the first message. For instance, if the NG-RAN node 711 requests an acknowledgment of message Ml 713, then a dedicated information element, for instance called “ack requested” is included in the message Ml 713. Upon reception of the message Ml 713, the NG-RAN node 712 checks the presence of the “ack requested” information element, and if present, sends the Ml ACKNOWLEDGE message 715 to the NG-RAN node 711. The same applies for when the NG-RAN node 712 requests an acknowledgement of message M2 714 (e.g. by including “ack requested” IE in message M2 714). The request for acknowledgment of a message may be based on a trigger or trigger event (or when a certain condition is met) as discussed above. In one case, the trigger may be the detection (directly or through a received notification) of an issue on the wireless backhaul link on which the Xn protocol message is to be transmitted. The issue may be detected or determined, by the NG-RAN node 711 or NG-RAN node 712, when the quality of the wireless link reaches a certain threshold due to congestion on the wireless link or poor radio conditions or lack of radio resources which may lead to some Xn protocol procedures failing in a similar manner as to that described above for figure 7a. The request for acknowledgment of a message may also be based on the critical characteristics (such as the priority level) of the message. In other words, in another example the trigger may be when the priority level of the message to be sent reaches a certain threshold indicating the message is critical (e.g. the priority level is high). For instance, if the paging of a UE concerns the transmission of an emergency message (the criticality or priority level will be high), a request for acknowledgment may be transmitted along with the RAN PAGING message. Figure 8a is a schematic diagram showing second example message flows 800 for acknowledging NG protocol messages (e.g. which are sent as part of a signalling procedure of the NG application protocol which may also be referred to as a NGAP procedure or NG protocol signalling procedure) in accordance with one or more embodiments of the present invention. This figure shows a NG-RAN node 801 like WAB-gNB 532 of figure 5, and an AMF 802 like the AMF 51 la of figure 5 in a 5G core network (5GC) like the core network 510 of figure 5. The NG-RAN node 801 may also be embedded in a satellite, like the satellite 160 of figure 1. It is assumed that a NG connection has been previously established between the NG-RAN node 801 and the AMF 802. As discussed above, the example message flows 800 may also apply for the wired link between BH-gNBl 501 of figure 5 and the AMF 511a. This figure illustrates another example method to improve the reliability of NG protocol (e.g. a NG application protocol) with the acknowledgment of the reception of NG protocol messages in accordance with one or more embodiments of the present invention. When the NG-RAN node 801 sends a NG protocol message Ml 803 to the AMF 802, the AMF 802 notifies the successful reception of the message Ml 803 by sending the ACKNOWLEDGMENT message 805 to the NG-RAN node 801. The ACKNOWLEDGMENT message 805 contains or includes information associated with the message Ml (e.g. a first message), such as an identifier of or identification information associated with the message Ml (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1). For example, the ACKNOWLEDGMENT message 805 may include the Procedure Code Value (as discussed above) and / or the type of message Ml 803 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1), which information may be included in the message Ml 803. Thanks to this identifier of message Ml, the NG-RAN node 801 understands that this is an acknowledgment of the message Ml 803. After the transmission of message Ml 803, the NG-RAN node 801 may start a timer. In case the ACKNOWLEDGMENT message 805 is not received at the expiry of the timer, the NG-RAN node 801 understands that the message Ml 803 has not been received (or has not been received correctly or successfully) at the AMF 802, or / and that the ACKNOWLEDGMENT message 805 is lost. Then, the NG-RAN node 801 can resend the message Ml 803 to the AMF 802. In case the message Ml 803 has not been successfully transmitted to the AMF 802 after a predefined maximum number of retries (e.g. in the case where the NG-RAN node 801 does not receive a Ml ACKNOWLEDGE message 805 from the AMF 802 after a predefined maximum number of attempts re-sending the message Ml 803), the NG-RAN node 801 may consider that the AMF 802 is no more reachable, and it may consider the NG connection with the AMF 802 as released or removed. Similarly, when the AMF 802 sends a NG protocol message M2 804 to the NG-RAN node 801, the NG-RAN node 801 notifies the successful reception of the message M2 804 by sending the ACKNOWLEDGMENT message 806 to the AMF 802. The ACKNOWLEDGMENT message 806 contains or includes information associated with the message M2 (e.g. a first message), such as an identifier of or identification information associated with the message M2 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1). For example, the ACKNOWLEDGMENT message 806 may include the Procedure Code Value (as discussed above) and / or the type of message M2 804 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1), which may be included in the message M2 804. Thanks to this identifier of message M2, the AMF 802 understands that this is an acknowledgment of the message M2 804. For instance, the message Ml 803 may correspond to the message ERROR INDICATION of the class 2 procedure Error Indication defined in TS 38.413 section 8.7.5. Then, the message ACKNOWLEDGMENT 805 is a new NG protocol message, composing or forming a new NG procedure, called Acknowledgment, to secure any NG procedure. In another example, the message M2 804 may correspond to the message OVERLOAD START of the class 2 procedure Overload Start defined in TS 38.413 section 8.7.7. Then, the message ACKNOWLEDGMENT 806 is the same message as ACKNOWLEDGMENT 805 but with a different content (i.e. a different identifier value to identify the acknowledged message). For example, the content of ACKNOWLEDGMENT 806 includes information associated with the OVERLOAD START message 804 (e.g. Procedure Code value for OVERLOAD START protocol procedure and / or type of message 804 is an initiating message), information associated with the ACKNOWLEDGMENT 806 (e.g. Procedure Code value for Acknowledgment protocol procedure and type of message 806 is an initiating message for the Acknowledgment protocol procedure) and information for identifying the sender of the ACKNOWLEDGMENT 806 is the NG-RAN node 801. In another example, the messages Ml 803 and M2 804 may respectively correspond to the messages HANDOVER REQUIRED and HANDOVER COMMAND of the class 1 procedure Handover Preparation defined in TS 38.413 section 8.4.1. Then, the messages 805 and 806 are the same NG protocol message ACKNOWLEDGMENT but with a different content (i.e. a different identifier value to identify the acknowledged message). For example, the content of ACKNOWLEDGMENT 805 includes information associated with the HANDOVER REQUIRED message 803 (e.g. Procedure Code value for Handover Preparation protocol procedure and / or type of message 803 is an initiating message), information associated with the ACKNOWLEDGMENT message 805 (e.g. Procedure Code value for Acknowledgment protocol procedure and / or type of message 805 is an initiating message for the Acknowledgment protocol procedure) and information for identifying the sender of the ACKNOWLEDGMENT 805 is the AMF 802. For example, the content of ACKNOWLEDGMENT 806 includes information associated with the HANDOVER COMMAND message 804 (e.g. Procedure Code value for Handover Preparation protocol procedure and type of message 804 is a successful outcome message), information associated with the ACKNOWLEDGMENT message 806 (e.g. Procedure Code value for Acknowledgment protocol procedure and / or type of message 806 is an initiating message for the Acknowledgment protocol procedure) and information for identifying the sender of the ACKNOWLEDGMENT 806 is the NG-RAN node 801. It can be noted, that for a class 1 procedure composed of messages Ml 803 and M2 804, the ACKNOWLEDGMENT message 805 may not be necessary as the transmission of M2 message 804 implicitly acknowledges the reception of message Ml 803. In other words, a second message (such as ACKNOWLEDGMENT message 805 or ACKNOWLEDGMENT message 806) for acknowledging receipt of a first message (such as the Ml message 803 or M2 message 804) is sent as part of or in accordance with a new NG protocol procedure for acknowledging successfully received messages (e.g. which may be referred to as an Acknowledgment procedure or acknowledgement NG application protocol procedure) to secure or improve the reliability of the NG protocol procedure to which the first message relates. It is noted that the methods described with reference to figure 7a relate to adding new messages to existing NG protocol procedures whereas the methods described with reference to figure 8a relate to applying a new NG protocol procedure. The content of an ACKNOWLEDGMENT message like the messages 805 and 806 may be composed of one or more of the following information elements: A Message Type as defined in TS 38.413 section 9.3.1.1, with the Procedure Code value set to the integer value corresponding to the Acknowledgment procedure (e.g. 255), and the Type of Message value set to “Initiating Message”; An identifier of the sender of the message, for instance a Global RAN Node ID, as defined in TS 38.413 section 9.3.1.5 when the sender is the NG-RAN node 801, or a GUAMI as defined in TS 38.413 section 9.3.3.3 when the sender is the AMF 802; An identifier of the acknowledged message, for instance the value of the Message Type (as defined in TS 38.413 section 9.3.1.1) which was included in the received message to acknowledge. For example, a second message sent to acknowledge receipt of a first message may include at least one of: information associated with the first message; information associated with the second message; identification information for identifying the sender of the second message (e.g. the ID of the AMF 802 in the case of message 805 or the ID of the NG-RAN node 801 in the case of message 806 as discussed above). The information associated with the first or second message may include identification information of the respective message (e.g. with the Procedure Code value and / or the Message Type as defined in TS 38.413 section 9.3.1.1 - see above description). The information associated with the first message or second may include at least one of: information, such as a Procedure Code value as discussed above, associated with the protocol procedure in or for which the respective message is sent; message type information, such as the Type of Message value as discussed above, set to a value indicating the type of the respective message (e.g. for the first message, the Type of Message value may be set to indicate the first message is an initiating message for the NG protocol procedure in or for which the first message is sent (e.g. OVERLOAD START protocol procedure) and for the second message, the Type of Message value may be set to indicate the second message is an initiating message for the NG protocol procedure in or for which the second message is sent (e.g. an Acknowledgment protocol procedure). According to a first example, NG protocol messages are required to be acknowledged by configuration, meaning that AMFs and NG-RAN nodes are configured to acknowledge NG protocol messages. This may concern all NG protocol messages defined in TS 38.413 or a subset of these NG protocol messages. According to a second example, the acknowledgment of a NG protocol message is explicitly requested by the sender of the message. In other words, a first message 803 or 804 sent by the sender (e.g. NG-RAN node 801 or AMF 802) may include information (e.g. an IE such as the “ack requested” IE discussed below) indicating the receiving node (e.g. AMF 802 or NG-RAN node 801) is requested or required to send an acknowledgement of the first message such as after receiving the first message (e.g. after receiving successfully the first message), and after the receiving node determines the information requesting the sending of an acknowledgement is included in the first message, the receiving node sends a second message (805 or 806) as an acknowledgement message acknowledging receipt of the first message. For instance, if the NG-RAN node 801 requests an acknowledgment of message Ml 803, then a dedicated information element, for instance called “ack requested” is included in the message Ml 803. Upon reception of the message Ml 803, the AMF 802 checks the presence of the “ack requested” information element, and if present, sends the ACKNOWLEDGMENT message 805 to the NG-RAN node 801. Similarly, if the AMF 802 requests an acknowledgment of message M2 804, then the information element “ack requested” is included in the message M2 804. Upon reception of the message M2 804, the NG-RAN node 801 checks the presence of the “ack requested” information element, and if present, sends the ACKNOWLEDGMENT message 806 to the AMF 802. The request of acknowledgment of a message may be based on a trigger or trigger event (or when a certain condition is met) as discussed above. In one case, the trigger may be the detection (directly or through a received notification) of an issue on the wireless backhaul link on which the NG protocol message is to be transmitted. The issue may be detected or determined, by the NG-RAN node 801 or AMF 802, when the quality of the wireless link reaches a certain threshold due to congestion on the wireless link or poor radio conditions or lack of radio resources which may lead to some NG protocol procedures failing in a similar manner as to that described above for figure 7a. The request for acknowledgment of a message may also be based on the critical characteristics (such as priority level) of the message. In other words, in another example the trigger may be when the priority level of the message to be sent reaches a certain threshold indicating the message is critical (e.g. the priority level is high). Figure 8b is a schematic diagram showing a second example message flow 810 for acknowledging Xn protocol messages (e.g. which are sent as part of a signalling procedure of the Xn application protocol which may also be referred to as a XnAP procedure or Xn protocol signalling procedure). This figure shows two NG-RAN nodes 811 and 812 like WAB-gNB 532 and BH-gNBl 501 of figure 5. The NG-RAN nodes 811 and 812 may also be embedded in a satellite, like the satellite 160 of figure 1. It is assumed that a Xn connection has been previously established between the NG-RAN nodes 811 and 812. As discussed above, the example message flows 810 may also apply for the wired link between BH-gNBl 501 and BH-gNB2 502 of figure 5. This figure illustrates another example method to improve the reliability of Xn protocol (e.g. a Xn application protocol) with the acknowledgment of the reception of Xn protocol messages in accordance with one or more embodiments of the present invention. When the NG-RAN node 811 sends a Xn protocol message Ml 813 to the NG-RAN node 812, the NG-RAN node 812 notifies the successful reception of the message Ml 813 by sending the ACKNOWLEDGMENT message 815 to the NG-RAN node 811. The ACKNOWLEDGMENT message 815 contains or includes information associated with the message Ml (e.g. a first message), such as an identifier of or identification information associated with the message Ml (e.g. the Message Type as defined in TS 38.423 section 9.2.3.1). For example, the ACKNOWLEDGMENT message 815 may include the Procedure Code Value (as discussed above) and / or the type of message M2 804 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1), which may be included in the message Ml 813. Thanks to this identifier of message Ml, the NG-RAN node 811 understands that this is an acknowledgment of the message Ml 813. After the transmission of message Ml 813, the NG-RAN node 811 may start a timer. In case the ACKNOWLEDGMENT message 815 is not received at the expiry of the timer, the NG-RAN node 811 understands that the message Ml 813 has not been received (or has not been received correctly or successfully) at the NG-RAN node 812, or / and that the ACKNOWLEDGMENT message 815 is lost. Then, the NG-RAN node 811 can resend the message Ml 813 to the NG-RAN node 812. In case the message Ml 813 has not been successfully transmitted to the NG-RAN node 812 after a predefined maximum number of retries (e.g. in the case where the NG-RAN node 811 does not receive a Ml ACKNOWLEDGE message 815 from the NG-RAN 812 after a predefined maximum number of attempts re-sending the message Ml 813), the NG-RAN node 811 may consider that the NG-RAN node 812 is no more reachable and it may consider the Xn connection with the NG-RAN node 812 as released or removed. Similarly, when the NG-RAN node 812 sends a Xn protocol message M2 814 to the NG-RAN node 811, the NG-RAN node 811 notifies the successful reception of the message M2 814 by sending the ACKNOWLEDGMENT message 816 to the NG-RAN node 812. The ACKNOWLEDGMENT message 816 contains or includes information associated with the message M2 (e.g. a first message), such as an identifier of or identification information associated with the message M2 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1). For example, the ACKNOWLEDGMENT message 816 may include the Procedure Code Value (as discussed above) and / or the type of message M2 804 (e.g. the Message Type as defined in TS 38.413 section 9.3.1.1), which may be included in the message M2 814. Thanks to this identifier of message M2, the NG-RAN node 812 understands that this is an acknowledgment of the message M2 804. For instance, the message Ml 813 may correspond to the message RAN PAGING of the class 2 procedure RAN Paging, defined in TS 38.423 section 8.2.5. Then, the message ACKNOWLEDGMENT 815 is a new Xn protocol message, composing or part of a new Xn procedure, called Acknowledgment, to secure any Xn procedure. In another example, the messages Ml 813 and M2 814 may respectively correspond to the messages RETRIEVE UE CONTEXT REQUEST and RETRIEVE UE CONTEXT RESPONSE of the class 1 procedure Retrieve UE Context defined in TS 38.423 section 8.2.4. Then, the messages 815 and 816 are the same Xn protocol message ACKNOWLEDGMENT but with a different content (i.e. a different identifier value to identify the acknowledged message to which the ACKNOWLEDGMENT message relates). It can be noted, that for a class 1 procedure composed of messages Ml 813 and M2 814, the ACKNOWLEDGMENT message 815 may not be necessary as the transmission of M2 message 814 implicitly acknowledges the reception of message Ml 813. In other words, a second message (such as ACKNOWLEDGMENT message 815 or ACKNOWLEDGMENT message 816) for acknowledging receipt of a first message (such as the Ml message 813 or M2 message 814) is sent as part of or in accordance with a new Xn protocol procedure for acknowledging successfully received messages (e.g. which may be referred to as an Acknowledgment procedure) to secure or improve the reliability of the Xn protocol procedure to which the first message relates. It is noted that the methods described with reference to figure 7b relate to adding new messages to existing Xn protocol procedures whereas the methods described with reference to figure 8b relate to applying a new Xn protocol procedure. The content of an ACKNOWLEDGMENT message like the messages 815 and 816 may be composed of one or more of the following information elements: A Message Type as defined in TS 38.423 section 9.2.3.1, with the Procedure Code value set to the integer value corresponding to the Acknowledgment procedure (e.g. 255), and the Type of Message value set to “Initiating Message”; An identifier of the sender of the message, for instance a Global NG-RAN Node ID, as defined in TS 38.423 section 9.2.2.3; An identifier of the acknowledged message, for instance the value of the Message Type (as defined in TS 38. 423 section 9.2.3.1) which was included in the received message to acknowledge. For example, a second message sent to acknowledge receipt of a first message may include at least one of information associated with the first message; information associated with the second message; identification information for identifying the sender of the second message (e.g. the ID of the NG-RAN node 812 in the case of message 815 or the ID of the NG-RAN node 811 in the case of message 816 as discussed above). The information associated with the first or second message may include identification information of the respective message (e.g. with the Procedure Code value and / or the Message Type as defined in TS 38.413 section 9.3.1.1 - see above description). The information associated with the first message or second may include at least one of information, such as a Procedure Code value as discussed above, associated with the protocol procedure in or for which the respective message is sent; message type information, such as the Type of Message value as discussed above, set to a value indicating the type of the respective message (e.g. for the first message, the Type of Message value may be set to indicate the first message is an initiating message for the Xn protocol procedure in or for which the first message is sent (e.g. RAN PAGING protocol procedure) and for the second message, the Type of Message value may be set to indicate the second message is an initiating message for the Xn protocol procedure in or for which the second message is sent (e.g. an Acknowledgment protocol procedure). According to a first example, Xn protocol messages are required to be acknowledged by configuration, meaning that NG-RAN nodes are configured to acknowledge Xn protocol messages. This may concern all Xn protocol messages defined in TS 38.423 or a subset of these Xn protocol messages. According to a second example, the acknowledgment of a Xn protocol message is explicitly requested by the sender of the message. In other words, a first message 813 or 814 sent by the sender (e.g. NG-RAN node 811 or NG-RAN node 812) may include information (e.g. an IE such as the “ack requested” IE discussed below) indicating the receiving node (e.g. NG-RAN node 812 or NG-RAN node 811) is requested or required to send an acknowledgement of the first message such as after receiving the first message (e.g. after receiving successfully the first message), and after the receiving node determines the information requesting the sending of an acknowledgement is included in the first message, the receiving node sends a second message (815 or 816) as an acknowledgement message acknowledging receipt of the first message. For instance, if the NG-RAN node 811 requests an acknowledgment of message Ml 813, then a dedicated information element, for instance called “ack requested” is included in the message Ml 813. Upon reception of the message Ml 813, theNG-RAN node 812 checks the presence of the “ack requested” information element, and if present, sends the ACKNOWLEDGMENT message 815 to the NG-RAN node 811. Similarly, if the NG-RAN node 812 requests an acknowledgment of message M2 814, then the information element “ack requested” is included in the message M2 814. Upon reception of the message M2 814, the NG-RAN node 811 checks the presence of the “ack requested” information element, and if present, sends the ACKNOWLEDGMENT message 816 to the NG-RAN node 812. The request of acknowledgment of a message may be based on a trigger or trigger event (or when a certain condition is met) as discussed above. In one case, the trigger may be the detection (directly or through a received notification) of an issue on the wireless backhaul link on which the Xn protocol message is to be transmitted. The issue may be detected or determined, by the NG-RAN node 811 or NG-RAN node 812, when the quality of the wireless link reaches a certain threshold due to congestion on the wireless link or poor radio conditions or lack of radio resources which may lead to some Xn protocol procedures failing in a similar manner as to that described above for figure 7a. The request for acknowledgment of a message may also be based on the critical characteristics (such as priority level) of the message. Figure 9a is a schematic diagram showing an example message flow 900 for indicating the support of NG acknowledged mode. This figure shows a NG-RAN node 901 like WAB-gNB 532 or BH-gNBl 501 of figure 5, and an AMF 902 like the AMF 51 la of figure 5 in a 5G core network (5GC) like the core network 510 of figure 5. The NG-RAN node 901 may also be embedded in a satellite, like the satellite 160 of figure 1. Several NG acknowledged modes may be defined, for example: The Acknowledged Mode 1 (AMI) where all the protocol messages have to be acknowledged permanently. In other words, in this case all protocol messages sent as part of NG protocol procedures are always or at all times required to be acknowledged; The Acknowledged Mode 2 (AM2) where only some of the protocol messages have to be acknowledged permanently. It may be a predefined subset of messages that are considered as critical to operate the network correctly. For example, the messages of class-2 procedures (i.e. without expected response) may be considered as critical; The Acknowledged Mode 3 (AM3), where the acknowledgment of a message is explicitly requested by the sender of the message. It will be appreciated that the disclosure is not limited to the three modes identified above. There may be more or less modes defined. Furthermore, the names AMI, AM2 and AM3 are given by way of example and different names may instead be used. At least one of the possible acknowledged modes need to be supported by the two network entities exchanging NG protocol messages. A NG acknowledged mode can be used for NG protocol messages exchanged between NG-RAN node 901 and AMF 902, when both the NG-RAN node 901 and the AMF 902 support this mode. The goal of figure 9a is to provide a method to check whether a NG acknowledged mode can be used between two network entities. In the example of figure 9a, the NG-RAN node 901 sends the message AM SUPPORT 903 to the AMF 902 indicating which NG acknowledged mode(s) the NG-RAN node 901 supports. Upon reception of message 903, the AMF 902 responds with the message AM SUPPORT RESPONSE 905 sent to the NG-RAN node 901. The message 905 also indicates the NG acknowledged mode(s) supported by the AMF 902. The NG-RAN node 901 may acknowledge the correct reception of message 905 by sending the message AM SUPPORT ACK 907 to the AMF 902. It can be noted that the messages 903 and 907 may be sent by the AMF 902, while the message 905 is sent by the NG-RAN node 901. The indication whether a network entity (i.e. a NG-RAN node or an AMF) supports an acknowledged mode may be an Information Element (IE) called “AM support”. This IE may be composed of several bits, each bit corresponding to one acknowledged mode, with value “1” meaning the acknowledged mode is supported and value “0” meaning the acknowledged mode is not supported (or vice versa where the value “0” means the acknowledged mode is supported and value “1” means the acknowledged mode is not supported). The message 903 and 905 may correspond to the messages NG SETUP REQUEST and NG SETUP RESPONSE corresponding to the NG Setup procedure defined in TS 38.413 section 8.7.1, and amended to include the IE “AM support”. Thus, the “AM support” IE may be shared at the establishment of the NG connection between NG-RAN node 901 and AMF 902. As an alternative to indicating whether an acknowledged mode is supported based whether a bit value is “1” or “0”, a network entity may include (e.g. in the NG SETUP REQUEST message or NG SETUP RESPONSE message) one or more information elements indicating the network entity supports one or more acknowledged modes and when it doesn’t support an acknowledged mode, the network entity may not include an information element for the particular acknowledged mode not supported. Figure 9b is a schematic diagram showing an example message flow 910 for indicating the support of Xn acknowledged mode. This figure shows two NG-RAN nodes 911 and 912 like WAB-gNB 532 and BH-gNBl 501, or like BH-gNBl 501 and BH-gNB2 502 of figure 5. The NG-RAN nodes 911 and 912 may also be embedded in a satellite, like the satellite 160 of figure 1. Several Xn acknowledged modes may be defined, for example: The Acknowledged Mode 1 (AMI) where all the protocol messages have to be acknowledged permanently. In other words, in this case all protocol messages sent as part of Xn protocol procedures are always or at all times required to be acknowledged; The Acknowledged Mode 2 (AM2) where only some of the protocol messages have to be acknowledged permanently. It may be a predefined subset of messages that are considered as critical to operate the network correctly. For example, the message of class-2 procedures (i.e. without expected response) may be considered as critical; The Acknowledged Mode 3 (AM3), where the acknowledgment of a message is explicitly requested by the sender of the message. At least one of the possible acknowledged modes need to be supported by the two network entities exchanging Xn protocol messages. A Xn acknowledged mode can be used for Xn protocol messages exchanged between NG-RAN nodes 911 and 912, when both the NG-RAN nodes 911 and 912 support this mode. The goal of figure 9b is to provide a method to check whether a Xn acknowledged mode can be used between two network entities. In the example of figure 9b, the NG-RAN node 911 sends the message AM SUPPORT 913 to the NG-RAN node 912 indicating which Xn acknowledged mode(s) the NG-RAN node 911 supports. Upon reception of message 913, the NG-RAN node 912 responds with the message AM SUPPORT RESPONSE 915 sent to the NG-RAN node 911. The message 915 also indicates the Xn acknowledged mode(s) supported by the NG-RAN node 912. The NG-RAN node 911 may acknowledge the correct reception of message 915 by sending the message AM SUPPORT ACK 917 to the NG-RAN node 912. It can be noted that the messages 913 and 917 may be sent by the NG-RAN node 912, while the message 915 is sent by the NG-RAN node 911. The indication whether a network entity (i.e. a NG-RAN node) supports an acknowledged mode may be an Information Element (IE) called “AM support”. This IE may be composed of several bits, each bit corresponding to one acknowledged mode, with value “1” meaning the acknowledged mode is supported and value “0” meaning the acknowledged mode is not supported (or vice versa where the value “0” means the acknowledged mode is supported and value “1” means the acknowledged mode is not supported). The message 913 and 915 may correspond to the messages XN SETUP REQUEST and XN SETUP RESPONSE corresponding to the Xn Setup procedure defined in TS 38.423 section 8.4.1, and amended to include the IE “AM support”. Thus, the “AM support” IE may be shared at the establishment of the Xn connection between NG-RAN node 911 and the NG-RAN node 912. As an alternative to indicating whether an acknowledged mode is supported based whether a bit value is “1” or “0”, a network entity may include (e.g. in the XN SETUP REQUEST message or XN SETUP RESPONSE message) one or more information elements indicating the network entity supports one or more acknowledged modes and when it doesn’t support an acknowledged mode, the network entity may not include an information element for the particular acknowledged mode not supported. Thus, based on information received at the NG-RAN node 901 in message 905 (or at the NG-RAN node 911 in message 915) indicating the AMF 902 (or NG-RAN node 912) supports at least one of a plurality of acknowledged modes (e.g. one or more of NG or Xn acknowledged modes such as AM1-AM3) and the acknowledged modes supported by the NG-RAN node 901 (or the NG-RAN node 911), the NG-RAN node 901 (or NG-RAN node 911) can determine whether at least one of the acknowledged modes is supported by both the NG-RAN node 901 and the AMF 902 (or both the NG-RAN node 911 and the NG-RAN node 912). In the case where at least one of the acknowledged modes is supported by both the NG-RAN node 901 and the AMF 902 (or both the NG-RAN node 911 and the NG-RAN node 912), the NG-RAN node 901 (or NG-RAN node 911) determines that the at least one acknowledged mode can be used when activated. Similarly at the AMF 902 (or NG-RAN node 912) based on information received at the AMF 902 in message 903 (or at the NG-RAN node 912 in message 913) indicating the NG-RAN node 901 (or NG-RAN node 911) supports at least one of a plurality of acknowledged modes (e.g. one or more of AM1-AM3) and the acknowledged modes supported by the AMF 902 (or NG-RAN node 912), the AMF 902 (or NG-RAN node 912) can determine whether at least one of the acknowledged modes is supported by both the NG-RAN node 901 and the AMF 902 (or both the NG-RAN node 911 and the NG-RAN node 912). In the case where at least one of the acknowledged modes is supported by both the NG-RAN node 901 and the AMF 902 (or both the NG-RAN node 911 and the NG-RAN node 912), the AMF 902 (or NG-RAN node 912) determines that the at least one acknowledged mode can be used when activated. Figure 10a is a schematic diagram showing a first example message flow 1000 for activating or deactivating a NG acknowledged mode by a NG-RAN node in accordance with one or more embodiments of the present invention. This figure shows a NG-RAN node 1001 like WAB-gNB 532 or BH-gNBl 501 of figure 5, and an AMF 1002 like the AMF 511a of figure 5 in a 5G core network (5GC) like the core network 510 of figure 5. The NG-RAN node 1001 may also be embedded in a satellite, like the satellite 160 of figure 1. When the NG-RAN node 1001 decides to activate or deactivate a NG acknowledged mode, the NG-RAN node 1001 sends a message 1003, such as a AM CONFIGURATION message 1003, to the AMF 1002, the message 1003 indicating a NG acknowledged mode is to be activated or deactivated. This message 1003 may include an Information Element (IE) called “AM activation”, which may be composed of several bits, each bit corresponding to one acknowledged mode, with value “1” meaning the acknowledged mode is activated and value “0” meaning the acknowledged mode is deactivated (or not activated) (or vice versa where the value “0” is to request or indicate activation of an acknowledged mode and value “0” is to request or indicate deactivation of the acknowledged mode). According to one embodiment, the message 1003 may be considered as a request from the NG-RAN node 1001, where the NG-RAN node 1001 proposes to activate (or deactivate) one or several acknowledged modes, and the final selection is up to the AMF 1002. Upon or after reception of message 1003, the AMF 1002 responds by sending a message, such as a AM CONFIGURATION RESPONSE message 1005, the message 1005 indicating whether the NG acknowledged mode is to be activated or deactivated. The message 1005 may include the “AM activation” IE as defined above, to confirm the activation or deactivation of the acknowledged modes: value “1” to confirm the activation of an acknowledged mode and value “0” meaning the acknowledged mode is deactivated (or vice versa where the value “0” is to confirm activation of an acknowledged mode and value “1” is to confirm deactivation of the acknowledged mode). In case the final decision is left to the AMF 1002, the content of the “AM activation” IE in the message 1005 may differ from the content of the “AM activation” IE in message 1003. However, if NG-RAN node 1001 has requested the activation of an acknowledged mode, then the AMF 1002 normally confirms the activation of an acknowledged mode (which can be different from the acknowledged mode proposed by the NG-RAN node 1001). It may be considered that AM2 and AM3 may be activated and used at the same time. There may be no interest or little benefit to activate and use AMI and AM2 at the same time, or AMI and AM3 at the same time. An activated acknowledged mode can be used for protocol messages exchanged between the NG-RAN node 1001 and the AMF 1002 when the acknowledged mode is supported by both the NG-RAN node 1001 and the AMF 1002. The activation may follow, for instance, the execution of the procedure for AM support sharing described at the figure 9a. According to one example, the “AM activation” IE is included in the messages AM SUPPORT 903 and AM SUPPORT RESPONSE 905. Then, a NG acknowledged mode may be activated and used as soon as the NG connection is established. Thanks to the procedure of figure 10a, a NG acknowledged mode can be dynamically activated or deactivated at the initiative of the NG-RAN node 1001. The activation of a NG acknowledged mode may be automatically activated (and used permanently) when there is a wireless link between the NG-RAN node 1001 and the AMF 1002. For instance, a NG acknowledged mode may be automatically activated (and used permanently) when the NG-RAN node 1001 is the gNB component of a WAB node (i.e. a WAB-gNB), and when the NG-RAN node 1001 indicates it is a WAB-gNB to the AMF 1002 (for instance at NG Setup procedure). Figure 10b is a schematic diagram showing a second example message flow 1010 for activating or deactivating a NG acknowledged mode by an AMF in accordance with one or more embodiments of the present invention. This figure shows a NG-RAN node 1011 like WAB-gNB 532 or BH-gNBl 501 of figure 5, and an AMF 1012 like the AMF 511a of figure 5 in a 5G core network (5GC) like the core network 510 of figure 5. The NG-RAN node 1011 may also be embedded in a satellite, like the satellite 160 of figure 1. When the AMF 1012 decides to activate or deactivate a NG acknowledged mode, the NG-AMF 1012 sends a message, such as a AM CONFIGURATION message 1013 to the NG-RAN node 1011, the message 1013 indicating the NG acknowledged mode is to be activated or deactivated. This message 1013 may include an Information Element (IE) called “AM activation”, which may be composed of several bits, each bit corresponding to one acknowledged mode, with value “1” meaning the acknowledged mode is activated and value “0” meaning the acknowledged mode is deactivated (or not activated) (or vice versa where the value “0” is to request or indicate activation of the acknowledged mode and value “1” is to request or indicate deactivation of the acknowledged mode). According to one embodiment, the message 1013 may be considered as a request from the AMF 1012, where the AMF 1012 proposes to activate (or deactivate) one or several acknowledged modes, and the final selection is up to the NG-RAN node 1011. Upon or after reception of message 1013, the NG-RAN node 1011 responds by sending a message, such as a AM CONFIGURATION RESPONSE message 1015, the message 1015 indicating whether the NG acknowledged mode is to be activated or deactivated. The message 1015 may include the “AM activation” IE as defined above, to confirm the activation or deactivation of the acknowledged modes: value “1” to confirm the activation of an acknowledged mode is activated and value “0” meaning the acknowledged mode is deactivated (or vice versa where the value “0” is to confirm activation of an acknowledged mode and value “1” is to confirm deactivation of the acknowledged mode). In case the final decision is left to the NG-RAN node 1011, the content of the “AM activation” IE in the message 1015 may differ from the content the “AM activation” IE in message 1013. However, if AMF 1012 has requested the activation of an acknowledged mode, then the NG-RAN node 1011 normally confirms the activation of an acknowledged mode (which can be different from the acknowledged mode proposed by the AMF 1012). It may be considered that AM2 and AM3 may be activated and used at the same time. There may be no interest or little benefit to activate and use AMI and AM2 at the same time, or AMI and AM3 at the same time. In order to use an activated acknowledged mode, an activated acknowledged mode needs to be supported by both the NG-RAN node 1011 and the AMF 1012. The activation may follow, for instance, the execution of the procedure for AM support sharing described at the figure 9a. According to one embodiment, the “AM activation” IE is included in the messages AM SUPPORT 903 and AM SUPPORT RESPONSE 905. Then, a NG acknowledged mode may be activated and used as soon as the NG connection is established. Thanks to the procedure of figure 10b, a NG acknowledged mode can be dynamically activated or deactivated at the initiative of the AMF 1012. The activation of a NG acknowledged mode may be automatically activated (and used permanently) when there is a wireless link between the NG-RAN node 1011 and the AMF 1012. For instance, an NG acknowledged mode may be automatically activated (and used permanently) when the NG-RAN node 1011 is the gNB component of a WAB node (i.e. a WAB-gNB), and when the NG-RAN node 1011 indicates it is a WAB-gNB to the AMF 1022 (for instance at NG Setup procedure). In case both a NG-RAN node and an AMF send an AM CONFIGURATION message (1003, 1013) at the same time with not the same value in the same “AM activation” IE to activate the same NG acknowledged mode, then in the case where both the NG-RAN node and AMF support more than one acknowledge modes, the most reliable acknowledged mode may be selected. For instance, it may be considered that AMI is more reliable than AM2, and that AM2 is more reliable than AM3. Thus, according to the procedures of figure 10a and 10b, a NG acknowledged mode can be dynamically activated or deactivated at the initiative of the NG-RAN node 1001 or AMF 1012. The activation of a NG acknowledged mode may be automatically activated (and used permanently) when there is a wireless link between the NG-RAN node 1001 or 1011 and the AMF 1002 or 1012. In another example, a NG acknowledged mode may be activated by a WAB-gNB of a WAB node (when the NG-RAN node 1001 is a WAB-gNB of the WAB node) or the AMF 1012 after occurrence or in response to a trigger or trigger event (or when a certain condition is met). In one case, the trigger may be when an issue with a wireless link between the WAB node and the AMF 1002 or 1012 (e.g. a wireless backhaul link through or via which the WAB-gNB 1001 or 1011 of the WAB node is connected to the AMF 1002 or 1012) is detected. The issue may be detected or determined when the quality of the wireless link reaches a certain threshold due to congestion on the wireless link or poor radio conditions or lack of radio resources which may lead to some NG and Xn protocol procedures failing. The WAB-gNB 1001 of the WAB node may determine there is an issue with the wireless backhaul link via the WAB-MT of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT). The AMF 1012 may determine there is an issue with the wireless backhaul link via the WAB-gNB of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT) and / or a NG-RAN node (e.g. a backhaul RAN node connected to the WAB-MT of the WAB node). In another case, the trigger may be when the priority level of the message to be sent reaches a certain threshold indicating the message is critical (e.g. the priority level is high). Figure 10c is a schematic diagram showing an example message flow 1020 for activating or deactivating a Xn acknowledged mode by a NG-RAN node in accordance with one or more embodiments of the invention. This figure shows two NG-RAN nodes 1021 and 1022 like WAB-gNB 532 and BH-gNBl 501, or like BH-gNBl 501 and BH-gNB2 502 of figure 5. The NG-RAN nodes 1021 and 1022 may also be embedded in a satellite, like the satellite 160 of figure 1. When the NG-RAN node 1021 decides to activate or deactivate a Xn acknowledged mode, the NG-RAN node 1021 sends a message, such as a AM CONFIGURATION message 1023 to the NG-RAN node 1022, the message 1023 indicating a Xn acknowledged mode is to be activated or deactivated. This message 1023 may include an Information Element (IE) called “AM activation”, which may be composed of several bits, each bit corresponding to one acknowledged mode, with value “1” meaning the acknowledged mode is activated and value “0” meaning the acknowledged mode is deactivated (or not activated) (or vice versa where the value “0” is to request or indicate activation of the acknowledged mode and value “1” is to request or indicate deactivation of the acknowledged mode). According to one embodiment, the message 1023 may be considered as a request from the NG-RAN node 1021, where the NG-RAN node 1021 proposes to activate (or deactivate) one or several acknowledged modes, and the final selection is up to the NG-RAN node 1022. Upon or after reception of message 1023, the NG-RAN node 1022 responds by sending a message, such as a AM CONFIGURATION RESPONSE message 1025, the message 1025 indicating whether the Xn acknowledged mode is to be activated or deactivated. The message 1025 may include the “AM activation” IE as defined above, to confirm the activation or deactivation of the acknowledged modes: value “1” to confirm the activation of an acknowledged mode is activated and value “0” meaning the acknowledged mode is deactivated (or vice versa where the value “0” is to confirm activation of an acknowledged mode and value “1” is to confirm deactivation of the acknowledged mode). In case the final decision is left to the NG-RAN node 1022, the content of the “AM activation” IE in the message 1025 may differ from the content the “AM activation” IE in message 1023. However, if NG-RAN node 1021 has requested the activation of an acknowledged mode, then the NG-RAN node 1022 normally confirms the activation of an acknowledged mode (which can be different from the acknowledged mode proposed by the NG-RAN node 1021). It may be considered that AM2 and AM3 may be activated and used at the same time. There may be no interest or little benefit to activate and use AMI and AM2 at the same time, or AMI and AM3 at the same time. In order to use an activated acknowledged mode, an activated acknowledged mode needs to be supported by both the NG-RAN nodes 1021 and 1022. The activation may follow, for instance, the execution of the procedure for AM support sharing described at the figure 9b. According to one embodiment, the “AM activation” IE is included in the messages AM SUPPORT 913 and AM SUPPORT RESPONSE 915. Then, a Xn acknowledged mode may be activated and used as soon as the Xn connection is established. Thanks to the procedure of figure 10c, a Xn acknowledged mode can be dynamically activated or deactivated at the initiative of the NG-RAN node 1021. The activation of a NG acknowledged mode may be automatically activated (and used permanently) when there is a wireless link between the NG-RAN nodes 1021 and 1022. For instance, a Xn acknowledged mode may be automatically activated (and used permanently) when the NG-RAN node 1021 is the gNB component of a WAB node (i.e. a WAB-gNB), and when the NG-RAN node 1021 indicates it is a WAB-gNB to the NG-RAN node 1022 (for instance at Xn Setup procedure). Thus, according to the procedure of figure 10c, a Xn acknowledged mode can be dynamically activated or deactivated at the initiative of the NG-RAN node 1021. The activation of a Xn acknowledged mode may be automatically activated (and used permanently) when there is a wireless link between the NG-RAN node 1021 the NG-RAN node 1022. In another example, a Xn acknowledged mode may be activated by a WAB-gNB of a WAB node (when the NG-RAN node 1021 is the WAB-gNB of a WAB node) after occurrence or in response to a trigger or trigger event (or when a certain condition is met). In one case, the trigger may be when an issue with a wireless link between the WAB node and the NG-RAN node 1022 (e.g. a wireless backhaul link connected between a WAB-MT of the WAB node and the NG-RAN node 1022) is detected. The issue may be detected or determined when the quality of the wireless link reaches a certain threshold due to congestion on the wireless link or poor radio conditions or lack of radio resources which may lead to some Xn protocol procedures failing. The WAB-gNB 1021 of the WAB node may determine there is an issue with the wireless backhaul link via the WAB-MT of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT). The RAN node 1022 (e.g. backhaul RAN node) may determine there is an issue with the wireless backhaul link via the WAB-gNB 1021 of the WAB node (e.g. from measurements performed by the WAB-MT or information received at the WAB-MT) and / or from measurements performed at the backhaul RAN node 1022. In another case, the trigger may be when the priority level of the message to be sent reaches a certain threshold indicating the message is critical (e.g. the priority level is high). It will be appreciated that the message flows of figures 7a to 8b may be used also in the case where one or more of the modes AMI to AM3 are activated. A method for use in a wireless communication system including in accordance with the present invention will now be described with reference to the figures. The method may be used to manage acknowledgement of messages sent as part of a signalling procedure of Xn and / or NG application protocol. The method may be performed by a network entity, such as or NG-RAN node or an AMF entity, so as to manage acknowledgement of Xn and / or NG messages sent (e.g. between the network entity and another network entity (e.g. another NG-RAN node or an AMF entity associated with a Xn or NG connection) over or through or via a link) as part of signalling procedures of Xn application protocol or NG application protocol. The link may be a wireless link or a wired link. The NG-RAN node may be a WAB node or a NG-RAN node (such as a backhaul NG-RAN node) or a gNB component of the WAB node (e.g. WAB-gNB). For example, with reference to the communication system 500 shown in and described with respect to figure 5, the network entity may be the WAB-gNB 542 or the BH-gNB2 502, or the AMF 511a. The method may be performed by software elements and / or hardware elements. The network entity may be implemented in a network node 400 as shown in and described with reference to figure 4 with the method being performed by an apparatus for the network entity including one or more processing units, such as the processing unit 402. Briefly, the method at the network entity, such as WAB node 540 (e.g. at WAB-gNB 542), includes after receiving a first message as part of a signalling procedure of Xn application protocol (e.g. Xn protocol message 714, or 814 as described above) or NG application protocol (e.g. NG message 704, 804 as described above), sending a second message acknowledging the network entity has received the first message. See for example step 1104 described below with reference to figure 11 where an acknowledgement message (i.e. a second message) is sent after receiving (e.g. successfully receiving so that the first message can be sent for further processing) a Xn or a NG protocol (i.e. a first message) in step 1102. The second message may be sent (e.g. as a new message) as part of an existing signalling procedure of the Xn or NG protocol (such as message 706, 716 as shown and described with reference to figures 7a, 7b) or as part of a new signalling procedure of Xn or NG protocol (such as an acknowledge procedure, an example of which is shown and described with reference to figures 8a, 8b and messages 806, 816). The Xn application protocol (XnAP) supports the functions of the Xn interface and the NG application protocol (NGAP) supports the functions of the NG interface. The first and second Xn and NG protocol messages are sent between the network entity and another network entity over respective Xn or NG connections or paths. The first message may be a message sent as part of a class 2 signalling procedure of the Xn or NG application protocol. By sending a second message acknowledging receipt of the first message, the network entity (second or receiving network entity) can indicate to the sender of the first message (e.g. another network entity or first sending network entity associated with a Xn or NG connection or path between the first and second network entities) that the first message has been received (e.g. successfully received) and the signalling procedure of the Xn or NG protocol can be continued as required (e.g. as normal) to maintain service (e.g. at the UEs served by a WAB node). When the first network entity does not receive a second message from the second network entity indicating the first message has been received at the second network entity, the first network entity can detect or determine that there is an issue (e.g. due to degradation of a link in the Xn or NG connection or path) and can take appropriate action to avoid system failure and interruption of service. For example, in the case the first sending network entity is a WAB node (more precisely the gNB component, WAB-gNB, of the WAB node) and the WAB-gNB does not receive a second message acknowledging receipt of the first message sent by the WAB-gNB, the WAB-gNB can inform the backhaul NG-RAN node supporting the WAB node about the issue, and the backhaul NG-RAN node may perform handover of the WAB node to another NG-RAN node to set up a more reliable link to the network. The WAB-gNB may also perform handover of served UEs to reduce the user plane and control plane traffic over the wireless backhaul link, which is used for the user plane traffic between the WAB-gNB and UE UPF(s), and the control plane traffic between the WAB-gNB and UE AMF(s)). In case the first network is an AMF and the second network entity is a WAB-gNB, the AMF may prioritize the traffic to handle the mobility (handover) of UEs served by the WAB-gNB. The AMF may also refrain from transmitting to the WAB-gNB status information like the NG protocol messages Overload Start, Overload Stop that do not contain useful information in this situation. In case the first and second network entities are NG-RAN nodes, like the first network entity is the backhaul NG-RAN node supporting a WAB node, and the second network entity is the gNB component, WAB-gNB, of the WAB node, the backhaul NG-RAN node may attempt to handover the WAB node to another backhaul NG-RAN node to set up a more reliable link between the WAB node and the network. In the case the network entity receiving the first message is a WAB node, a NG connection or path is set up between a gNB component of a WAB node (WAB-gNB) and an associated AMF entity (i.e. another network entity). A Xn connection or path is (additionally or alternatively to a NG connection) set up between the gNB component of a WAB node (WAB-gNB) and another NG-RAN node (i.e. another network entity). The NG connection or path and Xn connection or path includes a wireless link (e.g. between the MT component of the WAB node (WAB-MT) and a BH NG-RAN node). In other words, in the case where the network entity is a WAB node, the first message is received via (or over or through) a wireless link in the Xn path from the another NG-RAN node or the first message is received via (or over or through) a wireless link in the NG path from the associated AMF entity. In the case the network entity receiving the first message is an AMF entity (such as AMF 521a), a NG connection or path is set up between the AMF entity and an associated NG-RAN node (i.e. another network entity) such as WAB-gNB 542. The NG connection or path includes a wireless link (e.g. between the MT component of the WAB node (WAB-MT 541) and the BH NG-RAN node 502). In other words, in the case where the network entity is an AMF entity, the first message is received from the associated NG-RAN node via (or over or through) a wireless link (e.g. in the NG path). In the case the network entity receiving the first message is a NG-RAN node such as backhaul RAN node 502, a Xn connection or path is set up between the NG-RAN node 502 and a gNB component of a WAB node (e.g. WAB-gNB 542) (i.e. another network entity). The Xn connection or path includes a wireless link (e.g. between the MT component of the WAB node (WAB-MT 541) and the BH NG-RAN node 502). In other words, in the case where the network entity is a NG-RAN node, the first message is received via (or over or through) a wireless link (e.g. in the Xn or NG path). The second message may be sent when the network entity is required to send an acknowledgement message (e.g. second message) after receipt (e.g. successful receipt) of the first message as part of a signalling procedure for the Xn or NG application protocol. For example, the network entity may be configured such that it is required to send the second message at all times (e.g. permanently or always) acknowledging receipt of the first message. In another example, the network entity may send the second message when the first message includes information, such as ‘ack’ requesting information or IE, indicating the network entity is requested to send an acknowledgment of the first message, where in this case the second message is sent based on the ‘ack’ requesting information included in the first message. The network entity (e.g. WAB node 540) may send the second message acknowledging receipt of the first message when such ‘ack’ requesting information is included in the first message and when for example the acknowledge or acknowledged mode AM3 discussed above is activated at the WAB node 540. The network entity may determine that it is required to send an acknowledgment message (e.g. second message) after receipt (e.g. successful receipt) of the first message as described below with reference to step 1103 of figure 11. For example, the network entity may determine that it is required to send the second message when the first message includes information indicating the sender network entity (e.g. another network entity) sending the first message requests an acknowledgment of the first message (e.g. ‘ack’ requesting information is included in the first message) and / or on activation of one or more the acknowledged modes. An acknowledged mode is a mode in which the WAB node is required to send an acknowledgment message after receiving a message as part of a signalling procedure of the Xn or NG application protocol. See for example step 1101 described below with reference to figure 11 where an acknowledged mode may be activated for Xn and / or NG protocol. The first message may include information indicating the sender network entity requests an acknowledgment of the first message (e.g. ‘ack requesting information such as the “ack requested” IE discussed above) after the sender network entity determines at least one of: an issue on a link for use in communicating Xn or NG protocol messages to or from the sender network entity; a priority level of the first message meets a first threshold. The issue may be when link quality reaches a certain threshold level indicating the link has degraded to a point (due to congestion or poor radio conditions) where some signalling procedures for Xn or NG application protocol may fail. The first threshold may correspond to a certain threshold indicating the message is critical (e.g. the priority level is high), such as in the case where the message is a paging message relating to transmission of an emergency message. In an example, the one or more modes for acknowledging receipt of Xn or NG protocol messages (also referred to as acknowledged mode) include one or more of first, second and third modes or acknowledged modes (such as AMI to AM3 described above). The first mode is a mode in which all protocol messages sent as part of a signalling procedure of Xn application protocol or NG application protocol are required to be acknowledged at all times (e.g. always or permanently). In the case where the network entity is a WAB node and the WAB node is exchanging NG protocol messages with an associated AMF entity, the first mode may be automatically activated and used always when exchanging NG messages between the WAB node and AMF entity. The second mode is a mode in which some protocol messages (e.g. a subset) sent as part of a signalling procedure of Xn application protocol or NG application protocol are required to be acknowledged. The subset may include critical protocol messages that are considered as critical to operate the network correctly and / or messages of class 2 procedures. The third mode is a mode in which a protocol message sent as part of a signalling procedure of Xn application protocol or NG application protocol is required to be acknowledged when requested by the sender of the protocol message. The request (e.g. ‘ack’ requesting information or IE) may be included in the first message or sent separately. For each of the first, second and third modes, there is an Xn acknowledged mode for the Xn application protocol and an NG acknowledged mode for the NG application protocol. In order to apply one or more of the acknowledged modes, both the network entity sending the first message and the network entity sending the second message need to support (e.g. be capable of operating in) the one or more acknowledged modes and the one or more acknowledged modes is required to be activated. At least one acknowledged mode may be activated in response to a trigger. The trigger may be an event or a condition and may include at least one of: after the network entity determines an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity (e.g. a link in the Xn or NG connection or path); after receiving a message, from another network entity (e.g. another network entity associated with a Xn or NG connection with the network entity), indicating at least one acknowledged mode is to be activated; a priority level (e.g. criticality) of a message to be sent as part of a signalling procedure of Xn application protocol or NG application protocol meets a first threshold, (e.g. the first threshold representing a high priority, critical message). In the case where the network entity is a WAB node 540, an issue (such as congestion or degradation of link quality due to radio conditions) may be detected on the wireless backhaul link between the WAB-MT 541 and backhaul NG-RAN node 502. Examples of triggering activation of one or more acknowledged modes are described in more detail with reference to figures 10a to 10c. In the case where at least one Xn acknowledged mode or NG acknowledged mode has been activated, the network entity may deactivate the at least one Xn acknowledged mode or NG acknowledged mode in response to a trigger. The trigger may be an event or a condition and may include at least one of: after the network entity determines an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity (e.g. a link in the Xn or NG connection or path) has been resolved; after receiving a message, from another network entity (e.g. another network entity associated with a Xn or NG connection with the network entity), indicating at least one acknowledged mode is to be deactivated; a priority level (e.g. criticality) of a message to be sent as part of a signalling procedure of Xn application protocol or NG application protocol meets a second threshold, (e.g. the second threshold representing a low priority, not critical message). Examples of triggering deactivation of one or more acknowledged modes are described in more detail with reference to figures 10a to 10c. A network entity may indicate to another network entity (e.g. another network entity associated with the Xn or NG connection to the network entity) that it supports acknowledgment of Xn and / or NG protocol messages: for example, that the network entity supports one or more acknowledge modes (e.g. at least one Xn and / or NG acknowledged modes, such as modes AMI to AM3). The other network entity may also indicate whether it supports acknowledgment of Xn and / or NG protocol messages: for example, that the other network entity supports one or more acknowledged modes (e.g. at least one Xn and / or NG acknowledged modes, such as modes AMI to AM3). In an example, the network entity (such as an AMF entity or NG-RAN node (e.g. WAB node 540)) may send, to the other network entity (such as a NG-RAN node (e.g. WAB node) when the network entity is an AMF entity or a NG-RAN node or a AMF entity when the network entity is a NG-RAN node), information (e.g. support information, capability information) indicating the network entity supports one or more Xn / NG acknowledged modes in a message such as message 903, 913 described above with reference to figures 9a and 9b. The other network entity (such as a NG-RAN node (e.g. WAB node) when the network entity is an AMF entity or a NG-RAN node or a AMF entity when the network entity is a NG-RAN node) may send information (e.g. support information, capability information) indicating the other network entity supports one or more Xn / NG acknowledged modes. For example, after receiving a message from the network entity indicating the network entity supports one or more acknowledge modes, the other network entity may respond by sending a message 905, 915 described above with reference to figures 9a and 9b. When the network entity or the other network entity supports more than one acknowledged mode, the information sent may include information for each of the supported acknowledged modes indicating the respective acknowledged mode is supported. For example, the information may include an IE set to a value indicating whether the acknowledged mode is supported or not (e.g. a bit for each acknowledged mode as described with reference to figures 9a and 9b) or by only including information (IE) for the acknowledged mode when it is supported (and not sending any information otherwise). The support / capability information may be sent during establishment of a Xn or NG connection or after establishment of a Xn or NG connection. For example, in the case the network entity is a WAB node (e.g. WAB node 540), the support / capability information may be sent during establishment of a Xn connection between the gNB component of the WAB node (e.g WAB-gNB 542) and a NG-RAN node (such as backhaul RAN node 502) and / or during establishment of a NG connection between the gNB component of the WAB node (e.g WAB-gNB 542) and the associated AMF entity (e.g. AMF 521a). In the case where the network entity or other network entity is a WAB node (such as WAB node 540), the support / capability information may be information indicating the network entity is a WAB node and in this case, the other network entity receiving such support / capability information may infer from the fact that the network entity is a WAB node that it supports acknowledging Xn / NG protocol messages. For example, all WAB nodes may be configured to support acknowledgment of Xn / NG protocol messages. The second message sent by the network entity acknowledging the network entity has received the first message (e.g. a Xn and / or NG protocol message) may include at least one of: information associated with the first message; information associated with the second message; identification information for identifying the network entity sending the second message. The information associated with the first and / or second message may include at least one of: information associated with the signalling or protocol procedure in or for or during which the respective message is sent, such as a Procedure Code value as discussed above with reference to figures 7a to 8b; message type information for indicating the type of the message, such as the Type of Message value as discussed above with reference to figures 7a to 8b, set to a value indicating the type of the respective message. Foe example, the first message, the Type of Message value may be set to indicate the first message is an initiating message for the NG protocol procedure in or for which the first message is sent (e.g. OVERLOAD START protocol procedure) and for the second message, the Type of Message value may be set to indicate the second message is an initiating message for the NG protocol procedure in or for which the first message is sent (e.g. an Acknowledgment protocol procedure). The identification information for identifying the network entity sending the second message may include, for instance, a Global RAN Node ID, as defined in TS 38.413 section 9.3.1.5 when the sender is the NG-RAN node, or a GUAMI as defined in TS 38.413 section 9.3.3.3 when the sender is an AMF entity as discussed above with reference to figures 7a to 8b. Referring now also to figure 11 which is a flowchart of an example method 1100 for managing, at a network entity (such as an AMF or a NG-RAN node), an acknowledged mode, such as the NG or Xn acknowledged mode. For example, method 1100 is an example of a method for use in managing acknowledgement of messages sent as part of a signalling procedure of Xn or NG application protocol in a wireless communication system in accordance with one or more embodiments of the present invention. Method 1100 may be performed by a network entity such as an AMF entity or NG-RAN node so as to manage acknowledgement of messages sent (e.g. between the network entity and another network entity (e.g. another NG-RAN node) over or through or via a link) as part of signalling procedures of Xn application protocol or NG application protocol. The NG-RAN node may be a gNB component of a WAB node (i.e. WAB-gNB), or a NG-RAN node (such as a backhaul NG-RAN node). In one case, method 1100 is for use in a wireless communication system including a WAB node and may be performed at the WAB node (e.g. gNB component of the WAB node or WAB-gNB) or a network entity (e.g. a network entity which is associated with a Xn or NG connection with the gNB component of the WAB node, such as an AMF entity or a NG-RAN node) so as to manage acknowledgement of messages sent (e.g. between a WAB node and the network entity over or through or via a wireless backhaul link) as part of Xn or NG protocol procedures. For example, with reference to the communication system 500 shown in and described with respect to figure 5, the NG-RAN node may be the WAB-gNB 542 or the BH-gNB2 502, and the AMF may be the AMF 511a. The method 1100 as shown in and described with respect to figure 11 may be performed by software elements and / or hardware elements. The network entity (e.g. NG-RAN node or AMF entity) may be implemented in a network node 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 an apparatus for the network entity (e.g. WAB-gNB, NG-RAN node or AMF entity) including one or more processing units, such as the processing unit 402. At step 1101, a network entity (which may also be referred to as a first network entity), such as a AMF entity or a NG-RAN node, may activate an acknowledged mode for NG protocol messages exchanged with another network entity (which may also be referred to as a second or remote network entity), such as a remote NG-RAN node or a remote AMF as part of one or more NG protocol procedures (e.g. one or more signalling procedures of NG application protocol). Additionally or alternatively, a network entity (e.g. NG-RAN node) may activate an acknowledged mode for Xn protocol messages exchanged with another network entity (which may also be referred to as a second or remote network entity), such as a remote NG-RAN node as part of one or more Xn protocol procedures (e.g. one or more signalling procedures of Xn application protocol). The procedures for activation may be the procedures described with reference to the figures 10a, 10b and 10c. At step 1102, the NG-RAN node receives a Xn or a NG protocol message as part of a signalling procedure of Xn application protocol or a NG application protocol, or the AMF receives a NG protocol message as part of a signalling procedure of NG application protocol. For example, the NG-RAN node may receive NG protocol messages 704, 713, 714 or Xn protocol messages 804, 813, 814 as described above and the AMF may receive a NG protocol message 703 or a Xn protocol message 803 as described above. At step 1103, the AMF or the NG-RAN node may check whether the received message is to be acknowledged. The decision to acknowledge a message depends on the activated acknowledged mode(s) and / or may depend on the characteristics of the message to acknowledge. For example, in the case where the NG-RAN node is a WAB-gNB connected to an AMF or a BH NG-RAN node through or via a wireless BH link, and the AMI acknowledged mode is activated such that acknowledgement messages are sent on receipt of any received NG or Xn protocol messages, or the AM2 acknowledged mode is activated and the message received at step 1102 is considered as critical because it belongs to a class-2 procedure or the message received at step 1102 includes a request to acknowledge receipt of the message, the AMF or the NG-RAN node determines that the message is to be acknowledged. At step 1104, in case of the received message has to be or is required or requested to be acknowledged, the AMF or the NG-RAN node sends an acknowledgment message to the remote NG-RAN node or the remote AMF. While the present invention has been described with reference to examples and embodiments, it is to be understood that the invention is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the invention, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used. In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium. By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to nontransient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually 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 a wireless communication system including a network entity, the method at the network entity including:after receiving a first message as part of a signalling procedure of Xn application protocol or NG application protocol, sending a second message acknowledging the network entity has received the first message.

2. The method of claim 1, wherein sending a second message includes, at all times after receiving the first message as part of a signalling procedure of Xn application protocol or NG application protocol, sending a second message acknowledging the network entity has received the first message.

3. The method of claim 1, wherein the first message includes information indicating the network entity is requested to send an acknowledgment of the first message, wherein sending a second message includes sending the second message acknowledging the network entity has received the first message based on the information, included in the first message, indicating the network entity is requested to send an acknowledgment of the first message.

4. The method of claim 1, wherein sending a second message includes, after receiving the first message, sending a second message acknowledging the network entity has received the first message in the case where the network entity is required to send an acknowledgment message.

5. The method of claim 1 or claim 4, wherein sending a second message includes, after receiving the first message, sending a second message acknowledging the network entity has received the first message after determining the network entity is required to send an acknowledgment message.

6. The method of claim 5, further including:determining the network entity is required to send an acknowledgment of the first message in the case where the first message includes information indicating the network entity is requested to send an acknowledgment of the first message.

7. The method of claim 5 or claim 6, further including:determining the network entity is required to send an acknowledgment of the first message in the case where at least one Xn acknowledged mode or NG acknowledged mode is activated at the network entity.

8. The method of claim 7, wherein the at least one Xn acknowledged mode or NG acknowledged mode is one or more of:a first acknowledged mode in which all protocol messages sent as part of a signalling procedure of Xn application protocol or NG application protocol are required to be acknowledged at all times;a second acknowledged mode in which some protocol messages sent as part of a signalling procedure of Xn application protocol or NG application protocol are required to be acknowledged;a third acknowledged mode in which a protocol message sent as part of a signalling procedure of Xn application protocol or NG application protocol is required to be acknowledged when requested by the sender of the protocol message.

9. The method of claim 7 or claim 8, wherein the at least one Xn acknowledged mode or NG acknowledged mode is activated in response to a trigger.

10. The method of claim 9, wherein the trigger includes at least one of:determining, by the network entity, an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity;receiving a message, from another network entity, indicating the at least one Xn acknowledged mode or NG acknowledged mode is to be activated;a priority level of a message to be sent as part of a signalling procedure of Xn application protocol or NG application protocol meets a first threshold.

11. The method of claim 7 or claim 8, further including:sending, by the network entity to another network entity, a message indicating at least one Xn acknowledged mode or NG acknowledged mode is to be activated between the network entity and the other network entity;receiving, at the network entity from the other network entity, a message indicating whether at least one Xn acknowledged mode or NG acknowledged mode is to be activated between the network entity and the other network entity.

12. The method of claim 7 or claim 8, further including:in the case where the network entity determines an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity or in the case where a priority level of a message to be sent as part of a signalling procedure of Xn application protocol or NG application protocol meets a first threshold, sending, by the network entity to another network entity, a message indicating at least one Xn acknowledged mode or NG acknowledged mode is to be activated between the network entity and the other network entity;receiving, at the network entity from the other network entity, a message indicating whether at least one Xn acknowledged mode or NG acknowledged mode is to be activated between the network entity and the other network entity.

13. The method of claim 11 or claim 12, further including:in the case where the message from the other network entity indicates at least one Xn acknowledged mode or NG acknowledged mode is to be activated between the network entity and the other network entity, operating according to the at least one Xn acknowledged mode or NG acknowledged mode indicated in the message received from the other network entity.

14. The method of claim 7 or claim 8, wherein the at least one Xn acknowledged mode or NG acknowledged mode is always activated at the network entity.

15. The method of claim 7 or claim 8, further including: in the case where at least one Xn acknowledged mode or NG acknowledged mode has been activated, deactivating the at least one Xn acknowledged mode or NG acknowledged mode in response to a trigger.

16. The method of claim 15, wherein the trigger includes at least one of:determining, by the network entity, an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity has been resolved;receiving a message, from another network entity, indicating the at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated;a priority level of a message to be sent as part of a NG or Xn protocol procedure meets a second threshold.

17. The method of claim 7 or claim 8, further including:in the case where at least one Xn acknowledged mode or NG acknowledged mode has been activated, sending, by the network entity to another network entity, a message indicating at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated between the network entity and the other network entity;receiving, at the network entity from the other network entity, a message indicating whether at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated.

18. The method of claim 7 or claim 8, further including:in the case where at least one Xn acknowledged mode or NG acknowledged mode has been activated and where the network entity determines an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity has been resolved or where a priority level of a message to be sent as part of a NG or Xn protocol procedure meets a second threshold, sending, by the network entity to another network entity, a message indicating at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated between the network entity and the other network entity;receiving, at the network entity from the other network entity, a message indicating whether at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated.

19. The method of claim 17 or claim 18, further including:in the case where the message from the other network entity indicates at least one Xn acknowledged mode or NG acknowledged mode is to be deactivated, deactivating the at least one Xn acknowledged mode or NG acknowledged mode indicated in the message received from the other network entity.

20. The method of any one of the preceding claims, further including:sending, by the network entity to another network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

21. The method of claim 20, wherein sending, by the network entity, information includes sending, by the network entity to the other network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode after receiving, from the other network entity, information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

22. The method of any one of the claims 1 to 19, further including:receiving, at the network entity from another network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

23. The method of claim 22, wherein receiving, at the network entity, information includes receiving, at the network entity from the other network entity, information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode after sending, by the network entity to the other network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

24. The method of claim 20, claim 21 or claim 23, wherein the information sent by the network entity includes at least one of:information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode;information indicating the network entity is a WAB node in the case where the network entity is a WAB node.

25. The method of claim 21, claim 23 or claim 24, wherein the information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode is sent and the information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode is received when establishing a Xn or NG connection between the network entity and the other network entity.

26. The method of claim 11 or claim 12 or claim 13 or any one of claims 16 to 25, wherein the network entity is a NG-RAN node, wherein the other network entity is one of: a NG-RAN node; and an Access and Mobility Function, AMF, entity.

27. The method of claim 11 or claim 12 or claim 13 or any one of claims 16 to 25, wherein the network entity is an Access and Mobility Function, AMF, entity, wherein the other network entity is a NG-RAN node.

28. The method of any one of the preceding claims, wherein the second message includes at least one of:information associated with the first message;information associated with the second message;identification information for identifying the network entity sending the second message.

29. The method of claim 28, wherein the information associated with each of the first message and second message includes at least one of:information associated with the signalling procedure in which the message is sent;message type information, wherein the message type information for the message is set to a value indicating a type of the message.

30. The method of claim 29, wherein the first message, received at the network entity, includes the information associated with the signalling procedure in which the first message is sent, wherein the second message, sent by the network entity, includes the information associated with the signalling procedure included in the first message.

31. The method of any one of the preceding claims, wherein the network entity is one of:a NG-RAN node;an Access and Mobility Function, AMF, entity.

32. The method of claim 26 or claim 27 or claim 31, wherein the NG-RAN node is one of:a backhaul RAN node;a Wireless Access Backhaul, WAB, node;a gNB component of a WAB node.

33. The method of any one of claims 1 to 30, wherein the network entity is a Wireless Access Backhaul, WAB, node and wherein sending a second message includes, after receiving the first message, via a wireless link, as part of a signalling procedure of Xn application protocol or NG application protocol, sending, by the WAB node, the second message acknowledging the WAB node has received the first message.

34. The method of any one of the preceding claims, wherein sending a second message includes sending the second message acknowledging the network entity has received the first message in the case where the first message is received via a wireless link.

35. A method for use in a wireless communication system including a network entity, the method at the network entity including:sending a first message, to another network entity as part of a signalling procedure of Xn application protocol or NG application protocol;receiving, from the other network entity, a second message acknowledging the other network entity has received the first message.

36. The method of claim 35, wherein the first message includes information indicating the network entity requests an acknowledgment of the first message.

37. The method of claim 36, wherein information indicating the network entity requests an acknowledgment of the first message is included in the first message after a Xn acknowledged mode or NG acknowledged mode, in which a protocol message sent as part of a signalling procedure of Xn application protocol or NG application protocol is required to be acknowledged when requested by the sender of the protocol message, is activated.

38. The method of claim 36 or claim 37, wherein information indicating the network entity requests an acknowledgment of the first message is included in the first message after the network entity determines at least one of:an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity;a priority level of the first message meets a first threshold.

39. The method of claim 37, wherein the Xn acknowledged mode or NG acknowledged mode is activated in response to a trigger or is always activated at the network entity.

40. The method of claim 39, wherein the trigger includes at least one of:determining, by the network entity, an issue on a link for use in communicating Xn or NG protocol messages to or from the network entity;receiving a message, from another network entity, indicating the at least one Xn acknowledged mode or NG acknowledged mode is to be activated;a priority level of a message to be sent as part of a signalling procedure of Xn application protocol or NG application protocol meets a first threshold.

41. The method of any one of the claims 35 to 40, further including:sending, by the network entity to the other network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

42. The method of claim 41, wherein sending, by the network entity, information includes sending, by the network entity to the other network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode after receiving, from the other network entity, information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

43. The method of any one of the claims 35 to 40, further including:receiving, at the network entity from the other network entity, information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

44. The method of claim 43, wherein receiving, at the network entity, information includes receiving, at the network entity from the other network entity, information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode after sending, by the network entity to the other network entity, information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode.

45. The method of any one of claims 42 to 44, wherein the information indicating the network entity supports at least one Xn acknowledged mode or NG acknowledged mode is sent and the information indicating the other network entity supports at least one Xn acknowledged mode or NG acknowledged mode is received when establishing a Xn or NG connection between the network entity and the other network entity.

46. The method of any one of the claims 35 to 45, wherein the second message includes at least one of:information associated with the first message;information associated with the second message;identification information for identifying the other network entity sending the second message.

47. The method of claim 46, wherein the information associated with each of the first message and second message includes at least one of:information associated with the signalling procedure in which the message is sent;message type information, wherein the message type information for the message is set to a value indicating a type of the message.

48. The method of claim 47, wherein the first message, sent by the network entity, includes the information associated with the signalling procedure in which the first message is sent, wherein the second message, received at the network entity, includes the information associated with the signalling procedure included in the first message.

49. The method of any one of claims 35 to 48, wherein the network entity is a NG-RAN node, and the other network entity is one of: a NG-RAN node; and an Access and Mobility Function, AMF, entity.

50. The method of any one of claims 35 to 48, wherein the network entity is Wireless Access Backhaul, WAB, node, and the other network entity is one of: a NG-RAN node; and an Access and Mobility Function, AMF, entity, wherein sending a first message includes, sending the first message, via a wireless link, as part of a signalling procedure of Xn application protocol or NG application protocol.

51. The method of any one of claims 35 to 48, wherein the network entity is an Access and Mobility Function, AMF, entity, and the other network entity is a NG-RAN node.

52. The method of any one of claims 49 to 51, wherein the NG-RAN node is one of:a backhaul RAN node;a Wireless Access Backhaul, WAB, node;a gNB component of a WAB node.

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

54. A computer-readable medium carrying a computer program according to claim 53.

55. An apparatus for a network entity for a wireless communication system, the apparatus comprising:one or more processing units configured to perform the method as recited in any one of claims 5 1 to 52.s

Images