Graph neural network (GNN) based method for managing an ad-HOC mobile network

Abstract

The disclosure relates to a method for managing an ad-hoc mobile network. The method comprises obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network. The method comprises predicting a future state of the ad-hoc mobile network using a first GNN. The method comprises optimizing at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

Description

GRAPH NEURAL NETWORK (GNN) BASED METHOD FOR MANAGING AN AD-HOC MOBILE NETWORK TECHNICAL FIELD

[0001] The present disclosure relates to Graph Neural Network (GNN) based solution for efficiently managing the ad-hoc virtual mobile network for message delivery in a telecommunications network. BACKGROUND

[0002] Some of the 3rd Generation Partnership Project (3GPP) Fifth Generation (5G) use cases feature Unmanned Aerial Vehicle (UAV) to perform mission critical tasks. The main use cases include commercial package delivery, static infrastructure inspection, emergency response and indoor inspection and security.

[0003] In the case of an emergency response due to a hazardous material (hazmat) incident, drones might play an important role to provide first responders with aerial views from the area where the hazmat incident has occurred, for increased situational awareness.

[0004] Referring to Figure 1, one example of such incident 100 might be a fuel truck 5 involved in a highway accident that resulted in fuel spillage and / or a localized fire. In such a situation, drones 10 can transmit high quality video as well as data from other sensors. Access to such data can help assess the severity of the incident and optimize resources to be dispatched at the scene. Drones 10 can be deployed quickly and can arrive at the incident scene much faster than ground vehicles. Traffic on the highway may already be blocked or encountering heavy delays, slowing even the arrival of emergency vehicles on the scene. In addition, drones 10 can be deployed much closer to the incident for an initial assessment, without further endangering people.

[0005] If the incident necessitates it, a temporary Non-Public Network (NPN) with one or more low-powered cellular base stations (portable 5G cells) 15 can be placed in the area of the incident to provide connectivity for continuing to assess the situation locally and from the incident command center 20. Portable 5G cells 15 can add capacity and improve coverage when needed.

[0006] As shown in the example of Figure 1, low-powered cellular base stations can be used to enhance the coverage and capacity of wireless networks in areas where traditional cell towers 25 may not be practical or cost-effective. Further, UAVs 10 can be used to carry those low-powered cellular base stations 15 to locations that are difficult to access or where traditional infrastructures are not feasible.

[0007] Turning to Figure 2, and referring to [M. O. Aoueiley, R. Allani, R. Bouallegue and A. Yazidi, “Coverage Strategy for Small-Cell UAV-based networks in IoT Environment”, Journal of Sensor, 2023, Vol.23, pp 8771] UAVs 10 can be deployed by telecommunication service providers to provide aerial network access in remote rural areas, disaster-affected areas, or massive-attendance events.

[0008] An overview of an example UAV deployment for mobile network coverage extension is given in Figure 2. There are two UAV-based Radio Base Station (RBS) 10a and two UAV-based Relays 10b, which manage the connectivity between local devices and mobile operator’s network.

[0009] When those local devices are connected, a local ad-hoc network 200 can be created. One characteristic of this local ad-hoc network 200 is that it is “dynamically changing” due to the mobility of the involved devices 30. If this ad-hoc network 200 is created and managed, some services, such as message delivery, machine learning model deployment service, video streaming, can be realized through the network 200.

[0010] According to [M. Jin, H. Y. Koh, Q. Wen, D. Zambon, C. Alippi, G. Webb, I. King, S. Pan, “A Survey on Graph Neural Networks for Time Series: Forecasting, Classification, Imputation, and Anomaly Detection”, Submitted to Journal of Computer Science, August, 2023], time series are the primary data type used to record dynamic system measurements. Time series analytics can unlock a wealth of information implicit in available data. With recent advancements in Graph Neural Networks (GNNs), there has been a surge in GNN-based approaches for time series analysis. These approaches can explicitly model inter-temporal and inter-variable relationships, which traditional and other deep neural network-based methods struggle to do.

[0011] In Jin, Koh and Wen, a comprehensive review of graph neural networks for time series analysis is provided, which encompasses four fundamental dimensions: forecasting, classification, anomaly detection, and imputation. The forecasting is highlighted since the proposed solution is built on Spatial-Temporal GNN (ST GNNs) based technology for the prediction model, which is taxonomized in Figure 3.

[0012] A unified methodological framework of ST GNNs for time series analysis is provided in Figure 4. Specifically, the framework serves as the basis for encoding time series data for a downstream task – forecasting. As an extension, ST GNNs incorporate spatial information by considering the relationships between nodes in the graph and temporal information by taking into account the evolution of node attributes over time. Similar to [Y. Wang, Y. Pan, K. Wang, C. Liu and S. Jiang “GraphSAGE-LSTM-based deep canonical correlation analysis for batch process monitoring”, 2022 IEEE International Symposium on Advanced Control of Industrial Processes, August 7-9, 2022, Vancouver, BC, Canada], we systematically categorize ST GNNs from three perspectives: spatial module, temporal module, and overall model architecture, as shown in the figure.

[0013] Referring to [G. Jin, Y. Liang, Y. Fang, J. Huang, J. Zhang, and Y. Zheng “Spatio-temporal graph neural networks for predictive learning in urban computing: A survey,” arXiv preprint, vol. abs / 2303.14483, 2023], a multichannel data communication concept was proposed to provide a uniform way to communicate over virtually any type of communications media in such a way that multiple, sometimes parallel communication paths appear as a single robust, secure, and reliable communication link between communicating peers.

[0014] This approach is based on the Distributed Systems intercommunication Protocol (DSiP) [J. Holmstrom, J. Rajamaki and T. Hult, “DSiP Distributed System intercommunication Protocol – A Traffic Engineering Solution for Secure Multichannel Communication”, published in Recent Researches in Coomunications, Electrical & Computer Engineering, Jan, 2011] which handles communication channel selection and hides link establishment issues from devices and / or software that wish to communicate with each other using the DSiP solution. DSiP is simultaneously a protocol-level and routing-level traffic engineering software solution for intelligently handling data routing, using all kinds of physical media, including IP and non-IP communication. It increases the reliability, security and controllability of communication systems being completely independent from operators.

[0015] However, this solution cannot work for the scenarios described in relation with Figure 2, i.e., ad-hoc local network due to coverage extension using a drone. This is because of the device mobility in 5G UAV use cases. For message delivery service in an emergency response case (disaster-affected areas), the traditional hop by hoprouting mechanism cannot be guaranteed to provide reliable and efficient routing paths, which are required by a mission critical application.

[0016] For instance, an UAV changes position from time to time. The truck on the ground in Figure 1 can send a message to its current neighbor, UAV 10, which was far away at the previous time step. Then the UAV 10 carries the message and pass it to the radio base station 25 when it enters mobile network coverage. This use case doesn’t exist in traditional mobile networks.

[0017] [K. Rusek, J. Suarez-Varela, P. Almasan, P. Barlet-Ros and A. Cabellos- Aparico, “RouteNet: leveraging Graph Neural networks for Network Modeling and Optimization in SDN”, arXiv:1910.01508v2, July 2020] proposes RouteNet, a network model based on Graph Neural Network (GNN). It understands the complex relationships between topology, routing, and input traffic to produce accurate estimates of the per-source / destination per-packet delay distribution and loss. The proposed model leverages the ability of GNNs to learn and model graph-structured information and as a result, it can generalize over arbitrary network topologies, routing schemes and traffic intensity. The architecture view of the model is given in Figure 5. The network optimization not only includes the latency but also packet loss requirements.

[0018] As shown in Figure 5, the optimizer first takes the network state as an input. It retrieves the network topology, the traffic matrix and routing paths from the input; and then feed that information into RouteNet to do Key Performance Indicator (KPI) prediction (delay, jitter and packet loss). The optimizer adapts the routing paths and link states in an iterative way to improve the KPI, such as to minimize the delay, jitter and packet loss. Eventually the optimizer provides the efficient routing paths for the given network topology. Input: xp, xl, R Output: ℎ^^^^^^^^, ℎ^^^^^^^^, ^^�^^^^^^1 foreach p ∈ R do ℎ0^^^^← [xp, 0..., 0]; 2 foreach l ∈ N do ℎ^0^^^← [xl, 0…, 0]; 3 for t = 0 to T - 1 do 4 foreach p ∈ R do 5 foreach l ∈ p do 6 ℎ^^^^^^^^← RNNt (ℎ^^^^^^^^ , ℎ^^^^^^^^) 7 ^�^^^^^^^^^^+^,^^^^1← ℎ^^^^^^^^8 end 91014 end 15 ^^�^^^^^^← Fp(hp)

[0019] RouteNet is a GNN based KPI prediction model. Its internal working is described in the above pseudo code. The detail explanation regarding the RouteNet algorithm can be found in the paper referenced above. SUMMARY

[0020] How to build and manage an ad-hoc network among moving objects (UAVs, vehicles, etc.) that support different communication protocols is a challenging problem. This is a new use case in 5G / 5G and beyond (5GB) / sixth generation (6G) networks. To solve this problem, there is provided a computer implemented graph neural network (GNN) based method for managing an ad-hoc mobile network. The method comprises obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network. The method comprises predicting a future state of the ad-hoc mobile network using a first GNN. The method comprises optimizing at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0021] There is provided a network node for managing an ad-hoc mobile network. The network node comprises processing circuits and a memory. The memory contains instructions executable by the processing circuits whereby the network node is operative to obtain a node status for each of a plurality of nodes within the ad-hoc mobile network. The network node is operative to predict a future state of the ad-hoc mobile network using a first GNN. The network node is operative to optimize at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0022] There is provided a non-transitory computer readable media having stored thereon instructions for managing an ad-hoc mobile network. The instructions comprise obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network. The instructions comprise predicting a future state of the ad-hoc mobile network using a first GNN. The instructions comprise optimizing at least oneservice running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0023] The method, network node and non-transitory computer readable media provided herein present improvements to the way ad-hoc mobile networks operate. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic illustration of an example emergency response to road incidence, taken from [P. Burks, P. C. Tse, A. Chen, I. Cheorghisor, J. Khan, E. Ringer, R. Sengupta, A. Takacs, C. Werner and M. Williamson “Open Generation Uncrewed Aircraft Systems (UAS) Use cases”.2022].

[0025] Figure 2 is a schematic illustration of an example extension of mobile network coverage using UAV.

[0026] Figure 3 is a graph of a methodology-oriented taxonomy of GNNs for time series analysis, taken from [M. Jin, H. Y. Koh, Q. Wen, D. Zambon, C. Alippi, G. Webb, I. King, S. Pan, “A Survey on Graph Neural Networks for Time Series: Forecasting, Classification, Imputation, and Anomaly Detection”, Submitted to Journal of Computer Science, August 2023].

[0027] Figure 4 is a block diagram showing a general pipeline for time series analysis using GNN, taken from [G. Jin, Y. Liang, Y. Fang, J. Huang, J. Zhang, and Y. Zheng “Spatio-temporal graph neural networks for predictive learning in urban computing: A survey,” arXiv preprint, vol. abs / 2303.14483, 2023].

[0028] Figure 5 is a block diagram of the architecture of the RouteNet proposed in [K. Rusek, J. Suarez-Varela, P. Almasan, P. Barlet-Ros and A. Cabellos-Aparico, “RouteNet: levraging Graph Neural networks for Network Modeling and Optimization in SDN”, arXiv:1910.01508v2, July 2020].

[0029] Figure 6 is a schematic illustration of the network connectivity within an ad- hoc virtual mobile network using different communication protocols.

[0030] Figure 7 is a block diagram showing network connectivity using different communication protocols.

[0031] Figure 8 is a flowchart of GNN based ad-hoc virtual mobile network (AVMN) prediction and routing path building for message delivery.

[0032] Figure 9 is a schematic illustration of the mapping of an ad-hoc network into a local network representation with node features.

[0033] Figure 10 is another schematic illustration of the mapping of an ad-hoc network into local network representation with node features, in relation with GNN layers.

[0034] Figure 11 is a sequence diagram of AVMN management.

[0035] Figure 12 is a flowchart of a mechanism for AVMN creation of business logics in management system (MS)-AVMN.

[0036] Figure 13 is a flowchart of a mechanism for connectivity report generation of business logics in client / collection agent (CA)-AVMN.

[0037] Figure 14 is a flowchart of the prediction of the AVMN state at next time step using the trained spatial temporal (ST) GNNs.

[0038] Figure 15 is a sequence diagram of message delivery via the AVMN.

[0039] Figure 16 is a flow diagram showing an example of GNN based routing path building model.

[0040] Figure 17 is a flowchart of a mechanism for message delivery of business logics in CA-AVMN.

[0041] Figure 18 is a flowchart of a method for managing an ad-hoc mobile network.

[0042] Figure 19 is a schematic illustration of a hardware in which steps and / or method described herein can be executed.

[0043] Figure 20 is a schematic illustration of a virtualization environment in which the different steps and hardware components described herein can be deployed. DETAILED DESCRIPTION

[0044] Various features will now be described with reference to the drawings to fully convey the scope of the disclosure to those skilled in the art.

[0045] Sequences of actions or functions may be used within this disclosure. It should be recognized that some functions or actions, in some contexts, could be performed by specialized circuits, by program instructions being executed by one or more processors, or by a combination of both.

[0046] Further, computer readable carrier or carrier wave may contain an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

[0047] The functions / actions described herein may occur out of the order noted in the sequence of actions or simultaneously. Furthermore, in some illustrations, someblocks, functions or actions may be optional and may or may not be executed; these are generally illustrated with dashed lines.

[0048] At least some aspects of the techniques described herein may be implemented using artificial intelligence, which comprises a variety of techniques as would be apparent to a person skilled in the art, including machine learning techniques. Machine learning techniques include deep learning and Neural Network (NN), or Artificial Neural Network (ANN). Both NN and ANN may be used interchangeably herein. In some contexts, an Artificial Neural Network could include biological portions.

[0049] Further, looking forward, in a virtual world (e.g., the metaverse, digital twins, etc.), the techniques described herein could be applied in relevant virtual scenarios.

[0050] Referring to Figure 6, mobile phones, cars, trucks 30 and two drones 10a are provided within a boundary 605. Among those moving devices 30, different communication protocols can be used to exchange information.

[0051] As long as device connectivity exists, it is possible to create an ad-hoc mobile network, which in some instances could include virtual portions and could be called ad-hoc virtual mobile network (AVMN), on top of these moving devices. Naturally, this AVMN changes dynamically since this ad-hoc network depends on the position and trajectory of the moving devices 30. The AVMN is built based on different communication protocols in the devices, such as Wi-Fi, Bluetooth, etc. As long as two devices are equipped with the same communication protocol / interface, the connectivity between those devices can be set up.

[0052] Some devices can be equipped with multiple communication protocols and can “translate” and relay information to, from and between incompatible devices.

[0053] Neighboring nodes are first identified / selected based on their physical distance according to given criteria, such as a radius around the node. The criteria might include other factors, such as security or privacy related measurements. Then, the common communication interface / protocol on the devices are verified for network connectivity.

[0054] In contrast with traditional message / packet routing mechanisms, the proposed solution is a data-driven approach. It builds a model to predict a future state of the AVMN based on the current state, by applying spatial temporal (ST) GNNs to historical datasets. Based on the real AVMN (built from the measurement) and the predicted AVMN (created by the GNN based on the prediction model), the routingpath can be optimized for each message delivery. The detailed description of the proposed solution is discussed hereafter.

[0055] The solution described herein builds an ad-hoc virtual mobile network (AVMN), or more generally an ad-hoc mobile network, using the information collected from the moving or fixed objects present in an area. This is managed and operated by the central management system deployed in the cloud or in an operator network.

[0056] The management system is able to determine, or get information concerning, the communication protocols supported by the managed objects in the area, build a representation of the connectivity between those managed objects through the identified communication protocol, and eventually create the AVMN.

[0057] A GNN is used to capture the network topology and node connectivity for this AVMN. The Spatial-Temporal (ST) GNN model, referring to [Jin, Koh, and Wen], is selected to be trained based on historical data. Then, the state of the AVMN at next time step is obtained by applying this trained ST GNNs model to the data collected at the previous time steps.

[0058] With both current and predicted AVMN states, the system implements a proactive way for the message delivery. For instance, the system is able to find the most efficient way to move a message from a current node to a target node based on their relative positions at two different time steps.

[0059] The management system operates the AVMN using a dynamic controlling mechanism, which relies on the mobility information of the objects, e.g., the location and trajectory of the managed object.

[0060] The advantages of the proposed solution include to provide efficient message delivery service in 5G / 5GB / 6G use case scenarios, especially in emergency cases, where the extension of the mobility coverage is required for mission critical applications in the region. The solution provides dynamic selection of communication protocol / interface to help maintaining stable capacity. The solution allows minimizing routing overhead: the topology is decided by the management system. Due to mobility within the network, bad routes are not generated in the routing table, avoiding unnecessary routing overhead. The solution limits hidden terminal problems, meaning collision of packets due to simultaneous transmission due to nodes not in the direct transmission range of the sender, but with the transmission range of the receiver. The solution is low cost and easy to build because it is not relying on infrastructure andthere are no installation costs. The solution provides decentralization and robustness: nodes can be used to multi-hop messages to the destination node. If one node exits the network the system is not affected.

[0061] Turning to Figure 7, a single node 30-1 has two communication protocols, one is Device to Device Communication Protocol (D2DCP) for UAV 40 and the other is D2DCP for vehicle 45. The node 30-1 applies D2DCP for Vehicle 45 to communicate with TruckA 30-2a and TruckB 30-2b respectively. The node also applies D2DCP for UAV 40 to communicate with the flying object 10, which may be a drone.

[0062] In the example, different D2DCP protocols are present in the same node. The overhead of those protocols might be different to meet different performance criteria. By nature, those difference contributes to the “heterogenous characteristics” in the communication protocol.

[0063] Referring to Figure 8, the left side illustrates the business logics 801 to predict the AVMN status at the next time step based on the AVMN statuses in the past, using the trained ST GNNs model; and the right side shows the logic flow 810 to build the routing path in a proactive way using two consecutive AVMNs graph representation (node features).

[0064] A graphSAGE with LSTM is an example of ST GNNs that can be used for AVMN prediction. RouteNet can be modified and applied for routing the message in the AVMN.

[0065] It should be noted that while the methods described herein refer mainly to a single ad-hoc mobile network, a plurality of AVMNs can run in parallel on the same hardware / network nodes. A network provider could for example provide two or more virtual ad-hoc networks to different clients, for similar or different purposes. These AVMN can provide different services and different types of services.

[0066] The GNN-based ad-hoc virtual mobile network (AVMN) prediction logics 801, on the left side of Figure 8, starts by collecting all the needed information, including node statuses for one AVMN, step 802. An example of such information is presented in the box, further down, showing the example definition of the managed object / node. Such information can include information about: node name and identifier, current time, central processing unit or graphic processing unit status, capacity and usage, memory status, capacity and usage, mobility including location, speed and direction, power status and power consumption including battery capacity,usage, charging status and capacity for remote charging, cooling apparatus status, power consumption and temperature, interface, neighbors, message status, etc. Then, the AVMNs are updated, step 803, based on given criteria, such as distance, protocol, connection quality of service (QoS), etc. Then a graph representation is prepared for use as input to the trained GNN (the spatial temporal model of the AVMN) at the current time t=tk, step 804. The trained GNN is then used, step 805, to predict the AVMNs at the next time stamp / step (t=tk+1). Both graph representations of the real AVMN (at t=tk) and predicted AVMN (t=tk+1) are stored in storage 808, step 806. A check is made to see if all AVMN have been processed, step 807 and if yes, the prediction logic ends, if not, the next AVMN is processed.

[0067] The AVMN proactive routing path building logics 810, on the right side of Figure 8, starts by retrieving from storage 808, all the graph representations of real AVMNs (at t=tk) and predicted AVMNs (t=tk+1), step 811. The nodes for ingress messages and for egress messages are found in the real AVMN, step 812. This information can be obtained from messages exchanged between nodes, which include a message source and destination. An encoding for the GNN is prepared, step 813, based on a key performance indicators (KPI) prediction model, which predicts network topology, routing paths, message traffic, etc.). The GNN based KPI prediction model is then applied, step 814. This GNN can use the same or a similar architecture as the other GNN described previously, it can have the same number of layers but it could have a different number of layers. At the time of writing this specification, two layers are preferred, but based on future capacities and optimisations, the number of layers should not be a limitation. The data used for training this second GNN for KPI prediction is the not same as the data used to train the first GNN. At step 815, there is a check if the objective requirements (latency, energy consumption, etc.) are fulfilled. If yes, the routing information is sent to all the nodes within the AVMN, step 816. If not, the routing policy is adjusted and the constraints of the predicted AVMN are checked, step 817.

[0068] The GNN-based graph network representation for AVMNs is described next.

[0069] Referring to Figure 9 one AVMN (and its node components: cell phones, UAV-based RBS and Vehicles) is mapped into a graph network representation 910. Each node in the network (elements labeled: UEn, Truckn, Carn, UAVnin Figure 9) has five node features: mobility, powerStatus, neighbors, messageStatus and interfaces. The definition of these node features will be given further down. Thesenode features can be encoded into a node vector or tokenized as given in the following equation. hu= {mobility, powerStatus, neighbors, messageStatus, interfaces}

[0070] Turning to figure 10, by following the GNN architecture referring to [Jin, Koh and Wen], the feature vector or token representation at each node (corresponding to the nodes on the right side of Figure 9) of the GNN layer is passed to the aggregation layer (GNN-layer 2) (neighbors of the nodes in the 1stlayer), which does a weighted average over its neighbor nodes and add the sum on top of its own value if the vanilla GNN is considered. The non-linearity of the network system is captured via an activation function, e.g. ReLU, or signed, etc., which is applied after aggregation of the neighbour nodes. Through the aggregation, the network topology / connectivity is captured in the node representation.

[0071] Below is the embedding generation algorithm of graphSAGE, taken from [W. L. Hamilton, R. Ying and J. Leskovec, “Inductive representation Learning on Large Graphs”, 31st Conference on Neural Information Processing System (NIPS 2017), Long beach, CA, USA], which can be used to generate the feature vector or token representation for each node within the network. Algorithm 1: GraphSAGE embedding generation (i.e., forward propagation) algorithm Input: Graph ^^^^(^^^^, ℰ); input features {x^^^^, ∀^^^^ ∈ ^^^^}; depth K; weight matricesWk, ∀k ∈ {1, …, K}; non-linearity σ; differentiable aggregator functions AGGREGATEk, ∀k ∈ {1, …, K}; neighborhood function ^^^^ : ^^^^ → 2^^^^Output: Vector representations z^^^^ for all ^^^^ ∈ ^^^^ 1 ℎv0← x^^^^, ∀^^^^ ∈ ^^^^; 2 for k = 1…K do

[0072] When the above algorithm is used for AVMN, to keep the network topology, a concatenation operation is used to merge the node feature and its neighbor features after the aggregation, as shown in the algorithm. The inter-temporal relationship is then considered by applying Recurrent Neural Network (RNN), Long Short-Term Memory (LSTM), or transformer on those token representation at node level. AgraphSAGE and LSTM is one of those ST GNNs. At a specific time, t = t0, the graphSAGE (GNN) can be used to generate a token for each node since the network topology / connectivity is considered to be stationary. The same procedure can be repeated to generate a set of node token representations within the network at timestamp from t = t1 to t = tk. The “historical token representations” can be used to predict a “token representation” at t = tk+1using an RNN / LSTM / transformer. In summary, the algorithm starts with the spatial processing, then, later on integrates with temporal processing. The detailed description of this method can be found in [Y. Wang, Y. Pan, K. Wang, C. Liu and S. Jiang “GraphSAGE-LSTM-based deep canonical correlation analysis for batch process monitoring”, 2022 IEEE International Symposium on Advanced Control of Industrial Processes, August 7-9, 2022, Vancouver, BC, Canada].

[0073] The interface and neighbor definition for the managed objects are provided next.

[0074] To build an ad-hoc mobile network, two kinds of information on each managed object are needed: the interface(s) available at each managed object and a list of neighbors of the managed object. The definition on the interface and neighbor lists are given below.

[0075] Next is an example definition of interface and neighbor lists. interfaces: [ { interface_name: "…", ip_address: "", subnet: "", / *for a local fixed / virtual network* / mac_address: "", access_point: "", state: "", interface_medium: "Wifi", / * Wifi, Bluetooth, d2dcp4UAV, d2dcp4V, etc... * / , interface_max_bandwidth: 0 } ] neighbors: [ / * A list of neighbor nodes * / { nodeName: "neighbor_1" interface_name: "neighbor_flex_interface", interface_medium: "d2dcp", interface_max_bandwidth: 20, / *Gbps* / access_point: "neighbor_1_access_address", security_key_token: "accessToken", connectivity_status: "active", / *active|inactive* / connectivity_QoS: { packetLossRate_pct: 5, / *pct (percentage) %* / packetRetransRate_pct: 1, / *pct (percentage) %* / RTT: 10 / *millisecond* / } } ]

[0076] In the neighbor list, for each neighbor node (managed object), the protocol information, access information and connectivity information (status and QoS) can be provided. The information can be used by a management system for AVMN (MS- AVMN) 1120 (see Figure 11) to create a new AVMN or modify the exist one. Both “interfaces” and “neighbors” lists are included in “node”, as indicated below.

[0077] Next is an example definition of the managed object / node. node: { node_name: "", node_id: 1234, current-time: CURRENT-TIME-GMT, cpu-status:[{ cpu-capacity: "", cpu-usage-pct: 20 } ], / *list for multiple CPUs* / gpu-status:[{ gpu-capacity: "", gpu-usage-pct: 10 } ], / *list for multiple GPUs* / memory-status: {memory-capacity:"", memory-usage-pct:20}, mobility: { location: { latitude: 40.741895, longitude: -73.989308 } speed: { velocity: 20 direction: { vector-x:0.4243,vector- y:0.5657, vector-z: 0.7071 } powerStatus: {power-supplier-type: "Battery", / * Battery|portableBattery|Grid* / power-capacity: "", power-usage-pct: 20, power-charging-mode: "remote", / * local|remote|configurable * / power-charging-time-full-capacity: 600 / *seconds* / } fanStatus: { power-consumption-pct: 10, device-temperature: 30 / * degree * / } interfaces : [], neighbors : [], messageStatus: { msg-size: "", msg-deadline: "", msg-src: "", msg-dest: ""} }

[0078] The client / collection agent for AVMN (CA-AVMN) 1110 (see Figure 11) at device side sends the node information to the MS-AVMN 1120. The MS-AVMN 1120 retrieves the information under “mobility” and verifies the connectivity between the managed nodes to see if a link is still valid for the AVMN at next time slot.

[0079] The service calls for managing and AVMN are presented next, in relation with Figure 11 which presents the two main components from an architecture standpoint: the client / collection agent for AVMN (CA-AVMN) 1110, and the management system for AVMN (MS-AVMN) 1120.

[0080] The service calls 1101 between CA-AVMN and MS-AVMN are related to service discovery (here, searching for AVMN service) and registration, and go both directions. This follows a common approach, such as Domain Name System or Service (DNS) look up, to locate AVMN services provided by the network operator. Then registration is done according to a standard procedure, of which the steps are not repeated here for simplicity.

[0081] Calls 1102 are used to send the node status report: the CA-AVMN 1110 collects and builds the node information according to the format provided in figure 5 and the accompanying algorithm included in the background section; then send the node status report to the MS-AVMN 1120. Based on the received information, the MS-AVMN applies the business logics to create an ad-hoc virtual mobile network.

[0082] After the AVMN is created, the neighbor nodes are added into the node information, which can be pulled by CA-AVMN or sent by MS-AVMN based on the registration or subscription, referring to the third calls flow 1103.

[0083] Each node (managed object) within the AVMN collects and updates node information, especially for the connectivity towards neighboring nodes. Then the CA- AVMN 1110 sends the connectivity report to the MS-AVMN 1120 about these neighbor nodes (connectivity status and connectivity QoS) referring to calls 1104.

[0084] Call flows 1105 and 1106 are used to retrieve and provide updates on the information for a node, its status, and information on its interfaces and its neighbors. The delta on the update can be provided instead of whole update in order to save costs or reduce energy consumption.

[0085] Examples of those service call APIs for AVMN management are given below. Send the node status report PUT / avmn / management / node-status-report?nodeId=NODE-ID • This call sends the node information that includes INTERFACE, in which the current neighbor nodes are present. Retrieve the current / update neighbor nodes GET / avmn / management / neighbor-nodes?nodeId=NODE-ID• This call gets the update on neighbor node list from the management system. Those nodes can not be seen from the client device itself. Send the connectivity report PUT / avmn / management / neighbor-connectivity- report?nodeId=NODE-ID • This call sends the connectivity report (connectivity_status, connectivity_QoS) from the client device to the management system.

[0086] Figure 12 presents the business logic flow at MS-AVMN for AVMN management.

[0087] For a given period, the MS-AVMN retrieves all the nodes for a covering area for a given period, step 1201, based on node location and node moving trajectory, including speed and direction. MS-AVMN selects, step 1202, the nodes within the covering area using the policy given based on the node position at next time slot (e.g., distance centric approach). The covering area is defined according to the points of interest configured by the AVMN service provider based on the consumer’s requests.

[0088] Then the MS-AVMN loops, step 1203, over all the selected nodes to find their neighbor nodes according to criteria based on the physical distance as well as the communication protocol shared by two nodes, step 1204. Both the location and the trajectory of the managed objects within the AVMN should be considered for neighbor selection.

[0089] There is a second loop, step 1205, in which the MS-AVMN checks, step 1206 the connectivity and records the interface media, access point and access token for interface in the node. When the last node has been checked, i.e., the “neighbor searching” process is completed, step 1207, the MS-AVMN removes the isolated nodes that do not have any neighbor nodes, i.e., these nodes are filtered out, step 1208 and builds and saves the virtual ad-hoc networks, step 1209.

[0090] Figure 13 shows the business logic flow at client side (CA-AVMN) for AVMN management. The objective of this business logic is to do a validation of the connectivity towards neighbor nodes provided by MS-AVMN. After the connectivity is validated “success” (in term of status and QoS), the corresponding network link in AVMN is confirmed.

[0091] At step 1301, the CA-AVMN retrieves the interface from the received message. The CA-AVMN loops over all the neighbor nodes in the interface, step 1302. The CA-AVMN connects the neighbor nodes using the given interface mediaand access information, step 1303. The CA-AVMN updates the connectivity report for interface (connectivity status and connectivity QoS), step 1304. The CA-AVMN checks if this is the last neighbor node, step 1305 and if it is, builds a neighbor node connectivity report, step 1306 and sends, step 1307, the node status report to the controller (MS-AVMN).

[0092] Referring to Figure 14, AVMN prediction using ST GNNs model is presented. The algorithm shows how to apply the trained ST GNNs model to predict AVMN at next time step. The model accuracy is measured by calculating the similarity score between real measurement of AVMN that is collected from field (t=tk) and the predicted AVMN (t=tk) using the trained ST GNNs. If the similarity score indicates a problem with the prediction model, an alarm or notification is raised, and the ST GNNs can be retrained. The algorithm presented in figure 14 is a variation on the GNN-based AVMN prediction logics 801 that was previously described.

[0093] The MS-AVMN loops over all the AVMNs in the system, step 1401. The MS- AVMN picks one AVMN and retrieves the network information and nodes statuses, step 1402. The MS-AVMN builds, step 1403, the network graph representation (real AVMN) using the node status and the network topology information according to the trained ST GNNs model (t=tk). The MS-AVMN applies the trained ST GNNs model to predict the AVMN state at next time step (t=tk+1), step 1404. The MS-AVMN retrieves the predicted AVMN state the current time step (t=tk), step 1405, and calculates the difference between the ream AVMN state and predicted AVMN state at time t=tk, step 1406. If the difference is under a given threshold corresponding to a given criteria, step 1407, the MS-AVMN stores the predicted AVMN state at t=tk+1, step 1409, and the verifies if this was the last AVMN, step 1410. If the difference is above the threshold, step 1407, the MS-AVMN raises an alarm and / or sends a notification concerning the ST GNNs, step 1408.

[0094] Figure 15 shows the service calls for message delivery via AVMN.

[0095] After the ad-hoc virtual mobile network is created, the MS-AVMN 1120 can provide the service through the network. One of these services is “message delivery”, which aims at moving a message from one node to the other in an efficient way.

[0096] The first two service calls 1501 and 1502 are related to service discovery and response, respectively, to search for the message delivery service provided by the MS- AVMN 1120. Then, at the device side, the CA-AVMN 1110 sends the message status 1503 to the MS-AVMN 1120. An acknowledgement message is sent in call 1504.Based on the collected information (message status, node status, AVMN status), which may be obtained through a request for routing instructions for message delivery, 1505, the MS-AVMN schedule the message delivery plan for the next time slot. The MS-AVMN responds, 1506, with the latest routing instructions.

[0097] Each managed device in the AVMN can query the MS-AVMN to get routing instructions to move messages from one node to the other. An example of routing instruction is provided below. dynamicRouting: [ { routingRuleId: 1234, timePeriod: {startTime: START-TIME-GMT, endTime: END- TIME-GMT}, routingRules: [ { conditions: { msgMaxSize: MAX-MSG-SIZE, / * MegaByte * / msgdeliveryPriority: LEVEL, / * LEVEL=0,1,2,…10 * / msgResidingTime: 2000 / * seconds * / }, dispatching: { egressNodeList: [ { nodeName: "neighbor_1" interface_name: "neighbor_flex_interface", interface_medium: "wifi", / * wifi, bluetooth, d2dcp4UAV, d2dcp4V, etc... * / interface_max_bandwidth: NUMBER-MBPS, / *Mbps or Gbps * / access_point: "neighbor_1_access_address", security_key_opaque: "stringToken", connectivity_status: "Active|inActive", connectivity_QoS: { packetLossRate_pct: 5, / * pct (percentage) % * / packetRetransRate_pct: 1, / * pct (percentage) % * / RTT: 10 / *millisecond* / } ], nodeSelection: "roundrobin" / *roundrobin|random|first* / } } } ] } ]

[0098] As shown in the above example, “dynamicRouting” contains a list of routing instructions, each of which having a time period to be applied. In other words, the MS-AVMN is able to send multiple routing instructions across different time periods, either continuously or not.

[0099] Each routing instruction also contains one or multiple routingRules that have “conditions” and “dispatching” for moving the message. In “egressNodeList”, it provides a list of neighbor nodes, from which the destination is selected. The CA- AVMN sends those qualified messages to the selected node according to the “conditions”.

[0100] At the end of “dispatching”, nodeSelection provides the mechanism for how the neighbor nodes should be picked for delivering the message. For instance, nodeSelection=“first” means that the first node in the list should always be picked.

[0101] The example service calls that will be described hereafter refer to the example of service call APIs provided below. In the payload of the 200 OK response, “dynamicRouting” refers to the code for dynamic routing provided above.

[0102] Example of service call APIs: • Request for routing instructions - GET / avmn / messagedivery / routing / msgdeliveryschedule? nodeId=NODE-ID - This call gets the routing instructions from the management system. • Response (200 OK) - 200 OK with the “dynamicRouting”

[0103] Referring again to Figures 16 and 8, and more specifically to the right part of Figure 8, 810, a proactive Routing Path Building logics (Routing decision flow at MS-AVMN for message delivery) is presented. First, the system, i.e., the MS- AVMN, retrieves both real AVMN at current time step and predicted AVMN at the next time step, 811. Based on the collected information, the system locates the edge nodes which communicate either with other AVMN or backbone mobile network. Among those nodes, the system filters out these nodes (logical entity) responsible for ingress messages and the others for egress messages, 812.

[0104] Once that is done, the GNN based Routing Path Optimization model can be built by the MS-AVMN, 813. The inputs for the model are: 1. Real AVMN at t=tk: 2. Predicted AVMN at t=tk+13. A list of egress nodes (logical entity) 4. A list of ingress nodes (logical entity)

[0105] The objective of the optimizer 1601 is to minimize the overall latency or the total energy consumption for message delivery within AVMN.1,2, … ^^^^, ^^^^ = 0, 1, … ^^^^(^^^^^^^^^^^^^^^^^^^^^^^^+1)}where is the measurements on the latency on each message delivery, ^^^^(^^^^) is number of the message to be delivered on the node i. N is the total number of nodes in AVMN, ^^^^^^^^is the measurement of energy consumption on the node (e.g., CPU load, etc.), β a weight coefficient for balancing the focus of the objective function, where β=0 if the focus is made on “energy consumption”, and β=1 if the focus is made on “latency”. In the equation, ^^^^ contains the actions allowed for message delivery for all the nodes, which are constrained by the predicted AVMN status (t=tk+1).

[0106] The GNN based KPI prediction model 1602 is applied, 814 and a routing path policy is obtained.

[0107] The routing path policy at each node can be adjusted, 817, to meet the objective, 815, by searching the actions in the policy space given above. An example of policy, which includes an action for each node, is provided here: 1. send the message to one of the reachable nodes, or 2. hold the message. The number of possible actions is equal to the number of reachable other nodes plus one for holding the message. Then all those possible actions at each node that form the action space can be searched by the algorithm. The policy contains all the action selected for each message at each node. The policy can change, such that at a given time slot K, the policy can contain all the actions picked for each message at different nodes.

[0108] The final output of the routing path policy is sent, 816, to each node as a routing instruction to move the message in AVMN. The reference model published in [8] can be used as a base to build this GNN based Routing Path building model.

[0109] Figure 17 illustrates the business logic flow at CA-AVMN for message delivery. The CA-AVMN receives, step 1701, routing instructions from the MS- AVMN. The MS-AVMN might be implemented in either edge cloud or central cloud, while, for mission critical scenarios, the MS-AVMN can be implemented as rApp / xApp in SMO, in an O-RAN implementation. The CA-AVMN retrieves and validates the routing information, step 1702. The CA-AVMN compares, step 1703,the newly received routing information with the current one. If there are no differences, 1704, the CA-AVMN updates the current routing rules, step 1705. Or, if there are differences, 1704, the CA-AVMN sends an acknowledgement to the management system, step 1706.

[0110] Turning to Figure 18, there is provided a computer implemented graph neural network (GNN) based method 1800 for managing an ad-hoc mobile network. The method comprises obtaining, step 1805, a node status for each of a plurality of nodes within the ad-hoc mobile network. The method comprises predicting, step 1810, a future state of the ad-hoc mobile network using a first GNN. The method comprises optimizing, step 1812, at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0111] The method may further comprise, before obtaining a node status: discovering, step 1801, the plurality of nodes within a given telecommunication range, obtaining, step 1802, the node status for each of the plurality of nodes, obtaining, step 1803, a list of neighbor nodes for each of the plurality of nodes and creating, step 1804, the ad-hoc mobile network including the nodes and at least a portion of the neighbor nodes.

[0112] The method may further comprise obtaining, step 1806, a time sequence of node status for each of the plurality of nodes within the ad-hoc mobile network, generating, step 1807, a sequence of graphs of the ad-hoc mobile network, one graph for each time of the time sequence and training, step 1808, the first GNN, using the sequence of graphs. It should be noted that token representation is one way to present the graphs, but other ways could also be used.

[0113] The node status may comprise any one or more of: a node status, one or more interface type, one or more interface capability, one of more communication protocol, a connection quality of service for the one or more interface, an absolute or relative location or position, a moving direction of trajectory, central processing unit, memory and available battery information, and distances from neighbor nodes.

[0114] The method may further comprise generating, step 1809, a graph of the ad-hoc mobile network for use as input to the first GNN.

[0115] The first GNN may comprise two layers, a first layer comprising a first group of nodes of which all messages are aggregated in a single node, and a second layer comprising a second group of nodes of which the messages are aggregated in neighboring nodes of the first group of nodes. Although two layers is the defaultsettings from the common practice in literature, there is no such limitation, and any number of layers, such as 3, 4, 5, or more can be used if the network is large and there is enough available computational power.

[0116] Predicting the future state of the ad-hoc mobile network using the first GNN may further comprise using, step 1811, a combination of the first GNN and a Recurrent Neural Network (RNN), Long Short-Term Memory (LSTM), or transformer, wherein the graph of the first GNN is tokenized and used as input to the RNN, LSTM or transformer to predict the future state of the ad-hoc mobile network.

[0117] The at least one service may comprise a message delivery or relay service, a data pipeline service, an object detection service, an artificial intelligence (AI) / machine learning (ML) model deployment service or a video streaming service.

[0118] When the service is a message delivery or relay service, optimizing the at least one service may comprise: computing, step 1813, message routing paths, using a current state and the future state of the ad-hoc mobile network and obtaining, step 1814, a routing path policy, based on the message routing paths, using a second GNN, for routing messages within the ad-hoc mobile network. The routing path policy may take different forms, and one form is to have one routing path policy per network nodes. In other implementations there could be one routing path policy, with conditions or rules, for many network nodes.

[0119] The routing path policy may take into account any one or more of: interface compatibility of the nodes, communication protocol compatibility of the nodes, physical distances and moving trajectory of the nodes, latency between the nodes, central processing unit, memory and available battery of the nodes.

[0120] The second GNN may be trained using key performance indicators data of the plurality of nodes within the ad-hoc mobile network.

[0121] The layout of the second GNN may comprise a single layer layout or may be the same as the layout of the first GNN.

[0122] When the service is a deployment service for an AI / ML model, optimizing the at least one service may comprise identifying data sources for the AI / ML model and building a data pipeline for the AI / ML model and selecting a node to deploy the AI / ML model, based on the data sources and data pipeline, using a second GNN.

[0123] The steps for deployment service for an AI / ML model may include collecting the data sources and AVMN information, selecting a node to deploy thetrained AI / ML model, build the data pipeline for the AI / ML model, notifying the data source and users, pulling the data from the data sources, applying the AI / ML model for inference / prediction / anomaly detection, etc. and sending the outcome of the trained AI / ML model to users / applications.

[0124] When the service is a video streaming service, optimizing the at least one service may comprise identifying clients to be served and selecting one or more nodes to act as streaming servers, based on the clients to be served, using a second GNN.

[0125] The steps for video streaming service may include collecting the clients to be served and AVMN information, selecting the origin server for video streaming, selecting one or several nodes as “streaming servers”, notifying the clients, and the clients streaming the video using those selected nodes.

[0126] The ad-hoc mobile network may be a virtual mobile network and multiple ad-hoc virtual mobile networks may be running on top of the plurality of nodes and run different services.

[0127] The first GNN may be a pre-learned large GNN model.

[0128] It should be noted that methods and steps described herein are, generally, computer implemented methods and steps. The term computer may be interpreted as having different meanings, such as explained next, for example.

[0129] Referring to Figure 19, there is provided a network node (HW) 1901 and 10, 30 (referring to Figure 6), in which functions and steps described herein can be implemented.

[0130] The network node 1901, 10, 30 (which may go beyond what is illustrated in Figure 19), may be a user device, such as a smartphone, a tablet, a computer, a wearable such as a watch or glasses, a connected vehicle, including but not limited to a bicycle, a car, a truck, a plane, a drone, a boat or any other flying or floating vehicle, etc.

[0131] The network node 1901 may be a server, a radio base station, or any other computing device which may be part of a cloud computing system, edge computing system, or which may be a standalone device.

[0132] The network nodes act, in combination, and form an ad-hoc mobile network in which messages can be sent in situation where the conventional communication network fails or are otherwise lacking. The method for managing the ad-hoc mobile network gets and monitors statuses of the network nodes (which canmove, fail, etc.) within the ad-hoc mobile network, predicts a future state of the ad- hoc mobile network using a GNN and continuously optimizes at least one service running on the ad-hoc mobile network accordingly.

[0133] The network node 1901 comprises processing circuitry 1903 and memory 1905. The memory 1905 can contain instructions executable by the processing circuitry 1903 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein.

[0134] The network node 1901 may also include non-transitory, persistent, machine-readable storage media 1907 having stored therein software and / or instruction 1909 executable by the processing circuitry 1903 to execute functions and steps described herein. The network node may also include network interface(s) and a power source.

[0135] The instructions 1909 may include a computer program for configuring the processing circuitry 1903. The computer program may be stored in a physical memory local to the device, which can be removable, or it could alternatively, or in part, be stored in the cloud. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0136] Referring to Figure 20, there is provided a virtualization environment 2000 in which functions and steps described herein can be implemented.

[0137] The virtualization environment 2000 (which may go beyond what is illustrated in Figure 20), may comprise systems, networks, servers, nodes, devices, etc., that are in communication with each other either through wire or wirelessly, e.g., through a network interface component (NIC) comprising physical network interface(s). Some or all of the functions and steps described herein may be implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, containers, etc.) executing on one or more physical apparatus in one or more networks, systems, environment, etc.

[0138] A virtualization environment provides hardware 2001 comprising processing circuitry 2003 and memory 2005. The memory 2005 can contain instructions executable by the processing circuitry 2003 whereby functions and steps described herein may be executed to provide any of the relevant features and benefits disclosed herein.

[0139] The hardware 2001 may also include non-transitory, persistent, machine-readable storage media 2007 having stored therein software and / or instruction 2009 executable by the processing circuitry 2003 to execute functions and steps described herein.

[0140] The instructions 2009 may include a computer program for configuring the processing circuitry 2003. The computer program may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program may be stored in a physical memory local to the hardware 2001, which can be removable, or it could alternatively, or in part, be stored in the cloud. The computer program may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0141] Referring again to Figures 19 and 20, there is provided a network node 1901, 2001, 10, 30 comprising processing circuits 1903, 2003 and a memory 1905, 2005. The memory contains instructions executable by the processing circuits whereby the network node is operative to receive a routing path policy obtained according to the corresponding steps described previously.

[0142] Still referring to Figures 19 and 20, there is provided a network node 1901, 2001, 10, 30 for managing an ad-hoc mobile network comprising processing circuits and a memory. The memory contains instructions executable by the processing circuits whereby the network node is operative to obtain a node status for each of a plurality of nodes within the ad-hoc mobile network. The network node is operative to predict a future state of the ad-hoc mobile network using a first GNN. The network node is operative to optimize at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0143] The instructions may comprise further instructions for executing any of the steps described herein.

[0144] Still referring to Figures 19 and 20, there is provided a non-transitory computer readable media 1907, 2007 having stored thereon instructions 1909, 2009 for managing an ad-hoc mobile network. The instructions comprise obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network. The instructions comprise predicting a future state of the ad-hoc mobile network using a first GNN. The instructions comprise optimizing at least one service running on thead-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

[0145] The non-transitory computer readable media 1907, 2007 may comprise further instructions 1909, 2009 to execute any of the steps described herein.

[0146] Modifications will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that modifications, such as specific forms other than those described above, are intended to be included within the scope of this disclosure. The previous description is merely illustrative and should not be considered restrictive in any way. The scope sought is given by the appended claims, rather than the preceding description, and all variations and equivalents that fall within the range of the claims are intended to be embraced therein. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMS 1. A computer implemented graph neural network (GNN) based method for managing an ad-hoc mobile network, comprising: - obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network; - predicting a future state of the ad-hoc mobile network using a first GNN; and - optimizing at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

2. The method of claim 1, further comprising, before obtaining a node status: - discovering the plurality of nodes within a given telecommunication range; - obtaining the node status for each of the plurality of nodes; - obtaining a list of neighbor nodes for each of the plurality of nodes; and - creating the ad-hoc mobile network including the nodes and at least a portion of the neighbor nodes.

3. The method of any one of the preceding claims, further comprising: - obtaining a time sequence of node status for each of the plurality of nodes within the ad-hoc mobile network; - generating a sequence of graphs of the ad-hoc mobile network, one graph for each time of the time sequence; and - training the first GNN, using the sequence of graphs.

4. The method of any one of the previous claims, wherein the node status comprises any one or more of: a node status, one or more interface type, one or more interface capability, one of more communication protocol, a connection quality of service for the one or more interface, an absolute or relative location or position, a moving direction of trajectory, central processing unit, memory and available battery information, and distances from neighbor nodes.

5. The method of any one of the preceding claims, further comprising generating a graph of the ad-hoc mobile network for use as input to the first GNN.

6. The method of any one of the preceding claims, wherein the first GNN has two layers, a first layer comprising a first group of nodes of which all messages are aggregated in a single node, and a second layer comprising a second group of nodes of which the messages are aggregated in neighboring nodes of the first group of nodes.

7. The method of any one of the preceding claims, wherein predicting the future state of the ad-hoc mobile network using the first GNN further comprises using a combination of the first GNN and a Recurrent Neural Network (RNN), Long Short-Term Memory (LSTM), or transformer, wherein the graph of the first GNN is tokenized and used as input to the RNN, LSTM or transformer to predict the future state of the ad-hoc mobile network.

8. The method of any one of the preceding claims, wherein the at least one service comprises a message delivery or relay service, a data pipeline service, an object detection service, an artificial intelligence (AI) / machine learning (ML) model deployment service or a video streaming service.

9. The method of any one of the preceding claims, wherein, when the service is a message delivery or relay service, optimizing the at least one service comprises: - computing message routing paths, using a current state and the future state of the ad-hoc mobile network; and - obtaining a routing path policy, based on the message routing paths, using a second GNN, for routing messages within the ad-hoc mobile network.

10. The method of claim 9 wherein the routing path policy takes into account any one or more of: interface compatibility of the nodes, communication protocol compatibility of the nodes, physical distances and moving trajectory of the nodes, latency between the nodes, central processing unit, memory and available battery of the nodes.

11. The method of claim 9, wherein the second GNN is trained using key performance indicators data of the plurality of nodes within the ad-hoc mobile network.

12. The method of claim 9, when dependent on claim 6, wherein the layout of the second GNN comprises a single layer layout or is the same as the layout of the first GNN.

13. The method of any one of the preceding claims, wherein, when the service is a deployment service for an AI / ML model, optimizing the at least one service comprises: - identifying data sources for the AI / ML model and building a data pipeline for the AI / ML model; and - selecting a node to deploy the AI / ML model, based on the data sources and data pipeline, using a second GNN.

14. The method of any one of the preceding claims, wherein, when the service is a video streaming service, optimizing the at least one service comprises: - identifying clients to be served; and - selecting one or more nodes to act as streaming servers, based on the clients to be served, using a second GNN.

15. The method of claim 1, wherein the ad-hoc mobile network is a virtual mobile network and wherein multiple ad-hoc virtual mobile networks are running on top of the plurality of nodes and run different services.

16. The method of claim 1, wherein the first GNN is a pre-learned large GNN model.

17. A network node comprising processing circuits and a memory, the memory containing instructions executable by the processing circuits whereby the network node is operative to receive a routing path policy obtained according to claim 9.

18. A network node for managing an ad-hoc mobile network comprising processing circuits and a memory, the memory containing instructions executable by the processing circuits whereby the network node is operative to:- obtain a node status for each of a plurality of nodes within the ad-hoc mobile network; - predict a future state of the ad-hoc mobile network using a first GNN; and - optimize at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

19. The network node of claim 19, further operative to execute any one of the steps of claims 2 to 16.

20. A non-transitory computer readable media having stored thereon instructions for managing an ad-hoc mobile network, the instructions comprising: - obtaining a node status for each of a plurality of nodes within the ad-hoc mobile network; - predicting a future state of the ad-hoc mobile network using a first GNN; and - optimizing at least one service running on the ad-hoc mobile network based on the predicted future state of the ad-hoc mobile network.

21. The non-transitory computer readable media of claim 18, wherein the instructions further comprise any one of the steps of claims 2 to 16.

Images