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

Inventory traffic before choosing a transport

Record every flow that can cross the aircraft-to-ground boundary. For each one, identify its direction, source, destination, average rate, peak rate and interval, maximum useful age, and consequence of delay or loss.

Keep uplink and downlink calculations separate. A service can have very different capacity in each direction, and a quoted aggregate rate may not describe either one. Also separate an average over a minute from a burst over 100 milliseconds. Both can be numerically correct while producing very different queue delay.

Use one explicit planning equation

For each direction, calculate:

Required capacity equals the sum of application rates multiplied by encapsulation and protection factors, divided by planned utilization.

Every term needs a definition:

1. Application rate comes from a message schedule, encoder measurement, sensor specification, or file-size and transfer-time requirement.
2. Encapsulation factor accounts for headers and trailers. Small packets can carry a high percentage of overhead.
3. Protection factor covers the actual encryption, tunnel, forward-error correction, retransmission, or provider behavior. It should not be a universal percentage copied between systems.
4. Planned utilization reserves room for variation and consequential traffic. It is an engineering assumption that must survive end-to-end testing.

Use decimal network units unless the equipment specifies otherwise: 1 Mbps is 1,000,000 bits per second, and one byte is eight bits. State the convention so a megabyte storage value is not mistaken for a megabit transmission rate.

Example 1: signed telemetry

This editorial calculation estimates one aircraft-to-ground telemetry stream. It does not prescribe a MAVLink configuration.

Assume 20 messages per second, each with 32 bytes of application payload. The MAVLink FAQ states that MAVLink 2 adds 25 bytes per packet when signing is used. Put one message in each UDP datagram, add the 8-byte UDP header defined by RFC 768, and use the minimum 20-byte IPv4 header from RFC 791.

The rate before any link-specific allowance is:

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

For an illustrative plan, add 25 percent for unmodeled protection and tunnel effects, then limit planned use to 70 percent:

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

The 25 percent and 70 percent values are disclosed assumptions, not values from MAVLink or the RFCs. Replace them with packet captures and measurements from the actual cipher, tunnel, modem, link layer, aggregation, and retry configuration.

This modest result does not describe a complete C2 service. Commands, acknowledgements, heartbeats, time synchronization, link management, and other state may be separate flows. Message freshness, delivery behavior, and loss detection remain requirements even when the arithmetic fits in a narrow pipe.

Example 2: variable-rate video

Assume an encoded aircraft video downlink averages 3.0 Mbps and reaches 6.0 Mbps over the hardest representative one-second scene. Assume 1,200 bytes of video in each packet, a 12-byte fixed RTP header, an 8-byte UDP header, and a 20-byte IPv4 header. RFC 3550 supplies the RTP header value used here.

The fixed-header factor is:

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

Add an illustrative 15 percent recovery allowance and plan to use no more than 75 percent of available capacity:

The arithmetic omits RTCP, RTP extensions, codec fragmentation, encryption, VPN framing, modem overhead, and provider repair traffic. Measure those elements in the installed path.

The input bitrate also cannot be inferred from resolution alone. The Axis bitrate-control paper documents how frame rate, compression, group-of-pictures length, scene motion, lighting, and control mode change encoded demand. A bitrate cap can protect a network while reducing image quality or frame rate. Acceptance testing therefore has to evaluate useful video quality and peak packet rate together.

Example 3: a 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 raw application rate is:

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

Assume onboard processing reduces that stream by 4:1. The application rate becomes 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 factors produce 368 Mbps. Neither figure is a product specification or a measured rate. The calculation shows why a payload integration plan may need onboard recording, event selection, a low-rate preview, derived products, or delayed transfer.

Bandwidth is not latency or availability

A path can pass a throughput test and still deliver old commands. Record at least these measures beside capacity:

• one-way and round-trip latency distributions, not only an average;
• jitter and queue delay under concurrent traffic;
• message age at the receiving application;
• delivery success and burst-loss behavior;
• handoff or path-transition interruption;
• time to detect degradation or loss;
• useful application quality after adaptation; and
• recovery time and state after service returns.

Historical estimates can help expose categories without setting present-day requirements. ITU-R Report M.2171 models command and non-payload communication for spectrum planning, but it also states that its information is not for operational use. Its scenarios are evidence that critical traffic may have a lower data rate than payload traffic, not a current minimum for a commercial drone.

Protect consequential traffic during congestion

A bulk file or video burst should not fill the only queue. Define traffic classes, bounded queues, and shaping behavior before testing. One possible design order is to preserve valid commands, command responses, required aircraft state, and link health; reduce optional telemetry and video; then pause bulk transfer. The actual order depends on the function. Video used for a safety-related purpose is not equivalent to ordinary inspection video.

Priority marking helps only when every relevant segment honors it or implements an equivalent policy. Check the airborne router, modem, service network, ground gateway, and control station under congestion. The secure BVLOS communications guide explains why protection mechanisms and alternate paths can add their own overhead and shared dependencies.

Degradation and declared link loss are different states. Capacity controls should define thresholds and recovery behavior. The operational response after C2 is declared unavailable belongs in the lost-link procedure.

Turn a provider rate into an acceptance test

A published Mbps figure is incomplete until its scope is known. Ask:

• Is it application goodput, IP throughput, modem throughput, or radio line rate?
• Does it apply to the uplink, downlink, each direction, or both in aggregate?
• Is it a minimum, measured typical value, configured cap, or theoretical maximum?
• Over what interval are sustained and peak results reported?
• Which security, tunnel, FEC, and link-layer overheads are included?
• Were every required flow and every active aircraft represented together?
• What latency, jitter, loss, data-age, and transition results accompany it?
• Which traffic is reduced first when the path is constrained?
• Can logs reproduce application and wire rates by traffic class?

Then verify the complete configuration with representative message schedules, hard video scenes, payload products, security settings, simultaneous flows, and degraded conditions. 14 CFR 107.49 requires a Part 107 remote pilot in command to ensure before flight that control links between the ground control station and aircraft work properly. The rule does not supply the engineering values. The calculation and the C2 interface contract must make "working properly" testable for the installed system and planned operation.