A general idea of a UAV is to move in 3D airspace. It can be manually controlled via remote, usually, a human operator or it can be an autonomous flight with various levels of autonomy.
According to the Drone Industry Insights (2019. https://dronelife.com/2019/03/11/droneii-tech-talk-unraveling-5-levels-of-drone-autonomy/) there are 6 levels of drone operations autonomy:

Autonomy Level	0	1	2	3	4	5
Human Contribution to the Flight Control
Machine (Drone Systems) Contribution to the Flight Control
Flight Automation Degree	None	Low	Partial	Conditional	High	Full
Remarks	Remote Control (fully RC). UAVO controls the drone in 100% manually (i.e. operator directly drives control surfaces).	UAVO in Control but the drone has at least one function it controls independently to the human operator (i.e. flight stabilisation).	UAVO is responsible for operation safety. The drone can take over controls given by the operator and modify it (i.e. heading, altitude hold, position hold, “smart” flight modes).	UAVO acts as fall-back: the drone performs autonomous operation under given conditions (i.e. using preloaded flight plan). The Drone can introduce slight modifications to it. i.e. avoid collisions with detected objects.	UAVO is out of control here, the drone performs autonomous flight and is able to use its duplicated systems to remain safe and operable all time.	The drone performs fully autonomous decisions on the way they implement given task, using data and possibly AI to plan the flight and modify it.
Environment Interaction (i.e. Collision Avoidance)	None	Sense and Alert UAVO		Sense and Avoid, usually also Alert UAVO	Sense and Navigate

UAV ecosystem uses many levels of communication protocols. Starting from on-board communication between systems, through aerial-to-aerial and aerial-to-ground, finishing on satellite communication. Communication in UAV operations is essential to its safety, reliability and performance. Here we discuss the most popular communication protocols used in drones (Figure 1).

On-board communication protocols are used to exchange communication between the drone components, usually flight controller (FC), sensors and actuators. Those protocols are commonly known and shared with UGVs and IoT world, so we just briefly present their list here without in-depth review.
Actuators are specific for drones however, we discuss them in the following sub-chapter in-depth, along with remote control protocols (RC protocols).
The most common on-board, low-level communication interfaces and protocols are:

• I2C,
• SPI,
• Serial/UART (COM),
• CAN (not so common),
• One-wire (rare).

The exact protocol use is usually driven by the set of sensors and components, that are present on-board of the UAV. Flight controller sometimes exposes set of dedicated ports (connectors), sometimes they are universal plugs that can be used as configured in the FC configuration.
In many cases, an elementary set of sensors is integrated with the FC, Additionally, for GPS positioning, NMEA protocol is frequently used.

Remote Control is an essential part of drones. While there do are fully automatic systems that take-off, implement the mission and then land 100% automatically, in any case, there is a backup solution using manual operation such as RC control. Additionally, following mission progress and current system conditions is essential thus telemetry is a natural part for all flying objects whether they perform autonomous or remote-controlled flight at the moment.

As from the beginning, RC was used to control actuators directly (usually control surfaces), so actuators communication protocols were and still are an essential part of the on-board communication. In Figure 2 we present a list of protocols and their assignment to the sections of the control sequence.

Remote control units communicate over FM radio one or bidirectional way, from the Ground Station/Controller to the aerial unit, referred as a Receiver, even if nowadays links are bi-directional and both parties play the role of transmitter and receiver.

On the physical level, we distinguish “analogue” RC that is (or rather “was”, as it is rare to find users now) operating on 27MHz and 25MHz bandwidth. This kind of communication couldn't share radio bandwidth so every pair (transmitter+receiver) sharing the same radio space needed to use a slightly different frequency, not to interfere. Transmitter and Receiver had both exchangeable oscillators and it was pretty common, operators sharing common space had to first agree, who is using which frequency. That was rather uncomfortable in use. For those reasons, the analogue transmission is mostly abandoned now, even if its great advantage was long communication range, virtually up to the horizon.

Digital era brought the use of 2.4 and 5.8 GHz, open frequencies. As transmitters and receivers became more complex, computerized and smart, many protocols introduced “channel” hopping, changing actively their frequency during operation, once the interference has been detected.

Radio communication between Transmitter and Receiver is mostly manufacturer dependent, but the following ones are most common:

• DSM family by Spectrum. Spectrum is considered to be a highly reliable radio manufacturer:
  • DSMX - latest of “DSMs”, also available as cheaper hardware from Orange manufacturer. DSMX is a new version of DSM2 and is backwards compatible: DSMX Transmitter can handle DSM2 Receiver. DSMX uses up to 60 channels.
  • DSM2 - also by Spectrum, uses two frequencies to transmit data.
  • DSSS - a single channel, rather old technology by Spectrum. Channel is selected and fixed during whole transmission, opposite to the FHSS model (see remark below).
• ACCESS / FRSKY by FrSky RC, bringing i.e. automated re-binding and up to 24 channels.
• FAAST by Futaba - 18 / 14 / 12 channel ones (18 channel is 16 linear + 2 binary), 12 channel is fastest one with legendary reliability.
  • FHSS and S-FHSS - new frequency-hopping spread spectrum protocol by Futaba, replacing FAAST.
• A-FHSS by HiTEC - similar to other manufacturers, another spread spectrum frequency hopping technology.
• AFHDS and AFHDS2 by FlySky - another RC protocol, the second one offers telemetry (bi-directional). Pretty popular due to the cheap hardware.
• HiSky protocol - used in popular WL Toys.
• DEVO - used in Walkera products (former are WK2401/2601/2801 currently abandoned).

On the logical level, most popular RC protocols, once decoded by the RF, include:

• PWM (historically that is the most popular protocol and still a kind of backwards compatible “backup” that most devices can still “understand” it) - the major disadvantage is, every channel requires separate wire;
• PPM (Pulse Position Modulation), referred also as CPPM - similar to PWM but it is not the duty cycle (as in PWM) but “distance” of the fixed pulse from the ticks defined by the clock signal; As classical PWM pulse takes between 1ms and 2ms max, and the 50Hz frame gives us 20ms, it is (theoretically) possible to send up to 10 channels, ordered. This is limited as the frame itself also requires some “space” between pulses. This is, how PPM “queues” channels, one after another and thanks to this trick there is only one data wire necessary to connect Receiver and FC.
• PCM (Pulse Code Modulation) - a digital transmission, capable to detect errors
• Serial protocols that include (among others)
  • SBUS (used in Futaba and FrSky) and their variations, it is inverted UART signal in general.

Servos are connected with 3 cables, power (+/-) and control. PWM frequency is constant but it is the duty cycle, that controls the servo rotation. Analogue (classical) servos use 50Hz PWM frequency. Modern, digital servos use 300Hz and up.
As digital servos are still not very popular, here we describe analogue servos' control principals. Analogue servo uses PWM standard frequency that is 50Hz, so the period is 20ms. A 0-degree rotation angle is equivalent to the 1ms high/19ms low digital control signal duty cycle, while 180 degrees is for 2ms duty cycle. Naturally, this scale tends to be linear, so 90 degree is equivalent to 1.5ms: see figure 3 for graphical representation of the control signal.

As one can see from the above, the most common case is a servo operating on 0..180 degrees range. Servos with other rotation range may use a different duty cycle.

Many communication protocols are shared with IoT, computer networks, automotive industry, UGV, airborne systems and even space industry. Here we focus shortly on those, that are used in drones or are on its way to be used in the nearest future.

Obviously, satellite communication protocols are one of the most frequently used, in terms of the drone (and operator) positioning. While it is possible to receive raw satellite signals over the radio and use it to decode the signal and obtain a lon/lat position using triangulation method (see the chapter on navigation for more details) it is common to rather use ready GNSS (referenced also as GPS) receiver module, that simply communicate to the flight controller or other device, providing 2D/3D position (3D includes altitude), positioning accuracy, number of satellites in view (it directly impacts positioning quality) and so on. Manual decoding requires a huge amount of resources thus is implemented with integrated circuits. Here we focus on communication between an FC and GNSS receiver rather than between satellites and receiver.
GNSS modules use textual and binary communication, depending on the particular receiver chip and PCB board design. In particular, most GNSS receivers are able to deliver information using NMEA protocol that is a standard communication protocol at the moment, usually in a textual form over the serial connection (the most common is 9600 bps). At the moment, a binary communication protocol is being introduced as more efficient and simply delivering position data much faster yet it is still a niche solution.
Sample NMEA data for Tallinn/Estonia Old City Central Market square is present below:

$GPGGA,095531.290,5926.238,N,02444.715,E,1,12,1.0,0.0,M,0.0,M,,*6A
$GPGSA,A,3,01,02,03,04,05,06,07,08,09,10,11,12,1.0,1.0,1.0*30
$GPRMC,095531.290,A,5926.238,N,02444.715,E,,,100920,000.0,W*74

Receivers are free to use (you do not need to purchase any licence/contract) and they're able to position using multiple satellite constellations.
Obviously, there are additional services(i.e. improved quality on positioning) that are charged for use and it may be reasonable to use it in some scenarios.
Additionally to the satellite communication, there is also aerial and satellite communication that provides additional live data, i.e. related to the correction of the impact of the current state of the ionosphere, ephemeris, and other factors causing incorrect and inaccurate positioning. Those are handled by GNSS receivers and too complex to provide them here but please note, they constitute an important factor of the quality of the drone positioning and is essential to the precise and secure operations and their performance in most scenarios.

ADS-B (Automatic dependent surveillance-broadcast) is an airborne protocol that drones barely use at the moment, but that is changing over time. Each commercial aircraft broadcasts information about its current position, velocity, direction and so on that can be received using special modules or even out of tuned DVB-T receiver (USB TV stick). ADS-B can be freely received and decoded but it is forbidden to broadcast it without permission and licence. Communication uses 1090 MHz band.

The simplicity of reception of the signal caused open-source implementations and rise of flight information services like i.e. very popular FlightRadar24 that directly benefit from ADS-B reception via distributed receiver network operated by amateurs.