Long Range UAS Mission by LPWAN Communication

One of the key challenges for long range Unmanned Aerial Systems (UAS) is the limitation of the communication capability. Many existing communication technics are conventionally adopted in UAS to improve the quality of the communication such as satellite communication, cellular networks, and relay aircrafts. However, the mentioned solutions often incur several drawbacks including costs, complexity, communication delay, or inefficient power consumption. LoRaWAN is one of the recently emerging communication technics used in the Low Power Wide Area Networks (LPWAN) technology. It has a promising potential to improve the coverage of UAS communication, since it can transmit/receive signals below the noise floor in a very long range with very low energy consumption by using the waveform modulation technique called Chirp Spread Spectrum (CSS). In this paper, we show the potential of LPWAN as the supplementary communication in UAS. The experiment results show that LoRaWAN can maintain the communication capability beyond 80 km where the popular RF device, RFD900x, has lost its ability to communicate at this distance.


Introduction
The communication subsystem of unmanned aerial system (UAS) is often the key limit factor of a longrange mission due to the required continuous update of the telemetry and mission data. Therefore, the extension of the UAS communication range is constantly attract attention from the research community.
The key challenges are to maximize the coverage and data rate while minimizing the power consumption [1]. Extending the signal travelling distance results in a significant power attenuation along the path causing a very low power efficiency. Increasing the amount of transmitted data is achieved with the cost of heavy power consumption [2,3].
Besides the normal RF communication, there are multiple approaches to extend the range of the UAS mission including satellite communication, relay aircrafts, cellular network, and low power wide area network (LPWAN). In which, each approach has its own advantages and disadvantages. While relay aircrafts carrying the same type of RF transceivers as the mission aircraft to extend the distance of the mission seems to be simplest in implementation of the same communication protocol. But, the control of multiple aircrafts at the same time makes the mission more complicated [4,5]. Another existing solution to increase the range of UAS operation is to use the cellular networks. The drawback of cellular network is the lack of network infrastructure in some areas [6,7]. For the beyond line of sight (BLOS) scenario, the satellite communication is quite effective. However, there are subscription expenses to use the satellite services [8]. With all the mentioned limitations, the Low Power Wide Area Network (LPWAN) technology has a potential for improving the communication capacity in UAS because of its low energy expense and the capability to receive/transmit signals in a very long range below the noise 2. LPWAN Background LPWAN (Low Power Wide Area Network) is a technology that allows multiple endpoints to form a network over a long range with the characteristics of low-power consumption and low bit rate in a narrow bandwidth [11]. The LPWAN is originally designed for IoT applications and machine-tomachine (M2M) communication. The usual data capacity of LPWANs are 10 to 1000 bytes per transmission at the uplink speed up to 200 kbps, whose range varies from 1 to 1000 km, depending on the communication technics and the tradeoff between the data size and data rate.

Type of LPWAN
There are three popular types of LPWANs as follows [11,12]. The first type is Long Term Evolution for Machine Type Commutation (LTE-M) and Narrowband-IoT (NB-IoT). They are both 3rd Generation Partnership Project (3GPP) standards that operate on the licensed spectrum. NB-IoT, also known as CAT-NB1, is specifically on indoor coverage, low cost and low power. It has a data rate up to 200Kbps and limits the bandwidth at 200kHz. LTE-M, also known as CAT-M1, offers higher bandwidth than NB-IoT. The receive bandwidth of LTE-M around 1.4 up to 5 MHz. LTE-M consumes the highest bandwidth of all mentioned LPWAN technologies. However, The LTE-M's transmission power is equal to NB-IoT.
The next type is Weightless SIG, which has three different standards including the unidirectional Weightless-N, bidirectional Weightless-P, and bidirectional Weightless-W. Weightless-W is the most unpopular options because Weightless-W's battery life is shortest. Weightless types N and P use unlicensed spectrum in the sub-1 GHz but also support licensed spectrum operation using 12.5 kHz narrowband technology.
The last type is the LoRaWAN. LoRa runs in various unlicensed sub-gigahertz bands specified by LoRa Alliance. LoRa use chirp spread spectrum (CSS) modulation, allowing the communication in a very long range with less interference than other LPWANs. All users can program the LoRa chip with open source library from Semtech Corporation, which allows users to freely manage their desirable packet size. Nowadays, LoRa technology is implemented in many long-range communication projects because of its very low receiver sensitivity up to -148 dBm. Table 1 shows the comparison of LPWAN technologies in many important aspects. LoRa possesses the highest link budget of all mention standards. Regarding the security aspect, LoRa offers 32-bits security technology, while the best contender only offers 16-bits technology. LoRa also implements CSS which allow the reception of the signal below the noise floor. Due to the operational characteristics of UAS, maintaining the communication system between Ground control Station (GCS) and Unmanned Aerial Vehicle (UAV) is critical for the survivability. Therefore, the communication subsystem of the UAV should offer a secured stable long-range connection. We chose LoRaWAN as the most potential candidate in this work because of several advantages on the communication range, network security and power efficiency.

Class of LoRaWAN Devices
LoRaWAN classifies its end devices three classes according to how the end device exchanges data with the server [13]: Class A: The end device has a duty cycle of active/sleep interval, while the server remains active. The end device wakes up and transmit its data packet and wait for a potential data reception within the specified intervals. If the Server demands to send some message to the end device, the server must wait for the End device to wake up and transmit first.
Class B: The data transmission cycle is specified by the periodic beacon signal emitted by the server. The end device regulates its transmission windows using the beacon signal as the reference. Therefore, the server can control the speed and cycle of data transmission.
Class C: The end device has almost no sleep. It opens the slot for the data reception from the server all the time allowing a non-scheduling timely data transfer in exchange of energy expense.
The concept of operation of every class of LoRaWAN is illustrated in Figure 1.

Figure 1. LoRaWAN classes
The class of end devices is determined based on the requirement of each application. For UAS application, class B seems to be the most suitable class where the power consumption and the success rate of transmitted are optimized. However, the LoRa class B driver is under development and will be available soon. So, the work presented in this paper will use only class A and class C devices for the experimentation.

LoRaWAN Topology
According to the LoRaWAN topology as shown in Figure 2, there are four hardware components necessary for the operation.

End Device.
It is the data transfer device that using the LoRa modulation technique to encapsulate the data and broadcast it to LoRa gateways.

2.3.2
Gateway. It is the medium device between End-device and Network service. Generally, Gateway will send data received from End-device to Network service using internet. Gateway is also the point to schedule the Downlink signal coming from Network service to send to the End device.

Network Service.
It is the LoRaWAN main network, is responsible for sorting and collecting data from the connected gateways. It also decodes the received data before forwarding to the Application Server via the internet. The network service usually in the form of a Cloud system so that the users can access to the network whenever the connectivity to the Internet is available.

Application Server.
It is the user interface software using the Network service Application User Interface (API) to control Network service or Downlink data to End-device. Application Server usually is installed with Network service for simple and fast data transfer.

Concept of Operations and System Overview
We have designed the concept of operations, hardware structure, and software structure of LoRaWAN technology for this research as follows.

Concept of operation
In this system design, we use MAVLink [16] as the standard protocol for exchanging telemetry data between drones and GCS. The overall system will focus on checking the condition of the telemetry signal through MAVlink in order to be used as a condition to enable communication by LoRa. The system will start by checking the quality of the telemetry signal. If the quality of telemetry signal is lower than 10%, the warning message will first be downlink via LoRa system to alert and to check the stability of LoRa communication system to prepare LoRa system for the event of the telemetry signal loss. After the telemetry signal between UAV and GCS has been acknowledged as lost, UAV is still set to continue the assigned mission as the LoRa system begins the full back up operation. The process begins with the downlink of the telemetry warning message requesting the next command from the GCS whether to continue the mission, to put the UAV to return to land mode (RTL), or to stop the mission and return to the base. After GCS has sent the next command to the UAV, LoRa begins to downlink the UAV's location and check the condition of the main signal every 60 seconds so that the GCS can continue to monitor the operation and observe the movement of the UAV in absence of the main communication system. If the primary communication system gets back online, the system will switch to the main communication system automatically and the LoRa system will stop sending the UAV's information and get back to monitor the telemetry connection quality as usual. Figure 3 shows the flowchart of the UAV back-up communication CONOPS.

Hardware structure
The hardware structure used in this research is divided into two parts, which are the hardware installed on the UAV and the hardware on the GCS as illustrated in Figures 4 and Figure 5. For the hardware installed on the UAV, the key component is the flight controller, which signal the control surfaces and actuators on the UAV. In this research, the Pixhawk 2 (The cube black) [17] is used as a flight controller. The Pixhawk 2 will be connected to the telemetry, device used to communicate between UAV and GCS, via UART.  [18] is used as the main communication subsystem in this research. A companion computer is necessary as the interface between the flight controller and LoRa system. Raspberry Pi Zero [19] is chosen a companion computer that works alongside with the flight controller to receive and forward commands to the LoRa system. The RFM95W [20] is the UAV's LoRa End-device. The MAVlink protocol [16] is used as a communication protocol between Raspberry pi zero and the Pixhawk 2. The connection between each hardware installed on the UAV is shown in Figure 6.

Software structure
The software structure in this work is divided in to two parts, the LoRaWAN part and the system control part as shown in Figures 8 and 9. The software is installed inside the Raspberry pi zero which is used as a companion computer for the UAV. The details of the software components are as follows.

The LoRaWAN
Package forwarder: The Hardware Abstraction Layer (HAL) of the LoRa gateway. The program will get raw data of the LoRa message it received to LoRa gateway bridge. LoRa gateway bridge: The program which convert the raw data received from the package forwarder into a JSON (JavaScript Object Notation) object to match the LoRa server implementation model and publish it to the MQTT (Message Queuing Telemetry Transport) broker and also do the conversion of the JSON object received from the LoRa server back to its original form for sending to the End device as well.
MQTT broker: The communication medium software for connecting various programs within the Gateway together. It will operate in the form of publish /subscribe programs. The program that want to send data to other programs must publish the information and the information topic to the MQTT broker. After that, when any program wants to receive data from the publisher program, it must subscribe to that data by choosing from the topic of information. MQTT broker can support the program to connect to the broker at the same time to 1000 programs, including the ability to encrypt the data. Using MQTT as a medium for data transmission make it easier to send and receive data from various programs on the gateway and to support data receiving from more gateway in the future.
Network server: The program at the centre of the LoRaWAN network is responsible for handling redundant data that occurs during the transmission of data from the gateways to the server, managing data when there are many connections and prioritizing the delivery of downlink to end devices.
App server: The user interface program that works with the LoRa Network server. It will handle the join to server request message sent from end devices, managing the encryption and decoding of the data that the end devices send to the server and providing the API service to connect with third-party programs via the system API PostgreSQL: Object-relational database management system using ORDBMS (Object-Relational Database Management System). It can use almost any type of SQL (Structured Query Language) code. It is also the most modern opensource database system.

System control
MAVlink monitor: the main program that will monitoring the MAVlink message to observe the UAV status and the connection quality. It will command the API interface to send the downlink message and observe the UAV's information from uplink message too.
API interface: Connect to the network server through the API service of the app server for change some setting of the network or sending the downlink message to the end device.
Uplink MSG handler: Subscribe to the uplink data topic in MQTT broker for logging the uplink message received from the end-device to a text file. All software in the system control part are written in Python.

Experimental Setup and Results
There are two aspects that this work is focusing on the LoRaWAN technology for the long range UAS mission. The first one is the ability to extend the distance of the communication of the existing RF transceiver. Another aspect is on the variation of each class of LoRaWAN devices that suitable for UAS application.

Communication range test
The distance test is performed by simulating the distance of the communication using the signal attenuator as illustrated in Figures 10 and 11. There are 3 tested distance, which are 10, 30, and 80 km (as according to the specification of the RFD900x, the maximum communication distance is 80km, demonstrated by the Edge Research labs on a balloon [17]). To select the size of the attenuator, the principle of free space lost [22] are used in the calculation to find the optimal attenuator to simulate each tested distance. The format of the message to be used for RFD900x during the test is sending MAVlink messages as usual for communication between UAV and GCS. For the LoRa, only UAV coordinates will be sent during the test. However, the LoRa device has a limit on the size of messages that can be sent up to 51 bytes [23] with a low data rate, the size of messages to be sent with LoRa should be as small as possible. So, for the effective communication, the Military Grid Reference System (MGRS) positioning method instead of The World Geodetic System (WGS) is used stead in order to make the size of the UAV coordinates smaller. The Lora communication system on both the UAV side and the GCS side must have a program to convert these positions. The parameters used to measure the test results are Received Signal Strength Indicator (RSSI) of both sides. In the test, both types of devices are placed at 200 meters away from their pair before the test begun. The test will start with enabling the communication without any attenuator and then changing the attenuator according to the simulated distance.  Figure 10. The connection between each hardware installed on the UAV with the attenuator Figure 11. The connection between each hardware installed on the GCS with the attenuator From the results of the Table 2, The RSSI of RFD900x reach 0 percent at the distance of 80 km, but LoRa keeps the RSSI in the operational range at 80 km and beyond. From the test, we can clearly see that the noise floor level in the test area (-90 to -100 dBm) has affect the communication directly, the RFD900x has lost its ability to communicate when the RSSI level is equal to or below the noise floor. The RFD900x cannot demodulate the transmitted data although its sensitivity is lower than the noise floor (-121 dBm [18]), while LoRa can demodulate the signal below the noise floor level [24] (Sensitivity @ -142 dBm) resulting in the ability to communicate over a longer distance. Hence, LoRa can be used as a supplementary module for UAS using RFD900x as a primary communication system.

LoRaWAN class verification test
Using LoRa to exchange data requires the uplink from the end device downlink from the Gateway to exchange data between devices. When data is downlink, consideration of the LoRa End-device class selection is important. Due to the timing of opening of the RX slot of End-device in each class is different. It also results in different energy consumption. Therefore, we must test the amount of energy that LoRa consume to send a message every 60 seconds for 1 hour of class A and class C. Therefore, the number of messages sent are 60 in total. The testing End-device will transmit an Uplink message then the Gateway will answer the Uplink message with acknowledge Downlink message.

Table 3. Power consumption and success rate of transmission of class A and C LoRaWAN
From the test results in Table 3, class A uses less power than class C, but there is a chance that the downlink message will not be successful because of the RX slot time mismatch problem. This is a major weakness that makes class A unsuitable for UAV missions that require high accuracy and consistency in data transmission. On the other hand, the weakness of class C is the power consumption, but in the other hand we got better communication quality. To implement Class C, we suggest optimizing the size of the battery by consider the amount of time to enable the LoRa system on the UAV.

Conclusions
This paper reports the adoption of another communication technics called LoRaWAN in a long range UAS mission where the distance can be extended with a low power consumption. The LoRa's capability of a long-range data exchange below noise floor using the Chirp Spread Spectrum (CSS) modulation appeals to the potential supplementary communication in UAS. The experimental results show that LoRaWAN can maintain the communication capability beyond 80 km where the popular RF device, RFD900x, has lost its ability to communicate at this distance. Moreover, the comparison between LoRaWAN Class C and Class A suggests that LoRaWAN Class C is more suitable for UAS application.