27 UAV Network Topologies
27.1 Start Simple
27.1.1 Choose a Shape for Each Mission Need
A group of aircraft maps the edge of a wildfire. The lead operator needs urgent status now, while large images can wait. One aircraft can speak directly to the ground station, another needs a relay, and a third may carry data until it returns. Calling the group a mesh does not prove that each mission need has a safe path.
Separate the traffic before choosing the shape. Mark command, urgent status, position, summaries, and large files. Give each one an age limit, energy cost, receiver, and fallback. Name any central point whose loss would stop the mission. Record which aircraft may relay for others and how the operator learns that a path has changed.
Then move and break the formation. Turn the central aircraft away. Drain one battery. Block the ground path. Change the relay order. Let a stored file arrive late. Check whether urgent status remains timely, old data is marked, relay work stays within energy limits, and the operator can explain the route actually used.
No single shape is best for every flight or traffic type. The proof is limited to the tested mission, motion, and equipment. The deeper sections compare star, mesh, layered, relay-chain, and carry-later patterns, then connect route freshness, roles, energy, and failure evidence.
Ask of each path: Who sends? Who receives? How old may it be? Can it wait? Can it use a relay? What happens when the hub is lost? How much flight energy may relaying spend? How does the operator see a path change? Which test proves the answer?
Keep command and urgent status on the clearest bounded path. Let large files wait when the mission permits. Test the choice while aircraft move, not on a bench. Note the route, time, battery state, and result. Reopen the choice when the formation, ground station, terrain, or traffic mix changes.
Start with a mission that moves, loses energy, and changes its radio path while it works. In UAV Network Topologies, the practical question is what the aircraft must sense, relay, decide, and prove before the flight or network role is safe enough to trust.
27.2 Learning Objectives
By the end of this chapter, you will be able to:
- Compare star, mesh, hierarchical, relay-chain, and store-carry-forward UAV topology patterns.
- Separate physical topology from logical routing behavior.
- Choose a topology using mission role, traffic class, link freshness, gateway reachability, energy reserve, and payload behavior.
- Identify when a topology has hidden single points of failure.
- Write a topology decision record that explains selected and rejected patterns.
27.3 Select Topology by Traffic
If you only need the decision shortcut, this layer is enough: choose the topology separately for command, telemetry, urgent status, summaries, and bulk payloads, then prove that each path still exists during the mission.
Before select Topology by Traffic, inspect Figure to compare "Rejected Pattern" with "Traffic Classes". Their juxtaposition makes A topology choice is ready only when traffic classes, link and role records, gateway exit, payload behavior, rejected pattern, and fallback rule match current evidence visible.
Read Figure from "Rejected Pattern" to "Traffic Classes". Taken together, "Rejected Pattern" and "Traffic Classes" express A topology choice is ready only when traffic classes, link and role records, gateway exit, payload behavior, rejected pattern, and fallback rule match current evidence. For select Topology by Traffic, the observed relationship between "Rejected Pattern" and "Traffic Classes" is evidence that "Rejected Pattern" carries into the next decision.
Mobile summary: Pick the topology per traffic class, then recheck the records that prove each path, gateway exit, and fallback still works.
Fresh traffic
Commands, health state, and urgent status need current paths, clear ownership, and fallback behavior when a hub or relay disappears.
Delay-tolerant traffic
Imagery, logs, and batch observations can use buffering or store-carry-forward when the mission records mark them as safe to delay.
Exit traffic
Every topology record should name where data leaves the aerial network and what happens when that gateway observation becomes stale.
27.4 Practitioner: Write The Corridor Record
For the utility corridor example, the useful record is not "mesh versus star." It is the traffic split that keeps current work safe while letting bulky observations wait.
27.5 Why Topologies Change In Flight
A UAV topology is not fixed by the diagram drawn before launch. It changes when movement, energy, payload, and gateway evidence change.
- Motion drift: a mesh-capable fleet can become a relay chain when aircraft spread along a corridor.
- Energy drift: the best relay can stop being the right relay when reserve falls below the return threshold.
- Payload drift: bulk imagery can consume the path needed for current control unless traffic classes are separated.
- Gateway drift: a stale gateway observation should force buffering, reroute, role replacement, or mission recall.
- A topology decision is a mission decision, not just a diagram shape.
- Star topology is easiest to supervise, but the hub and ground link must be checked as dependencies.
- Mesh topology can reroute around some failures, but only when alternate physical links really exist.
- Hierarchical topology is useful when UAV roles differ, such as workers, relays, leaders, and gateways.
- Store-carry-forward is appropriate when delay-tolerant data can be buffered until a gateway or peer contact improves.
27.6 Prerequisites
Revisit these chapters if the terms are unfamiliar:
- UAV Networks Introduction: UAV roles and mission fit.
- UAV Network Features and Challenges: mobility, energy, link, payload, and operations trade-offs.
- FANET Fundamentals: aerial ad hoc links and routing choices.
- UAV Swarm Coordination: task ownership, formation behavior, and state freshness.
27.7 How This Chapter Fits
The introduction and features chapters explain why UAV networks are useful. This chapter focuses on the communication shape that lets those roles work together. Later FANET, gateway, coordination, and production chapters use this topology vocabulary when they evaluate routes, gateway exits, and fallback behavior.
The overview depth layer shows the topology decision map that anchors mission service, traffic classes, link records, gateway exit, role records, payload behavior, rejected pattern, and fallback rule.
27.8 Role-First Orientation
Start by assigning roles before naming a topology:
- Sensor platform: collects observations and sends summaries or event records.
- Aerial relay: forwards messages when direct reachability is weak.
- Temporary access point: provides short-term coverage for field devices, responders, vehicles, or inspection teams.
- Gateway: moves mission traffic from the aerial network to ground operations or backhaul.
- Coordinator: tracks mission state, roles, route intent, or path arbitration.
- Data carrier: stores lower-priority data while moving toward a better contact.
The selected topology should state which role matters for each traffic class and what role changes when energy, link freshness, or gateway reachability changes.
27.9 Topology Patterns
Each pattern solves a different readiness problem. Avoid choosing the pattern from fleet size alone; choose it from the traffic, records, and failure behavior the mission needs.
Before topology Patterns, inspect Figure 27.1 to compare “Store-Carry-Forward” with “Hierarchical Relay”. Their juxtaposition makes UAV topology pattern comparison showing star, mesh, hierarchical relay, and store-carry-forward patterns with their main dependency and fallback question visible.
Read Figure 27.1 from “Store-Carry-Forward” to “Hierarchical Relay”. Taken together, “Store-Carry-Forward” and “Hierarchical Relay” express UAV topology pattern comparison showing star, mesh, hierarchical relay, and store-carry-forward patterns with their main dependency and fallback question. For topology Patterns, the observed relationship between “Store-Carry-Forward” and “Hierarchical Relay” is evidence that “Store-Carry-Forward” carries into the next decision.
27.9.1 Star
All aircraft report through a ground station, controller, or hub UAV.
Best fit: supervised missions with a reliable hub path and simple coordination.
Check question: what happens when the hub, ground link, or hub energy reserve is unavailable?
27.9.2 Mesh
Aircraft exchange state with peers and can route through more than one path.
Best fit: missions where individual UAVs may lose contact but nearby peers can still help.
Check question: are the alternate paths physically reachable, fresh, and trusted?
27.9.3 Hierarchical
Aircraft take different roles, such as workers, relays, leaders, gateways, and standby nodes.
Best fit: missions where sensing, relaying, gateway exit, and supervision should not all sit on the same aircraft.
Check question: who replaces a role when that aircraft returns, loses link quality, or fills its payload queue?
27.9.4 Relay chain
Aircraft form a path across a corridor, valley, route, shoreline, field edge, or temporary coverage line.
Best fit: long or narrow mission areas where direct ground contact is unreliable.
Check question: where does the chain become a single point of failure?
27.9.5 Store-carry-forward
Aircraft buffer data while moving toward a peer, gateway, or recovery point.
Best fit: delay-tolerant payloads, sparse contact, weak gateways, or missions where live delivery is not required.
Check question: which traffic can wait, how much can be buffered, and when is the backlog unacceptable?
27.9.6 Hybrid
The mission combines patterns, such as star supervision with mesh peer state, or a relay chain with store-carry-forward payloads.
Best fit: missions with different freshness needs for commands, status, summaries, and bulk observations.
Check question: which traffic class uses which path and fallback?
27.10 Physical Versus Logical Topology
A routing protocol can advertise mesh behavior, but the physical topology may still be a chain, a star, or disconnected islands. Check the physical radio and motion records before trusting the logical label.
Physical reachability Which aircraft, ground nodes, and gateways can currently hear each other?
Neighbor freshness How old is each peer, route, and gateway observation?
Traffic class Which messages need current delivery, and which can be buffered?
Role separation Which aircraft sense, relay, coordinate, carry data, or act as gateway candidates?
Energy reserve Which topology role changes when an aircraft must return or reduce service?
Payload behavior Which payload data is live, summarized, compressed, buffered, or delayed?
Gateway exit Where does mission data leave the aerial network?
Fallback trigger What event causes reroute, role replacement, buffering, or recall?
27.11 Topology Decision Record
The decision record should be short enough to keep current during a mission. It should still be detailed enough that another teammate can see why one topology was accepted and another was rejected.
Before topology Decision Record, inspect Figure 27.2 to compare “Energy” with “reroute”. Their juxtaposition makes UAV topology decision record showing mission service, selected topology, rejected topology, traffic classes, physical links, gateway exit, energy reserve, payload behavior, fallback action, and recheck trigger visible.
Read Figure 27.2 from “Energy” to “reroute”. Taken together, “Energy” and “reroute” express UAV topology decision record showing mission service, selected topology, rejected topology, traffic classes, physical links, gateway exit, energy reserve, payload behavior, fallback action, and recheck trigger. For topology Decision Record, the observed relationship between “Energy” and “reroute” is evidence that “Energy” carries into the next decision.
Mission service What field decision, device, operator, or process depends on the UAV network?
Selected topology Which topology pattern is used for each important traffic class?
Rejected topology Which plausible pattern was rejected, and what records made it weaker?
Current records What link, route, gateway, energy, payload, and movement records support the choice?
Fallback action What changes if the hub is unavailable, a relay returns, a gateway path is stale, or a payload queue grows?
Recheck trigger What mission, route, payload, weather, role, or gateway change forces a new topology check?
27.12 Utility Corridor Inspection
Scenario: A field crew wants UAV support for a utility corridor after a storm. The mission needs current status notes for crews and can tolerate delayed upload for high-resolution imagery.
Initial idea: Use star topology. Every UAV reports directly to the ground station.
Route records:
- The corridor is longer than the reliable ground-station view from one position.
- Bulk imagery can wait, but urgent status notes should move while the UAV is still near the fault.
- One aircraft may need to return before the corridor is complete.
- The field crew can accept a lower-frequency summary while imagery buffers.
Accepted topology:
- Use hierarchical relay behavior for current status notes.
- Use store-carry-forward for bulk imagery when the gateway path is weak.
- Keep ground supervision for launch, recall, and final acceptance.
- Record a role replacement rule for relay aircraft that need to return.
Rejected topology:
- Pure star topology was rejected because the mission depends on direct ground reachability that the route cannot prove.
Fallback behavior:
- If the relay role becomes stale or low on reserve, the nearest suitable aircraft takes the relay role before the current relay returns.
- If no current route exists, urgent status is retried through the freshest peer path and bulk imagery buffers.
- If the payload queue becomes too large, the mission marks affected segments as pending upload instead of pretending the imagery was delivered.
The result is not “mesh is better than star.” The result is a documented topology split: current status gets a relay path; bulk imagery gets store-carry-forward; supervision stays centralized.
27.13 Topology Selection Checklist
Use this checklist before accepting a topology diagram.
Start with traffic Separate command, telemetry, urgent status, summaries, and bulk payloads.
Name the exit Identify how each traffic class leaves the aerial network.
Map physical links Do not assume mesh behavior unless alternate physical paths are current.
Assign roles State which UAVs sense, relay, coordinate, carry data, or provide gateway assistance.
Test role loss Ask what happens when the hub, relay, leader, gateway candidate, or data carrier leaves.
Record rejected patterns A teammate should know why a simpler or more resilient alternative was not used.
Define stale behavior State when a link, neighbor, route, or gateway observation becomes too old to use.
Protect urgent traffic Do not let bulk payload transfer consume the path needed for current control or status.
27.14 Common Pitfalls and Misconceptions
Mesh can improve resilience only when alternate physical links exist and the routing state is fresh. In a narrow corridor, a mesh protocol may still behave like a relay chain.
A star hub, relay chain midpoint, gateway UAV, or coordinator can quietly become the mission dependency. Record how each role is replaced.
Operator commands, telemetry, urgent status, summaries, and bulk observations usually need different freshness and delivery behavior.
A topology diagram is not current proof. Neighbor, route, gateway, energy, and payload state can age quickly during flight.
A path that can carry short status messages may still be unsuitable for high-volume imagery. Payload behavior belongs in the topology record.
27.15 Interactive Checks
27.16 UAV Networks for IoT
27.16.1 Start Simple
Prove One Survey Reading Before Trusting the Flight Map
Picture a small aircraft checking a flooded field. Its camera sees one blocked drain, and the ground team must decide whether to send a person there. The first question is not how modern the aircraft looks. It is whether one reading can be traced from the moving aircraft to the right place and time on the ground.
An actuator means a part that causes a physical action, such as moving a camera mount. A gateway means a device or service that joins two message paths. A payload means the useful reading, image, or command carried inside a message.
Record aircraft identity, source time, position, payload version, link path, and receiver state. Fly beyond one link, delay a reading, repeat it, restart the ground receiver, and reject an old position as current. Keep urgent safe action local when a remote path disappears.
This runway does not prove airworthiness, radio coverage, or mission safety. The deeper sections explain aircraft roles, moving links, energy limits, network patterns, and the evidence needed for a real flight decision.
Start with a mission that moves, loses energy, and changes its radio path while it works. In UAV Networks for IoT, the practical question is what the aircraft must sense, relay, decide, and prove before the flight or network role is safe enough to trust.
27.16.2 Start With the UAV Network Role
A UAV network is an IoT system that uses one or more aerial nodes as part of the sensing or communication path. The aerial node may collect observations, provide temporary access, relay traffic, or bridge an isolated area back to a ground gateway.
Before start With the UAV Network Role, inspect Figure to compare "Aerial Relay" with "ROLE 1". Their juxtaposition makes start UAV network design from the role: mobile sensor, aerial relay, or flying actuator, each with its own payload and use cases visible.
Read Figure from "Aerial Relay" to "ROLE 1". Taken together, "Aerial Relay" and "ROLE 1" express start UAV network design from the role: mobile sensor, aerial relay, or flying actuator, each with its own payload and use cases. For start With the UAV Network Role, the observed relationship between "Aerial Relay" and "ROLE 1" is evidence that "Aerial Relay" carries into the next decision.
The first design decision is not the aircraft model. It is the network responsibility: what traffic must move, which links are realistic during flight, where the data exits the mission area, and what records prove that the mission can be trusted.
If you only need the intuition, this layer is enough: a UAV becomes part of the IoT network when its height, mobility, and temporary placement change how field data is sensed, moved, or delivered. Pick the role first, then choose aircraft, topology, and route details.
Aerial Sensor
The UAV carries a camera, thermal sensor, gas sensor, or other payload and sends observations to a ground system or local relay.
Temporary Access Point
The UAV offers short-lived connectivity to responders, devices, vehicles, or field teams when fixed infrastructure is absent or poorly placed.
Aerial Relay
The UAV forwards traffic between nodes that cannot maintain a direct path, such as ground sensors and a command post.
Gateway Bridge
The UAV helps move mission traffic from the local area toward a ground gateway, backhaul link, or operations platform.
27.16.3 Mission Readiness Record
A useful first pass moves from mission need to link records before topology. That keeps the design from looking complete on a diagram while hiding an impossible handoff, stale path, or missing return route.
For a post-storm road inspection, the first record might name the UAV as an aerial sensor, require live status for blocked road segments, allow image batches to wait during poor coverage, and keep a route and energy reserve for returning to the launch point. If the field team also needs temporary connectivity, that is a second role with its own proof.
Do Not Start With Fleet Size
Fleet size is meaningful only after the mission role, traffic freshness, gateway exit, route envelope, and energy reserve are understood.
Separate Urgent And Delay-Tolerant Data
Control, telemetry, and safety messages usually need fresher paths than bulk imagery or periodic environmental observations.
27.16.4 Single UAV or Multi-UAV?
The “Do Not Start With Fleet Size” card above says fleet size only makes sense once the mission role, traffic freshness, gateway exit, and energy reserve are already understood. Once those records are in place, a one-aircraft mission and a many-aircraft mission are not just different sizes of the same design; they carry different failure and cost profiles.
| Consideration | Single UAV | Multi-UAV |
|---|---|---|
| Failures | High | Low |
| Scalability | Limited | High |
| Survivability | Poor | High |
| Speed of mission | Slow | Fast |
| Cost | Medium | High |
| Bandwidth required | High | Medium |
| Antenna | Omni-directional | Directional |
| Complexity of control | Low | High |
| Failure to coordinate | Low | Present |
A single UAV is simpler to operate and needs no coordination logic, but the whole mission depends on one link budget and one airframe, so failure or route interruption cannot be recovered by handing the role to another aircraft. A multi-UAV system spreads that risk, scales further, and finishes the mission faster, at the cost of directional antenna planning, higher control complexity, and a failure mode a single-UAV mission cannot have at all: aircraft that fail to coordinate with each other (Gupta, Jain, and Vaszkun, 2015). This is the trade-off the fleet-size record above should name before the mission commits to either shape.
27.16.5 FANET Links as Time Evidence
A Flying Ad Hoc Network, or FANET, uses moving aerial nodes to form air-to-air and air-to-ground links. The hard part is not that the links exist. The hard part is proving that the links are fresh enough for the message being carried.
Compared with a fixed wireless network, a FANET changes more quickly. UAVs turn, climb, descend, land, hand off between gateways, and sometimes lose line of sight. A route that worked a minute ago may no longer be a safe assumption. The network record therefore needs time, position, role, energy, and gateway context.
Under-the-hood review should ask whether every message class has a defensible path. Telemetry and safety status may need a fresh live link. Bulk imagery may tolerate store-carry-forward. A gateway bridge may need an explicit ownership and backhaul record. These differences are what turn a UAV demonstration into a network architecture.
27.16.6 Summary
UAV networks extend IoT systems with aerial sensing and communication roles. A UAV can collect observations, provide temporary access, relay traffic, or bridge a mission area to a ground gateway. A FANET adds changing air-to-air and air-to-ground links, so route freshness, traffic priority, energy reserve, gateway reachability, and fallback behavior must be recorded before the design is trusted.
27.16.7 Key Takeaway
Start a UAV network design with the mission role and link evidence; aircraft choice, fleet size, and topology come after the network responsibility is clear.
27.16.8 See Also
UAV Capabilities and Constraints
Use this next to examine flight time, payload, mobility, weather, and operational limits.
UAV Network Topologies
Compare single-UAV, multi-UAV, relay, mesh, and gateway-centered layouts.
Flying Ad-Hoc Networks (FANETs)
Study the routing and freshness issues that appear when UAVs forward traffic for one another.
FANET Gateway Optimization
Choose gateway handoff strategies once the mission role and traffic classes are clear.
27.17 Summary
This chapter treated UAV topology as a traceable mission decision:
- Star: simple supervision with a hub dependency.
- Mesh: peer paths that require current physical links and route records.
- Hierarchical: role separation for workers, relays, leaders, gateways, and standby aircraft.
- Relay chain: coverage across long or narrow areas, with possible chain breakpoints.
- Store-carry-forward: delayed delivery for payloads that can wait for better contact.
- Decision record: selected and rejected topology, current records, fallback action, and recheck trigger.
27.18 What’s Next
- To check coordination after topology selection, read UAV Swarm Coordination.
- To connect topology choices to FANET routing, read FANET Fundamentals.
- To study gateway handoff and exit paths, read FANET Gateway Optimization.
- To prepare production checks, read UAV Networks: Production Checks.
27.19 Key Takeaway
UAV topology is dynamic. Star, mesh, cluster, relay, and hierarchical patterns should be selected from mission traffic, mobility, range, redundancy, and gateway constraints.