Aerospace and Electronic Systems Magazine August 2016 - 7

Afonso et al. Figure 2. Profile of the average received power (a) as a function of position along an horizontal line and (b) as a function of UAV altitude. Besides the expected decrease of received power with increasing distance, an abrupt drop is visible above the BS, which can be explained by the antenna pattern and respective downtilt. It is important to highlight that even though a UAV located over this "hole" is basically at the centre of the cell, it is possible that a stronger signal can be received by a neighbour BS, which may result in a handover. In fact, when the altitude increases, the handover probability will tend to be higher. By inspection of Figure 2b, we can see that, for a typical LTE receiver sensitivity of -100 dBm, a maximum altitude around 1.7 km could theoretically be supported. lem between two peers, especially if both peers are placed behind certain types of NAT. While a full and rapid deployment of IP version 6 could be the ideal solution to overcome all the problems raised by the use of NATs, in the meantime, to allow devices to establish peer-to-peer communications, one has to circumvent these problems by using NAT traversal techniques. Due to the wide range of NAT implementations, several traversal tools, methods, and protocols usually employed on client-server applications (Figure 3) have been developed over time, such as: C DEVICE TO DEVICE COMMUNICATION When establishing a connection between two devices over the Internet, some difficulties can arise due to the network architecture. This is particularly true when direct communication is expected between UAVs and GCSs, and possibly when they are placed in different mobile networks. To overcome Internet Protocol (IP) version 4 address scarcity, most operators have resorted to private networks and use network address translation (NAT) when communication to the Internet is necessary, as shown in Figure 3. Unfortunately, NAT is not standardized, creating interaction difficulties due to the diversity of NAT rules that may be used. This raises security problems from the possible fracture in the communication between hosts and third party servers that implement NAT traversal protocols. Basically this can lead to a connectivity prob- C Session traversal utilities for NAT (STUN) protocol, RFC5389, which is used for detecting the presence of NAT and the public IP address. It works for the least problematic NAT implementations, but unfortunately it is not a complete solution, particularly on networks masqueraded by symmetric NAT. Traversal using relays around NAT (TURN) protocol, RFC5766, which is used for relaying data between hosts in the presence of a NAT with address and port dependent mapping and filtering rules [12]. This type of NAT maps every internal request to a unique external IP and port, preventing the communication from the public side. TURN provides devices not only with the tools to control the operation of the relay but also to exchange data with other devices using the relay. Interactive connectivity establishment, RFC5245, is a protocol that provides a full NAT traversal solution. It helps devices to discover enough information about their network topologies and possibly finding a communication path using other protocols such as STUN and TURN [12]. C Figure 3. NAT as an interface between a private network and a public network. AUGUST 2016 IEEE A&E SYSTEMS MAGAZINE In a typical scenario, connections between UAVs and GCSs may have to resort to different mobile networks. In order to deal with the possible presence of NATs, communication modules must implement 7

Table of Contents for the Digital Edition of Aerospace and Electronic Systems Magazine August 2016