Planning Integrated Unmanned Aerial Vehicle and Conventional Vehicle Delivery Operations under Restricted Airspace: A Mixed Nested Genetic Algorithm and Geographic Information System-Assisted Optimization Approach

Using Unmanned Aerial Vehicles (UAVs), commonly referred to as “drones”, as a supplementary mode for last-mile deliveries has been a research focus for some years now. Motivation lies in the reduced dependency on Conventional Vehicles (CVs) and fossil fuels and in serving remote areas and underprivileged populations. We are building a flexible, modular framework for integrated CV-UAV parcel delivery operations planning that is responsive to infrastructure and demand and offers an open and practical tool for future adaptations. The entire model and solution methodology are practical tools for decision making and strategic planning, with novelties such as the variable Launch Site types for Launch and Recovery Operations (LAROs), the tailored Assignment and Routing Optimization nested GA, the consideration of airspace restrictions of any shape and size, the inclusion of GIS tools in the process, the modularity of the platform, and most importantly, the inclusion of all the above in a single, comprehensive, and holistic approach. Because of the need for safe UAV deployment sites and the high presence of restricted airspace zones in urban environments, the intended field of application is assumed to be the delivery of small packages in rural and under-connected areas, the execution of inter-city deliveries, and the expansion of a city’s original service range. A single CV is equipped onboard with UAVs, while special locations, such as Remote Depots (RDs) with UAVs and Virtual Hubs (VHs) for UAV deployment facilitation, are introduced. The framework considers the presence of Restricted Zones (RZs) for UAV flights. Part of the methodology is implemented in a GIS environment, taking advantage of modern tools for spatial analysis and optimal path planning. We have designed a tailored nested GA method for solving the occurring mode assignment and vehicle routing optimization problems and have implemented our workflow on a devised case study with benchmark characteristics. Our model responds well to unfavorable network types and demand locations, while the presence of RZs notably affects the expected solution and should be considered in the decision-making process.


Introduction
The transformation of the transport sector is a pivotal part of efforts towards a sustainable future, especially in cities. The EU has set ambitious targets for 2020-2030, aiming for a reduction of 40% of GHGs relative to 1990 levels and a share of 35% of zero-or low-emission new cars and vans by 2030 [1]. A 100% zero-emission fleet is envisioned in cities by 2050, and several countries are set to ban internal combustion engines in urban areas by 2032 [2]. In another context, rapid consumer behavioral changes have led to a significant increase in online shopping and at-home and at-work deliveries. Delivery services rely heavily on conventional vehicles running on fossil fuels, such as delivery trucks or vans, and this is 2 [47], Tangent Bug [48,49], using a tangent visibility graph and then employing Dijkstra among possible paths [50], the Artificial Potential Field [51], and others.
Much of the existing research focuses on optimization methodologies and theoretical system setups for best performance; however, there is little consideration for real-world constraints and daily transportation challenges and their applicability in a true decisionmaking process. We want to design a system where both infrastructure and transport vehicles play an active role in the delivery process. Also, the variety of options should allow for adaptation to available infrastructure, equipment, and demand, leading to scalable operations and informed decision-making strategies. The CV can reach destinations within the CV network for in-person deliveries but is also equipped with UAVs for aerial ones. Throughout the network, predefined locations for possible UAV deployment, named Virtual Hubs (VHs), are introduced; these could be open spaces, parking lots, rest areas, etc., implying minimal to moderate infrastructure investments. Some of the Delivery Locations (DLs) may also serve as pop-up UAV deployment sites if conditions allow. In both cases, the CV must wait for deployed UAVs to return before leaving for the rest of its route. We are additionally introducing the concept of Remote Depots (RDs), with in-house available UAVs for transshipment. There, the CV can unload items, and the RD personnel assume payload preparation and UAV deployment, unleashing the CV immediately. This implies heavier investment in infrastructure, possibly justified at locations where local demand is often significant, or the CV network is insufficient. The way we structure the problem, the CV is not required to travel through all network nodes or edges; the assignment and routing solution will determine the mandatory nodes and then the actual CV route each time. A deconstructed version of the original CV network is produced, consisting of only mandatory nodes with action(s) and shell edges resulting from the shortest paths between said nodes. This approach extends the problem definition and sets a solution methodology for reallife operations, where the initial physical network is a given and the nodes to visit are different every time. Also, UAV paths do not follow a straight line but are estimated based on imposed no-fly zones, infrastructure setup, and demand. Blending the methodology with GIS allows the integration of common file types in network analysis and airspace restrictions and the use of modern tools for spatial analysis and optimal path planning. To obtain an optimal solution, we elaborate a tailored nested genetic algorithm scheme where each mode assignment iteration (outer GA) is associated with an optimal routing (inner GA), and then the best assignment option is chosen. The framework requires basic input, demand, and supply data, and it can address variable network types, conditions, and infrastructure, unleashing the potential for further adaptations.
Summing up our contribution, several aspects of our method can individually be seen as novel, but mostly when regarded as a holistic approach that includes all of them: -We are proposing a mix of variable launch sites for LARO, featuring different characteristics among them. Customer locations can be used for CV-based UAV deployment, if local conditions allow (space, safety, airspace restrictions, customer approval, etc.). Virtual Hubs, for example, open spaces, parking lots, etc., can also be used for CVbased LARO. In both of those cases, the CV must wait for all its UAVs to return. UAVs can also be deployed from the Central Depot at the start, without any CV involvement, but also at the end, receiving items from the CV. Remote Depots are another facility type where the CV can leave items for UAV delivery, and LARO is performed by the depot personnel. Not all LARO locations are necessarily used. -Deliveries can be made both by CV and UAV. - The CV network is available for routing and LARO, but not all nodes and links are necessarily used. We distinguish the mandatory nodes for actions and routing after the assignment process, creating the so-called "shell network". This allows for our model to be practically implemented with different demands and infrastructure each time. -The Assignment and Routing Optimization nested GA is developed specifically for our problem, with its two steps being interconnected and using different methods for the inner and outer GA (discrete values resulting from the service nodes for the assignment process and random keys-based ordering of nodes for routing). -We have considered the presence of Restricted Zones of any shape and size and adjusted our model to filter out non-reachable locations, either because they are in such zones or because the resulting UAV paths are longer than the UAV range allows. -We are adjusting the model, incorporating spatial and optimal path analysis with GIS as part of the methodology, and opening to modern methods and input norms. - The formulation is conveniently simplified but unique to its kind since it must address the specific setup. It creates a modular and open platform that is open to modifications, and we present all the analytical calculations involved. This also helps with strategic planning, e.g., deciding where to establish Remote Depots or Virtual Hubs, by conveniently testing alternative locations. - The consideration of all the above in a single proposed method, in a comprehensive and holistic approach.

General Problem Description
Several items must be delivered from a Central Depot (CD) to customers at Delivery Locations (DLs). CVs travel through a fixed network, whereas UAVs are more flexible, although they are obliged to navigate around potential no-fly zones. The CV is not limited by its operational range and is expected to be able to complete the entire journey without refueling or charging. The UAVs are assumed to be electric, with battery capacity and energy consumption performance defining their maximum range. A battery swap is executed at the start of operations or during the UAV preparation at each site when the same UAV is used again. Each item is assigned to a mode for the final stretch or the entirety of the journey.
In our setup, UAVs can be launched or recovered at allowed locations throughout the network; these locations are not limited to the DLs or the CD, but additional Virtual Hubs (VHs) for convenient CV layover and in situ UAV deployment, and Remote Depots (RDs) with adequate UAVs are also available. When UAVs are deployed from the CD or the RDs, the CV does not have to wait for the UAVs to return. However, at RDs, a certain service time for item delivery is implied before the depot's personnel assume the package mounting and UAV deployment activities. At any other location where UAVs are mass-deployed from the CV, the latter must wait for the last UAV to return. Under the given network and introduced demand and restrictions, the goal is to find the best combination of item assignment and CV routing in terms of the total time to complete operations. A simplified illustration of this setup is presented in the following figures (Figures 1-3).

-
The Assignment and Routing Optimization nested GA is developed specifically for our problem, with its two steps being interconnected and using different methods for the inner and outer GA (discrete values resulting from the service nodes for the assignment process and random keys-based ordering of nodes for routing). -We have considered the presence of Restricted Zones of any shape and size and adjusted our model to filter out non-reachable locations, either because they are in such zones or because the resulting UAV paths are longer than the UAV range allows. -We are adjusting the model, incorporating spatial and optimal path analysis with GIS as part of the methodology, and opening to modern methods and input norms. - The formulation is conveniently simplified but unique to its kind since it must address the specific setup. It creates a modular and open platform that is open to modifications, and we present all the analytical calculations involved. This also helps with strategic planning, e.g., deciding where to establish Remote Depots or Virtual Hubs, by conveniently testing alternative locations. - The consideration of all the above in a single proposed method, in a comprehensive and holistic approach.

General Problem Description
Several items must be delivered from a Central Depot (CD) to customers at Delivery Locations (DLs). CVs travel through a fixed network, whereas UAVs are more flexible, although they are obliged to navigate around potential no-fly zones. The CV is not limited by its operational range and is expected to be able to complete the entire journey without refueling or charging. The UAVs are assumed to be electric, with battery capacity and energy consumption performance defining their maximum range. A battery swap is executed at the start of operations or during the UAV preparation at each site when the same UAV is used again. Each item is assigned to a mode for the final stretch or the entirety of the journey.
In our setup, UAVs can be launched or recovered at allowed locations throughout the network; these locations are not limited to the DLs or the CD, but additional Virtual Hubs (VHs) for convenient CV layover and in situ UAV deployment, and Remote Depots (RDs) with adequate UAVs are also available. When UAVs are deployed from the CD or the RDs, the CV does not have to wait for the UAVs to return. However, at RDs, a certain service time for item delivery is implied before the depot's personnel assume the package mounting and UAV deployment activities. At any other location where UAVs are massdeployed from the CV, the latter must wait for the last UAV to return. Under the given network and introduced demand and restrictions, the goal is to find the best combination of item assignment and CV routing in terms of the total time to complete operations. A simplified illustration of this setup is presented in the following figures (Figures 1-3).

Assumptions and Constraints
Apart from the general description, certain assumptions and constraints need to be set to accurately describe the proposed delivery system:

•
A single CV is available, departing from the Central Depot and attempting to deliver the items to their destinations.

•
The CV is assumed to have adequate capacity for the items, and any UAVs may be needed onboard.

•
Vertical Take-off and Landing (VTOL) UAVs are selected.

•
Each destination can be visited once for delivery or UAV deployment (or both during the same stop) but can be accessed more than once for routing purposes.

Assumptions and Constraints
Apart from the general description, certain assumptions and constraints need to be set to accurately describe the proposed delivery system:

•
A single CV is available, departing from the Central Depot and attempting to deliver the items to their destinations.

•
The CV is assumed to have adequate capacity for the items, and any UAVs may be needed onboard.

•
Vertical Take-off and Landing (VTOL) UAVs are selected.

•
Each destination can be visited once for delivery or UAV deployment (or both during the same stop) but can be accessed more than once for routing purposes.

Assumptions and Constraints
Apart from the general description, certain assumptions and constraints need to be set to accurately describe the proposed delivery system:

•
A single CV is available, departing from the Central Depot and attempting to deliver the items to their destinations.

•
The CV is assumed to have adequate capacity for the items, and any UAVs may be needed onboard.

•
Vertical Take-off and Landing (VTOL) UAVs are selected.
• Each destination can be visited once for delivery or UAV deployment (or both during the same stop) but can be accessed more than once for routing purposes.

•
There is no predefined mode assignment for the items, but there is an option to force one if needed.

•
There is no predefined order of visits for the destinations, but there is the option to force one if needed.

•
The CD is the start and end node for the conventional vehicle tour.
We also assume the following: • Each item is assigned to one vehicle (CV or UAV) for the final step of delivery.

•
The CV can be assigned to multiple destinations. • Each UAV has the capacity for one item. • Each UAV can travel to and return from one destination per tour (the same UAV can be later re-deployed, but we have assumed enough UAVs for all operations anyway). • UAVs can be deployed as a fleet from a single station.

•
The launch of all UAVs from a launch site is simultaneous, but each one returns at a different time depending on the length of its tour. • A UAV is recovered at the same location where it was launched.

•
Remote Depots can deploy UAVs without the CV having to wait for their return. A certain amount of transshipment time is still required.

•
The CD, used at the start of operations, can deploy UAVs without the CV having to wait, and no transshipment time is required. • Only one transfer between vehicles is allowed per item.
We are proposing a framework that extends from inputs to analysis to solution methodology. Figure 4 below summarizes said framework and workflow until the final solution.

PEER REVIEW 7
• Each item is assigned to one vehicle (CV or UAV) for the final step of delivery.

•
The CV can be assigned to multiple destinations.

•
Each UAV has the capacity for one item.

•
Each UAV can travel to and return from one destination per tour (the same UAV can be later re-deployed, but we have assumed enough UAVs for all operations anyway).

•
UAVs can be deployed as a fleet from a single station.

•
The launch of all UAVs from a launch site is simultaneous, but each one returns at a different time depending on the length of its tour. • A UAV is recovered at the same location where it was launched.

•
Remote Depots can deploy UAVs without the CV having to wait for their return. A certain amount of transshipment time is still required.

•
The CD, used at the start of operations, can deploy UAVs without the CV having to wait, and no transshipment time is required.

•
Only one transfer between vehicles is allowed per item.
We are proposing a framework that extends from inputs to analysis to solution methodology. Figure 4 below summarizes said framework and workflow until the final solution.  Basic information on the physical network acts as initial input (Conventional Vehicle Network, CVN), the infrastructure (Central Depot (CD), Remote Depot (RD), Virtual Hub (VH)), as well as equipment specifications (CV and UAV operational characteristics). Then certain locations (Delivery Locations (DLs)) represent demand for item deliveries.
Preliminary analysis defines which sites are finally allowed for UAV deployment (Launch Sites (LSs), among CD, RDs, VHs, and some of the DLs) and which pairs of DLs and LSs are within the maximum UAV range (straight flight path) of each other (DL l LS,max , LS i DL,max ). For the above pairs, actual optimal paths around RZs are estimated, and UAV-feasible connections are again filtered based on the UAV's range. Each item is then associated with potential service nodes (Service Nodes Pool (SN k )). A service node for an item may be its own DL node (if within the CVN) or any allowed LS that is reachable by UAV. Analysis "a2" offers an alternative way to perform the assignment later (task T1). Instead of assigning items based on their Service Nodes Pool, we could inversely use the DL LS l sets of the launch sites. This would be helpful if we were to base our assignment on clustering strategies.
To obtain the optimal solution, we are setting up a nested two-level optimization process, seeking the optimal assignment of items to a service node (l k ) and optimal CV routing. Each time an assignment iteration is produced, a set of mandatory nodes (T v M ) for visit emerges. At each of these nodes, waiting times (wt i ) for the CV are calculated based on the actions required (e.g., in-person delivery, UAV launch and recovery, items delivered to an RD for UAV deployment by the personnel). The shortest paths (Ŝ ij ) between mandatory nodes are calculated using the given CVN and a new "shell" network is created. The shell network is constructed by a subset of mandatory nodes and the travel costs between them. Routing for the CV is then a matter of selecting the best order of visits (Ŝ M ij ) across mandatory nodes. (In our case study experiments, we have opted to use the nested GA with a custom gene structure for tasks T1, T2, and an A* algorithm for the shortest path analysis s2.) The target is to minimize Global Operations Time (GOT), the time needed for all vehicles (CV and deployed UAVs) to complete their tasks and return to their intended base.

Mathematical Formulation
We introduce a series of notations and variables, shown in Table 1.

Variables
x CD i : Binary variable (0,1) indicating node type "Central Depot" x RD i : Binary variable (0,1) indicating node type "Remote Depot" x VH i : Binary variable (0,1) indicating node type "Virtual Hub" x DL i : Binary variable (0,1) indicating node type "Delivery Location" x LS i : Binary variable (0,1) indicating node type "Launch Site" L CV ij : Length of CVN edge ft ij : UAV flight time at cruising altitude L UAV ij : Length of UAV edge, at cruising altitude tta: Time to ascend (take-off to cruising altitude) ttd: Time to descend (cruising altitude to landing) tft ij : Total UAV airtime from take-off to landing x UAV ij : binary variable (0,1) for the existence of direct UAV connection (in range), j ∈ V, i = j xd CV i : binary variable (0,1) indicating final delivery with CV |L l |: number of items assigned to launch site dth ij : time for UAV deployment-to-home wt i : waiting time of CV on node x CRD i : binary variable (0,1) indicating whether a node is either type of depots ct M ij : cost (time) for shortest path between two mandatory nodes xa i : binary variable for access of node by CV u f ij : binary variable for edge traveled by UAV uv ij : binary variable for edge traveled by CV pa ij : cumulative passes over edge by CV The fixed network that is traversable by the CV (Conventional Vehicle Network, CVN) is first introduced. Let it be an undirected graph, i.e., G = (V , E ), where each vertex ("node") belongs to the set: Edges of the E [G ] space result from the connection between two nodes i and j, as e(i,j), belonging to the respective set: A binary variable, x CV ij , shows whether a connection exists between two nodes for the CV.
A cost, ct ij , is awarded to each edge; we will be using time since it is of primary concern in logistics operations and is also a common parameter between edges (travel times) and nodes (service and waiting times). The vehicle can travel an edge in both directions (an undirected graph).
'L CV ij ': length of road link between points i and j 'S CV ': CV mean speed Information on the types of CVN nodes follows. Several types are identified and can be passed on to the nodes: a Central Depot (CD), which is the starting point for the operations; Remote Depots (RDs), which can provide additional UAVs for delivery; and Virtual Hubs (VHs), which are designated safe areas for UAV deployment (e.g., parking lots, open spaces, organized launch/land bases). All others are considered generic nodes. Also, there is demand for deliveries at certain locations (Delivery Locations, DLs). A list, "K", of "m" items (each element: "k") is given, along with their geographic position: A DL may not be reachable by CV at all, i.e., it may not belong to the CVN. A vertex set, "V", is created, combining CVN and DL nodes (V = V ∪ [DL]). The DL of each item is matched with a vertex of the "V" space and is then represented by it. The set of the respective nodes is defined as For computational convenience, we introduce an expansion of the initial CVN graph including any DLs outside the CVN: Nodes outside the initial set V (resulting from DLs) would have no edge connection with any other node in V.
UAVs may launch and land at certain locations based on prevailing restrictions. Such locations are called Launch Sites (LSs), and they are potential points for launching and collecting UAVs. We also introduce a definition for DLs that are visitable by UAV, "UL".
Based on the above, available special node types in the vertex set (V) may be: This subset here only contains one vertex, always named "0". • Remote Depots (RDs), forming a subset of vertices, T v RD , x RD i = 1. An RD may be a designated location with available UAVs to deploy. As such, a Conventional Vehicle will not have to carry UAVs onboard or wait for any deployed UAVs to return. • Virtual Hubs (VHs), forming a subset of vertices, A Virtual Hub is an initially designated location throughout the conventional network where conventional vehicles are allowed to deploy UAVs (e.g., parking lots, special bases for take-off and landing).
A Customer Location is a point of demand for a specific item delivery, item collection, or service. UAV-visitable locations (UL) form an additional subset among DLs, T v UL , Site is ultimately a location where a UAV can be launched or collected, depending on circumstances (UAV range and DL location, flight restrictions, weather, other temporary technical issues). CD, RDs, VHs, and DLs may be Launch Sites or not. A Launch Site is an "allowed" site for launch or collection.
Launching and collecting a UAV is possible in other locations than just the CD and DLs. Additionally, not all DLs are potential LSs. This is different from the assumption commonly made in the literature about cooperative truck-drone systems, where drones can only fly from or to customer locations or the CD. A schematic representation of node sets is shown in Figure 5.
Vehicles 2023, 5, FOR PEER REVIEW 10 conventional vehicles are allowed to deploy UAVs (e.g., parking lots, special bases for take-off and landing). Launching and collecting a UAV is possible in other locations than just the CD and DLs. Additionally, not all DLs are potential LSs. This is different from the assumption commonly made in the literature about cooperative truck-drone systems, where drones can only fly from or to customer locations or the CD. A schematic representation of node sets is shown in Figure 5. For computational reasons, a duplicate node of the CD (CD'), forming a set , is created, along with its associated edges, only this time it is characterized as an RD. This serves to cater to a generalized case of using the CD for UAV deployment at the end of the CV route rather than at the start of operations. For computational reasons, a duplicate node of the CD (CD'), forming a set T v CD , is created, along with its associated edges, only this time it is characterized as an RD. This serves to cater to a generalized case of using the CD for UAV deployment at the end of the CV route rather than at the start of operations.
For UAV operations, we define an undirected graph, F = (V, A). Edges of the A[F] space result from the connection between two nodes i and j, as a(i,j), belonging to the set: We assume typical UAV VTOL behavior, which implies an initial vertical ascent to the cruising altitude and finally a vertical descent to the landing position. Figure 6 illustrates the flight pattern suggested. The UAV can operate within a certain range, defined by its specs and battery is usually expressed in time. The following parameters regarding the UAV are mean cruise speed (S UAV ), mean speed of ascend (S UAV asc), mean speed of descend range of operation (time) (R UAV ), and cruising altitude (H UAV ).
Flight time "ftij" is the time needed for a UAV to fly from location "i" to loca at cruising altitude. This is essentially the weight (in time) of an edge if traveled b We assume a symmetric problem for the UAV operations, i.e., ftij = ftji.
'L UAV ij': distance between points i and j 'S UAV ': UAV mean flight speed "Time to ascend" (tta) and "time to descend" (ttd) values are considered. Con only direct flights between nodes (no stops at other nodes), the total flight time " tween two points is calculated as

UAV Range and Connections
One of the most important processes within the proposed workflow is the id tion of the allowed LSs and UAV-visitable DLs. This is executed in stages as ne mation emerges.

•
Stage 0: Initial Infrastructure (CD, RDs, VHs); • Stage 1: Physical constraints on emerging DLs (e.g., area characteristics, o safe room for take-off and landing); The UAV can operate within a certain range, defined by its specs and battery, which is usually expressed in time. The following parameters regarding the UAV are defined: mean cruise speed (S UAV ), mean speed of ascend (S UAV asc ), mean speed of descend (S UAV des ), range of operation (time) (R UAV ), and cruising altitude (H UAV ).
Flight time "ft ij " is the time needed for a UAV to fly from location "i" to location "j" at cruising altitude. This is essentially the weight (in time) of an edge if traveled by UAV. We assume a symmetric problem for the UAV operations, i.e., ft ij = ft ji .
'L UAV ij ': distance between points i and j 'S UAV ': UAV mean flight speed "Time to ascend" (tta) and "time to descend" (ttd) values are considered. Considering only direct flights between nodes (no stops at other nodes), the total flight time "tft ij " between two points is calculated as

UAV Range and Connections
One of the most important processes within the proposed workflow is the identification of the allowed LSs and UAV-visitable DLs. This is executed in stages as new information emerges.
Stage 3 analysis assumes that any location "i" falling within an RZ cannot be an LS or UL; thus, x LS i = x UL i = 0. To reduce the computational burden, pre-processing for feasible UAV connections may be performed only for nodes of interest, that is, the Launch Sites T v LS and eligible Delivery Locations T v UL . As with the CV, we define a binary variable, x U AV ij , representing a direct connection between two nodes, for the case of the UAV.
The existence of a direct UAV connection between two nodes is determined by the range, "R UAV ", of the UAV and/or extraordinary conditions (e.g., takeoff and landing restrictions, air traffic rules, weather).
Based on the above analysis, for each Launch Site and Delivery Location, a set of reachable nodes is formed. The analysis is performed at two levels. First, the maximum reachable DLs and LSs are identified, assuming no air space restrictions and straight-line paths between node pairs. Acquiring optimal paths around obstacles is an intensive process. By first applying the Level 1 filter, which is simple and quick, the overall computational effort is significantly reduced. Figure 7 explains the proposed two-level process for finalizing the UAV edge weights and the reachable LSs for each DL. ), since there is no po for other pairs to have feasible UAV connections. Acquiring optimal paths aroun cles is an intensive process. By first applying the Level 1 filter, which is simple an the overall computational effort is significantly reduced. Figure 7 explains the p two-level process for finalizing the UAV edge weights and the reachable LSs for e  We employ a suitable algorithm for obtaining optimal paths around the RZs. Source and target nodes are feasible LS and DL pairs that have resulted from the first-level Level analysis.
New values for flight time and total flight time ( f t ij and t f t ij , respectively) emerge based on the length of the new flight paths. The edges a(i,j) of graph F = (V, A) are updated, responding to t f t ij . The values x U AV ij are also updated based on the new flight times between nodes: The final lists of reachable LSs and DLs are calculated: Since all UAV-related calculations will be based on the actual flight paths around obstacles, we can substitute respective values as follows: f t ij = f t ij , t f t ij = t f t ij . Each time a package is delivered to a location, a certain service time on the spot is considered. We assume a similar service time for both delivery via conventional vehicle and UAV, "st".
A delivery request can be served by CV (at the node of said request) or by UAV (launching from another node among eligible launch sites). A pool of eligible service nodes can be defined for each item, containing the launch sites within range of the delivery location and the node of the delivery location itself. If the DL is not part of the original CVN, its own node cannot be part of this pool, SN k .
A DL may be non-serviceable. This happens when it is located outside the CVN, i.e., no CV can reach this destination, and at the same time, no allowed LS is located within the UAV range. In our algorithm, this state is plainly described by an empty SN k pool. In this case, the DL is removed from demand.

Mode Assignment and Vehicle Routing
Having determined the potential LSs for all delivery locations, the assignment of each item to a UAV or CV follows. If the item is assigned to a node (let it be "l k ") other than its own (d k ), the request is executed via UAV. If an item is assigned to its own node (l k = d k ), the delivery is made by the CV.
We use the binary variable "xd CV i " to define whether a delivery is made by a conventional vehicle at a node or not.
These nodes form a subset of "delivery with CV": We also introduce another binary variable, "xl i ", to define whether a node is ultimately used for UAV launch or not. These nodes must belong to the CVN.
Nodes form a subset of "assigned launch sites": Nodes finally assigned as service nodes for either action (UAV launch or CV delivery) are Mandatory Nodes with Action(s) (item delivery or UAV launch), named "TMa". The CV must visit them at some point along the route and perform an action other than just passing by. T In our method, this distinction between generic and mandatory nodes is crucial. This is because the full network is given, but not all nodes must be visited, and the problem changes depending on infrastructure, conditions, equipment constraints, and demand. The full set of mandatory nodes results from the union of the two sets: T v DLCV (delivery locations served by conventional vehicle) and T v aLS (assigned launch sites), and the CD (which must be the first and last node to be visited, hence the inclusion of its duplicate): There is a possibility of the CD or its duplicate being nodes with action (belonging to the T v Mα ). We define a "clean" set, T v Mc , excluding the CD and CD', as We keep track of the items assigned to the same launch site for UAV delivery. As such, each node belonging to the T v aLS will feature a list of the assigned items. A respective list is formed for each of the assigned launch sites: The number of assigned items per launch site is the length of the list: |L l |.
The use of a node as an LS implies a certain time cost (transshipment cost). This is because of the necessary preparations for UAV deployment. We include this transshipment cost in a variable called "tc i ". UAVs are assumed to launch simultaneously, but they naturally return at a different time.
When a UAV is deployed, a certain amount of time is required for it to return to its base. This travel time, from deployment at node "i", delivery at node "j", and back to home "i", "dth ij ", is calculated as At every node, a certain waiting time, "wt i ", for the CV is considered. Each node "i" inherits the "burden" of assigned delivery locations. If item delivery is its only duty at the node, this time is essentially the service time. If the spot is used for UAV deployment, the waiting time is also a result of the transshipment time for each item and the time from deployment to the home of the last UAV to return. If the aLS is an RD, the node is only weighted by the delivery of an item via CV (if any) and the time to unload the rest of the items for UAV transport. The typical service time, st i , is used for unloading, as if it were a case of normal deliveries. However, we assume that service times here are affected by the number of unloaded items, as they would be for multiple deliveries on the spot. At depots, the transshipment cost does not affect the CV.
For the special case of the CD, since there is no CV delivery and there is no unloading time for any UAV-assigned item, the CV does not have to wait, and everything is processed independently. Any UAV deployment from the CD would normally happen at the start of the operations, but we will also be allowing the CD to host actions as the last node of the tour. The CD duplicate (used as the last node of the tour) carries the characteristics of an RD to emulate the expected procedure of item unloading and UAV deployment.

Sub-Paths between Mandatory Nodes
In our case, where most network types should be addressed, typical TSP constraints restricting multiple node/edge passes and forcing the use of all nodes do not apply since not all nodes are mandatory and both butterfly routes and multiple node/edge passes are allowed (e.g., because of network dead ends or reaching a node for delivery or launch and immediately returning from the same road). We structure our method in such a way that it is not hampered by infeasible solutions: All mandatory nodes are always included in the solution (at least once for completing an action), and path continuity is ensured.
For assessing the performance of each solution, a certain route must be constructed, passing through the mandatory nodes and any other nodes necessary to form a continuous path. We will base this two-step method on the principle of optimality, stating that "in a graph with no negative dicycles, optimal paths must have optimal subpaths" [24]. We define a subgraph of the original G graph, G M = T v M , E M . Mandatory nodes (resulting from the assignment process) form the node set T v M . Each edge, e M , is a "shell" edge, representing the shortest path between two nodes through the original network. For each i, j ∈ T v M , i, j ∈ V , there is a path of nodesŜ ij = [i, . . . , j] and edgeŝ S (i,j) = [(i, i + 1), . . . , (j − 1, j)], and the cost of the shell edge is The shortest path can be calculated via an appropriate algorithm each time (e.g., Dijkstra [37], A* [38], IDA* [39], LPA* [40]), depending on the complexity and size of the network. Now, a certain sequence of visits must be defined through the mandatory nodes. The path always features the CD as the first and last node of visitation. As explained before, the CD's duplicate visited at the end is considered an RD.
After decomposing the solution route to the nodes forming its shell edges, we have the order of visit of all nodes. The selected nodes constitute a subset, T v ACCV , with each one characterized by the binary variable xa i .
The nodes are appended in the order of visits within the subset. This subset ultimately describes the problem's possible solution each time. A node may be traversed more than once and may be repeated in the sequential order of visits. However, actions of delivery and/or launch only happen once.
If an edge is ultimately used by the conventional vehicle or the UAV, there is a binary variable to keep track of (uv ij and uf ij , respectively).
Since in our accepted spectrum of network types and based on our problem definition, it is possible that a CV edge is traversed more than once, we keep a record of the cumulative passes over each edge along the tour under the variable pa ij ∈ Z.

Objective Function and Solution Performance Calculations
For each node, there is a time of approach "t app i " since the start of delivery. Travel times along the selected edges of the conventional vehicle network are added, as are waiting times at preceding nodes.
Additionally, depending on which actions are taken (delivery at the node, deployment of UAVs), there is a time of departure, "t dep j ", at each node visited by the CV. In this case, the nodes of visitation are ordered.
In case of a depot, the UAVs will be returning to their base independently from CV operations. We still need to know when the last one returns to the depot. The time of return should be Two values regarding the entire operation are of importance: the amount of time spent out for the CV and the entire time spent until any operation (CV or UAV) has finished. CV total time (CVT) is This value should be identical to the time of approach, t app j , at the last node. If we were to optimize based on the CVT only, the routing of each assignment iteration would essentially be a form of TSP problem among mandatory nodes with weights. It is possible, however, that UAVs are still operating even after the CV has completed its own route. All operations are finished when the CV has returned to the depot and the last remaining UAV has been retrieved at the intended location. This is defined as Global Operations Time (GOT): We use the GOT as the objective function, and the goal is to find a solution that minimizes its value.
Minimize max max t ret l , CVT , or alternatively : The description of the solution output includes the following minimum information: • The assignment of items to their respective service node (l k for each k); • The order of visit of mandatory nodes (ordered set of T v M ).

Assignment and Routing Optimization Nested Genetic Algorithm
We propose a nested Genetic Algorithm (GA) scheme where a routing optimization algorithm (inner GA) is executed for each assignment suggestion and the resulting GOT value is used to select the best assignment (shell GA). It is essentially a cluster-first, routingsecond approach, where each clustering iteration is tied to its own optimal routing. GAbased methods are commonly used in this family of problems [52], mainly because of their NP-hardness and complexity [53]. In our case, preliminary processing produces discrete alternatives (Service Nodes Pool) for the assignment of items and a subset of nodes that need to be ordered. Both are conveniently translated to genes and chromosomes. Additionally, one process essentially depends on the other (routing is applied to mandatory nodes that result from assignment); thus, a nested scheme makes sense.
Outer GA (Mode and Service Node Assignment of Items) For the outer GA, the chromosome consists of genes, whose total number equals the number of items, m = |K|, (delivery locations). Each gene can take the discrete values of the available service nodes (SN k ) for the respective DL. Random mutation and single-point crossover are employed to produce new offspring and a ranking parent selection is used to qualify the best parents for mating. An example of the above gene structure for the outer GA (mode assignment) is shown in Figure 8.
For the outer GA, the chromosome consists of genes, whose total number equals the number of items, = | |, (delivery locations). Each gene can take the discrete values of the available service nodes ( ) for the respective DL. Random mutation and single-point crossover are employed to produce new offspring and a ranking parent selection is used to qualify the best parents for mating. An example of the above gene structure for the outer GA (mode assignment) is shown in Figure 8. Random mutations are introduced to genes to keep diversity in the population and escape local optima.

Inner GA (Conventional Vehicle Routing)
For the inner GA, we need to find the optimal order of visits to the mandatory nodes. Since the CD and its duplicate will always be the first and last nodes, respectively, the chromosome features genes, one for each of the mandatory nodes, without the start and  Random mutations are introduced to genes to keep diversity in the population and escape local optima.

Inner GA (Conventional Vehicle Routing)
For the inner GA, we need to find the optimal order of visits to the mandatory nodes. Since the CD and its duplicate will always be the first and last nodes, respectively, the chromosome features genes, one for each of the mandatory nodes, without the start and end nodes, T v Mc . We employ a random-keys GA [24], where each node is ordered in ascending order based on its respective gene value. The gene values are randomly produced within a set range (e.g., 0-100). Single-point crossover and ranking parent selection are used. The final path begins and ends with the CD (its duplicate at the end), and in between there are the ordered nodes resulting from the previous process. The GOT value resulting from routing is passed to the respective outer GA iteration and used for its own optimization process. An example of the above gene structure for the inner GA (CV routing) is shown in Figure 9.
EER REVIEW 17 end nodes, . We employ a random-keys GA [24], where each node is ordered in ascending order based on its respective gene value. The gene values are randomly produced within a set range (e.g., 0-100). Single-point crossover and ranking parent selection are used. The final path begins and ends with the CD (its duplicate at the end), and in between there are the ordered nodes resulting from the previous process. The GOT value resulting from routing is passed to the respective outer GA iteration and used for its own optimization process. An example of the above gene structure for the inner GA (CV routing) is shown in Figure 9. Again, random mutations are introduced to genes to keep diversity in the population and escape local optima.

Input Data
We devise a test CV network with all types of facilities (CD, RD, VH) and demand data, carrying benchmark characteristics, to perform a solid stress test on our algorithm.
The said network should offer certain features: • The geographical size of the network should resemble that of a large city or the distances between neighboring cities. • There must be dead-end edges, i.e., edges that are connected to a single node at one end (to resemble last-mile cases with limited connections).

•
A node is not necessarily connected to all its closest ones (to emulate missing links). Ordered T 12.00 5 -9 -10 -7 -2 Again, random mutations are introduced to genes to keep diversity in the population and escape local optima.

Input Data
We devise a test CV network with all types of facilities (CD, RD, VH) and demand data, carrying benchmark characteristics, to perform a solid stress test on our algorithm.
The said network should offer certain features: • The geographical size of the network should resemble that of a large city or the distances between neighboring cities. • There must be dead-end edges, i.e., edges that are connected to a single node at one end (to resemble last-mile cases with limited connections). • A node is not necessarily connected to all its closest ones (to emulate missing links).
• At some point, there must be a series of consecutive edges with a single node connection in between (to resemble possible stops along a single corridor).
As far as node types and delivery locations, • There must be a CD and at least one RD (apart from the CD duplicate) away from it. • There must be a few Virtual Hubs, distributed evenly throughout the network (not all Virtual Hubs will necessarily serve as allowed Launch Sites).

•
There must be at least one Delivery Location outside the given CV network where only a UAV can be of service.
The following figures (Figures 10 and 11) describe the case study network and its node types.   Certain specs for the CV and the UAV are selected. The specifications for the UAV resemble today's advanced commercial UAVs and are naturally expected to improve in the future (see indicative enterprise-grade UAV specs at [54][55][56]).

Application and Solution
A 60 min UAV range and a 40 km/h CV speed are selected, and RDs are placed at critical locations, based on the experience gained by previous experimentation.
The network is transformed into GIS format, and Restricted Zones (RZs) of various types and shapes are introduced. RZ sizes and shapes resemble common cases met in airspace no-fly zones (e.g., ATZs usually cover a range of 3000-8000 m around the airport). Such zones are commonly archived and updated in GIS databases; thus, we believe it makes sense to include such an approach in our framework. The RZs are shown in Figure 12 (as they would normally exist in relevant flight information maps), and Figure 13 depicts the final solid "obstacles" resulting from analysis in GIS.  DLs and potential LSs that fall within the RZs are removed from UAV operations. For each DL and its maximum potential LSs, optimal UAV paths around the RZs are calculated. The calculations are carried out through a flow direction algorithm [57], using D8 [58], Multiple Flow Direction (MFD) [59], or D-Infinity (DINF) [60] methods and accumulated cost surface and slope line [61]. An example of such analysis for our case study is shown in Figure 14, while Figure 15 includes all optimal paths created for initially reachable node pairs.   DLs and potential LSs that fall within the RZs are removed from UAV operati For each DL and its maximum potential LSs, optimal UAV paths around the RZs are culated. The calculations are carried out through a flow direction algorithm [57], using [58], Multiple Flow Direction (MFD) [59], or D-Infinity (DINF) [60] methods and accu lated cost surface and slope line [61]. An example of such analysis for our case stud shown in Figure 14, while Figure 15 includes all optimal paths created for initially re able node pairs.  (a) (b) Figure 14. Example of optimal paths between a DL and LSs: (a) LSs in maximum UAV range of DL (UAV range from Node 10, indicated by red circle); (b) optimal paths for initially feasible LSs (paths shown as green lines around purple RZs).

Figure 15.
All UAV optimal paths between DLs and potential LSs within maximum UAV range. Lines around purple RZs show respective paths between node pairs. After establishing the shortest paths around the RZs, a further filter is applied, excluding paths that now exceed the UAV range, and the Service Nodes Pool is updated for each DL.
After running the algorithm and the optimization workflow, we have obtained the following results: GOT = 16,340.8 s, CVT = 16,340.8 s. Figures 16 and 17 below show the gene and solution evolution process through our nested GA algorithm.

EER REVIEW 21
After establishing the shortest paths around the RZs, a further filter is applied, excluding paths that now exceed the UAV range, and the Service Nodes Pool is updated for each DL.
After running the algorithm and the optimization workflow, we have obtained the following results: GOT = 16,340.8 s, CVT = 16,340.8 s. Figures 16 and 17 below show the gene and solution evolution process through our nested GA algorithm.   The Service Nodes Pool, the assigned service node, and the final mode for e are included in Table 2. Table 3 describes how the CV routing is performed, whi 4 shows the actions taken at each mandatory node and how time accumulates u end of operations.  0  2  5  5  2  3  2  3  6  6  2  3  2  4  7  7  7  5  9  9  8  8  6  10  10  0  8  12  14  0  7  11  11  8  10  12  14  12  8  13  13  13  9 14 14 10 12 12 The Service Nodes Pool, the assigned service node, and the final mode for each item are included in Table 2. Table 3 describes how the CV routing is performed, while Table 4 shows the actions taken at each mandatory node and how time accumulates until the end of operations. A graphical representation of the solution is shown in Figure 18. We have recalculated the optimal solution, excluding the RZs, to compare the results. A GOT of 14,756.5 s has been obtained. In the presence of RZs, the GOT (16,340.8 s) was significantly higher (9.7%) and different assignment and routing options were selected. In Figure 19, the two solutions are depicted side by side in a similar simplistic manner for easier direct comparison.

Conclusions
We have developed a modular framework and a solution optimization methodology for integrated UAV and CV operations. Our entire platform offers flexibility in adaptation to infrastructure (links, nodes, types of facilities) and equipment (vehicle specs), network We have recalculated the optimal solution, excluding the RZs, to compare the results. A GOT of 14,756.5 s has been obtained. In the presence of RZs, the GOT (16,340.8 s) was significantly higher (9.7%) and different assignment and routing options were selected. In Figure 19, the two solutions are depicted side by side in a similar simplistic manner for easier direct comparison. We have recalculated the optimal solution, excluding the RZs, to compare the results. A GOT of 14,756.5 s has been obtained. In the presence of RZs, the GOT (16,340.8 s) was significantly higher (9.7%) and different assignment and routing options were selected. In Figure 19, the two solutions are depicted side by side in a similar simplistic manner for easier direct comparison.

Conclusions
We have developed a modular framework and a solution optimization methodology for integrated UAV and CV operations. Our entire platform offers flexibility in adaptation to infrastructure (links, nodes, types of facilities) and equipment (vehicle specs), network

Conclusions
We have developed a modular framework and a solution optimization methodology for integrated UAV and CV operations. Our entire platform offers flexibility in adaptation to infrastructure (links, nodes, types of facilities) and equipment (vehicle specs), network characteristics (missing links, dead-ends, butterfly routes), and the response to restricted airspace. Because of the need for safe UAV deployment sites and the high presence of restricted airspace zones in urban environments, the intended field of application is assumed to be the delivery of small packages in rural and under-connected areas, the execution of inter-city deliveries, and the expansion of a city's original service range.
Each step, from inputs to final optimization, is part of a modular workflow that allows for preference-based solutions (e.g., constraints for certain locations, shortages in equipment, priority in deliveries, routing). Since not all nodes and edges of the physical network are necessarily visited, a shell network is created resulting from mandatory nodes and the shortest path total costs between them, deconstructing and simplifying the problem. Restricted Zones are considered for UAV flights, altering the traditional straight-line approach, and using obstacle routing instead. A GIS environment is used for spatial analysis and optimal path planning. We have developed a tailored nested GA method for obtaining optimal solutions in terms of mode assignment for each item and routing of the CV.
Our model was implemented in a case study with benchmark characteristics. Substantial gains in performance (total time of operations) can be achieved with wise infrastructure choices and improved equipment specifications. Experiments have shown the robustness of the formulation and general methodology from preliminary analysis to final solution optimization. The presence of Restricted Zones significantly alters the potential solutions and is worth considering for a more realistic approach. It is a modular workflow with an easy "front-end" and a solid mathematical background that can be practically used for decision-making purposes at a strategic level and is open to future adaptations.
The entire model and solution methodology are practical tools for decision making and strategic planning, but we offer some specific novelties. For example, our variable Launch Site types for LARO, the tailored Assignment and Routing Optimization nested GA, the consideration of airspace restrictions of any shape and size, the inclusion of GIS tools in the process, the modularity of our platform, and, most importantly, the inclusion of all the above in a single, comprehensive, and holistic approach could be highlighted. In terms of the transport system setup, further research could be directed toward including more CVs instead of one, considering altitude and terrain specifics and the stochastic nature of travel times both for the CVs and UAVs.    0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20   0  0  0  23,899  inf  inf  inf  inf  10,611  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  11,133  7752  inf  1  0  0  23,899  inf  inf  inf  inf  10,611  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  11,133  7752  inf  2  23,899  23,899  0  13,880  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  24,885  inf  inf  3  inf  inf  13,880  0  10,717  5038  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  4  inf  inf  inf  10,717  0  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  5  inf  inf  inf  5038  inf  0  9870  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  6  inf  inf  inf  inf  inf  9870  0  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  16,017  7  10,611  10,611  inf  inf  inf  inf  inf  0  12,358  inf  inf  inf  inf  inf  inf  inf  inf  inf  inf  11,020  inf  8  inf  inf  inf  inf  inf  inf  inf  12,358  0