SIGNALING PROTOCOLS FOR LOCAL AREA NETWORKS OF DRONES

Unmanned Aerial Vehicles (UAVs) or drones have become extremely popular and are used in various commercial applications. When multiple UAVs communicate and work together, they form a UAV network. A private UAV network or Local Area Network of Drones (LoDs) is a special type of UAV network which has the minimum number of UAVs to carry out a certain task. All UAVs in a LoD use the wireless medium to send and receive the data as well as the control signals. An organization or a single owner will be more interested in this type of network, where they want multiple UAVs to scan an area, communicate with each other, and send all the images and live video streams to a single ground station. The currently available commercial UAVs Can send the video signals to and receive control signals only from their own ground station controllers. However, in an LoD network where UAVs are connected in tandem, the UAVs that are in the middle of the network have to carry the control and video signals of other UAVs. Given the limited processing power and dynamic memory capacity of UAVs, this would increase the queuing delays and performance. In this paper, we study the frame formats of existing control, feedback, and data messages of commercial AR UAVs and propose a new approach to construct the payloads of control and feedback frames that are suitable for an LoDs. We compare the performance of our approach of single control and feedback frame for all UAVs in a LoD branch with that of separate control and feedback frames for each UAV. We calculate and compare the UAV node processing delay in both types of signaling mechanisms and show that the single control and feedback frame signaling has less delay on the average.


INTRODUCTION
Commercial UAVs provide a variety of services in various domains such as agriculture, surveillance, rescue, and construction. UAVs have become a powerful tool for commercial applications with their live video recording and streaming capabilities. The live video streaming helps the owner of a UAV to manage a large area while staying near the ground station or even at home. For example, a person may use a UAV to monitor an agricultural farm and receive live streaming videos of the farmland at a ground station [1].
In commercial applications of UAVs, the UAVs can provide more flexibility to their owners if they work together in a network. We can use several UAVs and form an LoD to be used in some of these commercial applications [2]. The communication mechanism is a key issue in a LoD. The communication in an LoD happens from one UAV to its neighbor UAV in tandem and finally, to the ground station and vice-versa.
Most modern commercial UAVs provide the facility to communicate between UAV and a smartphone app, in which the smartphone first sets up a Wi-Fi connection with the UAV and then control signals are transferred from the smartphone app to the UAV in packet format. The UAV, in turn, sends the feedback signals and streaming video to the smartphone. The feedback signal has information about UAV's flight status, battery status, flight altitude and many others. Thus, signaling protocols play a key role in UAV to smartphone communication. In a LoD, there is only one ground station for all UAVs which can be a computer or a smartphone that acts as the controller as well as the video receiver. Sending separate control signals to each UAV or receiving separate feedback signals from each one of them is inefficient and would lead to a waste of channel bandwidth. Depending on the processing power of the UAV and its dynamic memory capacity, this process results in increased packet loss and delay. It then leads to poor control and instability of UAVs movements as the UAVs and the ground station will not receive the control and feedback signals on time. Therefore, the control and feedback signal packets used for flying a single UAV has to be studied and should be adapted appropriately to be used in LoD networks.
The structure of the rest of the paper is as follows. Following a brief discussion of LoD topology in section 2, we discuss the signaling protocols used in two popular types of commercial UAVs. In section 4, we introduce the new signaling packets for LoD networks. Section 5 shows via simulations the performance improvement of LoD networks using this new approach. Finally, the paper is concluded in section 6.

REVIEW OF LODS TOPOLOGY
As mentioned in the above section, an LoD network is a network with several UAVs. An LoD has a star-connected relay topology, where the ground station is at the headend and all UAVs are located in the branches [3]. A simple LoD is shown in Figure 1. Each UAV in this network has the capability to communicate with its neighbor UAVs in the same branch. The distance between two UAVs in any two different branches of an LoD is larger than the maximum Wi-Fi coverage distance of 100m, except in the case where the branches are made to be closer to improve reliability [4].
The control, feedback, and data messages in an LoD branch follow the same path as shown by bidirectional arrows in Figure 1. In an LoD, each UAV has a unique Internet Protocol (IP) address as well as a Media Access Control (MAC) address. With reference to the LoD network in Figure 1, let us assume that there are m branches and each branch has n UAVs. The first UAV of each branch is directly connected with the ground station through the wireless connection. In Figure 1. A LoD with three branches the next section, we discuss the control and feedback signaling of existing commercial UAVs manufactured by two popular companies.

SIGNALING PROTOCOLS IN EXISTING COMMERCIAL UAVS
At present, there are two established companies, DJI [5] and Parrot [6] in the market that design a range of UAVs for commercial applications. These two companies work independently and produce different types of UAVs. However, the design of communication signals between the UAV and the controller app has some common features in all these UAVs.
These signals are carried in packets and communication channels of two frequency bands (2.4 or 5 GHz) are used to transfer the control and feedback signals as well as the data signals. In most UAVs, the designers send control and feedback signals in one frequency band and data is transmitted over the other frequency band to avoid communication interference as well as to minimize the loss of control packets. In such designs, the 2.4 GHz frequency band is used for control and feedback signal transmission and 5 GHz frequency is used for data transmission. This design is shown in Figure 2. Current designs of Parrot UAVs and some models of DJI are examples of this type of arrangement. However, initial versions of Parrot UAVs such as AR 2.0 uses 2.4 GHz band for both data and control signals.
Some UAVs swap these two frequency channels to transmit their control and data signals. In this type of design, the 5 GHz frequency is used to send control and feedback signals, and the data is transmitted over the 2.4 GHz frequency. DJI has some UAV models (e.g. Phantom 2 Vision and Vision +) that use this convention. Figure 3 shows this type of communication arrangement. Both types of communication systems have their own advantages as well as disadvantages. In this paper, we discuss the signaling method used in AR 2.0 drones and modify it to design the signaling for LoD networks.

Parrot's AR UAVs
As described in their development guide, AR 2.0 UAVs use various control signals to represent different control commands. These control signals are transmitted from the smartphone to the UAV on Wi-Fi. AR 2.0 UAVs have four types of communication services, first to control the UAV, second for the navigation data, third for the video stream, and the last for the control port information [7].    Information about the UAV navigation data (navdata): This is the second type of communication service in AR 2.0 UAVs. Once, the controller connection is established with the UAV and the control signal is transferred from the smartphone to the UAV, UAV sends its navdata to the smartphone. The navdata has information such as the status, speed, engine rotation speed and the battery level of the UAV. In the design of AR 2.0 UAVs, the UDP port number 5554 is allocated to receive this navdata information. This information is sent to the client 15 times per second in demo mode and 200 times per second in full mode.
 The video stream and Control Port: AR 2.0 UAVs send their video data in UDP or Transmission Control Protocol (TCP) packets, depending on the version. The UDP port 5555 is assigned to receive the video packets. AR 2.0 UAVs use TCP protocol and AR 1.0 UAVs use UDP protocol for the transmission of the video stream. The TCP port 5559 is used to send critical data. It is used to retrieve the configuration information data.

AR 2.0 UAV Control Packet
As we discussed in the previous section, once a controller is bounded with a UAV, it sends control signals continuously to the onboard UAV system. These control signals are carried in UDP packets as we saw earlier in section 2. We first study the UDP packet of AR 2.0 UAV and then, consider how it can be adapted for signaling in LoDs when a common control packet and a common feedback packet is used for all UAVs in a branch.
AR 2.0 UAVs use various control commands to send the control signals to the onboard UAV system. These control commands are application data that is generated by the controller (a mobile app or a computer program). These application data are passed to the transport layer and a UDP control packet datagram is created. A UDP datagram has two parts, an 8-byte header and a 1024 bytes payload. The UDP datagram of an AR 2.0 UAV is presented in Table 1. The AR 2.0 development guide provides a list of mostly used control commands for AR 2.0 UAVs.  (16)) followed by a command name, an equal sign, a sequence number, and an optional list of comma-separated arguments whose meaning depends on the command. A UDP packet of AR 2.0 UAV can hold one or more control commands, separated by newlines (byte value 0A (16)). But an AT command must reside in a single UDP packet and splitting an AT command in two or more UDP packets is not possible. In AR 2.0 UAVs, strings are encoded as 8-bit ASCII characters with a carriage return character (byte value 0D (16)) represented by <CR>, hereafter called a newline delimiter. We studied all the AR 2.0 UAV control commands to find the maximum UDP packet size. AR 2.0 UAV uses similar types of control command with a different number of arguments, for e.g., the two commands AT*PCMD and AT*PCMD_MAG. As we are interested in the maximum size of UDP payload for a single control command, we consider the command with maximum argument size from among the similar types of commands. Table 2 shows the details of the UDP data for each control command. We can see from Table 2, the maximum size of the payload required for the UDP data for one control command of a AR 2.0 UAV cannot be more than 41 bytes. However, more than one command can be placed in a UDP packet. We used Wireshark to study the control commands of AR 2.0 UAVs. Wireshark traces showed there is a maximum of three control commands in a single UDP packet. Even if all these control commands are sent together, we require only 130 bytes of payload, and therefore, they can fit into a single UDP packet. These control commands are transmitted in a frame from the ground station to the AR 2.0 UAV. Wireshark showed that a control frame has 8 bytes of UDP header, 20 bytes of IP header and 14 bytes of Ethernet header. We investigated and found that the Wireshark Wi-Fi frame capturing does not work well with Windows and it gives incorrect Ethernet header details [8]. We examined Wi-Fi frames in Wireshark with Linux to check the Ethernet header. The Wireshark captured frames in Linux give the correct Ethernet header. We use standard Wi-Fi 802.11 MAC frame format for the AR 2.0 UAV control frame. Table 3 shows the maximum size of the control frame for AR 2.0 UAV which has 192 bytes. The ground station usually sends 30 control commands per second to the UAV as we verified using Wireshark.  Table 4 provides information about the navdata that is transmitted from the AR 2.0 UAV to the ground station. UDP port 5554 is used to send the navdata from the UAV to the ground controller. This navigation data is received periodically (less than 5ms) by the client application and it has various information such as flight speed, altitude, distance, roll, pitch, camera, and much more. Each UAV sends this information in a single UDP packet. As shown in Table 4, standard navdata has 4-byte header, 4-byte UAV state, 4-byte sequence number, 4 bytes for tag vision, and 4 bytes for the checksum data in the checksum block. The navdata information is stored in several options fields in a UDP packet. Each option field has a 2-byte header, a 16-bit integer for the size of a block, and a data block. These fields are used to specify what type of navigation data is received by the ground station. The information in options fields is stored in the form of a 32-bit integer and 32-bit single-precision floating-point number or arrays. As in the control frame, the feedback frame also contains 4 bytes of a checksum at the end of the frame. Wireshark showed that each feedback frame has 492 bytes of feedback data and when we use the standard MAC header the size of the feedback frame will be 558 bytes. The feedback frame that is transmitted from the AR 2.0 UAV to the ground station is shown in Table 5.  Table 8 which has 1534 bytes.

MANAGEMENT OF CONTROL AND FEEDBACK FRAMES IN LODS
In an LoD network, we can treat each UAV individually and simply send the control messages from the ground station to each one of them and receive separate feedback and data frames from each of them at the ground station. However, this will result in wasting bandwidth. Instead, we can send a single control frame to all UAVs in a branch and receive a single feedback frame containing feedback information from all UAVs in a branch. Since a UDP packet has a maximum size, the number of UAVs whose control or feedback information that can be packed into one UDP packet is limited. Therefore, in section 4.3.1, we first investigate this situation and find the maximum number of UAVs in a branch that we can have to send control information and receive navdata using a single UDP packet.

Single Control and Feedback frame per each branch
In this section, we discuss the single control and feedback frame mechanism to manage the signaling in a LoD. We know that the Maximum Transfer Unit (MTU) in a Wi-Fi network is 2304 bytes [9]. Thus, the maximum size of a UDP packet is 2284 bytes after removing the 20 bytes of IP header. Since the UDP header is 8 bytes, the maximum UDP payload size is 2276 bytes. As we determined before, the maximum payload size required to carry the control signal of a AR 2.0 UAV is 130 bytes, and therefore, we can assemble the control signals of 15 UAVs into a single control packet. On the other hand, the payload size required to carry the feedback signal of a UAV is 500 bytes including the checksum. Therefore, a single feedback packet can carry the feedback signals of 4 UAVs with 276 unused bytes. If we did not consider the checksum in the feedback data, then also we can have a maximum of 4 UAVs. This arrangement is shown in Figure 4.  In a LoD network, the ground station can create a single control frame for 4 UAVs in a branch. This frame has a payload of 130*4= 520 bytes. This single frame also has 8 bytes UDP header, 20 bytes IP header, 30 bytes 802.11 MAC header and 4 bytes FCS as shown in Table 7. UAV 1 will receive a single frame of 582 bytes. UAV 1 processes this frame, extracts its control command and repacks the remaining data into a new frame before sending it to UAV 2. Now, UAV 2 decapsulates the frame to extract its control command. This process repeats at each UAV and continues until the last UAV (UAV 4) receives its control command as shown in Figure 4.
In a Similarly manner, each UAV processes the feedback frame traveling in the opposite direction from UAV 4 to the ground station. The ground station receives a feedback frame with feedback data of 4 UAVs as shown in Table 8. In this LoD network, UAV 4 creates a feedback frame of 558 bytes and sends it to UAV 3. UAV 3 processes this incoming feedback frame and reconstruct a new single frame by adding its feedback data and passes it to UAV 2. The process continues until up to UAV 1 node. Finally, the ground station receives a single feedback frame that has the feedback information of all 4 UAVs. Table 9 shows the control and feedback frame processing at each UAV along a branch. We used only four UAVs in a branch in this LoD network with this new signaling mechanism. However, in an LoD network with more than four UAVs in a branch, these single control, and feedback frame signaling mechanisms can still be used. If the network has more than four UAVs in a branch, a ground station will send one control frame for every four UAVs and receive one feedback frame from those four UAVs. For example, if a branch has eight UAVs, the ground station will send two control frames to first UAV, one for first four UAVs and the other for the last four UAVs. The ground station will receive two feedback frames, one from the first four UAVs and the other from the second 4 UAVs. Each one of these feedback frame has the feedback information of four UAVs.

Separate Control and Feedback frame per each node
The second method of signaling is the transmission of separate control and feedback frame for each UAV as shown in Figure 5. In order to compare with the case of a single control frame, we consider an LoD with only 4 UAV nodes in a branch. The ground station generates four control frames, one control frame for each UAV and broadcasts them. Assuming that only UAV 1 is in its Wi-Fi range, which is the case in a LoD, these four control frames will be received by UAV 1 and placed in a queue. The first frame in the queue is processed by UAV 1 and remaining three control frames are broadcast. Then, they will be picked up by UAV 2 and placed in its queue. The process continues until the 4 th frame is received at UAV 4. Because the frames for other UAVs have to wait in the queue of a UAV until the frame destined for itself is processed, they incur a delay. In this signaling mechanism, each UAV also generate a feedback frame and broadcasts it. As shown in Figure 6, UAV 4 sends its own feedback frame to UAV 3. UAV 3 sends its own feedback frame and that of UAV 4 to UAV 3 and so on. Finally, the ground station receives four separate feedback frames. These feedback frames also undergo queuing and processing delays. It should be noted that the same queue is used to store the incoming control and feedback frames but a separate queue is used for video frames.

ANALYSIS OF THE PROPOSED SIGNALING MECHANISMS FOR LODS
We discussed two mechanisms in section 4 to manage the signaling in an LoD. In this section, we will compare the single control and feedback packet signaling mechanism with the separate control and feedback signaling mechanism. We first calculate the total delay from the ground station to each UAV node for both scenarios in the LoD and then compare these delays. The total delay to travel a frame from one node to the other in the network depends on several factors. The basic equation for the total delay is given below:  where TD is the total delay and it is the time between the arrival of a frame at a node and arrival of the same frame at the next node. PD is the processing delay and it is the time that a node spends to process the packet. QD is the queuing delay and it is the time that a packet spends in a queue at a node while waiting for the packets ahead of it to be transmitted. In both scenarios (single control and feedback packet), two separate queues are maintained, the first for control and feedback frames and the second for the video frame. PRD is the propagation delay and it is the time that a packet takes to propagate through the communication media from a node to the next node. It is calculated by dividing the distance from the node to the next node by the propagation speed through the medium. As the distance between the two UAV will always be less than 100 m, the propagation delay will be the same for both scenarios and we will not consider it in our calculation. TRD is the transmission delay and it is the time required to put an entire frame into the media. TRD depends on the transmission rate (R). In both scenarios, the transmission rate is the same and as such, we will not consider it in our calculation as well. As such, for comparison purposes, the total delay for both signaling mechanisms will be taken as the sum of PD and QD.

The total delay for separate control and feedback frame
In this section, we calculate the total delay for separate control and feedback frame signaling for the LoD network. To calculate the delay, we have to first find the arrival rate (λ) of control and feedback frames at each UAV and also the service rate (µ). The service rate is the processing speed of the AR 2.0 UAVs to process different incoming frames. Furthermore, the AR 2.0 UAV processes three types of frames (i.e. control, feedback, and video). Therefore, we have to consider the time shared by the processor to process control, feedback and video frames. AR 2.0 UAV development guide does not provide the information about the processor time sharing to process these three frames. But we have already calculated the size of control and feedback frames and we also know as to how many of these control and feedback frames can be send in one second to and from the AR 2.0 UAV. Hence, we can find the average processing speed to process these frames used by AR 2.0 processor. In AR 2.0 UAV, for smooth communication with the ground station, a control frame should be sent in a regular basis, usually, 30 times per second. It means AR 2.0 can process 30 control frames per second and, as we have already calculated, the single control frame size of 192 bytes. Therefore, the processing speed required by AR 2.0 UAV to process the control frame will be 46.08 (0.192*8*30) kbps. The AR 2.0 UAV can send 15 feedback frames per second to the ground station and the size of one feedback frame is 558 bytes. Therefore, the processing speed of feedback frame is 66.96 (0.558*8*15) kbps. We need the find out the AR 2.0 UAV video processing rate to calculate the processor time sharing between control, feedback and video signals. As per the AR 2.0 development guide, the video frame bit rate of this UAV, can be set between 500 kbps to 4000 kbps. This is the rate of raw video data rate. We captured many video frames in Wireshark and calculated the average video processing speed. We used the Wi-Fi frame header size for calculating the processing speed of video frames. Our calculation gives us the average video frame processing rate of AR 2.0 UAV as 4758 kbps. Therefore, the overall processing speed of AR 2.0 UAV is equivalent to 4871 kbps (46.08+66.96+4758). This processing speed is required to process the control, feedback, and video signals. Now, we can calculate the time sharing of the AR 2.0 processor to process these frames. Hence, in the AR 2.0 UAV, 0.95% (46.08/4871) of the total processing speed is used to process the control frames, 1.37 % (66.96/4871) of the total processor speed to process feedback frames and the remaining 97.68 % of the total processor speed is used to process the video frames.
Since in an LoD network, each UAV has to communicate with its neighbors, we used Edimax WAP [10] on each UAV to enable communication. The processing speed of this WAP is 150 Mbps. If this WAP capability is provided in each UAV, the overall processing speed of each UAV will be 150 Mbps. Now, we can use the same fractions that we calculated for AR 2.0 to calculate the average processing speeds of control, feedback, and video frames in the LoD network. Therefore, in the LoD network, each UAV node can process control frames with a speed of 1.43 Mbps (0.95% of 150 Mbps), feedback frames with a speed of 2.06 Mbps (1.37 % of 150 Mbps) and video frames with a speed of 146.51 Mbps.
In delay calculation, we used queuing theory formulas. The control and feedback delay calculation for the separate control and feedback signaling is given in Tables 10 and 11, respectively. We used the following parameters to calculate the delays.
 λ is the mean rate of arrival of a frame  µ is the mean service rate or processing speed to process the frame,  ρ is the utilization of the server  Lq is the mean number of frames in the queue  QD is the queuing delay  PD is the processing delay  TD is the total delay  TDGC is the total delay from the ground station to the UAV node for control frames processing  TDGF is the total delay from the ground station to the UAV node for feedback frames processing
TD = (((λ/µ) 2 / (1-(λ/µ))) /λ) + (λ/µ) (7)[  Table 11 shows the queuing and processing delay calculation for a feedback frame for the separate control and feedback signaling in the LoD network. We found the number of feedback frames arriving at each UAV and calculated the arrival rate of feedback frames. We found the total delay at each UAV node in the LoD network with the help of Tables 10 and 11. The total delay calculation is shown in Table 12. We also calculated the delay from the ground station to each UAV node as shown in Table 12.

Cross-Layer Design of Single control and Feedback Frame
We used a cross-layer design to process each incoming frame. In cross-layer design, the frame is processed at the MAC layer without going through higher layers in the TCP/IP model. As before, the rate of control frames arriving at each UAV and the rate of feedback frames leaving each UAV is 30 frames per second and 15 f frames per second, respectively. We used the same queuing delay formulas to calculate the delay of frames with a single control and feedback frame for all 4 UAVs. The delay calculations for control and a feedback frame are given in Tables 13  and 14. We also calculated the delay from the ground station to each UAV node as given in Table 15.  Control frame processing of a LoD branch with 4 UAVs

Delay comparison
We calculated the delay from each UAV node to the ground station for both types of signaling mechanisms in the last section. Table 12 shows the delay for the current signaling mechanism, where separate feedback and control frame is used for each UAV and the delay for the single control and feedback signaling mechanism in Table 15. The delay comparison graph shown in Figure 6 was drawn with the help of Table 12 and 15. We can see from the graph that our newly developed single control and feedback frame mechanism has a lower delay compared to the existing signaling method. The reduction in delay as a percentage with the new signaling mechanism is presented in Table 16.  The delay in both signaling mechanisms is due to the high volume of video frame processing by each UAV. We can see from Table 16 that the new signaling mechanism reduces the delay around twenty percent for control frame processing and at least five percent for feedback frame processing. Thus, the single control and feedback frame signaling mechanism is a better approach for the signalling in LoDs as far as the delay is concerned.
In an LoD network, frames have to pass from one UAV node to the other. Thus, if a node malfunctions, frame corruption happens whether we have a single control and feedback packet or not. The reliability under node malfunctioning has already been discussed in [4]. The research result in [4] shows that two redundant branches will give near 100% reliability.
The packet loss rate for the AR 2.0 UAV is not given or measured in the literature. However, Silva et al. [11] have conducted multiple experiments to evaluate the performance of the Multi-UAV network. They calculated the packet loss by sending 500 packets between UAVs in the Multi-UAV network. This research result shows a maximum of 0.9 packet loss out of 500 packets transmitted between UAVs in different scenarios. We can consider this packet loss rate to estimate the packet loss rate of the network with a newly proposed signaling mechanism. Hence, the frame loss rate with separate control and feedback signaling for each UAV is given by 0.18% (0.9/500*100). Since we are combining the control or feedback signals of four UAVs into a single frame, the frame loss rate will be 0.72% and is very low. As such, the reduction in delay comes at a cost of increasing the frame loss rate.

CONCLUSION
The main purpose of this paper is to investigate the frame rates of the current signaling mechanism in LoDs and proposing a new signaling mechanism to reduce the delay from the ground station to each UAV. For this purpose, we studied the control, feedback, and video frame rates of AR 2.0 UAVs that are transmitted between a UAV and ground station. In the LoD network, when multiple frames arrive at a single UAV node, they have to wait in the queue before being transmitted to the next UAV node and this introduces a delay in communication.
However, each UAV in the LoDs network can maintain two separate queues, one for control and feedback frames and the other for video frames to mitigate the queuing delay. Using a cross-layer design and combining the payloads of frames destined for 4 UAVs in an LoD branch into single frames, the delay experienced by control and feedback frames could be reduced to around twenty percent and at least five percent respectively. Therefore, this new signaling mechanism is a better approach for an LoD network.