Drone technologytechnical explainer

How Much Bandwidth Does a Drone Need? C2, Telemetry, Video, and Payload Data

A calculation-based method for sizing drone uplink and downlink capacity for command, telemetry, video, and payload data without relying on one universal Mbps figure.

Prototype UAS command-and-control radio mounted in a test rack aboard NASA's S-3 Viking research aircraft.
A prototype UAS command-and-control radio in a test rack aboard NASA's S-3 Viking. Photo: NASA / Jim Griner

A drone does not have one universal bandwidth requirement. The useful number is the capacity required in each direction for a defined mix of command, telemetry, video, and payload traffic under both normal and peak conditions. Calculate application data first, add measured protocol and protection overhead, preserve capacity for consequential traffic, and then verify the result on the complete aircraft-to-ground path.

Bandwidth is only one dimension of link performance. A command stream may use few bits while still requiring strict latency, data-age, availability, and failure-detection limits. A high-rate payload transfer may tolerate delay but consume nearly every available bit if it is not shaped. The UAS data-link roles guide explains the functional distinction; this article turns those roles into a capacity plan.

Start with traffic classes, not a radio label

Record every flow that can cross the aircraft-ground boundary. For each flow, identify its direction, operational purpose, source, destination, average rate, shortest credible peak interval, and consequence if it arrives late or not at all.

The four common groups are:

  • Aircraft command: operator or automation inputs sent toward the aircraft. The application rate is often low, but an old, duplicated, misrouted, or missing command can matter more than a lost block of payload data.
  • Telemetry: state returned from the aircraft, such as mode, position, energy, propulsion, navigation quality, and link health. Different telemetry fields may need different rates and maximum ages.
  • Video: an encoded stream whose rate changes with resolution, frame rate, codec, encoder settings, scene motion, lighting, and quality target.
  • Payload data: imagery, point clouds, spectral samples, measurements, files, and metadata. A payload may send a low-rate preview while retaining a much larger source product onboard.

Classify by function and consequence, not by media type alone. Video used only to inspect an asset is payload traffic. Video used for a safety-related function can be non-payload communication. Current 47 CFR Part 88 similarly defines control and non-payload communications by whether a transmission supports flight safety or regularity, while defining payload as mission information that is not CNPC. That regulatory definition does not assign a universal rate to either class.

Keep uplink and downlink calculations separate. A link advertised with one large download number may have a much smaller upload path, different scheduling behavior, or one shared aggregate limit. An operator may need little steady uplink capacity but a significant burst to send a mission update. The aircraft may return modest telemetry beside a much larger video or sensor stream.

A repeatable sizing method

Use decimal networking units unless a specification says otherwise: 1 Mbps is 1,000,000 bits per second, and one byte is eight bits. State the convention so that a storage figure in megabytes is not mistaken for a network figure in megabits.

For each direction, use this planning relationship:

required capacity = sum(application rate x encapsulation factor x protection allowance) / planned utilization

The terms need evidence:

  1. Application rate comes from a message schedule, an encoder measurement, a sensor specification, or a timed file-transfer requirement.
  2. Encapsulation factor accounts for protocol headers and trailers. Small, frequent packets can have a much larger percentage overhead than long payload packets.
  3. Protection allowance accounts for the actual forward error correction (FEC), retransmission, encryption, tunnel, or provider behavior. Do not assume one percentage works for every network.
  4. Planned utilization prevents a design from depending on permanent queue saturation. It is an engineering choice, not a regulatory constant.

Calculate both sustained demand and demand over a specified peak interval. A one-second peak and a 100-millisecond burst are not interchangeable. Document whether queues can absorb the burst without violating the maximum age of command or health data.

Example 1: signed telemetry over IPv4 and UDP

This example estimates wire demand for a deliberately simple telemetry stream. It is an editorial calculation, not a required MAVLink configuration. The assumed direction is an aircraft-to-ground telemetry downlink.

Assumptions:

  • 20 messages per second
  • 32 bytes of application payload in each message
  • signed MAVLink 2, with 25 bytes of packet overhead
  • one MAVLink message in each UDP datagram
  • an 8-byte UDP header and minimum 20-byte IPv4 header
  • a generic 25 percent planning allowance for unmodeled protection, recovery, or tunnel effects
  • a 70 percent planned utilization ceiling

The official MAVLink FAQ states that MAVLink 2 has 12 bytes of overhead without signing and 25 bytes with signing. It also makes an important security distinction: signing authenticates messages, but MAVLink does not provide encryption.

Before the planning allowance, the rate is:

20 x (32 + 25 + 8 + 20) x 8 = 13,600 bit/s

After the assumed allowance and utilization ceiling:

13,600 x 1.25 / 0.70 = 24,286 bit/s, or about 24.3 kbps

The header inputs are traceable. RFC 768 defines an 8-byte minimum UDP length, and RFC 791 defines a minimum IPv4 header of five 32-bit words, or 20 bytes. The 25 percent allowance is not traceable to either standard. It must be replaced with the measured behavior of the actual tunnel, cipher, modem, link layer, aggregation, FEC, and retry policy.

This calculation also should not be read as a complete C2 requirement. Command traffic, acknowledgments, heartbeats, time synchronization, link management, and other state may be separate flows. Reliability, latency, data age, and failure detection still need requirements even when the arithmetic produces a small number.

Example 2: compressed video with a short peak

The assumed direction is an aircraft-to-ground video downlink. Assume an encoder produces 3.0 Mbps on average and a 6.0 Mbps peak measured over a one-second interval under the hardest representative scene. Assume each packet carries 1,200 bytes of video, with a fixed 12-byte RTP header, 8-byte UDP header, and 20-byte IPv4 header. Add an illustrative 15 percent recovery or FEC allowance and plan to use no more than 75 percent of available capacity.

The fixed-header factor is:

(1,200 + 12 + 8 + 20) / 1,200 = 1.0333

Required sustained capacity is:

3.0 x 1.0333 x 1.15 / 0.75 = 4.75 Mbps

Required peak capacity is:

6.0 x 1.0333 x 1.15 / 0.75 = 9.51 Mbps

RFC 3550 establishes the 12-byte fixed RTP header used in the example. The arithmetic excludes RTCP, RTP extensions, codec fragmentation headers, encryption, VPN framing, modem overhead, and any provider-specific repair traffic. Those items need to be measured or modeled separately.

The 3.0 and 6.0 Mbps inputs are assumptions, not a recommendation for a resolution or codec. The Axis bitrate-control paper documents why a single video label is insufficient: resolution, frame rate, compression, group-of-pictures length, camera settings, lighting, motion, and scene complexity affect encoded bitrate. Variable-rate video can rise sharply when the scene changes. A maximum-rate controller can constrain the stream, but the trade can be lower image quality or frame rate.

For that reason, test useful video quality and the peak packet rate together. An encoder that stays inside the pipe by destroying the detail needed for the mission has met a network limit but not the mission requirement.

Example 3: a raw sensor stream

Consider a 20-megapixel sensor producing one 12-bit sample per pixel at one frame per second. This simplified example assumes one sample, not three color channels, for each pixel. The assumed direction is an aircraft-to-ground payload downlink.

The raw application rate is:

20,000,000 x 12 x 1 = 240 Mbps

Assume onboard processing achieves a 4:1 reduction. The resulting application rate is 60 Mbps. With a 15 percent framing and metadata allowance and a 75 percent utilization ceiling:

60 x 1.15 / 0.75 = 92 Mbps

Without the assumed reduction, the same planning method produces 368 Mbps. Neither result is a product claim. The 4:1 reduction and both allowances are disclosed assumptions.

The result explains why a payload integration may need onboard recording, event selection, lower-rate previews, derived products, or delayed transfer. The payload integration interface gate helps close the associated storage, compute, timing, power, and data-path decisions.

Historical rates are context, not a shopping table

ITU-R Report M.2171 contains scenario estimates in which command-and-control traffic is measured in thousands of bits per second while some non-payload surveillance data reaches hundreds of thousands of bits per second. The report is useful evidence that critical control traffic need not be the highest-rate traffic.

It is not a current small-drone requirement. The 2009 report explicitly says its information is for spectrum estimation and is not relevant for operational purposes. Its aircraft categories, traffic assumptions, and non-segregated airspace scenarios cannot be turned into a modern minimum rate without a new system analysis.

Likewise, a low command rate does not make the aircraft autonomous. The automation and autonomy authority test asks who can set goals, change plans, and handle conditions beyond a scripted sequence. Those authority questions remain even when commands are infrequent.

Preserve consequential traffic when capacity degrades

Do not let a file transfer or video burst fill the only queue. Define separate traffic classes, bounded queues, and shaping rules before testing. A common starting policy is to reserve capacity for valid commands, command responses, critical aircraft state, and link health; reduce nonessential telemetry and video; then pause bulk payload transfer. The actual order must follow the system safety analysis. A safety-related video function may deserve different treatment from ordinary mission video.

Traffic marking alone is insufficient. Every segment, including the airborne router, provider network, ground gateway, and GCS, must preserve the intended classification or implement an equivalent policy. Verify behavior during congestion, not just in an unloaded laboratory.

Link degradation and complete link loss are different states. The capacity policy should define thresholds, hysteresis, and recovery, while the UAS lost-link procedures guide owns the operational response after the control link is declared unavailable. Security overhead and trust boundaries belong in the secure BLOS communications guide.

What a published 10 Mbps figure does not answer

Disclosure: Austin Lawson is the owner and editor of Unmanned Innovation and the CEO and co-founder of Avidron UAS, Inc. The ARC details below come from Avidron's public product page and were not independently tested for this article.

The manufacturer says Avidron ARC supports C2, telemetry, and full-motion video over LEO networks, publishes a 10 Mbps throughput figure, and prioritizes command and telemetry during degraded conditions. It also describes an architecture combining aircraft-mounted hardware, onboard compute, and software-defined control. These are attributed manufacturer statements, not measurements made for this article.

The video example above approaches that published figure at its assumed peak. That comparison does not establish whether the example fits. A buyer would still need to know whether 10 Mbps is application goodput or a lower-layer rate, uplink, downlink, or aggregate, sustained or burst, and what overhead, latency, coverage, network conditions, concurrency, and test interval apply. The same questions belong on every vendor data sheet.

Technology selection comes after requirements. The RF, LTE, satellite, and mesh comparison examines architecture tradeoffs. The Starlink integration analysis addresses why an internet service and terminal do not by themselves form a complete aviation C2 system. The C2 interface requirements guide shows how to turn the selected path into controlled interfaces.

Procurement and acceptance questions

Require suppliers and integrators to answer these questions for each direction:

  • Is the quoted rate application goodput, IP throughput, modem throughput, or radio line rate?
  • Is it a guaranteed minimum, measured typical value, configured cap, or theoretical maximum?
  • Over what interval are sustained and peak rates defined?
  • Which protocol, security, FEC, tunnel, and link-layer overheads are included?
  • What rates were measured with every required flow active at once?
  • What latency, jitter, loss, and data-age results accompany the throughput?
  • How does the system behave during congestion, handoff, coverage loss, or provider variation?
  • Which traffic is shaped, reduced, or stopped first, and who controls that policy?
  • What useful video or payload quality remains at the constrained rate?
  • Can logs reproduce application and wire rates by traffic class?

Finally, test the installed system with representative scenes, message rates, payload products, security configuration, network paths, and degraded conditions. 14 CFR 107.49 requires a remote pilot in command to ensure before a small UAS flight that all control links between the ground control station and aircraft work properly. That rule does not supply the engineering numbers. The calculation, interface requirements, and end-to-end evidence must make “working properly” concrete for the actual system and operation.

Claim record

Sources

Reviewed

  1. 14 CFR 107.49: Preflight Familiarization, Inspection, and Actions for Aircraft OperationElectronic Code of Federal Regulations · regulator · accessed Sep 1, 2026
  2. 47 CFR Part 88: Uncrewed Aircraft System ServicesElectronic Code of Federal Regulations · regulator · accessed Sep 1, 2026
  3. Report ITU-R M.2171: Characteristics of Unmanned Aircraft Systems and Spectrum RequirementsInternational Telecommunication Union · research · accessed Sep 1, 2026
  4. Bitrate Control for IP VideoAxis Communications · manufacturer · accessed Sep 1, 2026
  5. MAVLink Frequently Asked QuestionsMAVLink · technical documentation · accessed Sep 1, 2026
  6. RFC 3550: RTP, A Transport Protocol for Real-Time ApplicationsInternet Engineering Task Force · standard · accessed Sep 1, 2026
  7. RFC 768: User Datagram ProtocolInternet Engineering Task Force · standard · accessed Sep 1, 2026
  8. RFC 791: Internet ProtocolInternet Engineering Task Force · standard · accessed Sep 1, 2026
  9. Avidron ARC: Secure BLOS CommunicationsAvidron UAS · manufacturer · accessed Sep 1, 2026