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:
- Application rate comes from a message schedule, an encoder measurement, a
sensor specification, or a timed file-transfer requirement.
- Encapsulation factor accounts for protocol headers and trailers. Small,
frequent packets can have a much larger percentage overhead than long payload
packets.
- 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.
- 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.
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.