Automatic Path Planning Offloading Mechanism in Edge-Enabled Environments

Abstract

The utilization of edge-enabled cloud computing in unmanned aerial vehicles has facilitated advances in autonomous control by employing computationally intensive algorithms frequently related to traversal among different locations in an environment. A significant problem remains in designing an effective strategy to offload tasks from the edge to the cloud. This work focuses on creating such a strategy by employing a network evaluation method built on the mean opinion score metrics in concoction with machine learning algorithms for path length prediction to assess computational complexity and classification models to perform an offloading decision on the data provided by both network metrics and solution depth prediction. The proposed system is applied to the A* path planning algorithm, and the presented results demonstrate up to 94% accuracy in offloading decisions.

1. Introduction

The recently perceived emergence of unmanned aerial vehicles (UAVs) with diverse modes of transport: on road, in air, and in water, has facilitated their adoption in a variety of applications ranging from freight and human transportation, environment surveillance to rescue operations. The specific applications include biological material delivery [1], human search and rescue operations [2], emergency medicine [3], warehouse operations [4].

Although the discussed deployments might be deemed successful, a plethora of issues still limit the ubiquitous implementation of UAVs. An unmissable constraint of such systems is their computational capability [5]. While algorithms used by vehicles to fulfill their tasks such as simultaneous localization and mapping, motion planning, and path planning tend to be computationally intensive [6,7], the computing power of devices present on-board vehicles is prone to be constrained either by available energy supply or by the physical space demands [8].

To address the limitation mentioned above, several cloud-enabled systems utilizing on-demand and elastic computing resources were created. The utilization of cloud computing resources as they are defined [9] by the National Institute of Standards and Technology (NIST) have the following characteristics:

• On-demand self-service to enable the unilateral provision of services automatically, without the requirement for human interaction;
• Broad-network access allowing access to cloud capabilities through the network while using standard mechanisms;
• Resource pooling resulting in dynamical assignment and reassignment of resources;
• Rapid elasticity leaving capabilities elastically and rapidly provisionable to reflect the computation requirements;
• Measured service.

The utilization of cloud resources has had immediate implications for the field of autonomous unmanned aerial vehicles, of which the major is increased computational power and storage. Therefore tasks can be performed either on-board a vehicle or offloaded to a remote computing environment, resulting in an expeditious solution of complex assignments such as computer vision, object recognition or mapping by employing highly available and expandable computational resources with the possibility of using parallel computation paradigms. Additionally, the rapid elasticity and on-demand self-service without the requirement for human interaction provided the ability to offload tasks dynamically. Lastly, arising from the nature of cloud computing, access to big data generated by UAV systems was facilitated, while the data exchange became more straightforward as a result of broad-network access. Some examples of cloud systems as discussed are Rapyuta [10], serving as a platform for cloud robotics helping in offloading heavy computation from on-board units by provisioning adaptable environments for cloud computation, the C2TAM cloud framework [11] designed for cooperative mapping and the cloud control system for a group of UAVs [12].

Regardless of the undeniable advantages offered by cloud computing utilization, a significant setback remains the requirement for uninterrupted and expeditious network connection, which in real-world applications cannot be granted at all times. Additionally, in the limited set of scenarios where a stable internet connection can be retained, network-induced traffic elicits from data transfer among the UAV. A remote cloud frequently renders cloud-enabled applications unusable due to the unacceptable response time.

These drawbacks led to the employment of edge-enabled UAV applications. Edge computing transfers computational services to closer proximity with an end-user and, therefore, minimizes the application response time. In comparison with the more traditional cloud computing models, where the application runs on a constrained device while the computationally intensive core services and processes are executed in the cloud environment, the edge-enabled application may operate in three models [13]:

• Cloudlet: may be characterized as a collection of computers disposing of stable internet connectivity, having resources located in close proximity for use by mobile devices. Therefore, it can be regarded as a data center suitable for provisioning resources to end devices in real-time over a WLAN/LAN connection;
• Fog computing: Fog computing resembles a decentralized architecture for computing built upon usually heterogeneous computing nodes, which can be located at various points in the system between the end devices and the cloud environment. The heterogeneity is not transparent for the end device and allocates resources in accordance with requirements;
• Mobile edge computing: Mobile edge computing may be defined as a subset of edge-computing technologies used in a manner bringing computational and storage capabilities to the edge of a radio access network such that the network latency is reduced. The nodes in this implementation are located at the same point as the network controller or a base station.

Application of the edge computing technology in the field of autonomous vehicles can be found in visual navigation, and mapping [14,15], or in drone navigation [16]. While the discussed technology suppresses disadvantages present with both cloud computing and on-board computing, offering a solution to computation and storage constraints, increased latency, and requirement for persistent internet connectivity, an issue yet-to-be addressed is an effective task allocation in order to highlight the advantages of edge-enabled systems further. Therefore, a solution must be developed to improve metrics perceivable in UAV arrangements, such as time to solve a task or energy consumption for a task.

In accordance with the described development of the UAV technologies, this paper is concerned with automatic path planning task scheduling between the edge and the cloud environment. The task of path planning itself is performed over an eight-connected grid-map of various sizes and obstacle densities in concoction with a graph-search algorithm A*. The purpose of the proposed system will be the evaluation of the algorithm runtime by the means of machine learning, while simultaneously estimating the data transfer time to and from the cloud environment.

Therefore, in regards to the algorithm evaluation, this system will utilize a strategy allowing to omit efforts in exact algorithm runtime prediction, which is derived from the premise that for the purpose of an efficient path planning task offloading between two environments, that is edge and cloud, it is not necessary to perform such prediction, and a dichotomous classification to identify a more advantageous environment for the computation is sufficient.

In order to allow the classification as described, we investigate the behavior of the A* algorithm in grid maps with varying occupancy rates, that is, a differing number of obstacles present in the map. On the basis of the described identification, the system shall predict the length of a potential path plan between two locations on the map. For the purpose of the path length prediction, we propose a regression model, which the system shall provide with a measurement of the map occupancy rate. The prediction of the solution length is deemed to be particularly important for the estimation of the A* algorithm runtime, as it is described in Section 3.

Furthermore, the utilization of the regression model for path length prediction facilitated the employment of classification models to aid offloading decisions. As we have outlined, the purpose of the classification model is a dichotomous classification between the cloud and the edge environment. In order to perform the classification, the model utilized data acquired prior to its deployment. The dataset was built on the measurements of time required to complete a specific problem in each environment, that is, edge and cloud. After the problem was solved in each environment, solution times were compared, and the faster system was recorded alongside the predicted path length. In addition, the dataset includes a mean opinion score measurement as a reflection of comprehensive network quality estimation, which is vital in the offloading consideration due to the fact that an insufficient network quality may significantly prolong the solution time in the case in which a problem is transferred to the cloud. Therefore, the implemented mean opinion score takes several network metrics into consideration, in particular round trip time, data transfer times and packet drop rates, which are demonstrated in later sections to affect response times from the cloud environment or, eventually, inhibit successful solutions.

The described set of capabilities should enable efficient task distribution with the aid of classification models in order to minimize the application response time to the minimum.

Lastly, the designed system will also be constrained by the efficiency and speed of the implemented algorithms and models, as not to mitigate the effects of the scheduling by the slow evaluation speeds. The requirement for speedy evaluation is essential for successful deployment of time-critical applications where performance, availability, and responsiveness are vital for task completion [17].

Ultimately, in this work, we focus on creating a system that can perform an offloading strategy, which would be adaptable in a variety of edge-cloud environments in regards to their performance. The goal is the creation of methods that would not require an extensive supporting infrastructure; however, they would produce near-optimal offloading decisions.

This paper is separated into several sections. The first section deals with a path planning algorithm and analyzes its performance in the edge and cloud environment. Specifically, algorithm runtimes under differing conditions are analyzed and evaluated. In addition, a regression model is created in this section with the aim of assisting in algorithm behavior prediction.

The second section is concerned with computer network performance measurement and evaluation. A set of metrics is described and measured to test their relation to the offloading mechanism behavior. Subsequently, a method for comprehensive network performance evaluation is proposed.

Consequently, the following part focuses on the utilization of a machine learning and network evaluation system to perform dynamic task offloading among the edge and cloud environment. Hence, a dataset on the basis of the proposed metrics is constructed and supervised machine learning models are defined and trained. Lastly, performance of the designed system is measured and summarized.

2. Related Work

Earlier studies enabling usage of remote computing focused primarily on cloud computing [18,19] mainly in control of unmanned aerial vehicles. However, those systems demonstrated the insufficiency of relying only on cloud computing in real-time. Therefore, several papers focus on latency suppression by designing quality of service-aware [20] and enhanced task assignment among computing environments, especially in collaborative cloud robotics systems [21]. In addition, platforms forming ad hoc cloud computing utilize resources available in other vehicles [22]; however, those resources are sporadically available and unreliable in their nature [23]. For this reason, edge-enabled systems emerged [24,25]. Even though the introduction of edge computing reduced latencies observed in the cloud-only systems and provided available resources to the UAV systems, effective methods to offload some computation tasks from the edge to the cloud had to be established.

Approaches to the edge-cloud computation offloading can be categorized by a stage at which the offloading decision is made—offloading at the design stage or offloading at the runtime stage.

Authors in [26] state that the edge should provide on-demand services, while the cloud should be invoked only when it is necessary. An illustration of system offloading tasks at the design stage can be found in [27], where a simultaneous localization and mapping for indoor mobile robots employ edge–fog–cloud computing architecture designed to segregate tasks among three layers. The lowest layer, called “the robot layer”, collects and forwards data towards the upper layers. Some smart city robotics applications [24] separate computation into the device layer, performing only non-demanding computations, an edge layer regarding edge nodes as a hosting infrastructure and a cloud layer performing intensive computational tasks.

In summary, if the decision to offload tasks to the edge is made at the design stage, a pattern where end devices perform only light tasks, edge devices perform more intensive tasks such as collection and analysis of data [28] or hosting a micro datacenter [29], while cloud invocation is performed only for the most resource-demanding problems, such as big data analysis [30] or data streaming [31].

In contrast to the approach to offload tasks at the design stage, systems performing offloading at the runtime were proposed. Similarities in terms of distribution of tasks among the system’s components by their demands on computational requirements [32] can be observed. Furthermore, some dynamic offloading strategies focus on energy efficiency, trying to minimize energy consumption during task solving [33,34]. Other classes of dynamic offloading approaches in edge-cloud systems are time-concerned offloading strategies [35] and, respectively, both time and energy-concerned strategies [36].

The offloading decision making can be characterized as a multiobjective optimization problem; therefore, methods may be divided into traditional and advanced offloading decisions [37]. Traditional approaches utilize methods of genetic algorithms [38] or the Stackelberg game algorithm [35]. However, they struggle with the heterogeneity of edge-cloud systems; therefore, their adaptation in differing environments may be troublesome [37]. Conversely, advanced techniques address problems perceived in traditional approaches by introducing deep reinforcement learning [39], blockchain [40], federated learning [41] or recurrent neural networks [42]. Advanced methods may produce near-optimal solutions; however, they require a large enabling infrastructure such as blockchain networks or computer grids intended for deep reinforcement learning [37].

Lastly, offloading mechanisms for the purpose of path planning offloading were developed [43]. Those components were separated into two classes—local and remote. The local planning algorithm is the A*, while the remote one is Dijkstra’s algorithm. Primarily, the A* algorithm is used. However, if the system detects a possible improvement in the selected path, the remote planner is invoked. The decision to offload a task is based on the cost made up of two components—proximity of the trajectory to detected obstacles and the curvature of the trajectory, meaning the system accounts for the cost of path traversal. Hence, the decision omits the availability of the processing capacities regarding the concern of memory requirements.

3. Theoretical Background

The offloading strategy from edge to cloud denotes computation transfer from a device limited in resources to a theoretically resource unconstrained cloud environment. However, cloud computing disposes of vast resources, applications utilizing only cloud struggle with latencies, which results from the requirement to transfer data related to a problem over the internet. In contrast, edge devices are located at the network’s edge, closer to the data source. Therefore, latencies posed by data transmission are negligible. The design of offloading strategies and mechanisms is an ongoing research topic, where most work can be split up into two major classes. In the first class, the offloading is secured by the system’s architecture. Therefore, the solution is provided with a crisp definition of tasks to be solved on the edge and cloud, respectively. Such implementation may be beneficial when the application consists of more than one module or component. The second class automates the task division between the two. Most of those systems consider a variety of parameters, seeking to find an effective strategy. In most cases, parameters taken into consideration when the offloading strategy is deemed automatic are application runtime, network performance and device performance. Because algorithms for finding path plans are usually not modular, this work focuses on automated offloading strategies. This section investigates path planning algorithm behavior in terms of runtime on devices with different parameters and network performance analysis and evaluation.

3.1. Path Planning Algorithm Runtime Analysis

As indicated earlier, one of the vital parameters to consider when creating an edge-to-cloud offloading strategy is the algorithm’s runtime deployed in the system. This work uses the A* algorithm as a reference due to its ongoing widespreadness related to its usability in a wide scope of applications such as efficient path planning in self-reconfigurable robots [44], smart home service systems [45], and automated guided vehicles [46,47].

The algorithm can be regarded as a combination of methods of Dijkstra’s search algorithm and heuristic methods such as best-first search used to guide the search, consequently resulting in performance improvement, mainly a reduction in computation time while the algorithm preserves optimality and completeness [48]. A fundamental concept in the discussed algorithm is the evaluation function of the “total cost” containing two parts, defined [49] as follows:

$$f\left(n\right)=g\left(n\right)+h\left(n\right),$$

(1)

where $g\left(n\right)$ is an actual cost of the optimal path from the starting node to the node under consideration n, while the $h\left(n\right)$ resembles the cost from n to a preferred goal node of n.

The heuristic function used in the graph search may significantly affect the algorithm performance [50]. There have been implemented various alterations with varying heuristics in order to reduce time or space complexity [51] and implementations relaxing the admissibility criterion to expedite the process of the path search at the cost of retaining optimality [52]. Further in this work, we employ the Euclidean (straight line) distance as monotonous and admissible in order to retain algorithm optimality:

$$h=\sqrt{{(x_n-x_g)}^2+{(y_n-y_g)}^2},$$

(2)

with $x_n$ and $y_n$ denoting coordinates of an evaluated node, while $x_g$ and $y_g$ indicate end node coordinates. The time complexity of the A* algorithm is defined in terms of the branching factor referring to the average number of successors per state, and the solution depth referring to the shortest possible path as $O\left(b^d\right)$ [53] where b is the branching factor and d is solution depth.

To evaluate the algorithm performance in both edge and cloud environments, we have performed a series of tests on randomly generated finite graphs with non-negative weights. A solution was guaranteed to exist on each graph. The first experiment tested runtime dependence on the solution depth. Therefore, the test measured the time the algorithm required to find a solution on a graph with 25% occupied nodes, that is, nontransferable nodes. The trial had 14 levels of graph order. In addition, each step required the algorithm to find a path on ten differing graphs.

Runtime depending on the solution depth is depicted in Figure 1 both for the edge and cloud environments. Figure 2 illustrates the calculated difference in solution times. It can be observed that while there is a minimal time difference between the edge and the cloud when the found path plan is short, for example, on minuscule maps, the difference is more significant when the solution depth increases.

In pursuance of further comprehension of the path planning algorithm behavior, successive experimental evaluation was performed to examine the relation between the depth of the calculated solution and the rate of cells marked as occupied in the map. On that account, a set of maps with randomly marked occupancy was created. The initial test instance did not contain occupied nodes. Therefore, the occupancy rate was zero. In consecutive test instances, the occupancy rate was increased in steps of 5%. In addition, the final instance of the test reported an occupancy rate of 30%. The limit as mentioned above in the percentage of cells marked as occupied arose from practical limitations of the random map generator in view of the fact that maps with higher rates were no longer reliably created so that there is a viable path between two selected points.

In addition, every step of the test encompassed ten random maps on which the algorithm was required to calculate a solution corresponding to the earlier experiment. The only exception was the stage with no occupied nodes. During every test stage, the algorithm accomplished one hundred path calculations, that is, ten per every map. Measured outputs were subsequently evaluated by median path length calculation separately for each step of the test. Figure 3 provides an illustration of the results. Graphed values present the median length of the calculated solution as multiples of solutions found in the best-case scenario, meaning on the map with no present obstacles, where the solution would be equal to a straight-line path.

3.2. Network Performance Analysis

Following the definition provided in preceding sections, task offloading from an edge device to a cloud can be in general understood as a strategy to transfer computationally expensive tasks from an edge device frequently constrained in resources to a device, or frequently a set of devices, with an abundance of resources to minimize the time of computation required by a specific task.

It can be concluded that task offloading poses a requirement to transfer the data related to the problem [54,55]. By way of illustration, a map for the path plan calculation has to be transferred from the edge to the cloud environment prior to the path planning algorithm initiation. Subsequently, the established solution must be transferred back from the cloud to the edge, which can be later utilized by a vehicle. In consequence of data transfer requirements, an appropriate offloading strategy should evaluate not only a diminution of computation time but also the performance of the network the data is transferred through should be accounted for [56].

The proposed solution will utilize cloud computing resources available to the general public, which connotes the public cloud paradigm [9]. Public cloud computing resources are in general accessed via public internet connections [57]. Performance of such network connection will typically fluctuate in time [58], with dependence on a number of conditions. This includes the number of applications utilizing the connection at a time, resulting in the alternation of the network bandwidth availability and response times from remote network resources. In case the network uses wireless technologies, the transmission speed may be altered by conditions of the environment changing the signal strength [59].

This section investigates possible approaches to the network performance evaluation necessary to determine the functionality of the application. The evaluation is necessary as while the network’s performance may be sufficient for some non-time-sensitive applications transferring only limited amounts of data, it might be deemed unsatisfactory for an industry-based application demanding a real-time control of machines. The system proposed in this work can be regarded as an instance of such industrial application. Therefore, strict requirements on the performance are posed. Additionally, the designed system can be categorized as telemetry due to the collection of measurements and data with their automatic transmission to other remote points. Performance requirements for such are defined [60] as in

Table 1. Network performance requirements for telemetry applications.

Metric	Range
Round trip time	<250 ms
Packet drop rate	0%
Network bandwidth	2 Kbps–50 Mbps

:

The following sections provide further insights on the specific performance requirements and discuss their impact on the network performance and the application functionality.

3.2.1. Round Trip Time

A round trip time (RTT) resembles an essential metric frequently employed to determine the connection’s speed and reliability. The discussed metric represents the amount of time necessary for a signal from one point in the network to reach another point with the addition of time required to acknowledge the signal received. When computer networks are utilized in a solution, a signal whose RTT is measured refers typically to a network packet.

In general, the performance of networked applications increases with reduced RTT [61] by enabling better utilization of a path’s capacity, as illustrated in Figure 4 depicting the response times of a cloud server measured on an edge device. For this measurement, the round trip time was artificially increased by the software Clumsy. The graph demonstrates the increase in response times when the RTT time increased even though the server performance, location, used application and protocol were indifferent.

3.2.2. Packet Drop Rate

Another evaluated metric is the packet drop rate, representing errors that occurred during data transfer [62]. Precisely, packet drop occurs when packets transferred via a computer network fail to reach their intended destination. Loss of packets may occur on a range of occasions if a network resource is busy and can not deliver data, particularly in wireless networks if there is radio frequency inference. As a direct result of said loss being detectable, data transmission will take longer due to the behavior of some communication protocols requiring a network resource re-transmitting packets to deliver uncorrupted data. This statement is supported by Figure 5, showing response times from a cloud server measured on an edge device. Similar to the measurements with the round trip time, package loss was induced by a specialized software named Clumsy. Undeniably, response times increased steeply with the growing percentage of lost packets even though server performance, location, used application and protocol went unaltered.

3.2.3. Data Transfer Time

The last considered metric is the data transfer time signifying the time necessary to transfer data of determining size between two points in the network. The determinate value of said metric can be calculated based on network bandwidth, the maximum rate of data transfer through a given path or based on measured network speed to obtain more accurate results. The calculation is carried out as $T=\frac{I}{R}$ where I refers to data size, while R refers to network speed. Figure 6 depicts measured data transfer times. Further, in this solution, we will use measured network speed to achieve higher accuracy due to defined network bandwidth being typically higher compared to actual speed.

3.3. Metric Evaluation

In the context of computer networks, metrics are quantitative and qualitative means to determine their desired behavior. There are several various metrics of which evaluation is suitable for disparate use cases, some of which are: capacity, jitter, round trip time, packet loss, and bandwidth or availability [63]. Results of monitoring these parameters are affected by a range of factors, which by way of illustration may be the geographical location of communicating points, network configuration, type of used medium, communication protocol, or application using network resources [64]. Subsequent sections elaborate on some of the delineated metrics further.

Several approaches have been developed to evaluate overall network performance. Two generally accepted and prevalent approaches are the quality of service (QoS) and the quality of experience (QoE). While the former is rather a set of individual measurable parameters, such as those we have outlined in earlier sections, which the network equipment monitors and manages [65], the latter is a measurement of how the service is experienced by an end-user [66]. However, some applications may not be sensitive to QoS and QoE. As in control of industrial processes, telemetry is the opposite—an example of a service requiring real-time data streaming performance with an additional characteristic of zero tolerance for informational error and loss. Therefore, QoS requirements are defined tightly. In addition, QoS calculation and enforcement may be difficult to perform in some time-critical applications as its components may be handled by different underlying infrastructures [67]. On the other hand, QoE as a holistic approach focuses on the entirety of the service from the perspective of a user [68]. Even though QoE has been initiated as a subjective metric based on human ratings, there are numerous procedures to gather objective, algorithmic evaluation [69].

4. Offloading Mechanism Design and Implementation

The presented section is aimed at the implementation of the system for offloading strategy utilization as well as on the design of the strategy itself. As a result, the following sections are concerned with designing and deploying the system’s components vital for the strategy deployment. Figure 7 displays the flow of the process in the system. Figure 8 portrays a high-level presentation of the proposed system’s architecture with all of its primary components. Individual parts can be categorized into two primary groups, that is local and remote. The remote group is represented solely by the cloud computing environment and its mechanisms. In contrast, the local group contains both the UAV and the edge server. The proposed separation implies that while the cloud environment will be reachable via the public internet connection, both UAV and the edge server will be interconnected through the wireless local area network.

This separation follows principles described in earlier sections and sustains reliable connectivity between the edge and the UAV. The connection reliability and speediness are crucial due to the deployment of core modules on the edge server. This separation follows principles described in earlier sections and sustains reliable connectivity between the edge and the UAV. The connection reliability and speediness is crucial due to the deployment of core modules on the edge server of which the most important to ensure the basic functionality is the application server the UAV will communicate with in order to create requests for path plan generation and the local instance of the path planning module utilized for path plan generation. In addition, the edge server is responsible for the operation of components required for the offloading strategy realization. Those are components created to monitor and evaluate parameters of the network connection between the edge and the cloud as well as for monitoring of the problem parameters, that is, map occupancy ratio and predicted depth of the solution. Lastly, the classification model for appropriate action determination, whether the problem should be offloaded to the remote cloud environment or solved locally, is deployed in the edge. In contrast, with the edge complexity, the remote part is equipped solely with the path planning module instance.

4.1. Map Monitor

The map monitor as a component provides essential data for the classification system. The primary function of this monitor is the estimation of map occupancy rate, that is, the percentage of nodes in the map that are considered not transferable. That is achieved by iterative browsing throughout the nodes registered in the map and evaluating their state. This information is necessary for the other function, which is a prediction of the path length. Section 3.1 presented the relation of time complexity to the solution depth. In addition, path length in relation to map occupancy was investigated. Therefore, we regard solution depth as one of the viable parameters to automate the decision to offload a task from the edge to the cloud. However, a significant disadvantage of such a parameter is that the solution depth is known only after the algorithm has terminated. In order to address this drawback, we aimed at the construction of a model capable of predicting the depth of the solution prior to the algorithm execution being initiated.

Figure 9 presents the structure of the map monitor module. As illustrated, when a UAV issues a request to find an appropriate path plan, a map is sent to the application server. Consequently, the occupancy counter estimates the occupancy rate in the received map and determines the map size and outputs those data towards the linear regression model. Concerning the data presented in Figure 3, the model is built upon the least squares method:

$$y=\alpha +\beta x,$$

(3)

in which the estimated value $\widehat{\beta }$ is calculated as:

$$\widehat{\beta }=\frac{{\sum }_{i=1}^n(x_i-\overline{x})(y_i-\overline{y})}{{\sum }_{i=1}^n{(x_i-\overline{x})}^2},$$

(4)

and consqeuently, the estimated $\widehat{\alpha }$:

$$\widehat{\alpha }=\overline{y}-\left(\widehat{\beta }\overline{x}\right).$$

(5)

Therefore, after calculating respective values, this model can estimate multiples of the best-case solution, that is, a straight line, between two nodes by having information about the occupancy rate in the map. Hence, the system can predict the final solution length by trivial multiplication of the best-case solution depth.

4.2. MOS Monitor

The presented component is responsible for the monitoring and evaluation of network performance. Combined with the map monitor, it fulfills the role of providing essential information about the problem properties to the offloading strategy. The component structure is presented in Figure 10. It employs three separate elements to measure metrics, namely RTT, transfer speed and packet drop rate, following definitions in Section 3.2. Lastly, the evaluation model calculates the network performance using the mean opinion score (MOS) model to provide a network rating for the classification model.

The mean opinion score is a widely used technique for the network performance evaluation to represent the system’s comprehensive quality. Despite its common utilization of said model in assessing video or audio streams, there is no limitation to those services. The evaluation is based on the singular metrics performance categorization into five classes (5—excellent, 1—bad). According to the performance requirements for telemetry applications presented in Section 3.2, we split values for each metric in a manner delineated in

Table 2. Definition of rating classes for needs of the MOS monitor.

Class	Value	RTT (ms)	Packet Drop (%)	Transfer Speed (Mbps)
Excellent	5	(0; 62)	0	(50; inf)
Good	4	(63; 125)	-	(50; 37.5)
Fair	3	(126; 187)	-	(37.5, 25)
Poor	2	(188; 250)	-	(25; 12.5)
Bad	1	(250; inf)	[1; 100]	(12.5; 0.002)

.

As the network quality evaluation of the system is based on the combination of outlined approaches (see Section 3.2), the system performs continual measurement of three metrics. The continual measurement is employed to avoid the offloading decision withheld due to the time required to assess the performance. However, continual measurement may observe the variance in the acquired results. Therefore, we utilize an exponential smoothing for each metric calculated as follows:

$${\displaystyle s_t=\alpha x_t+(1-\alpha )s_{t-1}=s_{t-1}+\alpha (x_t-s_{t-1}).}$$

(6)

The smoothing factor $\alpha$ is calculated as:

$${\displaystyle \alpha =1-e^{-\Delta T/\tau }};{\displaystyle \tau =-\frac{\Delta T}{ln(1-\alpha )}}.$$

(7)

After smoothing, acquired values are tested whether they belong to a respective interval to assign an appropriate class. Subsequently, the mean opinion score can then be calculated as a simple arithmetic mean:

$${\displaystyle S=\frac{{\sum }_{n=1}^N{V}_n}{N}},$$

(8)

where $V_n$ refers to the value of one of the rating classes described in Table 2, and the resulting scores will facilitate holistic network quality evaluation for the machine learning algorithms implemented in later sections.

4.3. Classification Model

The present section aims to utilize machine learning models for automated task offloading in edge and cloud-enabled systems. At first, a method of data collection employed for the model training is elaborated. Subsequently, we define two machine learning approaches, namely the k-nearest neighbors and the logistic regression model. The two supervised learning models are chosen to compare various methods in the discussed classification task. In addition, the choice of the classification algorithm is based on the premise that for the objective of determining whether a path planning task will be solved in a more time-effective manner in the cloud environment or the edge does not necessarily require attempts at the prediction of the exact algorithm runtime but rather a dichotomous classification, meaning the more edge-effective class and the more cloud-effective class should suffice.

4.3.1. Data Collection

To maintain a diminutive time of computation for not mitigating the potential benefits of the offloading mechanism, this system will utilize an offline learning method to train models. That implies the necessity to secure data collection prior to the training. Hence, a measurement to acquire a dataset viable for the training of both models was set up. Considering that the proposed algorithms shall realize the offloading strategy based on the properties of the map and the network connection between the edge and the cloud, components to evaluate problem parameters had to be involved alongside other components in the system.

Therefore, the dataset collection was carried out by iteratively issuing the simulated UAV requests towards the edge’s application server. Those requests contained randomly generated maps and the required start and endpoints for the path plan. Subsequently, the map monitor had to estimate map occupancy and size and use the regression model for solution depth prediction. Concurrently, the MOS monitor measured and evaluated the properties of the network. Because there could not be any classification model included at this point, every request was routed towards the edge environment and later towards the cloud environment, where path planning modules were eventually invoked.

The dataset illustrated in Figure 11 depicts measurements labeled by the respective class according to the environment, where the solution was provided quicker. At this stage, the response from either environment was awaited, and the earlier one was recorded. In contrast with measurements presented in previous sections, results of this data collection do not reflect only the path planning algorithm runtime, but rather the time response of both systems with underlying configuration and software equipment with a specific implementation, which will likely affect the performance. Therefore, it is imperative to note that results may vary by the technology employed even when the implementation itself remains unaltered, which may signify the requirement to pursue new measurements for each deployment. Additionally, like previous experiments, the software artificially altered the network performance parameters considering there was no practical possibility of capturing variant network states in a timely manner.

4.3.2. Classification Algorithms

As denoted earlier in this section, we have implemented two supervised machine learning algorithms for offloading strategy realization. Following the need for binary classification, we have established a set of labels:

$$y=\left\{0,1\right\},$$

(9)

where $y=0$ denotes the computation shall be executed on edge, whereas $y=1$ means offloading to the cloud.

The first implemented algorithm was the k-nearest neighbors built on the notion that the closest patterns to a concrete pattern for which a label is investigated provide valuable information [70]. Hence, we employed the p-norm as a similarity measure:

$${∥x^{{}^{\prime }}-x_j∥}^p={\left(\sum _{i=1}^q{\left|\left(x_i^{{}^{\prime }}\right)-{\left(x_i\right)}_j\right|}^p\right)}^{\frac{1}{p}},$$

(10)

corresponding to the Euclidean distance in the case when $p=2$. Accordingly, the classifier can be defined as:

$$f_c=\left\{\begin{array}{cc}1;& \sum _{iϵ{\mathit{N}}_K\left({\mathbf{x}}^{{}^{\prime }}\right)}{y}_i\ge 0.5\\ 0;& \sum _{iϵ{\mathit{N}}_K\left({\mathbf{x}}^{{}^{\prime }}\right)}{y}_i<0.5\end{array}\right\},$$

(11)

where K indicates neighborhood size and $N_K\left(x^{{}^{\prime }}\right)$ is the set of indices of k-nearest neighbors [71]. By way of K defining the locality of the classifier, where lower values result in smaller neighborhoods. In order to determine the optimal K value, an experimental evaluation shall be performed to examine the best model accuracy.

The second algorithm tested for the designed solution was the logistic regression classifier estimating the probability of an input belonging to a class. Hence, the output of this classifier can be either 1, signifying a specific sample belongs to a class or 0 when the sample does not belong to a class. Therefore, the primary goal is the probability estimation $P(y=1|x^{{}^{\prime }})$. This task is elucidated by learning a vector of weights and a bias term from the training sample [72]. A weight’s association with an input feature represents its importance for the classification decision. Additionally, the bias term is a real number added to the weighted inputs. In order to make a decision after learning, the model calculates a weighted sum by the formula:

$$z=\left(\sum _{i=1}^n{w}_i{x}_i\right)+b.$$

(12)

The $w_i$ represents individual weights and b is the bias. Because this sum is not guaranteed to result in the interval $[0,1]$, it is subsequently passed to the sigmoid function:

$$\sigma \left(z\right)=\frac{1}{1+e^{-z}}.$$

(13)

Next, we can define probabilities as:

$$\begin{array}{cc}P(y=1)=\sigma z,& \\ P(y=0)=1-\sigma z.\end{array}$$

(14)

Lastly, we can define the classifier function:

$$f_c=\left\{\begin{array}{cc}1;& ifP(y=1|x^{\prime })>0.5\\ 0;& otherwise\end{array}\right\}.$$

(15)

5. Experiments

The presented section provides insight into the performance of the system and its components. The experiments evaluate the monitors and the classification model, with attention given primarily to the prediction and classification. Therefore, a linear regression model is trained and tested for solution depth prediction accuracy as well as both the k-nearest neighbors, and the linear regression models are trained, tuned and evaluated. Lastly, tests to assess the time complexity of the solution were performed.

5.1. Solution Depth Prediction

In Section 4.1, we presented a linear regression model trained by the least-squares method for solution depth prediction based on the map occupancy. The model was trained on the data gathered and presented in Section 3.1, where the dependence of the path length on the map occupancy rate is graphed in Figure 3. Therefore, the model was trained with data acquired from randomly generated square-shaped maps.

The training yielded coefficients $\alpha =0.007$ and $\beta =0.9893$. Therefore, the model can be defined as follows:

$$y=0.007x+0.9893.$$

(16)

Resulting regression is graphed in Figure 12. For the evaluation of the model, we have calculated a set of metrics presented in

Table 3. Evaluation metrics of the linear regression model.

Mean Absolute Error	Mean Squared Error	Coefficient of Determination
0.0065	6.7346	0.98644

.

From the observation of the three metrics presented and from the graphed model, it can be concluded that the model fits the data well and has a high prediction accuracy. Hence, the model is fit to provide predicted data to the classification model for the offloading strategy realization.

5.2. Classification Model Training

The essential component of the designed system is undoubtedly the classification model as a means to make offloading decisions. As it was stated in Section 4.3, we tested two supervised learning models for performance comparison. Both models were trained on the dataset containing 182 entries, as displayed in Section 4.3.1.

The first trained model is the k-nearest neighbour. In order to estimate the best value of K, we have performed a series of experiments incrementally, increasing the value and comparing the model accuracy. The best results on the available dataset were achieved when $K=3$ resulted in 86% accuracy. In contrast, K values of 4 and greater resulted in the worst observed model accuracy of 81%. Therefore, any further implementation and evaluation continued with $K=3$. Further insight into the model performance is depicted in Figure 13.

The second trained model was the linear regression classifier. The training dataset remained identical to the one used for the K-NN training. The resulting accuracy of the model was measured at 94%. Further insight into the model’s accuracy is illustrated in Figure 14, where the confusion matrix is presented. The achieved accuracy is higher with the logistic regression classifier in comparison with the best results of the previously presented K-NN model. Results of the KNN classifier performance with differing k values are presented in Figure 15.

5.3. System’s Time Performance

Another evaluated aspect of the designed system is its time performance. In detail, we evaluate the time the classification models are required to learn on the dataset to determine and examine the time the system is required to make an offloading decision.

Following the prior statement, we have examined the learning times of the models with datasets of various sizes. The datasets contained, similarly to prior experiments, entries with predicted solution depth, measured mean opinion score and information about the environment, in which the problem was solved more expeditiously. Measured learning times for both models are depicted in Figure 16.

It is visible that the logistic regression model requires a significantly longer time to learn. However, it achieves greater accuracy in classification. In addition, the curve for the logistic regression shows a steeper increase compared to the K-NN model. Hence, we can conclude that offline training may significantly improve the time required to make an offloading decision compared to online and especially batch training. On the contrary, online or batch training would be more suitable in combination with the K-NN model.

Subsequently, we have performed a set of measurements to estimate the time the system required to decide whether the problem should be offloaded to the cloud environment or solved on edge to assess whether the system utilization shall not suppress potential benefits of effective problem offloading. To assess the time, we have employed the following formula:

$$TTC=Retrieva{l}_{MOS}+Retrieva{l}_{Occupancy}+Predictio{n}_{Depth}+Classificatio{n}_{Offloading}.$$

(17)

In the formula, the $TTC$ is the time to classification, $Retrieva{l}_{MOS}$ is the time needed to retrieve the latest MOS score, $Retrieva{l}_{Occupancy}$ represents the time the map monitor requires to estimate map occupancy rate, $Predictio{n}_{Depth}$ is the time required to predict solution depth, and finally, $Classificatio{n}_{Offloading}$ is the time either model requires to classify input data. Figure 17 presents measurement results. In accordance with displayed times, the recorded difference between the two classification models was not significant. Subsequently, the measured values did not show significant growth when the side of the map was not greater than 100 cells. With larger maps, however, the time to classify grew steeply. This phenomenon was caused by the operation of the map monitor and its evaluation of occupancy rate. Although the time increases steeply with larger maps, it is important to note that it is where the system shows the most benefit because with maps having smaller sides than 100 cells, the time only to make a decision is almost equal to the time to solve the path planning problem in either environment (see Figure 1).

5.4. Overall Solution Time

In the last evaluation, we have measured differences in the time the system requires to produce a solution, that is, to create a path plan from the moment a request for a path is received. This period, therefore, includes the time required to make an offloading decision, time to potentially offload the problem, as well as path plan generation itself. In order to perform the measurement, we have set up four scenarios:

• Exclusive edge utilization,
• Exclusive cloud utilization,
• Offloading mechanism with KNN classifier,
• Offloading mechanism with an LR classifier.

In addition, maps with side sizes ranging from 10 to 500 cells were generated with random occupancy rates within the constraints of the earlier described map generator. Similarly, MOS values were altered artificially and randomly; however, those were in ranges that were still allowed to reach the cloud. Results are presented in Figure 18.

It can be stated that when the map side size did not exceed 50 cells, it was up to 25.22% faster at 10 cells when the computation was performed only at the edge, and the offloading mechanism was not employed. Consequently, with large maps of a side size of at least 400 cells, the scenario when the only cloud was employed showed a negative time difference up to 6.72%; therefore, employment of only the cloud would yield a path plan faster. In contrast, utilization of the offloading mechanism has shown up to 93.74% saved time with small maps compared to cloud-only deployment and 11.76% in comparison with edge-only employment.

Therefore, differences in solution time are smaller with large maps compared to differences in path plan calculation due to the response time from the cloud.

6. Conclusions

This work has presented a system for automated computation offloading for path planning problems in edge-enabled cloud arrangements to expedite pathfinding for unmanned aerial vehicles. The primary objective is based upon the prediction of time a path planning algorithm will need to solve in either a cloud or edge computing environment. In contrast with some existing deployments, this automated offloading does not try to predict the exact run time for either environment but instead focuses on determining which of the two will enable the more expeditious solution to a planning problem. In order to do so, the system is equipped with monitors responsible for assessing both qualities of the network, critical due to the necessity to transfer data between the edge and cloud and for monitoring the map on which a path has to be found. That is achieved by evaluating map occupancy and size, allowing a regression model to predict the length of a potential path. Information provided by those monitors enables supervised learning classification models to estimate a potentially faster destination for problem-solving while considering computational power and network quality.

The experimental evaluation has demonstrated that such an approach to automated offloading strategies is feasible and may be beneficial in reducing computation time compared to exclusive utilization of the cloud or the edge. However, results have shown that extremal map sizes may have an opposite effect. A possible solution to this problem may be setting the threshold level, which would turn off the offloading mechanism and automatically forward the problem to the appropriate environment. In addition, the experimentation has demonstrated that times required to perform an offloading decision are only up to 60ms with the largest maps, which conclude that the mechanism does not impose great computational effort on the engines.

However, the system was able to make decisions; we perceive several areas for possible improvements. The main limitation of the implemented arrangement is the necessity for offline learning, which requires data collection related to the problem prior to the system employment. That may be a significant limiting factor since recording various network quality states might be time-consuming outside of laboratory conditions. Additionally, a possibility to utilize unsupervised machine learning algorithms should be examined to evade the necessity for data labeling, or an automated labeling system should be considered [73].

An objective comparison of the proposed system to other approaches may be problematic due to the usage of different technologies and offloaded problems. However, in contrast to some other solutions that concern path planning offloading, the proposed system considers computation times, as opposed to energy consumption [43].

However, systems that offload path planning problems have demonstrated up to 80% time saving with offloading decisions performed by using a resource-block based model [74]. Additionally, the proposed solution shows shorter learning times as well as shorter time to make a decision [75]. For the purposes of such comparison, it is essential to note that the resulting time conservation may be skewed by the underlying technology used in the implementation.

Subsequently, the system may be expanded to serve multiple UAVs concurrently, which shall require consideration of additional parameters such as the construction of mechanisms to monitor queues in both environments.

Lastly, any expansion of this approach should be preceded by the system’s optimization, that is, the enhancement of its components, primarily of the map monitor, which is rendered to be the primary speed decelerator by utilization of speedier algorithms and by enhancement of the system as a whole. This can be achieved by exchange of the technology on which the arrangement is deployed and by utilization of concurrent computation paradigms, e.g., using evolutionary computing [76].