Keywords

1 Introduction

With the advent of 5G, networks are expected to include an un-precedented functionality: fast deployment. Indeed, 5G requirements include the possibility of deploying a functional next-generation wireless networks in less than 90 min, where for LTE this would have required days. Such requirement would require the usage of a software-based and configurable network architecture as well as the availability of proper network nodes capable of moving in the territory. The 5G Service Based Architecture defined in 2019 provides an important step forward on the softwarization of the telco infrastructure by enabling the deployment and orchestration of Virtual Network Functions on the network infrastructure. On the other hand, Unmanned Aerial Vehicles have recently gained the attention of the communication community as a potential technology to deploy movable and agile network nodes for fast deployment of network nodes.

NATO SPS G5428 DAVOSS project focuses on merging those two concepts (5G SBA and UAVs) to build a communication and service architecture capable of providing coverage for monitoring, border security and safety applications. Indeed, DAVOSS project aims to develop a multi-layer virtualised system in which all the technologies listed above work together to guarantee efficient and effective borders and ports surveillance. Figure 26.1 depicts the proposed network and architecture. The proposal identifies four main system layers: the one constituted by sensors (Layer 1), the one composed by UAVs (Layer 2), the one deploying virtualisation (Layer 3) and the one including micro satellites (Layer 4).

Fig. 26.1
figure 1

Structure of the proposed system to guarantee efficient and effective border control and security against terrorist threats. There are four layers. The virtual layer dynamically assigns virtual network functions (VNFs)

Full size image

The project is approaching the end of the research activities, leading to the selection of the technologies to actually deploy and test in the project testbed. Agreements are being prepared in order to run experiments at the Trento Firemen (Vigili del Fuoco) training facilities for providing a suitable framework for testing DAVOSS results.

Next sections of the paper introduce the main research activities in the different layers of the DAVOSS project architecture.

2 Layer 1 – UAVs and Sensors

Layer 1 of the DAVOSS project consists of a sensor network with a drone-based mobile gateway. Basically, the drone flies above the sensors and communicates directly with each of them to collect their data. Therefore, designing an appropriate path is important for several reasons. First, such a path allows to reduce the energy consumption of the drone, which is translated to increasing the area it can cover and minimizing the time needed for collecting urgent information. Second, an efficient path allows the drone to hover very close to each sensor, which is translated to increasing the wireless throughput of each sensor and of the whole network.

The project is testing path planning algorithms using the following hardware components:

  • Drone: RE470 Quadcopter equipped with Pixhawk PIX PX4 2.4.8 Flight Controller and GPS.

  • LoRaWAN Gateway: Raspberry Pi-3 with RAK-831 Multi-channel LoRaWAN Gateway that uses Semtech sx1272 LoRa RF transceiver.

  • LoRaWAN Sensors: The sensors combines STM Nucleo L073RZ base board with Semtech sx1272 LoRa RF transceiver.

The algorithm consists of three stages. The first stage is initial sensors data collection. In this stage, the drone is configured with the GPS coordinates (waypoints) of each sensor, using the mission planner tool. The drone is then dispatched using the “Auto” flight mode to collect the data from each LoRaWAN sensor. In this mode, the drone simply flies from one waypoint to another. In the second stage, after the drone returns from its mission, its LoRaWAN gateway is connected to a LoRa server in order to extract the collected sensors data, as well as the metadata related to the communication with each sensor. In the third stage of the project, our Path Planning algorithm receives the metadata related to each sensor and computes an optimized path for the next drone flight.

The proposed algorithm consists of two parts. In the first part, the algorithm calculates the waypoints that should be traversed. These points are referred to as key waypoints. To this end, the algorithm takes into consideration the obstacles, as shown in the example in Fig. 26.2. After determining the key waypoints, the Path Planning algorithm determines the exact path that traverses all the key waypoints, while minimizing the length of the route and not entering the obstacle boxes (Fig. 26.3).

Fig. 26.2
figure 2

Path planning example in presence of an obstacle

Full size image
Fig. 26.3
figure 3

Path planning example (without obstacles)

Full size image

3 Layer 2 – UAV Networking

Layer 2 of DAVOSS architecture consists of drones which can communicate either among each other or through ultra-light vehicles and balloons, which is used for backhauling. The drones have mechanical parts, which are responsible for flight operations and a battery for power supply of carried equipment. Furthermore, the unmanned aerial vehicles (UAVs) of our system are considered as mobile base stations (BSs) thus they carry radio equipment (supporting LTE/4G standard communications to the ground peripherals) and hardware for baseband processing, called baseband unit (BBU).

Several configurations of the interconnections among UAVs and other platforms (aerial or terrestrial) are being studied using ns-3 network simulator (see Fig. 26.4).

Fig. 26.4
figure 4

Communication performance for different UAVs network configurations: ad-hoc, centralized, multi-layer and multi-group

Full size image

4 Layer 3 - Virtualization

The idea behind DAVOSS’ design of Layer 3 is the virtualization of most of the network operations in order to avoid loading the battery of the drone and the drone itself. That becomes fundamental to increase drones’ battery life and capabilities. A preliminary analysis of this aspect was presented in [1]. This represents a novel study in the research panorama because it seems the first work considering BBU impact on mobile BSs.

The mobile BSs collect data from the peripherals and transmit them to Layer 2. Without loss of generality, we considered the drones hovering and active (i.e. transmitting/receiving data from peripherals). For a correct theoretical analysis, we decided to use stochastic geometry, which represents the current most reliable mathematical model for radio access network of existing 4G cellular networks. As DAVOSS objective is to provide connectivity in complex scenarios and borders (areas without any existing reliable network infrastructure), we can reasonably consider mobile BSs and terrestrial peripherals (belonging to Layer 1) distributed according to two-dimensional homogeneous Poisson point processes (PPPs) respectively called Φbs and Φs, with intensity λ bs and λ m.

A UAV is normally a multirotor helicopter, which should carry either a remote radio head (RRH) and a BBU or only an RRH. As just mentioned, the flight time t fl and the operational time t op of a mobile BS is limited by its weight, its battery’s capacity and its transmission power.

The total average power p tot, consumed by a mobile BS, is composed by the average power consumed during takeoff (p to), flight (p fl), hovering (p ho) and landing (p la). Next, the average power consumption of a UAV-based BS includes the average transmission p tr and processing power p pr. In general, it has been demonstrated that the average power consumed during hover can represent an upper bound on the average power during flight [2]. Next, the average power consumed during takeoff and landing is approximately equivalent to the power consumed hovering. Then, an upper bound on total average power, consumed by a mobile BS, can be expressed as

$$ {p}_{tot}=4{p}_{ho}+{p}_{tr}+{p}_{pr} $$

Mobile BSs were assumed to be comparable to pico-BSs in terms of power consumption and coverage [3]. So, reasonable values of power consumption can be considered 1.9 W for power amplifier, 1 W for radio frequency hardware and 3 W for BBU. In the analysis we considered the general virtualization of all BBU operations thus, the deployment of all BBU on the pico-satellites (CubeSats). In this way, we obtained a sort of lower bound in terms of power consumption, which can give an upper bound on how much power we can save at the drones via virtualization. That is because this calculation still neglected the differentiation of power consumption for the various schemes of BBU’s sub-function virtualization. Moreover, it did not considered the power consumption required by hardware for backhaul/fronthaul transmissions, which permit the communications between drones and satellites. Figure 26.5 depicts the upper bound on the power gain according to the weight of the drone.

Fig. 26.5
figure 5

Power gain at the mobile BSs (drones) when BBU is virtualized. Obviously, by increasing the load of the drone, the impact of the weight of the BBU decreases

Full size image

5 Layer 4 – Aerial Backhaul (Microsatellites, Blimps)

5.1 CUBESAT Link Requirements

The virtualization of BBU network function imposes some requirements in terms of capacity to the link connecting the two network nodes involved in the RRH-BBU splitting operations, in our case the LTE RRH installed on board of the UAV and the BBU mounted on the cubesat rack. Such requirements depend on the splitting configurations, shown in Fig. 26.6.

Fig. 26.6
figure 6

Basic requirements of different RRH-BBU splitting configurations

Full size image

The baseline splitting configuration considered in DAVOSS is the Split D of Fig. 26.7, where L2H and L3 are relocated to the cubesat BBU unit, leaving to the RRH the functions mostly related to PHY-layer management (RF, L1L, L1H, L2H). The link requirements for the baseline configuration are given as follows:

  • link capacity ≥180 Mb/s (achieved with a quasi-zero bit-error-rate,

  • say: ≤10−12);

  • link delay not exceeding 4 ms.

Fig. 26.7
figure 7

Two possible Cloud RAN slicing configurations

Full size image

The aforesaid target value of capacity looks quite ambitious for small cubesats operating in the usual L and S bands, while the delay may be affordable. In the following, we shall analyze the transmission techniques and the cubesat equipment that would allow to reach the expected performance.

5.2 CUBESAT-Based RRH-BBU Connection Setup

In Fig. 26.8, the architecture of the virtualized monitoring system exploiting cubesats is depicted. A broadband sensor (e.g. a 3D scanner) transmits data from the border area to the drone upon the LTE standard. The data are turbo-encoded by the LTE UE and transmitted to the drone. The RRH mounted on the drone perform the demodulation of the encoded data and forward them to the BBU installed on cubesat. The BBU performs in real-time the turbo decoding and dispatches the decoded data to the remote control center in downlink at a convenient rate.

Fig. 26.8
figure 8

Architecture of the virtualized border monitoring system exploiting the cubesats

Full size image

The L2 management considers a HARQ mechanism relying on FEC turbo coding only, without any ACK/NACK mechanism. Such a choice has been motivated in order to avoid throughput starvation due to ACK/NACK looping. Such an issue is not critical in terrestrial links, but it may become serious in case of information forwarding through satellite links, whose latency is higher.

We target the implementation of the cubesat transceiver for CRAN splitting, according to the CPRI standard [4]. CPRI is designed for fiber connections, but we can adapt the specifications to the cubesat connection. The channel coding used by CPRI is Reed-Solomon (RS) codes. The RRH-BBU satellite transceiver should be implemented with commercial components.

The mathematical expression linking the sampling rate of the analog front-end AFE to the net bit-rate achievable by the transmitter is the following:

$$ {R}_b=\frac{S_R}{f_{ov}}\gamma $$
(26.1)

where SR is the AFE sampling rate expressed in Msamples/sec, f ov is the oversampling factor, expressed in samples/symbol, and γ is the number of information bits carried by each symbol. In [5], the MAX19713 component, commercialized by Maxim Integrated (San Jose, CA) is used for the implementation of a 60 Mb/s cubesat transceiver. The MAX19713 AFE is capable of supporting a sampling rate of 45 MS/s with 12 bits ADC and DAC converters [6]. In order to support the minimum required data rate of 180 Mb/s, imposing an oversampling rate of 3 samples/symbol – that is needed to guarantee the correct working of ADC and DAC [5] – the parameter γ should assume values higher than 12 bit/symbol. Clearly, it is better to consider other AFE components, characterized by higher sample rate. Having a look to the Texas Instruments’ shelf, we can find the AFE5816 product, originally designed for ultrasound systems and high-speed data acquisition systems [7], that is capable of supporting up to 80 MS/sec with 12 bit ADC and DAC. Fixing again fov = 3, the value of γ decreases to 6.75 bit/symbol that is still quite high, but much more affordable from the viewpoint of the link budget parameterization.

Thanks to the analytical evaluation of BER at the output of RS decoding shown in [6], the link budget should provide a link BER < 10−12, in the worst case of longest BBU-RRH distance. Such values will be confirmed by the simulations, described in details in the next section.

5.3 Preliminary Results

Two SIMULINK-based simulators have been employed in order to simulate the cubesat orbits and the cubestat link, respectively. Some relevant results are presented in the following figures, where Fig. 26.9 shows the allowed number of turbo iteration allowed by using the Split D architecture, while Fig. 26.10 represent the corresponding BER.

Fig. 26.9
figure 9

Number of turbo decoding iterations number allowed in case of Split D of virtual BBU

Full size image
Fig. 26.10
figure 10

Raw BER performance (blue curve and left axis) and BER after RS decoding (analytical lower bound – orange curve and right axis) vs. cubesat flight time in the worst case of 350 Km altitude and k 0 = 1

Full size image

6 Conclusions

This paper presented the ongoing activities to design a flexible border monitoring architecture based on the usage of aerial platforms (UAVs, blimps, cubesats), developed in the framework of the NATO SPS G5428 DAVOSS project. Future activities will be focused on implementing and measuring the actual performance of the architecture on a real scenario.