WO2025166329A1 - Small unmanned aerial system airleasing in congested and controlled airspaces - Google Patents

Abstract

A method includes receiving, by an air traffic control (ATC) system and from an unmanned aerial system (UAS), a routing request, the routing request including a first start position and a first end position, generating a three-dimensional path based on a directed airspace reservation graph and the routing request, the path beginning at the first start position, concluding at the first end position, and including a set of path segments, modifying the directed airspace reservation graph to include at least part of the set of path segments, and causing the UAS to travel from the first start position to the first end position in accordance with the at least part of the set of path segments.

Description

SMALL UNMANNED AERIAL SYSTEM AIRLEASING IN CONGESTED AND CONTROLLED AIRSPACES Cross-Reference to Related Applications [0001] The present disclosure claims priority to U.S. Provisional Applications 63/549,211, filed on February 2, 2024, and 63/678,302 filed on August 1, 2024, both of which are entitled “SMALL UNMANNED AERIAL SYSTEM AIRLEASING IN CONGESTED AND CONTROLLED AIRSPACES” and are incorporated herein by reference in their entirety. Government License Rights [0002] This invention was made with government support under grants CNS1931962 and CCF1909007 awarded by the National Science Foundation (NSF). The government has certain rights in the invention. Technical Field [0003] The present disclosure relates to unmanned aerial systems and, more particularly, to small unmanned aerial system airleasing in controlled airspaces. Background [0004] Unmanned aerial systems (UAS) are technologies that include unmanned aircraft (e.g., drones). These systems perform various operations such as surveillance, delivery, emergency response, and environmental monitoring. Small unmanned aerial systems (sUAS) may be a subset of UAS, typically weighing less than 55 pounds as defined by regulatory bodies like the Federal Aviation Administration (FAA). sUAS may include rotorcrafts, such as quadcopters and hexcopters. Brief Description of the Drawings [0005] Certain features of the subject technology are set forth in the appended claims. However, for the purpose of explanation, several embodiments of the subject technology are set forth in the following figures, where like reference numerals refer to the same or similar features in the various figures. [0006] FIG. 1 is a diagram of an example ATC system managing a swarm of UAS in accordance with one or more embodiments. - 1 - ACTIVE 706790912v1 [0007] FIG.2 is a diagram of an example airspace reservation graph in accordance with one or more embodiments. [0008] FIGS. 3A–3B are front and side views, respectively, of an example air tunnel in accordance with one or more embodiments. [0009] FIG. 4 is an example user interface of airleasing administration in accordance with one or more embodiments. [0010] FIG.5 is a flow diagram of an example process for airleasing by the ATC system in accordance with one or more embodiments. [0011] FIG.6 is a block diagram of an example computing system, in accordance with one or more embodiments. Detailed Description [0012] The rapid proliferation of unmanned aerial systems (UAS), particularly small unmanned aerial systems (sUAS), has highlighted deficiencies in current air traffic control (ATC) systems designed to manage their operations. Existing ATC systems, such as the National Aeronautics and Space Administration’s (NASA) unmanned aerial systems traffic management (UTM) concept, rely predominantly on static and linear airspace reservation techniques, where routes are predefined as direct paths from origin to destination. Such systems lack adaptability to real-time conditions, such as fluctuating air traffic densities, environmental changes, or unexpected obstacles (e.g., emergency airspace requirements for manned aircraft or sudden drone failures). Static reservation methods may lead to inefficient utilization of airspace, resulting in unnecessarily large safety buffers and excessive delays for UAS missions. Secondly, such systems do not sufficiently address complex routing needs, such as circular or incremental path planning, which may be utilized in scenarios like search-and-rescue operations or disaster response. Moreover, existing ATC systems may focus on theoretical frameworks that assume ideal conditions, overlooking the inherent unpredictability of real- world operations. For instance, many ATC systems fail when faced with hardware failures, communication disruptions, or non-linear environmental interactions like wind turbulence. Accordingly, there is a need for an ATC system capable of dynamic, fine-grained airspace management that provides safety and efficiency while accommodating the practical realities of UAS operations. [0013] The present disclosure describes ATC systems designed to manage UAS, including sUAS, in a more efficient and adaptive manner. Embodiments may employ a fine-grained - 2 - ACTIVE 706790912v1 airspace leasing (or “airleasing”) mechanism that allocates three-dimensional “air tunnels” as paths based on real-time conditions and mission requirements, optimizing airspace utilization and reducing operational inefficiencies. Embodiments may also include adaptive airspace leasing capabilities, enabling optimal utilization of available airspace without compromising safety, and can dynamically adjust airspace reservations to match real-time traffic densities, environmental conditions, and drone capabilities. Embodiments may also support various advanced features, including incremental path planning, real-time failure handling, smart routing, and complex routing. This enables efficient adjustments to ongoing operations, handling of unexpected failures, and support for non-linear and circuitous routes often utilized in applications like search-and-rescue missions, urban air mobility, and disaster response. Additionally, embodiments may integrate environmental awareness, leveraging real-time environmental data for safe and efficient flight operations under varying conditions. Although the present disclosure primarily describes the embodiments with respect to sUAS, embodiments may be similarly applicable to other forms of UAS. [0014] Referring now to the drawings, wherein like numerals refer to the same or similar features in the various figures, FIG.1 is a diagram of an example ATC system 108 managing a swarm of sUAS 102, 104, 106 in accordance with one or more embodiments. Not all of the depicted components may be used in all embodiments, and one or more embodiments may include additional, fewer, or different components than those shown in the figure. Variations in the arrangement and type of components may be made without departing from the spirit or scope of the claims as set forth herein. Furthermore, the components (e.g., modules) described with respect to the example ATC system 108 are used for convenience to refer to functionality that the example ATC system 108 is configured to perform by way of one or more components of the example ATC system 108 (e.g., computer-readable instructions in memory), which is described in further detail below with respect to FIG.6. [0015] Drone zone 100 [0016] A Pop-Up Drone Zone (PuDZ) is a self-managing, self-adapting framework that enables collision-free flights for a large number of aerial vehicles, such as sUAS. The PuDZ framework includes infrastructure, such as the example ATC system 108, to manage complex aerial operations by facilitating situational awareness, monitoring regulatory compliance, enforcing safety guidelines, and/or the like. To achieve this, the PuDZ framework may gather and process a wide range of information, allowing it to dynamically adapt routing algorithms, - 3 - ACTIVE 706790912v1 respond to environmental changes, oversee flight operations, and/or the like, in real time. This adaptive capability allows the PuDZ to maintain safe and efficient drone operations even in challenging or rapidly evolving conditions. [0017] In some embodiments, the PuDZ framework may integrate with broader traffic management systems, such as NASA’s UTM (Unmanned Aircraft System Traffic Management) system, which facilitates sUAS operations in low-altitude airspace. The PuDZ framework may also provide an effective solution for coordinating sUAS operations in regions where UTM services are unavailable or for highly localized and densely populated airspaces. [0018] The PuDZ framework may be lightweight and robust for rapid deployment (e.g., emergency response situations). The PuDZ framework may integrate multiple MAPE-K (monitor, analyze, plan, execute, and knowledge) loops, which may be an autonomic control structure in autonomic computing. The MAPE-K loop may be iterative, allowing the PuDZ to constantly adapt to both external and internal data, strategically processing new information in real-time. This allows for rapid and clean adaptation for a variety of conditions. The PuDZ framework may also leverage modular components that may easily be integrated or changed (e.g., due to evolving needs). [0019] A drone zone 100 may be a geographical region in which multiple sUAS 102, 104, 106 can operate collaboratively under the PuDZ framework provided by the example ATC system 108. An operator may configure and/or maintain the drone zone 100. To configure the drone zone 100, the operator may define a boundary by marking a region with an altitude ceiling on a user interface provided by the example ATC system 108. At runtime, the example ATC system 108 may dynamically create the drone zone 100 from the region boundaries, customizing and populating the infrastructure (e.g., sUAS 102, 104, 106) based on operational strategies, environmental data, and/or the like. To enable these features, the example ATC system 108 may include components (e.g., sub-systems) such as an airspace leasing module 116 and an environmental digital shadow (EDS) module 118. These components work together to manage the flight operation of the sUAS swarm, along with self-adaptations within the boundaries of the drone zone 100. [0020] Components of the Example ATC system 108 [0021] The example airspace leasing module 116 of the example ATC system 108 enables safe flight protocols in a variety of circumstances. In this example, the module 116 includes software and/or hardware that enable fine-grained route reservation, self-adaptation, and/or - 4 - ACTIVE 706790912v1 lightweight deployment and can operate with little or no prior knowledge of the environment covered by the drone zone 100. [0022] In order to take off, hover, or navigate a route, a sUAS 102 submits a routing request to the module 116 requesting an air tunnel (e.g., of radius r) from a start position (e.g., its current position) to an end position, which, in this example is represented as a set of GPS coordinates, or other suitable representation. Furthermore, in at least one example, the sUAS 102 also provides the module 116 movement patterns, maneuvers, and/or goals. For example, the sUAS 102 submits a promise to only move forward. [0023] The module 116 maps the incoming routing request to a three-dimensional (3D) path, which permits requests for complicated routes and maneuvers. The airspace leasing module 116 may be sufficiently flexible to enable multiple types of routing, including an in- time approach to reserve shorter air tunnels (e.g., 3D path segments) and/or temporal techniques to schedule airspace reservation in advance. For example, the sUAS 102 requests whole paths (e.g., air tunnels resembling cylinders), requests airspace incrementally by smaller path segments (e.g., air tunnel segments), and/or requests smart leasing (e.g., airleasing fully determined and managed by the ATC system 108) which leverages path-finding algorithms to navigate around obstacles in congested space. [0024] The module 116 reserves the entire path or only portions of the path that may be or will soon be in use. The module 116 may also release any unneeded currently reserved airspace (e.g., portions of the air tunnel the sUAS 102 has just traversed) to free airspace for other sUAS while retaining sufficient airspace for the sUAS 102 (e.g., to hover in its current position). [0025] To maintain the drone zone 100, the example airspace leasing module 116 utilizes an MAPE-K loop. For instance, the module 116 monitors (M) flight authorization requests, analyzes (A) the rate of request denial, plans (P) to convert to smart-leasing, and executes (E) the transition by broadcasting to the affected sUAS. This loop runs over a knowledge (K) base that retains historical information gathered for the duration of flight, which can be used to learn from previous missions. [0026] The example EDS module 118 of the example ATC system 108 enables the PuDZ to self-adjust its corresponding physical environment when overseeing a swarm of sUAS. In this example, the module 118 includes a digital shadow of the environment (e.g., a digital model of the physical world). The digital shadow may support data flow from the physical world to the digital representation of the physical world such that changes in the physical world - 5 - ACTIVE 706790912v1 are reflected or “shadowed” in the digital model. The EDS module 118 may integrate one or more external sources to gain a thorough digital image of the physical environment and adhere to relevant regulatory guidelines. [0027] Like the airspace leasing module 116, the example EDS module 118 follows an internal MAPE-K loop that enables it to enhance remote pilot in command (RPIC) awareness. For example, based on monitored weather conditions, the module 118 analyzes and filters out information as needed and provide the information with appropriate contextual data to the operator (e.g., via a user interface) and/or the airspace leasing module 116. The EDS module 118 utilize, for example, (1) weather services (e.g., APIs) to obtain (e.g., receive and/or retrieve) weather data such as temperature, precipitation, humidity, varying altitudes of wind, and/or visibility; (2) mapping services (e.g., APIs) to obtain (e.g., construct) terrain models and identify obstacles such as radio towers, buildings, hills, and/or other constitute no-fly zones; (3) airspace services (e.g., APIs) to obtain (e.g., receive and/or retrieve) information on regional restrictions such as lighting guidelines, designated no-fly areas, and/or other regional reports; and/or (4) a database (e.g., local and/or remote) that consolidates standard aviation regulations (e.g., local ordinances and/or FAA rules) along with contact details for local authorities such as air traffic control towers for proximal flight operations. The EDS module 118 may utilize other internal or external resources to build and/or maintain an environment digital shadow. [0028] Software implementation [0029] As the PuDZ framework may be deployable in both real world and simulation, the example ATC system 108 software uses Docker along with Docker compose, which enables consistent deployment at scale. For live field tests, the ATC system 108 may use Docker to start onboard software running on each sUAS 102, 104, 106, which may include MavROS and PX4 for the flight controller. In simulation, the ATC system 108 may spawn linked containers within a network that runs multiple instances of the sUAS onboard software (e.g., MavROS) and lastly a simulation environment (e.g., Gazebo ) for the physics engine and sensor data. The ATC system 108 may host an MQTT broker to facilitate lightweight and consistent communication protocols between multiple sUAS 102, 104, 106, the ATC system 108, and microservices. [0030] In one example, the airspace leasing module 116 is implemented in software (e.g., Python or other suitable software) and runs as a microservice on the example ATC system 108. The example ATC system 108 may support 3D route requesting for linear routes and circular - 6 - ACTIVE 706790912v1 routes, for both single and multiple route requests. The airspace leasing module 116 receives route or hover requests (hereafter simply referred to as route requests) from a sUAS over MQTT. The module 116 models each route into a 3D path segment (e.g., line segment) with an additional adaptive radius. The radius provides a safety buffer around the path segment, resulting in the reservation of an “air-tunnel” 110, 112, 114 (e.g., a cylindrical flight path in 3D space) segment. The module 116 may continuously determine whether the requested airspace is available. When airspace becomes available, the module 116 may reserve the requested space (e.g., path segments and safety buffers) and may authorize the flight. [0031] The airspace leasing module 116 generates a path for a routing request based on a fast computation that determines the 3D distance between the generated path and other nearby routes (e.g., requests and/or reservations). If the requested route maintains a minimum separation distance from other nearby routes, the module 116 may allow the flight to proceed (e.g., be reserved). This safety functionality remains consistent for all types of route requests, as the example ATC system 108 maps incoming routes to 3D path segment projections around the position of the requesting sUAS. For example, if a sUAS 102 requests a circle, the airspace leasing module 116 breaks down the circle into a series of 3D path segments, which along with individual radiuses are compared to nearby route requests and/or reservations. This allows for an improved degree of flexibility and a multitude of complicated routes to fly safely with fast communication from the PuDZ framework. [0032] Pre-flight, the airspace leasing module 116 may dynamically adjust safety buffers based on predetermined policies. For example, in one instance a new sUAS is introduced to the drone zone 100 and system policies require larger safety buffers while the sUAS is being calibrated. During flight, the airspace leasing module 116 may change airspace leases based on communication with the EDS module 118, which broadcasts live weather alerts, and/or user input from the user interface module 124. [0033] In one example, the EDS module 118 is also implemented in software and runs as an accompanying microservice to the airspace leasing module 116 running on the example ATC system 108. The example EDS module 118 obtains (e.g., receive and/or retrieve) data from a remote mapping service (e.g., MapBox) for providing (e.g., generating) an interactive 3D map and the FAA’s LAANC (low altitude authorization and notification capability) for modeling airspace classes and no-fly zones, as well as weather and terrain data from other remote services (e.g., APIs). The weather and terrain data may be gathered using isolated - 7 - ACTIVE 706790912v1 coroutines, which may filter and process information concurrently. The EDS module 118 may be integrated with a persistent database (e.g., over MongoDB), which may synchronize historical environmental information as needed. This enables the EDS module 118 to quickly adapt to and/or transmit new information. [0034] After obtaining terrain and/or weather information (e.g., models), the EDS module 118 may filter and/or broadcast data (e.g., packets) to the airspace leasing module 116 and/or onboard sUAS software to account for the terrain and/or weather information in future and/or current routes and/or route requests. For example, when the wind increases above a particular threshold, the EDS module 118 notifies the airspace leasing module 116 of the wind increase so that the airspace leasing module 116 may allocate larger safety buffers for new route and/or reallocate safety buffers for current routes. The EDS module 118 also or instead notifies the sUAS 102, 104, 106 of the wind increase, which may cause the sUAS 102, 104, 106 to query for updated air tunnels 110, 112, 114, respectively, to increase the buffer of the air tunnels 110, 112, 114 to account for the wind increase. [0035] Other components of the ATC system 108 [0036] The example ATC system 108 also includes a processing module 122. The processing module 122 may execute machine-readable instructions in the form of software programs. The processing module 122 may include a central processing unit (CPU). In some embodiments, the processing module 122 may also include additional hardware accelerators such as graphics processing units (GPUs) or field-programmable gate arrays (FPGAs) to handle specialized workloads. These components may work in conjunction to process data, execute instructions, and control the operation of other hardware and software elements within the ATC system 108. The processing module 122 may manage real-time data streams from multiple sources. For example, the module 122 processes telemetry from sUAS 102, 104, 106, environmental sensors 121, and/or communication module 120 to make rapid decisions. These decisions may include collision avoidance, path planning, and/or dynamic airspace allocation. Additionally, the processing module 122 may execute adaptive algorithms to respond to changes in environmental conditions or mission parameters for optimal PuDZ performance. [0037] The example ATC system 108 also includes a communication module 120. The communication module 120 enables the exchange of data between a host system and external devices, such as sUAS 102, 104, 106 or other connected infrastructure (e.g., remote servers). The communication module 120 includes one or more interfaces for transmitting and receiving - 8 - ACTIVE 706790912v1 information over various communication channels, employing hardware and/or software components for reliable and efficient data transfer. The communication module 120 includes hardware components, such as transceivers, antennas, and communication controllers. These components facilitate the conversion of digital signals to physical signals suitable for transmission over specific communication media, such as radio frequencies, optical fibers, or wired networks. For wireless communication, transceivers may handle both the transmission and reception of radio signals, leveraging technologies such as Wi-Fi, LTE, mesh networks, or specialized protocols such as Zigbee or LoRa for low-power operations. The software layer of the communication module 120 complements the hardware by implementing communication protocols and data encoding schemes. Protocols such as MQTT, TCP/IP, and/or custom- defined communication stacks enable the orderly transmission of packets, error detection and correction, and/or adherence to timing constraints. In the example ATC system 108, the communication module 120 manages incoming telemetry data, such as position, velocity, and battery status, while broadcasting operational commands, including flight paths, airspace reservations, and emergency maneuvers. This bidirectional communication enables the ATC system 108 to maintain situational awareness and dynamically respond to changes in the environment or mission requirements. Additionally, the communication module 120 may support multi-channel communication, enabling it to interface with multiple sUAS simultaneously or bridge connections with other ATC systems and external data sources, such as weather services. [0038] The ATC system 108 may also include a user interface module 124. The user interface module 124 may include a platform for human operators to interact with and control the functions of the ATC system 108. The user interface module 124 may include a presentation layer and an interaction layer. The presentation layer may visualize data, using elements such as graphical displays, charts, maps, and alerts. For the ATC system 108, this may include a real-time visualization of the drone zone, showing the positions, flight paths, and status of sUAS 102, 104, 106 operating within the zone. Additionally, it may provide overlays of critical environmental data such as weather conditions, no-fly zones, and airspace restrictions, offering operators a comprehensive situational overview. The interaction layer enables control of the ATC system 108 through input devices like keyboards, touchscreens, or control panels. The interaction layer may process user commands to perform tasks such as defining drone zone boundaries, assigning flight paths to sUAS, or configuring system parameters like altitude - 9 - ACTIVE 706790912v1 ceilings and safety buffers. It also facilitates dynamic adjustments, allowing operators to respond to real-time changes such as emergencies or evolving mission requirements. [0039] The ATC system 108 may also include one or more sensors 121. The sensors 121 may collect data about the physical and operational environment, enabling the ATC system 108 to maintain safe and efficient drone operations, particularly in smaller, localized drone zones. The sensors 121 may be hardware devices equipped with technologies to measure specific environmental parameters, which may then be processed and interpreted by the ATC system 108 to inform decisions. Sensors 121 may encompass a variety of types tailored to different aspects of the environment. For instance, meteorological sensors measure weather- related factors such as wind speed and direction, temperature, humidity, and precipitation. These measurements may be used for understanding flight conditions, as adverse weather can impact drone stability, navigation, and safety. Air pressure and density sensors may also be employed to monitor atmospheric conditions that affect drone performance, particularly at varying altitudes. For localized drone zones, acoustic or optical sensors may be deployed to detect and identify unexpected intrusions, such as manned aircraft, unauthorized drones, or wildlife. Environmental sensors can also monitor air quality, lighting conditions, and electromagnetic interference, providing a holistic understanding of the operational context. Data gathered by the sensors 121 may be processed by the processing module 122 and integrated into decision-making algorithms. For example, wind data may be used to dynamically adjust the boundaries of safe operating zones (e.g., airspace tunnel safety buffers), while obstacle detection data can inform real-time rerouting of drones. In addition to active management, sensor data may be used for long-term planning and optimization. Historical data from sensors 121 may be analyzed to identify trends, improve system algorithms, and enhance the robustness of the drone zone infrastructure. For instance, understanding recurring weather patterns or traffic bottlenecks allows for better system calibration and resource allocation. [0040] Components of the sUAS 102, 104, 106 [0041] The example processing module 126 is a central computational unit that may execute the software algorithms that control the behavior of a sUAS. The processing module 126 may include a microprocessor or embedded system. The processing module 126 handles tasks such as flight dynamics calculations, navigation, sensor data processing, and/or mission planning. The processing module 126 may execute real-time algorithms to maintain stability, adjust flight paths, and/or respond to dynamic environmental conditions. In addition, the processing module - 10 - ACTIVE 706790912v1 126 interfaces with other sUAS components, coordinating data flow and decision-making processes enabling seamless operation. The processing module 126 may coordinate the operation of the sensors 128, communication module 130, and flight controller 132, so that the sUAS operate according to commands from the ATC system 108 and/or from an operator. [0042] The sensors 128 gather data about the environment and/or internal state, providing the inputs utilized for navigation, safety, and/or mission-specific tasks. Environmental sensors (e.g., barometers, gyroscopes, accelerometers, GPS, and magnetometers) may provide data for flight stabilization and positioning. Sensors like LIDAR, ultrasonic range finders, infrared detectors, and/or cameras may be utilized to enable, for example, obstacle avoidance and precision navigation. The sensors 128 may generate continuous streams of data that the processing module 126 may use to maintain situational awareness and execute adaptive control strategies. The sensors 128 may also be used for specialized applications, such as thermal imaging for search-and-rescue missions or multispectral imaging for agricultural monitoring. [0043] The communication module 130 enables the sUAS to exchange data with external systems, such as other sUAS and/or an ATC system 108. The communication module 130 includes hardware such as transceivers and antennas, as well as software that implements communication protocols such as MAVLink, Wi-Fi, or cellular LTE. Through the communication module 120, in this example, the sUAS may receive mission instructions, transmit telemetry data, and/or coordinate with other sUAS in collaborative missions. For instance, the communication module 130 sends real-time updates about position, velocity, and battery status of the sUAS while receiving adjustments to flight path based on changes in the mission or environmental conditions. [0044] The flight controller 132 translates high-level commands (e.g., from the processing module 126) into precise motor and actuator controls. The flight controller 132 may integrate inputs from the sensors 128, such as gyroscope and accelerometer data, to calculate and adjust the orientation and thrust of the sUAS. The flight controller 132 enables stable flight by managing feedback loops for pitch, roll, yaw, and altitude, compensating for disturbances such as wind or payload shifts. The flight controller 132 may operate in real time, interfacing with the processing module 126 to execute navigation commands and/or with the communication module 130 to relay status updates. The flight controller 132 may also include features such as autonomous landing, geofencing, and/or fail-safe modes for emergency situations. - 11 - ACTIVE 706790912v1 [0045] FIG.2 is a diagram of an example airspace reservation graph 200 in accordance with one or more embodiments. Not all of the depicted components may be used in all embodiments, and one or more embodiments may include additional, fewer, or different components than those shown in the figure. Variations in the arrangement and type of components may be made without departing from the spirit or scope of the claims as set forth herein. [0046] The airspace leasing module 116 maintains an airspace reservation graph 200 for tracking existing leases (also referred to as “reservations”) in the drone zone 100 and for determining whether a routing request may be accommodated (e.g., reserved) in the drone zone 100. In this example, the airspace reservation graph 200 is a directed graph, denoted as G = (V, E) where vertices V (e.g., vertices 208, 210, 212, 216, 220, 222, 224, 234) represent the requested route segments and directed edges E (e.g., edges 214, 218, 226, 228, 230, 232) represent dependencies between the route requests. The dependencies may be based on the reservation status and therefore route proximity. The airspace reservation graph 200 is 3D on axes 202, 204, 206. [0047] The airspace leasing module 116 may break down the paths from a routing request into 3D segments. Each path segment may include a dynamic radius for a safety buffer. An airspace lease may be reserved for the entirety of the flight until the corresponding sUAS indicates to the airspace leasing module 116 that it has arrived at the endpoint of the leased path. When the airspace leasing module 116 has received an indication that the sUAS has arrived at the end of its leased path, the airspace leasing module 116 may trigger a callback that removes the leased space from the airspace reservation graph 200. In some embodiments, the airspace leasing module 116 also reserves a temporary path to represent the sUAS hovering (e.g., until a new routing request is received from the sUAS). [0048] The airspace leasing module 116 may perform deadlock detection based on the airspace reservation graph 200. In the airspace reservation graph 200, an edge ^ from vertex ^^ to vertex ^^ in graph ^ implies that the route associated with drone ^ (also denoted as route^) may be dependent on the route associated with drone ^ (denoted as route^). This dependency may arise when route^ cannot proceed until route^ vacates the leased segment or upholds the necessary minimum separation distance. Following this logical structure, deadlocks correspond to cycles found in ^. A cycle in the graph G indicates mutual dependencies among sUAS, where each sUAS in the cycle may be waiting for another to leave or release the leased space. Consider a cycle involving vehicles ^ and ^. ^’s path completion depends on ^ vacating a - 12 - ACTIVE 706790912v1 leased space. However, if ^’s path completion does not depend on ^’s position (or any other sUAS that eventually leads back to ^), then no cycle—hence, no deadlock—exists in the graph G. [0049] This deadlock detection process not only systematically represents the interactions and dependencies among route requests but also provides a clean interface to identify and resolve potential navigation conflicts quickly. On runtime, the airspace leasing module 116 may instantiate a deadlock detection process and run the process in an isolated thread (e.g., of the processing module 122), which has read access to the shared data structure responsible for holding all route requests and leased space (e.g., airspace reservation graph 200). [0050] If a deadlock is detected, in some embodiments, the module 116 cancels one of the deadlocked paths (e.g., vertices 220, 234 and edge 218), allocates a temporary tunnel, and dispatches new coordinates (e.g., the closest elevation that still maintains the requisite separation distance). Upon receiving the new coordinates, the sUAS moves to the new coordinates (e.g., ascend to the new altitude), waits for the reserved airspace causing the deadlock to clear, and sends a request for the originally intended waypoint. [0051] In congested airspaces or regions densely populated with obstacles (e.g., buildings), the process for path reservation may experience significant delays as the module 116 accommodates regular lease requests, which may be based on linear trajectories. To address this challenge and mitigate latency while maintaining rigorous safety standards, the airspace leasing module 116 employs a grid-based structure in these circumstances. Upon receiving a route request, the airspace leasing module 116 may convert the start and end coordinates in the route request into the East-North-Up (ENU) system and may initialize an individual thread running a graph traversal algorithm, such as A* search. The A* search employs a strategic search to find routes from the starting location to the destination, dynamically accommodating flight constraints and circumventing potential conflicts with other sUAS or obstacles from communication with the ATC system 108. Euclidean distance may be used for a cost function, which penalizes routes that deviate beyond a threshold amount from linear trajectories to the end position. The graph traversal algorithm is consistent and flexible, allowing for inclusion of obstacles, hazardous zones, and/or other sUAS in real-time, which may all reside as leased paths (e.g., air tunnels) within the airspace reservation graph 200. [0052] In multi-threaded embodiments, a dedicated thread is initialized for each route request, creating a competitive environment among threads to race for feasible path - 13 - ACTIVE 706790912v1 determination within the airspace reservation graph 200, which may hold up-to-date information on leased routes and obstacles in the area. When a thread successfully identifies a path, all other threads may stop, halting their processing until the identified path is reserved within the airspace reservation graph 200. In some embodiments, the entirety of the path is deconstructed into segments (e.g., segmented air tunnels) and reserved as path segments. [0053] Following route approval, the airspace leasing module 116 provides the reserved path back to the flight controller 132 of the sUAS in response to the routing request. The module 116 may utilize parallel processing and concurrency, rewarding requests that have more navigable routes. This approach significantly enhances system responsiveness and improves overall traffic management, reducing delays and increasing throughput in areas with crowded route requesting and obstacles. A high-level overview is illustrated in the pseudocode (Algorithm 1) provided below. search, the module 116 considers the potential violation with other active routes (e.g., on the airspace reservation graph 200). To reduce computation cost for collision checking in three dimensions, the module 116 may query a data structure, such as an R-tree (stored locally and/or remotely), to gather any potential conflicts with existing routes, defined by their proximity and the allowable minimum separation distance between lease radiuses. [0055] An R-tree is a spatial data structure designed to efficiently store, retrieve, and query geometric objects such as points, lines, and rectangles. R-trees are effective for spatial indexing in applications such as geographic information systems, computer-aided design, and collision - 14 - ACTIVE 706790912v1 detection. R-trees structure spatial data hierarchically, grouping objects into bounding rectangles that are stored as nodes in a tree. Each node in an R-tree may represent a bounding box that encompasses its child nodes or stored objects. The root node encompasses all the data within the structure. The R-tree may index the geographical boundaries of leased routes from the airspace reservation graph 200, enabling efficient checks for overlaps and proximity. The R-tree improves the identification of safe neighboring nodes (path segments) to explore as the A* search progresses, as the R-tree helps constrict the search base to filter out routes that could violate the proximity threshold. [0056] As route reservation operations are atomic, each pathfinding thread may receive updated information of leased space, including air space which may be adjusted during a hover request, or other incoming types of requests. If a conflict is detected, this implies that the neighboring node would create a route that is too close to another leased path. For example, consider a potential leased path ^ including a segment extending from the current position ^^ to the endpoint ^^, where ^ is the neighboring node. If the extension causes a violation, this path is discarded and alternative routes may be evaluated. After a threshold period of time, the path searching thread may timeout and restart planning from the original starting node (e.g., position). [0057] FIGS. 3A–3B are front and side views, respectively, of an example air tunnel 300 in accordance with one or more embodiments. In this multi-vehicle applications, airspace may be reserved for sUAS in the form of air tunnels 300, which may be cylindrical paths, defined by a radius 302 around a sUAS. There are a variety of approaches to maintaining minimum separation distance between sUAS in a shared airspace. Some approaches delegate the - 15 - ACTIVE 706790912v1 responsibility to a centralized airspace leasing module 116, which authorizes and reserves the use of airspace. In such approaches, the airspace leasing module 116 maintains a global minimum separation distance between each pair of sUAS and may accommodate worst-case aerodynamics (e.g., stopping distance), wind conditions, reflexes, and geolocation (e.g., based on GPS and other sensor data). In some embodiments, each sUAS is responsible for computing and maintaining separation distance from other sUAS. [0058] Minimum separation distance [0059] When in flight, drone d (also referred to herein as a sUAS) may continuously compute and/or receive the minimum separation distance with each neighboring drone d′ within its region of interest (ROI). The minimum separation distance between two drones accounts for intrinsic and/or extrinsic uncertainties related to each drone’s navigation and positioning. The inventors have identified four factors for determining the operational buffer. These include (a) geolocation uncertainty, (b) stopping distance, (c) wind conditions, and/or (d) the projected distance that a drone might travel between status messages. [0060] The operational buffer may be expressed as d_buffer = d_geo + d_stop + d_wind + d_proj. Here, dgeo represents the margins used to address geolocation uncertainties, dstop represents the distance for drone d to come to a complete stop in non-windy conditions, d_wind represents the additional distance to compensate for worst-case wind-induced deviations, and dproj represents the distance that a drone is projected to travel during interval P. The minimum safety distance for safe operations between drones d and d′, as perceived by drone d is thus be the sum of their individual operational buffers, adjusted by a comfort tolerance factor. This may be expressed as d_safe = d_buffer(d, P) + d_buffer(d′, L) + tolerance, where d_buffer(d, P) is the operation buffer for drone d, factoring in the standard broadcast period P, and d_buffer(d′, L) is the operational buffer for drone d′, adjusted for L = P +T_com. Here, L denotes the total effective interval that accounts for the broadcast period and/or communication latency T_com. This adjustment to the equation acknowledges that the broadcasted information from drone d′ may be rendered stale by an additional time factor of T_com. Given these factors, the minimum separation distance may be decomposed into a set of derived considerations (DC1–DC5). [0061] The first consideration addresses the geolocation of the current sUAS d and the geolocation of sUAS d′ from the perspective of sUAS d. (DC1): Each drone d periodically ascertains its geolocation and the geolocation of each neighboring drone d′, aiming to achieve - 16 - ACTIVE 706790912v1 a 99% confidence level that each drone is positioned within a specified 3D region around its computed coordinates. [0062] The next consideration relates to the drone’s stopping distance in non-windy conditions. (DC2): Each drone d periodically computes its maximum stopping distance and the maximum stopping distance of each neighboring drone d′, in non-windy conditions, given their current velocity. [0063] For computing additional stopping distances due to wind conditions, the next consideration considers tradeoffs associated with the challenge of measuring wind conditions during flight at various altitudes and locations, the volatility of the wind gusts, complexity of computing retaliative wind direction versus the drone’s direction of travel, and limited onboard computational resources. Therefore, assuming the worst-case scenario of the projected maximum wind-gusts and a tailwind leads to the next consideration. (DC3): Each drone d considers its additional stopping distance introduced by the maximum projected tailwind. [0064] Additionally, the system may consider any change in geolocation during the status update interval, also considering communication latency from neighboring drones’ status updates as depicted. (DC4): Each drone d computes its distance projected to travel and the distance projected to travel of each neighboring drone d′ between status updates, given their current velocity. [0065] Finally, a comfort distance between each drone may be considered for worst-case scenarios. (DC5): Each drone d has a minimum separation distance with each other neighboring drone d′. [0066] Geolocation uncertainty (DC1) [0067] Inaccuracies in a drone’s geolocation may arise due to errors in satellite signal delays, atmospheric conditions, multipath effects, and/or signal interference, alongside challenges posed by dynamic environmental factors and hardware limitations. Therefore, in order to reflect a drone’s position inaccuracies, the drone’s location may be represented as being within 3D bounded region of space rather than at a pinpoint location. This region provides a three-dimensional ‘container’ that reflects the uncertainty of the drone’s position. [0068] The sUAS flight controllers may utilize Extended Kalman Filters (EKF) and/or other sensors to aggregate data into a fused global data structure for both horizontal and vertical positioning. In some embodiments, the sUAS report pos_horiz_accuracy defined as ‘horizontal position 1-STD accuracy relative to the EKF local origin’, which indicate the estimated - 17 - ACTIVE 706790912v1 accuracy of the drone’s horizontal position as calculated by the EKF, with a ~68% confidence level that the drone’s true horizontal position is within this reported range from the EKF’s local origin point. By multiplying the pos_horiz_accuracy by the Z-score corresponding to 99% confidence in a normal distribution (≈ 2.576), horizontal error margin is effectively scaled. This adjusts the base of a cylinder on the horizontal plane, within which there may be a 99% confident level of the drone’s Similarly, vertical accuracy can be scaled to define the vertical height of the cylinder, providing a 3D spatial region for the drone’s probable location. Thus, to account for geolocation uncertainty in the minimum safety distance calculation, the _{following equation is defined: ^ ^ ^ ^^^ = 2.576 ∗ ^^^^^^^ ∗ ^^^^^ .} [0069] Stopping distance without wind [0070] The stopping distance of a distance the drone travels from the moment it is supposed to stop (e.g., receives an instruction to stop) until the point where it comes to a complete halt (e.g., actually stops). Excluding environmental perturbations like wind, this distance may include the reaction distance d_reaction and the braking distance d_braking. [0071] The reaction distance, given by dreaction, represents the distance the drone covers during reaction time. Each drone may report its status at intervals marked by P = t₁ −t₀. During these time intervals, the drone is unlikely to be stationary, and therefore the upper-bound on its potential movement may be considered. Specifically, the velocity increase over period P as v₁ = v0 + amax × P, where amax represents the drone’s maximum acceleration capacity and v0 is the velocity at the beginning of the interval. Therefore, the reaction distance may be defined as dreaction = v1 × Treaction where Treaction is the interval between receiving a stop signal and initiating deceleration. Under upper-bound considerations, it may be assumed T_reaction immediately trails P, hence Treaction = t2 − t1. Given that drones flying in the drone zone operate autonomously, T_reaction may be determined by system latency. [0072] At t2, the drone initiates deceleration. In this phase, the drone’s velocity at the onset of braking, v₂ = v₁ + a_max × T_reaction, may be considered, which incorporates the maximal potential increase in speed during the reaction interval. Hence, the braking distance, defined as the distance traversed from deceleration to a complete halt, is expressed as ^_{^^^ ^!^} = _{^^ ^⁄ 2"#^$ , where adec represents the drone’s deceleration capacity. Therefore, the total stopping distance is represented by the equation: ^&^^' = (^) ∗ *^^^$^^^!+ + (^^ ^⁄ 2"#^$ +.} - 18 - ACTIVE 706790912v1 [0073] System latency and the deceleration rate may be assumed to be fixed constants. While reaction time might vary according to the current processing load of the drone, the system may prioritize higher-priority processes (e.g., stop commands) over other lower-priority processes (e.g., computer vision, analytics). This limits variation in reaction times for prioritized processes such as emergency braking. [0074] Finally, as the drone’s maximum acceleration capacity is bounded by the drone’s maximum velocity capacity, the practical formulation of a_max may be accounted in the equation: _{"-^. = /^01"-^., 3^-^. − ^5 * 67, where vmax corresponds to the drone’s maximum velocity} corresponds to the drone’s velocity of reference and T to the time interval in question. [0075] The impact of wind (DC3) [0076] Computing the effect of wind speed and direction, especially with transient wind gusts, versus the drone’s heading and velocity is highly complex due to the unpredictable nature of wind behavior, countered by the drone flight controller’s response to these external forces. The present disclosure, therefore, makes two simplifying assumptions to focus on the worst- case scenario of tailwinds: (1) when wind conditions are within operational specifications, regardless of wind direction, sideways drift of the drone is minimal and remains within an acceptable drift_margin; and (2) tailwinds extend drone stopping distances more than other relative wind directions. [0077] Given a mean wind speed, μwind, and a predefined shape parameter, the scale _{parameter λ can be estimated using 8 = 9:^!# >} . This tailored wind profile can be Γ_{11 + 7} constructed for each flight session. Weibull distribution generally denotes speeds at 10 meters above ground level, adjustments for drone altitudes may be made _{using the wind power law, expressed as: ^(?+ = ^^^@3? A 5 ?^^@ 6 .} [0078] Here, v(z) signifies wind speed at altitude z, vref denotes reference wind speed at reference height zref, and α represents the wind shear exponent, which depends on surface roughness and stability of the atmosphere. This law enables refined altitude-specific wind speed estimations that can be tailored to each drone’s operational necessities. By integrating these elements, trajectory deviations for randomly generated wind profiles can be calculated within the Monte Carlo simulation. [0079] Projected distance during time interval P (DC4) - 19 - ACTIVE 706790912v1 [0080] Projected distance, d_proj, forecasts the drone’s displacement based on current operational conditions. For a drone with current speed v and subjected to a maximum acceleration a_max, the projected distance over a time interval P can be articulated through the _{kinematic equation: ^ ) ^ '^^B = ^ ∗ C + ^ "-^. ∗ C .} [0081] In incorporates the drone’s current motion state and its the specific time frame. In some embodiments, a conservative operative approach is adopted by factoring in a_max as the upper limit of potential acceleration when computing the projected distance. For drone d′, the period P is effectively L to account for communication latency. [0082] Minimum separation distance (DC5) [0083] The tolerances built into the foregoing equations for dynamically computing minimum separation distance may be sufficiently large to accommodate uncertainties associated with potentially nonlinear interactions of stopping distances, wind, geolocation, and other potential contributing factors. [0084] FIG. 4 is an example UI 400 (user interface) for airleasing administration in accordance with one or more embodiments. Not all of the depicted components may be used in all embodiments, and one or more embodiments may include additional, fewer, or different components than those shown in the figure. Variations in the arrangement and type of components may be made without departing from the spirit or scope of the claims as set forth herein. [0085] The ATC system 108 may provide the UI 400 to enable operators to interact with and manage drone zones efficiently. The user interface module 124 provides the UI 400 to an electronic device (e.g., smartphone, tablet, laptop) of the operator. The UI 400 may provide a combination of controls, real-time data visualization, and interaction capabilities, tailored to facilitate safe and effective drone operations. The UI 400 includes an interactive map-based interface. The map 406 may utilize geographic information system (GIS) data and/or integrate with mapping services to provide accurate, high-resolution visuals of the operational area. The operator may define the boundaries 404 of a drone zone by directly interacting with the map 406, using tools to draw, select, or edit regions dynamically. This interaction may include setting altitude ceilings, no-fly zones, and/or operational corridors for sUAS within the drone zone. The map 406 may also display layers of information, such as airspace classifications, - 20 - ACTIVE 706790912v1 obstacles, and/or regulatory constraints, allowing operators to have a comprehensive view of the environment. [0086] In some embodiments, the interface presents real-time environmental data 402, such as current weather conditions, to support informed decision-making. Weather data, including wind speed and direction, temperature, visibility, and precipitation, are integrated from external APIs and/or onboard sensors (e.g., sensors 121 and/or sensors 128) and displayed through intuitive visual indicators like icons, color-coded zones, and/or charts. Alerts and warnings may be generated automatically when weather conditions exceed safe operational thresholds, enabling users to take proactive measures (e.g., increase path buffer radiuses). [0087] In some embodiments, the operator uses the UI 400 to control and configure the drone zone in real time. This may include issuing commands to drones, such as defining or modifying flight paths, prioritizing routes, and/or setting operational constraints like maximum airspeed or geofencing parameters. The UI 400 enables dynamic adjustments, such as resizing the drone zone or reallocating airspace to accommodate changing mission requirements or environmental conditions. [0088] In some embodiments, the operator’s electronic device (e.g., smartphone) may communicate with the ATC system 108 so that data flows reliably and efficiently between the operator’s electronic device and the ATC system 108. Real-time updates from sUAS, environmental sensors, and/or the ATC system 108 are reflected on the UI 400 with minimal latency, enabling operators to maintain situational awareness and respond quickly to evolving conditions. [0089] FIG. 5 is a flow diagram of an example process 500 for airleasing by the ATC system 108 in accordance with one or more embodiments. For explanatory purposes, FIG.5 is described herein with reference to the ATC system 108 and sUAS 102 of FIG.1, and thus the process 500 may be a computer-implemented method. However, this is merely illustrative, and process 500 may be performed by any other system suitable for implementing the process 500. Additionally, for explanatory purposes, the operations of the process 500 are described herein as occurring sequentially or linearly. However, multiple operations of the process 500 may occur in parallel. The operations of the process 500 need not be performed in the order shown, and one or more operations of the process 500 need not be performed or can be replaced by other operations. - 21 - ACTIVE 706790912v1 [0090] At operation 502, the ATC system 108 receives a routing request from the sUAS 102. This request may initiate the process of determining and/or reserving a safe and efficient flight path within the drone zone 100 (e.g., operational airspace), accounting for current constraints and environmental conditions. [0091] The routing request is a structured data packet transmitted from the sUAS 102 to the ATC system 108, sent via a communication protocol such as MQTT or MAVLink. The routing request may include parameters for path planning, including the start position, which may represent the current location of the sUAS 102, and the end position, denoting the desired destination. These positions may be defined as GPS coordinates, but may also include altitude and orientation information to facilitate three-dimensional routing in complex airspace. [0092] Upon receiving the routing request, the ATC system 108 may validate the inputs to confirm that the inputs are complete and fall within the boundaries of the managed airspace (e.g., the drone zone 100). The start and end coordinates may be verified for precision, such as within a margin of error. The requested route may be checked against operational boundaries, including altitude ceilings, no-fly zones, and/or geofenced areas. The request may be evaluated to confirm compliance with regulatory and/or mission-specific constraints, such as restricted flight times or prohibited areas. [0093] The ATC system 108 may then initialize the routing process, mapping the start and end positions onto the airspace reservation graph 200. The graph 200 may represent the three- dimensional operational space of the drone zone, incorporating real-time data about environmental conditions, active reservations, and/or obstacles. The graph 200 may be accessed and/or maintained by the ATC system 108 and/or may be updated continuously using inputs from sensors, external data sources, and/or other sUAS. [0094] Before proceeding to pathfinding, the ATC system 108 may also consider additional metadata included in the routing request, such as the sUAS’s capabilities (e.g., maximum speed, turning radius, or endurance) and mission priorities. These factors may influence the optimization criteria used during pathfinding so that the generated route is not only feasible but also aligned with the operational goals. [0095] At operation 504, the ATC system 108 generates a 3D path based on the directed airspace reservation graph 200 and the routing request. In the path generation phase of routing, the ATC system 108 generates a 3D path from the start position to the end position using the directed airspace reservation graph 200 and/or the parameters specified in the routing request. - 22 - ACTIVE 706790912v1 [0096] The path may be a sequence of connected 3D segments, each segment representing a portion of the path. Path segments may be defined by their start and end points, spatial dimensions, and/or temporal properties. The ATC system 108 may incorporate an adjustable safety buffer around each segment to provide additional margin against potential conflicts, such as nearby drones or environmental hazards (e.g., wind that may push drones off course). The buffer may be represented as an extended volume around the path, dynamically adjusted based on conditions such as weather and congestion. Weather conditions, such as wind speed or turbulence, can increase the risk of deviation from the planned path, which may call for a larger safety buffer to compensate for potential deviation. In congested airspace, the buffer may be expanded to ensure sufficient separation between sUAS. Conversely, in low-density areas, the buffer may be reduced to optimize airspace utilization. Different segments of the path may have varying safety requirements based on localized factors, such as proximity to obstacles or regulatory constraints. The safety buffer may be varied across and/or within path segments. [0097] In some embodiments, the ATC system 108 uses a pathfinding algorithm (e.g., A*) to generate the route. The pathfinding algorithm may operate by searching for the shortest viable path from the start to the end position, minimizing the total cost while respecting constraints. For 3D routing, the ATC system 108 may evaluate potential paths through the airspace reservation graph 200, where each node represents a point or waypoint, and edges represent possible transitions between nodes. [0098] During execution of the pathfinding algorithm, the ATC system 108 may build the path incrementally, segment by segment. For each segment, the ATC system 108 may select the next node by evaluating the cost function, f(n)=g(n)+h(n), where g(n) is the cumulative cost from the start to the current node, and h(n) is the heuristic estimate of the remaining cost to the end position (e.g., straight-line distance to the end). The safety buffer may be factored into the cost calculation, with larger buffers increasing the path cost to prioritize safety while balancing airspace efficiency. The ATC system 108 continues until it reaches the end position or determines that no viable path exists within the constraints. If a conflict-free path is found, the ATC system 108 compiles the segments into a coherent 3D route, adjusting the safety buffer as needed along each segment to reflect environmental or traffic-specific factors. Once the path is generated, the path may be validated against the airspace reservation graph 200 to verify compatibility with active reservations. - 23 - ACTIVE 706790912v1 [0099] In some embodiments, the ATC system 108 generates a simple (e.g., straight-line and/or single segment) path without resorting to pathfinding algorithms (e.g., A*) for computational efficiency. This approach may be sufficient when the airspace is relatively uncongested, free of significant obstacles, and/or operational constraints allow for a direct route between start and end positions. In such scenarios, the ATC system 108 simplifies the path generation process by directly connecting the start and end positions with a single 3D line segment. The ATC system 108 may apply a safety buffer around the path to account for uncertainties such as slight deviations in flight trajectory or environmental variations. If minor conflicts are detected along the simple path, the ATC system 108 may adjust the path slightly by modifying the start or end coordinates (e.g., shifting the altitude or lateral position) and/or by splitting the straight path into a small number of segments to bypass a conflict. [0100] In some embodiments, the ATC system 108 handles multi-threaded pathfinding, enabling it to process multiple routing requests simultaneously. When a routing request is received, the ATC system 108 spawns an independent thread or task assigned to the routing request. Each thread operates in isolation, executing its own instance of the pathfinding algorithm, such as A*. This prevents the computations for one routing request from interfering with others. The scheduler of the ATC system 108 manages the allocation of processing resources to threads, optimizing for parallel execution and minimizing delays caused by contention for shared resources. [0101] To prevent conflicts between routing requests, the ATC system 108 may use shared data structures, such as an airspace reservation graph and/or an R-tree, to store and query active reservations. The shared data structures are accessed in a thread-safe manner using locks, mutexes, or other atomic operations for consistency. For example, when a thread identifies a potential conflict with an existing reservation, the thread locks the relevant section of a data structure, modifies the data structure to include the new reservation, and releases the lock. This prevents two threads from inadvertently creating overlapping reservations. [0102] Each thread independently performs pathfinding for its assigned routing request. If A* is used, for example, the thread dynamically evaluates potential paths, querying a shared airspace reservation graph 200 to detect conflicts. Because the airspace reservation graph 200 may continuously be updated with new reservations from other threads, the ATC system 108 provides each thread with access to the latest information, allowing it to make real-time - 24 - ACTIVE 706790912v1 adjustments during pathfinding. This prevents threads from generating paths that inadvertently conflict with newly created reservations. [0103] To improve efficiency, the ATC system 108 may prioritize threads based on the urgency or complexity of the routing requests. For example, high-priority threads handling emergency routes preempt lower-priority threads so that critical operations are addressed first. Additionally, the ATC system 108 may dynamically allocate computational resources to threads based on the complexity of the routing request, dedicating more processing power to complex paths that require extensive computations. For example, a routing request for a straight path is allocated less processing power than a routing request for a circular path as the straight path does not use a pathfinding algorithm. [0104] At operation 506, the ATC system 108 modifies the directed airspace reservation graph 200 to include at least part of the path (e.g., one or more path segments). For efficient and conflict-free use of the drone zone, the ATC system 108 may modify the directed airspace reservation graph 200 by incorporating segments of the generated path (from operation 504) for the sUAS 102. This operation balances the desire for immediate safety with the efficient utilization of the drone zone by reserving the portions of the path that are relevant to the current position and/or near-future trajectory of the sUAS 102. In some embodiments, the ATC system 108 reserves the complete path (from operation 504) for the sUAS 102 [0105] After the sUAS 102 requests a route and a viable path is generated, the ATC system 108 reserves the path segment that corresponds to the current location of the sUAS 102 and, in some embodiments, a number of subsequent segments. This approach minimizes the occupation of the drone zone 100 that the sUAS 102 will not reach immediately (or within a threshold period of time), allowing other sUAS (e.g., sUAS 104, 106) to use portions of the drone zone 100 that the sUAS 102 has yet to traverse. The reservation for each segment may include its spatial volume, temporal parameters (e.g., expected entry and exit times), and/or a safety buffer to account for environmental or operational uncertainties. [0106] To modify the airspace reservation graph 200, the ATC system 108 updates the graph 200 by creating nodes (vertices) and directed edges for each reserved segment that represent the segment and its relationship to adjacent segments. The nodes may store metadata about the reserved airspace, such as spatial boundaries, associated safety buffers, and/or the expected timing. The edges may store the sequence of traversal, for example, indicating the order in which the sUAS 102 will navigate the segments. - 25 - ACTIVE 706790912v1 [0107] In some embodiments, before adding a reservation, the ATC system 108 checks for conflicts with existing reservations or obstacles (e.g., objects, no-fly zones, environmental hazards) using the shared airspace reservation graph 200, R-tree, and/or similar structure. If conflicts are detected, the ATC system 108 may adjust the path and/or modify the reservation (e.g., narrowing the safety buffer) to resolve the conflict while maintaining safety. This enables the airspace reservation graph 200 to remain a valid representation of active and planned airspace usage. [0108] In some embodiments, rather than reserving the entire path at once, the ATC system 108 reserves additional segments dynamically as the sUAS 102 progresses along its route. When the sUAS 102 reaches a reserved segment, the system may pre-emptively reserve the next set of segments along the path. This incremental approach reduces the amount of airspace in the drone zone 100 held unnecessarily, allowing other sUAS to operate more freely while still maintaining a safe buffer for the sUAS 102. [0109] In some embodiments, as the sUAS moves through its reserved path, the ATC system 108 also updates the airspace reservation graph 200 to release segments that the sUAS 102 has completed. This real-time modification promptly removes expired or unutilized reservations, freeing up airspace in the drone zone 100 for other operations and preventing graph congestion. [0110] From a system-level perspective, the ATC system 108 may use a combination of locks, atomic operations, and/or similar mechanisms so that updates to the airspace reservation graph 200 are thread-safe and do not cause conflicts when multiple threads (associated with multiple requests) are reserving segments simultaneously. [0111] At operation 508, in response to the routing request, the ATC system 108 authorizes (e.g., causes) the sUAS 102 to travel from the start point to the end point in accordance with the reserved path segments. Once the path is generated and the initial segments are reserved in the directed airspace reservation graph 200, the ATC system 108 communicates the routing instructions to the sUAS 102 via its communication module 120. These instructions may include detailed waypoints, which may represent the transition points between path segments, and other operational parameters such as target speeds, altitudes, and/or timing constraints. The processing module 126 of the sUAS 102 interprets these instructions and interface with the flight controller 132 to execute appropriate maneuvers to follow the path segments. - 26 - ACTIVE 706790912v1 [0112] As the sUAS 102 traverses the reserved segments, the ATC system 108 may continuously monitor the progress of the sUAS 102 using telemetry data from the sUAS 102. This telemetry data may include real-time updates on position, velocity, orientation, and/or system status. By comparing this telemetry against the generated path, the ATC system 108 may verify that the sUAS 102 remains within its reserved airspace and may identify any deviations or potential conflicts that may arise. [0113] To maintain coordination, the ATC system 108 may dynamically reserve and release path segments as the sUAS 102 traverses the planned path. When the sUAS 102 approaches the end of its currently reserved segment, the ATC system 108 may preemptively reserve the next set of segments along the path, enabling uninterrupted travel. Simultaneously, segments that the sUAS 102 has already traversed may be released from the airspace reservation graph 200, freeing up airspace in the drone zone 100 for other sUAS operations. [0114] In cases where environmental or operational conditions necessitate adjustments, the ATC system 108 issues updated routing instructions to the sUAS 102. For instance, if a sudden obstacle or conflict is detected ahead, the ATC system 108 reroutes the sUAS by reserving alternative segments and providing new waypoints. The sUAS 102 may adjust its flight path accordingly, leveraging its onboard sensors and flight controller to execute smooth transitions. [0115] While the sUAS 102 is traversing a segment, the ATC system 108 may receive a notification (e.g., from the sUAS 102 and/or a remote server) notifying the ATC system 108 of environmental conditions, traffic conditions, and/or sUAS 102 conditions. When the ATC system 108 receives a notification, the ATC system 108 may dynamically adjust the planned route to respond to the notified condition to maintain the safety and efficiency of the operation. Notifications may correspond to a variety of conditions, such as adverse environmental factors (e.g., unexpected high winds, reduced visibility), changing traffic conditions (e.g., nearby sUAS or manned aircraft entering the vicinity), or issues with the sUAS 102 itself (e.g., low battery, sensor malfunction). [0116] Upon receiving the notification, the ATC system 108 may evaluate the reported condition in the context of the directed airspace reservation graph 200. If the condition necessitates a change in the path of the sUAS 102, the ATC system 108 initiates a path replanning process. Using the latest data, including updated environmental factors and traffic information, the ATC system 108 generates a new 3D path that avoids conflicts and mitigates the reported issue. For example, if the notification indicates severe turbulence in the current - 27 - ACTIVE 706790912v1 segment, the ATC system 108 computes an alternate route at a different altitude or lateral position to bypass the affected area. The newly generated path is integrated into the directed airspace reservation graph 200. The ATC system 108 may reserve the appropriate segments along the new path so they do not conflict with existing reservations. Simultaneously, the ATC system 108 may release previously reserved segments that the sUAS 102 will no longer use, freeing up airspace for other operations. [0117] Once the new path is generated and reserved, the ATC system 108 communicates updated routing instructions to the sUAS 102. These instructions may include the revised waypoints, target speeds, and/or any adjustments to operational parameters, such as altitude limits or timing constraints. The processing module 126 and flight controller 132 of the sUAS 102 execute the changes, transitioning seamlessly to the new path. The ATC system 108 may provide intermediate waypoints or holding positions for a smooth and safe transition between the current and updated routes. [0118] FIG.6 is a block diagram of an example computing system 600. The ATC system 108 may be embodied by a computing system 600. A computing system 600 is a desktop computer, laptop, smartphone, tablet, and/or any other electronic device having the ability to execute instructions, such as those stored within a non-transitory computer-readable medium. Furthermore, while described and illustrated in the context of a single computing system 600, those skilled in the art will also appreciate that the various tasks described hereinafter may be practiced in a distributed environment having multiple computing systems 600 linked via a local- or wide-area network in which the executable instructions may be associated with and/or executed by one or more of multiple computing systems 600. [0119] In its most basic configuration, the computing system 600 includes at least one processing unit 602 and at least one memory 604 linked via a bus 606. Depending on the exact configuration and type of computing system environment, memory 604 is volatile (such as RAM 610), non-volatile (such as ROM 608, flash memory, etc.) or some combination of the two. [0120] Computing system 600 has additional features and/or functionality. For example, computing system 600 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks, tape drives and/or flash drives. Such additional memory devices may be made accessible to the computing system 600 by means of, for example, a hard disk drive interface 612, a magnetic disk drive interface 614, and/or an - 28 - ACTIVE 706790912v1 optical disk drive interface 616. As will be understood, these devices, which may be linked to the system bus 606, respectively, allow for reading from and writing to a hard drive 618, reading from or writing to a removable magnetic disk 620, and/or for reading from or writing to a removable optical disk 622, such as a CD/DVD ROM or other optical media. The drive interfaces and their associated computer-readable media may allow for the non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computing system 600. Those skilled in the art will further appreciate that other types of computer-readable media that can store data may be used for this same purpose. Examples of such media devices include, but are not limited to, magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories, nano-drives, memory sticks, other read/write and/or read-only memories and/or any other method or technology for storage of information such as computer-readable (e.g., computer-implemented) instructions, data structures, program modules or other data. Any such computer storage media may be part of computing system 600. [0121] A number of program modules may be stored in one or more of the memory/media devices. For example, a basic input/output system (BIOS 624), containing the basic routines that help to transfer information between elements within the computing system 600, such as during start-up, may be stored in ROM 608. Similarly, RAM 610, hard drive 618, and/or peripheral memory devices may be used to store computer-executable instructions comprising an operating system 626, one or more applications programs 628, other program modules 630, and/or program data 632. Still further, computer-executable instructions may be downloaded to the computing system 600 as needed, for example, via a network connection. The applications programs 628 may include, for example, programs for airspace reservation graphs, path finding, and/or the like. [0122] An end-user may enter commands and information into the computing system 600 through input devices such as a keyboard 634 and/or a pointing device 636. While not illustrated, other input devices may include a microphone, a joystick, a game pad, a scanner, etc. These and other input devices would typically be connected to the processing unit 602 by means of a peripheral interface 638 which, in turn, would be coupled to bus 606. Input devices may be directly or indirectly connected to processing unit 602 via interfaces such as, for example, a parallel port, game port, firewire, or a universal serial bus (USB). To view information from the computing system 600, a monitor 640 or other type of display device may - 29 - ACTIVE 706790912v1 also be connected to bus 606 via an interface, such as via video adapter 642. In addition to the monitor 640, the computing system 600 may also include other peripheral output devices, not shown, such as speakers and printers. [0123] The computing system 600 may also utilize logical connections to one or more computing system environments. Communications between the computing system 600 and the remote computing system environment may be exchanged via a further processing device, such as a network router 641, that is responsible for network routing. Communications with the network router 641 may be performed via a network interface component 644. Thus, within such a networked environment, e.g., the Internet, wide area network (WAN), local area network (LAN), or other like type of wired or wireless network, it will be appreciated that program modules depicted relative to the computing system 600, or portions thereof, may be stored in the memory storage device(s) of the computing system 600. [0124] The computing system 600 may also include localization hardware 646 for determining a location of the computing system 600. In embodiments, the localization hardware 646 may include, for example, a GPS antenna, an RFID chip or reader, a Wi-Fi antenna, or other computing hardware that may be used to capture or transmit signals that may be used to determine the location of the computing system 600. [0125] While this disclosure has described certain embodiments, it is understood that the claims are not intended to be limited to these embodiments except as explicitly recited in the claims. On the contrary, the instant disclosure is intended to cover alternatives, modifications, and equivalents, which may be included within the spirit and scope of the disclosure. Furthermore, in the detailed description of the present disclosure, numerous specific details are set forth in order to provide a thorough understanding of the disclosed embodiments. However, the subject technology is not limited to the specific details set forth herein and can be practiced using one or more other embodiments. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure various aspects of the present disclosure. Additionally, in one or more embodiments, structures and components are shown in block diagram form to avoid obscuring the concepts of the subject technology. [0126] Some portions of the detailed descriptions of this disclosure have been presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer or digital system memory. These descriptions and - 30 - ACTIVE 706790912v1 representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. A procedure, logic block, process, etc., is herein, and generally, conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these physical manipulations take the form of electrical or magnetic data capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system or similar electronic computing device. For reasons of convenience, and with reference to common usage, such data is referred to as bits, values, elements, symbols, characters, terms, numbers, or the like, with reference to various presently disclosed embodiments. It is understood, however, that these terms are to be interpreted as referencing physical manipulations and quantities and are merely convenient labels that should be interpreted further in view of terms commonly used in the art. [0127] Unless specifically stated otherwise, as apparent from the discussion herein, it is understood that throughout discussions of the present embodiment, discussions utilizing terms such as “determining” or “outputting” or “transmitting” or “recording” or “locating” or “storing” or “displaying” or “receiving” or “recognizing” or “utilizing” or “generating” or “providing” or “accessing” or “checking” or “notifying” or “delivering” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data. The data is represented as physical (electronic) quantities within the computer system’s registers and memories and is transformed into other data similarly represented as physical quantities within the computer system memories or registers, or other such information storage, transmission, or display devices as described herein or otherwise understood to one of ordinary skill in the art. [0128] It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. - 31 - ACTIVE 706790912v1 [0129] As used herein, the phrase “at least one of” preceding a series of items, with the term “and” or “or” to separate any of the items, modifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require selection of at least one of each item listed; rather, the phrase allows a meaning that includes at least one of any one of the items, and/or at least one of any combination of the items, and/or at least one of each of the items. By way of example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” each refers to only A, only B, or only C; any combination of A, B, and C; and/or at least one of any of A, B, and C. [0130] The predicate words “configured to,” “operable to,” and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. In one or more implementations, a processor configured to monitor and control an operation or component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code. [0131] Phrases such as an aspect, the aspect, another aspect, some aspects, one or more aspects, an implementation, the implementation, another implementation, one or more implementations, one or more implementations, an embodiment, the embodiment, another embodiment, one or more implementations, one or more implementations, a configuration, the configuration, another configuration, some configurations, one or more configurations, the subject technology, the disclosure, the present disclosure, other variations thereof and alike are for convenience and do not imply that a disclosure relating to such phrase(s) is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. A disclosure relating to such phrase(s) may apply to all configurations or one or more configurations. A disclosure relating to such phrase(s) may provide one or more examples. A phrase such as an aspect or some aspects may refer to one or more aspects and vice versa, and this applies similarly to other foregoing phrases. [0132] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” or as an “example” is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, to the extent that the term “include,” “have,” or the like is used in the description - 32 - ACTIVE 706790912v1 or the claims, such term is intended to be inclusive in a manner similar to the term “comprise” as “comprise” is interpreted when employed as a transitional word in a claim. [0133] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein but are to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Headings and subheadings, if any, are used for convenience only and do not limit the subject disclosure. - 33 - ACTIVE 706790912v1

Claims

CLAIMS What is claimed is: 1. A computer-implemented method comprising: receiving, by an air traffic control (ATC) system and from an unmanned aerial system (UAS), a routing request, the routing request including a first start position and a first end position; generating, by the ATC system, a three-dimensional path based on a directed airspace reservation graph and the routing request, the path beginning at the first start position, concluding at the first end position, and including a set of path segments; modifying, by the ATC system, the directed airspace reservation graph to include at least part of the set of path segments; and causing, by the ATC system responsive to the routing request, the UAS to travel from the first start position to the first end position in accordance with the at least part of the set of path segments.

2. The computer-implemented method of claim 1, wherein the three-dimensional path includes a safety buffer.

3. The computer-implemented method of claim 2, wherein the safety buffer includes a set of adjustable radiuses associated with the set of path segments, wherein the set of adjustable radiuses are based on any one or more of environmental conditions or traffic conditions.

4. The computer-implemented method of claim 1, wherein generating the path comprises: spawning one or more threads associated with a multi-threaded path finding process; and atomically generating, with the one or more threads, the path preventing conflict with other threads.

5. The computer-implemented method of claim 1, wherein generating the path comprises: - 34 - ACTIVE 706790912v1 selecting a potential path segment in the directed airspace reservation graph, the potential path segment including a second start position and a second end position; and in response to determining that the potential path segment is free of conflict in the directed airspace reservation graph, selecting another potential path segment in the directed airspace reservation graph, the other potential path segment including a third start position located at the second end position and a third end position.

6. The computer-implemented method of claim 5, wherein modifying the directed airspace reservation graph comprises: in response to determining that the third end position is located at the first end position, reserving one or more of the potential path segments on the directed airspace reservation graph.

7. The computer-implemented method of claim 1, wherein modifying the directed airspace reservation graph to include at least part of the set of path segments comprises: reserving a first path segment corresponding to the first start position; and reserving a predetermined number of path segments following the first path segment.

8. The computer-implemented method of claim 1, further comprising: in response to determining the UAS has traversed a path segment of the path, releasing the traversed path segment on the directed airspace reservation graph.

9. The computer-implemented method of claim 1, further comprising and while the UAS is travelling: in response to receiving a notification, generating, for the UAS, another three- dimensional path based on the directed airspace reservation graph, the routing request, and the notification, wherein the other path includes a second start position and a second end position; modifying the directed airspace reservation graph based on the other path; and causing the UAS to travel from the second start position to the second end position in accordance with the other path. - 35 - ACTIVE 706790912v1

10. The computer-implemented method of claim 9, wherein the notification corresponds to any one or more of environmental conditions, traffic conditions, or UAS conditions.

11. The computer-implemented method of claim 9, wherein the notification is from any one or more of a sensor, a remote server, or a UAS.

12. A computing system for air traffic control comprising: a processor; and a non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the computing system to perform operations comprising: receiving, by the computing system and from an unmanned aerial system (UAS), a routing request, the routing request including a first start position and a first end position; generating, by the computing system, a three-dimensional path based on a directed airspace reservation graph and the routing request, the path beginning at the first start position, concluding at the first end position, and including a set of path segments; modifying, by the computing system, the directed airspace reservation graph to include at least part of the set of path segments; and causing, by the computing system responsive to the routing request, the UAS to travel from the first start position to the first end position in accordance with the at least part of the set of path segments.

13. The computing system of claim 12, wherein the three-dimensional path includes a safety buffer, the safety buffer including a set of adjustable radiuses associated with the set of path segments, wherein the set of adjustable radiuses are based on any one or more of environmental conditions or traffic conditions.

14. The computing system of claim 12, wherein generating the path comprises: spawning one or more threads in a multi-threaded path finding process; and - 36 - ACTIVE 706790912v1 atomically generating, with the one or more threads, the path preventing conflict with other threads.

15. The computing system of claim 12, wherein generating the path comprises: selecting a potential path segment in the directed airspace reservation graph, the potential path segment including a second start position and a second end position; and in response to determining that the potential path segment is free of conflict in the directed airspace reservation graph, selecting another potential path segment in the directed airspace reservation graph, the other potential path segment including a third start position located at the second end position and a third end position.

16. The computing system of claim 15, wherein modifying the directed airspace reservation graph comprises: in response to determining that the third end position is located at the first end position, reserving one or more of the potential path segments on the directed airspace reservation graph.

17. The computing system of claim 12, wherein modifying the directed airspace reservation graph to include at least part of the set of path segments comprises: reserving a first path segment corresponding to the first start position; and reserving a predetermined number of path segments following the first path segment.

18. The computing system of claim 12, further comprising: in response to determining the UAS has traversed a path segment of the path, releasing the traversed path segment on the directed airspace reservation graph.

19. The computing system of claim 12, further comprising and while the UAS is travelling: receiving a notification, wherein the notification corresponds to any one or more of environmental conditions, traffic conditions, or UAS conditions, and the notification is from any one or more of a sensor, a remote server, or a UAS; - 37 - ACTIVE 706790912v1 in response to receiving the notification, generating, for the UAS, another three- dimensional path based on the directed airspace reservation graph, the routing request, and the notification, wherein the other path includes a second start position and a second end position; modifying the directed airspace reservation graph based on the other path; and causing the UAS to travel from the second start position to the second end position in accordance with the other path.

20. A non-transitory computer-readable medium storing instructions that, when executed by a processor of a computing system, cause the computing system to perform operations comprising: receiving, by the computing system and from an unmanned aerial system (UAS), a routing request, the routing request including a first start position and a first end position; generating, by the computing system, a three-dimensional path based on a directed airspace reservation graph and the routing request, the path beginning at the first start position, concluding at the first end position, and including a set of path segments; modifying, by the computing system, the directed airspace reservation graph to include at least part of the set of path segments; causing, by the computing system responsive to the routing request, the UAS to travel from the first start position to the first end position in accordance with the at least part of the set of path segments; and in response to determining the UAS has traversed a path segment of the path, releasing the traversed path segment on the directed airspace reservation graph. - 38 - ACTIVE 706790912v1