PaperlayerView exact revision on arXiv

Source-linked AI summary

Internet of Drones

Mirmojtaba Gharibi, Raouf Boutaba, Steven L. Waslander

arXiv:1601.01289v2cs.NIcs.RO

TL;DR

The paper addresses the lack of a rigorous, drone-specific architecture for coordinating UAV access to controlled airspace and navigation. It develops a conceptual layered architecture by relating IoD to air traffic control, cellular networks, and the Internet, and specifies generic services and required features. The result is a blueprint and vocabulary that formulate IoD design problems and guide future protocol, simulation, and physical implementation work.

  • Problem

    Drone applications need coordinated airspace management and navigation, but existing publications had not provided a rigorous universal architecture for drone traffic management.

  • Method

    The paper develops a conceptual layered IoD architecture and compares it with air traffic control, cellular networks, and the Internet to define concepts, services, and system features.

  • Results

    The paper produces a blueprint and vocabulary for IoD implementation, identifies relationships and adoption barriers across routing, congestion control, admission control, and addressing, and specifies generic navigation and communication services.

  • Takeaways & Limitations

    The architecture provides a foundation for developing protocols and implementations for diverse drone applications, while establishing well-defined problems for further research.

  • Takeaways & Limitations

    The conceptual architecture remains to be validated through instantiated systems, simulations, and physical platforms, with routing and congestion control requiring future work.

Abstract

from arXiv · show

The Internet of Drones (IoD) is a layered network control architecture designed mainly for coordinating the access of unmanned aerial vehicles to controlled airspace, and providing navigation services between locations referred to as nodes. The IoD provides generic services for various drone applications such as package delivery, traffic surveillance, search and rescue and more. In this paper, we present a conceptual model of how such an architecture can be organized and we specify the features that an IoD system based on our architecture should implement. For doing so, we extract key concepts from three existing large scale networks, namely the air traffic control network, the cellular network, and the Internet and explore their connections to our novel architecture for drone traffic management.

I. INTRODUCTION

The paper proposes the Internet of Drones as a generic architecture for coordinated UAV access to controlled airspace and navigation. It addresses an emerging need for scalable drone traffic management by drawing lessons from established network structures while identifying IoD-specific challenges.

  • The IoD supports coordinated airspace access and navigation for applications including delivery, surveillance, inspection, search and rescue, agriculture, and cinematography.
  • Thousands of package-delivery flights could create conflicts along similar or intersecting routes, increasing the need for robust airspace allocation.
  • Before this work, drone traffic-management architecture lacked rigorous academic publication despite prototype announcements and related UTM and industry efforts.
  • The architecture studies air traffic control, cellular networks, and the Internet for scalable and fault-tolerant design lessons, while recognizing that none fully solves IoD challenges.
  • ATC assigns United States airspace to 24 ARTCC-managed areas, whereas thousands of drones require decentralized solutions and autonomous separation rather than centralized human intervention.

B. Cellular Network

Cellular networks illustrate partitioned coverage, localized base stations, and centralized admission control. The paper adapts these ideas cautiously because IoD computation, shared airspace, and provider competition make a centralized design unsuitable.

  • Cellular coverage is partitioned into cells whose base stations serve local users, with smaller cells in densely populated areas and larger cells in rural regions.
  • Cell sizes and base-station capacity are shaped by expected user demand, while neighboring stations use different frequencies to reduce interference.
  • Unlike the Internet’s best-effort model, cellular networks reject calls when resources cannot sustain them through completion, including future handoffs.
  • IoD differs from cellular networks because a drone’s destination is more predictable, enabling more optimized resource use than mobile-call admission.
  • A centralized IoD design is unsuitable because tasks are computationally intensive and airspace portions are not under one corporation’s exclusive control.

C. Internet

The paper uses the Internet’s layered, decentralized design as a reference for IoD while accounting for the physical cost of routing drones. It defines a structured airspace and generic services around navigation and coordination.

  • The Internet separates concerns across five service layers, allowing upper layers to use lower-layer services.
  • IoD can adapt Internet routing because its longer time scale permits more optimal route calculation, but drones cannot be dropped like buffered packets.
  • The architecture connects IoD with existing work on routing, congestion control, admission control, and addressing while identifying barriers to direct adoption.
  • IoD provides extensible generic services, especially coordinated navigation between nodes and location-aware communication for drone applications.
  • Airspace is organized into zones containing directed airways, intersections, and nodes, with regulated movement in transit areas and free flight inside nodes.
  • The zone graph supports within-zone pathways, while the interzone graph represents routes through gates and assigns transit costs between them.

B. Components

The IoD consists of drones and Zone Service Providers (ZSPs) connected through the cloud, with zones, graphs, and layered services organizing navigation and coordination. ZSPs manage zone-specific navigation, coordinate handoffs, and support extensible services through standard protocols.

  • Components: The architecture comprises drones and ZSPs, with all components connected to the cloud for communication between any two components.
  • Components: Within each zone, a ZSP provides navigation information between elements to requesting drones, while adjacent ZSPs coordinate responsibility transfer at zone boundaries.
  • Components: Zone graphs represent airways, intersections, and nodes, whereas interzone graphs represent gates connected by transits with associated travel costs.
  • Components: Drones must autonomously navigate planned routes, use sense-and-avoid technology, and support emergency landing beyond line-of-sight operation.
  • Components: The layered architecture separates navigation into interzone, within-zone, and trajectory tasks while providing extensible common services for applications.
  • Components: IoD systems must implement specified features and define protocols and interfaces that make those features accessible.

1) Airspace Layer:

The airspace layer keeps drones within the geometric boundaries of planned airways, intersections, and nodes while supporting monitoring, control, collision avoidance, and weather-aware execution.

  • 1) Airspace Layer:: ZSPs must maintain geometric maps of airways, intersections, and nodes and provide trajectories that remain inside their boundaries.
  • 1) Airspace Layer:: Drones must periodically broadcast three-dimensional coordinates and future trajectories for airspace path planning and progress calculation.
  • 1) Airspace Layer:: ZSPs may request precise maneuvers such as holding, moving to a new point, or landing at a point.
  • 1) Airspace Layer:: Drones must override planned trajectories to avoid dynamic obstacles and communicate with nearby drones for coordinated collision-avoidance maneuvers.
  • 1) Airspace Layer:: ZSPs must provide weather conditions, including wind speed and temperature, so drones can account for them during trajectory execution.

2) Node to Node layer:

The node-to-node layer manages movement within a zone by maintaining an up-to-date zone graph, assigning feasible pathways, and handling refuelling, emergencies, control, and congestion reporting.

  • 2) Node to Node layer:: ZSPs maintain a zone graph augmented with drone locations, future paths, progress, occupancy, spacing, and element metadata.
  • 2) Node to Node layer:: Drones broadcast their current element, progress, future path, and estimated remaining fuel time to all ZSPs.
  • 2) Node to Node layer:: ZSPs provide pathways and contingency paths between elements while checking drone performance against minimum path requirements and disclosing relevant metadata.
  • 2) Node to Node layer:: ZSPs direct drones needing refuelling to compatible fuel-station nodes according to the drone’s energy technology.
  • 2) Node to Node layer:: The layer supports commands to hold, move to an element, or land at a node, together with SOS handling and detection of abruptly silent drones.
  • 2) Node to Node layer:: Upon request, ZSPs provide congestion reports between any two elements inside a zone.

3) End to End layer:

The end-to-end layer coordinates travel across zones using interzone knowledge, gate and transit routing, handoff, and congestion communication, while the service layer broadcasts extensible zone-related messages.

  • 3) End to End layer:: Each ZSP must store at least partial interzone-graph information about gates and transit costs in its zone, augmented by drone broadcasts.
  • 3) End to End layer:: ZSPs provide the next intermediate gate between adjacent zones, using transit cost to support shorter routes.
  • 3) End to End layer:: Drones switch to the ZSP responsible for a new adjacent zone, whose ZSP must handle incoming and outgoing drones.
  • 3) End to End layer:: ZSPs explicitly notify at least adjacent-zone ZSPs about congestion on gates and transits.
  • 3) End to End layer:: The extensible service layer provides a common platform for broadcasting zone-related messages, such as local task requests, to drones in a zone.

5) Application layer:

The application layer has no prescribed feature requirements because applications are expected to build on generic services provided by the IoD’s lower layers. The architecture also assumes regulated, registered drone operations within municipally defined airspace elements.

  • 5) Application layer:: The application layer has no feature requirements, leaving future applications to use the generic services supplied by the four lower layers.Providing shared airspace navigation, control, and other services is intended to support many applications simultaneously rather than dedicated services for each application.
  • 5) Application layer:: IoD systems must address security threats including authentication, message jamming, airspace clogging, and hacking of drones or ZSPs.
  • 5) Application layer:: The architecture assumes public airspace ownership, government registration of drones, and operation under a selected IoD operating model.The passage specifies registration requirements for drone owners and notes that the paper adopts one of several possible operating models.
  • 5) Application layer:: Municipalities, consulting the FAA, define zones and the public airways, intersections, and nodes within them; operations must remain inside these elements.Areas outside designated zones are treated as unregulated, while unauthorized entry into private elements is considered trespassing.
  • 5) Application layer:: Private-airspace owners may design maps of private elements subject to municipal constraints, while IoDSP licenses and nondiscrimination obligations are set by municipalities.Municipal policies can regulate drone capacity or density and must be enforced.

B. Interactions with outside

Interactions outside the IoD architecture are implementation choices involving entities such as weather services, the FAA, fuel stations, and existing cellular infrastructure. The design combines standard-protocol interoperability, generic services, collision-free routes, and local autonomous control to support scalable drone operations.

  • B. Interactions with outside: External entities and protocols are not fixed by the architecture; they are selected during implementation to illustrate how an IoD system might operate.Potential participants include weather services, the FAA, fuel stations, drone owners, and other organizations.
  • B. Interactions with outside: Weather services can coordinate automated network disabling or enabling, while FAA no-fly declarations can be communicated to ZSPs through protocols.
  • B. Interactions with outside: Existing cellular base stations are positioned as potential ZSP deployments because they are already distributed, connected, and capable of running ZSP software.
  • B. Interactions with outside: Open standard protocols let drones and ZSPs exchange information across competing implementations, while drone position and future-path broadcasts give ZSPs a shared traffic view.
  • B. Interactions with outside: Openness, modularity, and interoperability are intended to lower network costs and entry barriers while allowing competition in implementations and algorithms.
  • B. Interactions with outside: Local autonomous subsystems contain failures and reduce computational complexity by limiting path reservations to the current zone.No ZSP can reserve a path beyond its zone, reducing the effect of a missed reservation on the wider system.
  • B. Interactions with outside: Generic services are designed to support diverse current and future applications rather than specialized application-specific services.
  • B. Interactions with outside: Collision-free airways and intersections reduce the need for costly three-dimensional urban mapping by guaranteeing selected safe trajectories.

B. Routing

The IoD favors moving drones while requesting directions from zone service providers rather than reserving entire paths, because future positions are difficult to predict. This approach can use airspace more efficiently but may require occasional grounding and motivates new routing algorithms.

  • Routing: IoD routing should avoid reserving an entire source-to-destination path because precise future drone positions are unpredictable.The advocated approach resembles the Internet’s incremental direction requests rather than ATM-style advance reservation.
  • Routing: Occasional grounding by zone service providers may result when insufficient airspace becomes available along a drone’s route.Grounding consumes energy, increases travel delay, and wastes airspace.
  • Routing: The routing problem is more complex than cellular admission because multiple routes may connect the same pair of nodes.The authors contrast IoD’s zone-graph resources with simpler future-cell capacity checks in cellular networks.
  • Routing: A routing algorithm that avoids full-path reservation could reduce the number of grounded drones while using airspace efficiently.The authors identify developing such an algorithm as an important IoD contribution, despite the harder resource structure.

C. Congestion control

IoD congestion control must allocate limited airspace fairly and efficiently while avoiding overload, but Internet mechanisms do not transfer directly because feedback is slower and multiple competing providers may grant access.

  • Congestion control: Congestion must be known within each zone service provider because holding or grounding drones is costly.Unlike Internet acknowledgments, direct congestion probing with drones is orders of magnitude slower.
  • Congestion control: IoD congestion control must achieve fair and efficient airspace allocation without overloading network elements.The paper presents this as an open research question rather than a solved design.
  • Congestion control: Token-bucket schemes are difficult to apply because multiple competing zone service providers may grant access to the same airspace element without sharing information.Internet token buckets represent available resources and grant access only when a token remains.
  • Congestion control: Fairness requires an explicit design choice about whether to prioritize faster drones or allocate airspace equitably among drones.The paper also connects fairness to quality-of-service considerations.
  • Congestion control: IoD protocols must account for wireless signaling capacity because broadcasts from drones and zone service providers can flood frequency channels.If signaling overhead is unavoidable, communication channels become a resource alongside airways and intersections.

F. Drones and minimum performance

IoD deployment depends on minimum drone capabilities, layered security, governance, and legal conditions that remain unresolved. The proposed architecture is therefore a conceptual foundation requiring implementation, validation, and compatible airspace rules.

  • Drones and minimum performance: VTOL capability may be required in lower urban airspace because hovering enables easier grounding or holding where available airspace is limited.The paper suggests higher urban altitudes may not require VTOL.
  • Drones and minimum performance: IoD security must span multiple layers because relying mainly on the application layer leaves lower-layer vulnerabilities.The paper identifies cross-layer security as a major architectural challenge.
  • Drones and minimum performance: The architecture requires protocol suites, inter-layer interfaces, and implemented layers so inconsistencies or inefficiencies can be exposed in practice.Implementation findings are intended to guide later architectural iterations.
  • Drones and minimum performance: IoD operation models should provide incentives for stakeholders, making game theory and mechanism design relevant to the system’s governance.The paper frames stakeholder incentives as an economic design question.
  • Drones and minimum performance: IoD must address legal and regulatory barriers, including requirements for airworthiness, flight plans, ADS-B, and related integration technologies.The FAA roadmap also identifies Sense and Avoid and Control and Communication as important technologies.
  • Drones and minimum performance: The authors argue that current restrictions on fully autonomous operation make IoD viable only if new UAS-specific airspace classes are introduced.This is presented as an author opinion about the FAA roadmap and the current theoretical status of IoD.

VII. CONCLUSION

The paper establishes a layered conceptual foundation for coordinating thousands of drones in congested urban airspace and providing generic services across applications. It defines architecture components, airspace structures, operational roles, and required layer features, while leaving substantial protocol and implementation work for future research.

  • VII. CONCLUSION: IoD targets scalable coordination and navigation for thousands of drones sharing congested, limited urban airspace.The architecture is intended to support multiple drone applications through a unified framework.
  • VII. CONCLUSION: The paper develops an architectural vocabulary, identifies components and boundaries, structures the airspace, and proposes strategies for using it.These elements form the conceptual foundation of the proposed system.
  • VII. CONCLUSION: Layering separates navigation and coordination from common services such as location-aware communication, enabling generic services for multiple applications.The paper specifies features that IoD systems should implement in each layer.
  • VII. CONCLUSION: The proposed operation model assigns roles to private and public organizations in IoD governance.Governance is included alongside the technical architecture.
Loading 1601.01289v2…