28  UAV Network Topologies

Star, Mesh, Hierarchical, Relay, and Store-Carry-Forward Decisions

emerging-paradigms
uav
topologies

28.1 Start Simple

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.

In 60 Seconds

UAV topology is the communication shape that connects aircraft, field devices, operators, relays, and gateway exits during a mission. Star topology is simple but depends on a hub. Mesh topology gives alternate paths but needs current neighbor and route records. Hierarchical and relay-chain designs separate roles when distance, coverage, or gateway access matters. Store-carry-forward is a valid topology choice when data can wait for a better contact.

28.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.

28.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.

UAV topology decision map showing mission service, traffic classes, link records, gateway exit, role records, payload behavior, rejected pattern, and fallback rule feeding topology choice.
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.

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.

28.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.

Current statusUse hierarchical relay behavior while the relay has fresh peer and gateway records.
Bulk imageryUse store-carry-forward when the gateway path is weak, and mark affected segments as pending upload.
Role replacementName the aircraft that takes over relay duty when the current relay is low on reserve or leaves the corridor.
Rejected patternReject pure star topology because the route cannot prove direct ground reachability along the whole corridor.

28.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.
Quick Check: Topology Choice Boundaries
Minimum Viable Understanding
  • 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.

28.6 Prerequisites

Revisit these chapters if the terms are unfamiliar:

28.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.

28.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.

28.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.

No-panel UAV topology pattern comparison showing star, mesh, hierarchical relay, and store-carry-forward patterns with dependency and fallback questions.
Figure 28.1: UAV topology pattern comparison showing star, mesh, hierarchical relay, and store-carry-forward patterns with their main dependency and fallback question.

28.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?

28.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?

28.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?

28.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?

28.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?

28.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?

28.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?

28.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.

No-panel UAV topology decision record showing mission service, selected and rejected topology, traffic classes, physical links, gateway exit, energy reserve, payload behavior, fallback action, and recheck trigger.
Figure 28.2: 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.

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?

28.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.

28.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.

28.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.

28.15 Interactive Checks

Label the Topology Decision Record

Knowledge Check

28.16 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.

28.17 What’s Next

28.18 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.