Keywords

1 Introduction

In recent years, flying ad-hoc networks (FANET) based on unmanned aerial vehicles (UAVs) are widely used in various fields: military, commercial, agricultural, etc. A feature of such networks is searching and rescuing of people affected by natural disasters [1]. FANET is a special kind of self-organizing network based on UAVs, which connects and communicates with each other in certain airspace through wireless channels, and has characteristics of distributed, non-central, rapid deployment, self-organization and strong self-healing. As practice has shown, the rapid deployment of such networks is very importance in eliminating the consequences and saving lives. This network is called the flying network for emergencies [2].

Flying ad-hoc networks consist of two segments: the flying segment and the terrestrial segment [12]. It is necessary for FANET to be easily deployable and self-configured ad-hoc UAVs network to connect with the emergency services on the terrestrial segment. All the UAVs must be communicated with each other and to the emergency services simultaneously without having any pre-defined fixed infrastructure [13] with the help of a multi-hop ad-hoc networks scheme. In this way, it not only delivers the aggregated data to the base station instantly but also can share data among the connected UAVs. Moreover, during the operation, if some of the UAVs are disconnected due to the objective conditions, it can still make their connectivity to the network through the other UAVs.

Also, due to the ad-hoc networking among the UAVs, it can solve the complications like short range, network failure and limited guidance which arise in a single UAV system [14]. Even though such distinctive attributes make FANETs an appropriate solution for different types of scenarios, but they also bring some challenging issues such as communications and networking of the multiple UAVs [15]. Also, it is necessary to consider the quality of services (QoS) for several priority services in a flying network. The Medium Access Control (MAC) layer, which serves as the main link layer mechanism, is an important component in a flying network. It has a direct impact on throughput system, data rate, transmission delay and must meet many strict requirements [4].

IEEE 802.11p protocol [5] is a modified version of the familiar IEEE 802.11 (Wi-Fi) standard. The use of that protocol in a flying network has been reviewed in many articles and has proven to be the most suitable for a flying network [6, 7]. It was originally developed for VANET - Vehicular ad hoc networks. IEEE 802.11p standard was adopted as Medium Access Control (MAC) and Physical Layer (PHY) specifications for the lower-layer Dedicated Short-Range Communication standard (DSRC), which has characteristics such as frequency range - 5.9 GHz (5.85–5.925 GHz), wide coverage (up to 1000 m), fast transmission rate (up to 27 Mbps), self-organization and fast convergence. It is expected that these characteristics will demonstrate excellent performance not only in vehicles on the ground but also in the interaction of unmanned aerial vehicles in the air, respectively, VANET is supposed to be moved into the air and used for UAVs.

Also, IEEE 1609.4 protocol [8] allowed adding a seven-channel MAC scheme to the MAC layer of IEEE 802.11p (Fig. 1). Each channel has a total bandwidth of 10 MHz. They include one control channel (CCH - Control Channel: 178) for managing the network and transmitting safety messages and six service channels (SCH - Service Channels: 172, 174, 176, 180, 182, 184) for other traffics. All vehicles must monitor the control channel with safety/control messages during the CCH period and will be able to switch to the service channel to exchange only non-safety applications. The channel access time is equally divided into repeating synchronization intervals of 100 ms, and each synchronization interval is divided into CCH Intervals (CCHI) of 50 ms and SCH Intervals (SCHI) of 50 ms (Fig. 2). Synchronization between vehicles is achieved by receiving the coordinated universal time (UTC) provided by the GPS equipped in each vehicle. It should be noted that although 6 SCH channels can be used, in practice channel 172 is used for accident avoidance safety of life, and channel 184 is used for high power, long-range services [11], so we only consider 4 SCH channels: 174, 176, 180, 182. The combination of IEEE 802.11p and IEEE1609.x is called wireless access in vehicular environments (WAVE) standard [9].

Fig. 1.
figure 1

Multiple channel IEEE 1609.4 protocol.

Full size image
Fig. 2.
figure 2

Division of time into CCH intervals and SCH intervals.

Full size image

IEEE 802.11p protocol uses the Enhanced Distributed Channel Access (EDCA) mechanism [10], which uses Carrier Sense Multiple Access with Carrier Sense and Conflict Prevention (CSMA/CA) to support various types of applications with quality of services. The EDCA mechanism allows messages, which have a higher priority to have a better chance of being transmitted than messages with a lower priority. There are four types of access categories: background traffic (AC0), traffic from the best attempt (AC1), video traffic (AC2) and voice traffic (AC3). Prioritization is achieved by varying the EDCA parameter set, including Contention Windows (CWs) and the Arbitration Inter-Frame Spaces (AIFS), which increase the probability of successful medium access for real-time messages.

In this paper, we propose a new MAC protocol based on IEEE 802.11p and IEEE 1609.4 protocols to perform communications between UAVs as well as between groups of UAVs. UAVs will be divided into different groups called clusters to move in rescue areas and perform missions. The proposed protocol includes three different protocols: cluster management protocol (CMP), intra-cluster communication protocol (IntraCP) and inter-cluster (InterCP) communication protocol. These protocols use different modified WAVE Service Advertisement (WSA) and WAVE Short Message (WSM) packets [16] to update information, transmit data within and between clusters.

The rest of this paper is organized as follows: Sect. 2 briefly presents the related works. In Sect. 3, we present the assumptions and problem statement. Section 4 describes the proposed protocol CMMpP. Section 5 finally concludes this paper and future works.

2 Related Works

The research of methods of transmission data in flying networks has been devoted to many research works. In the paper [17] the authors discussed using IEEE 802.11n and IEEE 802.15.4 for transmitting data in the flying network with a different number of UAVs in star and mesh topologies. The result showed that star network topology is affected by high UAV density and speed, which impact negatively in the packet delivery rate and the end-to-end delay and using mesh topology with IEEE 802.11n are safer than using star topology with the same protocol. Although the performance of IEEE 802.15.4 was not as better as IEEE 802.11n in a mesh topology.

The authors in [18] address the experimental evaluation of such high throughput enabling technologies, such as IEEE 802.11n and IEEE 802.11ac in real-world scenarios, using outdoor experiments in a UAV setting with only two UAVs.

In the paper [19] multi-UAV-aided vehicular network is presented, two UAVs are deployed to cooperate with three ground vehicles, UAV acts as a guide for vehicle. These UAVs can communicate with each other through WiFi (IEEE 802.11a) and ZigBee modules, where the WiFi module is for the image transmission and the ZigBee module is for command message delivery. The results showed the performance of delay and throughput of the air-to-air link is better than the air to ground link, but it is also evaluated in terms of average latency and throughput; a relatively large latency can be observed when video data are transmitted. IEEE 802.11s also used in [20] but the results are limited to single-hop and two-hop mesh networks.

In addition, there are many studies focused on creating MAC protocols for VANET [21,22,23]. All these ideas can be considered to apply for FANET communication.

3 Assumptions and Problem Statement

As mentioned above, UAVs are more widely used to serve special civilian purposes in searching and rescuing when people are lost in the forest, victims in natural disasters such as earthquakes, forest fires, tsunamis et al. The common point of these problems is the lack of telecommunication infrastructure or the complete or partial destruction of telecommunication infrastructure. Therefore, communication between rescue workers or with the victims is almost impossible. To overcome this problem, we propose a solution to use UASs (unmanned aerial systems), which includes one or more mobile base stations (MBS) and mission-oriented UAVs, which can be considered as a mobile heterogeneous gateway [2]. Thanks to the mobility of UAVs, we can create a communication network – Flying Network for Emergencies to support quickly and ensure strict conditions of the time in searching and rescuing [3].

One of the reasons for creating a network of UAVs is the coverage area is usually not large when using a high data rate. Look at Fig. 3 we can calculate the maximum distance between two UAVs related to the data rate as follow:

Fig. 3.
figure 3

The distance between two UAVs related to the data rates.

Full size image

It is assumed that the antennas are aligned along with the polarization, and both antennas have unity gain [25].

$$\begin{aligned} a(r)=\frac{P_r}{P_t}={G_t}\cdot {G_r}\cdot (\frac{\lambda }{4\cdot {\pi }\cdot {r}}) \end{aligned}$$
(1)

Where,

  • A(r) - Damping according to the Friis formula in distance r,

  • \(G_t\) - Transmit antenna gain, when the omnidirectional transmission \(G_t = 1\),

  • \(G_r\) - Receiver antenna gain, when the omnidirectional transmission \(G_r = 1\),

  • \(P_t\) - Transmitting antenna power (without losses) (W),

  • \(P_t\) - Receiving antenna power (without losses) (W),

  • r - Distance between antennas in meters.

  • \(\lambda = \frac{c}{f}\) (m) - Wavelength in meters corresponding to the transmission frequency.

  • \(A(r)=10\cdot {\lg (a(r))}\) - Damping according to the Friis formula in distance r in logarithm form.

  • \(P_{tx}=10\cdot {\lg \frac{P_t}{10^{-3}}} = 28.8\) (dBm) - Transmitting antenna power level [26].

  • \(P_{rx}=10\cdot {\lg \frac{P_r}{10^{-3}}}\) (dBm) - Receiving antenna power level.

  • \(P_n = -90\) (dBm) - Noise power over 10 MHz.

  • \(P_{rx} = P_{tx} - P_n\)

From these formulas, we have Table 1

Table 1. Relation between maximum distance and data rate.
Full size table

We can see that if the data rate is 12 Mbps, the distance between the two UAVs is only 445 m. Thus, the coverage area is not large. That is the reason why we should create a network of UAVs (Fig. 4).

Fig. 4.
figure 4

Network of UAVs for emergencies.

Full size image

It should be recalled that, in the proposed mission-oriented flying network, the UAVs move with specific purposes and are subject to geographical restriction. In a mission-oriented FANET environment, UAVs cooperatively communicate with each other to receive information on mission assignment from the base station or forward the collected data to the base station [24].

In particular, MBSs will deploy UAVs groups to areas around MBS to gather information, which will be disseminated between groups and transmitted to the base station. Not only that, but the UAVs groups also act as the intermediaries to make connections and transfer data between the base stations together to create a timely, efficient and effective rescue system and increase the coverage area of the flying networks.

In addition, in searching and rescuing, it is very necessary to have communicate among rescuers or between rescuers with victims or between victims with their relatives. In order to support these requirements when the telecommunications infrastructure is destroyed, we propose an architecture that uses the flying network for emergency over satellite systems. Satellite systems covering the entire earth can connect to almost every point on earth. Satellite user terminals are mobile devices that help quickly connect to satellites. In order to connect to the victim’s devices as well as transfer data to MBS or to satellites, on UAVs equipped: Satellite user terminal, IEEE 802.11p module, IEEE 802.11n/ac module. In this architecture, voice traffic can be transmitted from subscriber over UAVs via VoWiFi to the MBS (or to UAV, which can connect to satellite) and over satellite systems to telecom operator (Fig. 5).

Fig. 5.
figure 5

An architecture for flying ad-hoc network for emergency.

Full size image

In this paper, we focus on creating relevant communication protocols, which are cluster management protocol (CMP), intra-cluster communication protocol (IntraCP) and inter-cluster communication protocol (InterCP) for only one MBS in the flying network (Fig. 6). We call the combination of those protocols as Cluster-based Multichannel MAC IEEE 802.11p protocol (CMMpP). It should be noted that, in this paper, we call a group of UAVs as cluster and UAV as node alternatively.

Fig. 6.
figure 6

Groups of mission-oriented UAVs around a MBS.

Full size image

In order not to complicate the problem, we have some assumptions as follows:

  • The nodes will be divided into different clusters at the beginning of the mission, and each cluster will have different flight directions to gather information as well as increase the coverage of the network. Each node in the cluster also has its flight speed and flight direction, but this difference is within the allowable limit to ensure cluster stability. Also, during the task implementation, there will be no node left the cluster or join the cluster.

  • All UAVs is equipped with a GPS device to define the location, and time popularity coordinates of UAV is small enough so that calculation errors can be ignored.

  • We use two transceivers on each UAV to support multichannel transmission at the same time. Because negative affects of channel switching on spectrum efficiency and performance of safety applications do not make the single-radio approach a good candidate for multi-channel MAC architectures [23]. This is acceptable and has been proposed in several other studies [27, 28].

The problem statement is as follows:

First, the MBSs will move to the rescue area. There they will deploy groups of mission-oriented UAVs (clusters) to collect information, make connections and exchange data. These clusters will use Cluster Management Protocol (CMP) to elect their cluster head (CH) node. This CH node may change during the execution of the task depending on the location, speed of the nodes in the cluster. The CH node is responsible for collecting information from the cluster members (CM) and then transferring it to the base station or passing it to CHs of other clusters. The CH node also acts as intermediate for data transmission, scheduling, channel assignment through message controls.

Nodes will use IntraCP and InterCP to transmit data. These protocols employ multichannel MAC protocol IEEE 1609.4 standard and IEEE 802.11p protocol in combination with TDMA to conduct every communication. In particular, IntraCP protocol performs the following main tasks:

  • Collecting/Delivering control messages from/to CM on CCH channel.

  • Allocating the available SCH channels to CM for data traffic.

  • Contending to transmit data on the SCH in the cluster.

Meanwhile, the InterCP protocol is responsible for making communications between different clusters (transmitting both control messages on the CCH channel and data traffic on the SCH channel).

4 Proposed Work

4.1 Cluster Management Protocol (CMP)

The CMP protocol is responsible for maintaining and electing the cluster head for the current cluster. In the beginning, a node in the center of the cluster will be selected as the CH. This ensures that nodes from the beginning can exchange information with each other.

The decision which one stays CH is based on a total weighted factor F, which takes into account different metrics. These metrics involve the mobility information of each node, including the speed of a node (V) and the distance to the neighbors (D). A node identifies its neighbors by sharing this mobility information through control messages by using IntraCP protocol (in the next subsection).

The speed weight of the \(i^{th}\) node can be expressed as:

$$\begin{aligned} f_v(i)=\frac{1}{|V_i - V_{avg}|} \end{aligned}$$
(2)

where:

$$\begin{aligned} V_{avg} = \frac{V_1 + V_2 + V_3 + ... + V_n}{n} \end{aligned}$$
(3)

n is the number of neighbours, \(V_i\) is the speed of \(i^{th}\) node.

The denominator of Eq. (2) represents the average difference of speed between one node and all its cluster members. The idea here is that a node with similar velocity to most nodes in its neighborhood will cause less change in the cluster membership than a node, which is much faster or slower than the rest.

Next, we calculate the central position by:

$$\begin{aligned} D_{avg} = \frac{1}{n}\cdot (\sum _{i=1}^n x_i, \sum _{i=1}^n y_i, \sum _{i=1}^n z_i) \end{aligned}$$
(4)

where:

\((x_i, y_i, z_i)\) is the coordinate of the \(i^{th}\) node and we can express the distance weight of the \(i^{th}\) node as:

$$\begin{aligned} f_d{(i)} = \frac{1}{\sqrt{(x_i - D_{avg})^2 + (y_i - D_{avg})^2 + (z_i - D_{avg})^2}} \end{aligned}$$
(5)

Equation (5) represents the average distance between all neighbors and itself. It means how close the neighbors to one node are. Here also a great value is preferable, as it can be expected that nodes, which are placed closer together, will stay longer in each other transmission range.

Combining these measures, the total weight factor F is obtained, which shows the suitability of a node to become CH. The greater F is, the better it is qualified to be CH. The factors \(w_v\), \(w_d\) can be chosen between 0 and 1 according to the different scenarios. Their sum has to result in 1.

$$\begin{aligned} F = w_v \cdot f_v{(i)} + w_d \cdot f_d(i) \end{aligned}$$
(6)

4.2 Sharing Information

For the protocols to take place, each node will periodically update the information about the location of the node, speed of node in the cluster, ClusterID, SCH channel requests (if there is data to send) and Priority of service (with EDCA parameter sets) to all members in its cluster through control messages. Where,

  • Location is defined by the GPS system.

  • ClusterID is the identification of the cluster.

  • SCH channel request is information, which informs that this node needs to be assigned a SCH channel to transmit data. It also specifies whether it needs SCH channel for intra-cluster or inter-cluster communication.

  • Priority indicates the type of traffic transmitted in the SCH channel in the next interval. In this paper, we use four levels of priority, as shown in Table 2 [29].

Table 2. Delay parameter requirements for each type of traffic.
Full size table

4.3 Cluster-Based Multichannel MAC IEEE 802.11p Protocol (CMMpP)

Since both the IntraCP and InterCP protocols support each other as well as can happen at the same time, we will not present each protocol separately but combine it as CMMpP protocol.

In our proposed CMMpP protocol, each node is equipped with two transceivers, which are denoted by Trans1 and Trans2, respectively, which can operate simultaneously on different channels. Trans1 is always tuned on the CCH to monitor and perform transmission of control messages on the CCH channel while Trans2 is tuned to any SCH (channels 174, 176, 180, 182) to perform data transmission. Therefore, instead of using CCH intervals (CCHI) and SCH intervals (SCHI) with 50 ms duration for each one, we can use the whole synchronization interval 100 ms (Fig. 2). In addition to using CCH Channel 178 for control messages, we propose to use SCH channel 182 exclusively for the inter-cluster transmission of data. Thus, the SCH channels 174, 176, 180 will be used to assign to CMs for the intra-cluster transmission of data.

Operation of Trans1. First, CH will send a beacon message (B) packet to notify about starting Synchronization Interval (SI) on CCH channel to all members CMs of the cluster. After receiving the notification, the CMs will reply to update all information of nodes using UDI packets in Information Update Period. The information in this UDI packet will be used to redefine CH for the next synchronization interval if necessary and update the requests for using the SCH channels of CMs. Based on CH channel requests, CH will create schedules for CM intra- and inter- transmissions in the next SI interval. Next, in the Assignment Period, CH broadcasts a packet to announce schedule of transmissions (ST packets) to the CMs. The ST packet indicates which node will use which SCH channel to transmit data in the cluster or between different clusters. In addition, ST also shows information of the CH node for the next interval. To increase reliability and ensure CMs receive ST packets, CH will send ST packets two times. All these processes occur with TDMA mechanism on CCH channel under IntraCP protocol. Figure 7 shows the operation of CMMpP protocol.

Fig. 7.
figure 7

Operation of CMMpP protocol including IntraCP and InterCP protocols on CCH channel.

Full size image

The principle of assigning SCH channels for CMs is as follows: CH receives the SCH channel request information from CM. CH then searches for a rarely used (to reduce interference) SCH channel in the list of available SCH channels in accordance with the purpose of intra-cluster or inter-cluster communication. Then SCH channel will be assigned to CM through ST packet. After ending the intra-cluster communication period, the CH performs inter-cluster communication using the contention-based CSMA/CA mechanism in IEEE 802.11p to compete with the CHs of other clusters. When the environment is idle, it will broadcast the inter-cluster communication packet IUDI to disseminate all information of the cluster, list of active nodes and assigned SCH channels to other CHs (Fig. 7).

Operation of Trans2. At the same time, with the processes on the CCH channel, nodes also transmit data on SCH channels. On SCH channels, nodes including CH compete for data transmission via CSMA/CA mechanism in EDCA of IEEE 802.11p all the time. It means those nodes that participate in data transmission but have the same assigned SCH channel will compete based on updated priority information and respective EDCA parameter sets. We use priority by assigning different EDCA parameters to make sure that traffic tolerated to delay is transmitted before other traffics (see Table 2). It should be noted that transmissions taking place in the cluster (IntraCP) can use only SCH channels 174, 176, 180. Meanwhile, inter-cluster communication (InterCP) will take place on SCH channel 182. These operations occur on non-overlapped channels, so they do not affect each other.

We modify the WAVE Service Advertisement (WSA) packet format [16] by using optional fields to create a UDI packet. Figure 8 shows the format of the UDI packet.

Fig. 8.
figure 8

UDI packet format.

Full size image

Wave Version field defines the format of this WSA. The version number associated with the current standard is 1.

Additional Information field includes:

  • Location and Speed subfields indicate the location and speed of node in the cluster.

  • ClusterID subfield identifies the cluster.

Service field includes Priority subfield and EDCA Parameter set subfield. Priority indicates the priority of traffic that the current node needs to send, as shown in Table 2. EDCA Parameter set indicates the predefined EDCA parameters according to the priority. There are some studies that focus on this parameter to support the quality of service in a contention-based mechanism [30,31,32]. SCH Channel Request field includes two subfields to notify the CH about transmission demand on SCH channel in next interval.

  • Channel Access subfield is used to indicate that this node needs a SCH channel assignment or not. In particular, if the last bit is 1, it demands CH to assign the SCH channel; if the last bit is 0, it does not need a SCH channel in the next interval.

  • Type of Communication subfield indicates intra-cluster communication (the last bit is 1) or the inter-cluster communication (the last bit is 0). CH node uses this information to assign accordingly.

For ST packet format, we modify the WAVE Short Message (WSM) packet format [16] as shown in Fig. 9.

Fig. 9.
figure 9

ST packet format.

Full size image

Version, PSID (Provider Service IDentifier), WSM WAVE Element ID, Length and WSM Data (Payload) are required fields of WSM packet. We add the SCH channel assignment field to indicate the list of assigned SCH channels to CMs.

Next CH field is used to inform about new CH node in the next SI interval.

In this paper, we propose to use broadcast packets IUDI to inform the CHs of other clusters about the information of its cluster (Fig. 10). This packet is similar to the ST packet, and we add some of the following fields.

Fig. 10.
figure 10

IUDI packet format.

Full size image

Version, PSID, WSM Wave Element ID, Length, WSM Data (payload) fields are required fields by the standard.

Active nodes field indicates the list of active nodes, which have data to transmit on the SCH channels.

Service field is similar to the Service field in UDI packet format.

5 Conclusion

In this paper, we proposed an architecture that supports the communication among rescuers or between rescuers with victims or between victims with their relatives by using the flying network for an emergency over satellite systems. In particular, a MAC protocol based on IEEE 802.11p and IEEE 1609.4 protocols called CMMpP to support communication in flying ad-hoc network for emergency was developed. CMMpP protocol includes three components: Cluster Management Protocol, Intra-Cluster Communication Protocol and Inter-Cluster Communication Protocol. They use TDMA and CSMA/CA mechanisms to transmit control messages on the CCH channel and different kinds of traffics on SCH channels. We modify the WVA and WSM packets format and add some fields/subfields to those packets format to support the new protocol.

In the future, we will perform evaluations of the proposed protocol using simulation to consider its advantages and disadvantages. At the same time, we will focus on solving the problem of ensuring QoS for FANET for emergency network.