XGain Technical Notes | 5G measurement campaign to enable a drone centre
Writers: August Betzler , Joan Josep Aleixendri Cruelles , Adrian Pino
Organisation: i2CAT
Keywords: Rural Connectivity, Edge Computing, Drones, 5G, XGain Project
Among the 6 use cases (UCs) validated in the XGain project [1] that aims to find solutions to close the digital gap between cities and rural areas, the Catalan UC explores how a drone operations centre could impact the community in a variety of ways, e.g. economically and socially. Exploring the potential of said drone centre, a place where farmers and other rural stakeholders can come to learn about drone piloting and drone regulations, practice drone flying and test drones to implement new services, such as remote surveillance or monitoring of crops or livestock, is done via a pilot. The 5G Coebre Lab, with its wide space within a warehouse of approximately 65mx30m and with an approximate height of 9m, serves as pilot site for the project. It features also adjacent laboratory and meeting rooms. The wide space within the warehouse is where the validations with real drones will be performed, along with a demonstration of an exemplary drone service. This article describes how the challenge of preparing the pilot was tackled and how a measurement campaign was implemented to validate the chosen technologies and spaces.
Technology selection process
During the project lifetime, one objective is to deploy an information and communications technology (ICT) infrastructure that would allow to provide the necessary state-of-the-art communications and processing technologies to allow for any type of drone service to be tested in the drone centre. To achieve this, a series of steps had to be followed:
After comparing a variety of commonly used radio access and computing technologies, the use case leaders (i2CAT) decided to deploy a private 5G network to enable drone-to-infrastructure communications. Performance tests showed that compared to other solutions like Wi-Fi or 4G networks, a 5G private network has the best tradeoff between performance and coverage, while also enabling edge computing capacities, which is crucial for any low latency services users might want to test. This article focuses on the evaluation of the 5G network connection, given it is imperative for the private 5G network to be able to provide sufficient coverage and performance to implement drone services.
The next step was to select the right 5G hardware to cover the entire warehouse and potentially adjacent laboratories, to provide additional high-data rate services. Considering the limited indoor space that needs to be covered, a 5G small cell should be able to provide sufficient connectivity. The small form factor and energy efficiency of small cells, combined with the fact that nowadays “all-in-one” standalone solutions exist that combine the radio unit and the baseband unit, the decision was made to use this type of base station for the warehouse. To enable the private 5G network, also a dedicated compute node was used to host the 5G Core, behind which the edge services can be hosted on another dedicated compute node. Further, it can be assumed that the drone needs to either capture videos or any other types of sensorial data, which can be done by the drone itself (as a commercial product) or it needs to be implemented apart. To enable some capacity to create or process data on the drone, an extreme edge device is considered too. Considering this combination of technologies, the following devices were chosen for the pilot site:
Cablefree Emerald Indoor cell?
Comss365 5G/LTE CPE?for 5G connection from the drone
This combination of hardware allows to implement a generic type of drone service depicted in Figure 1.
The diagram features a drone equipped with an extreme edge device and a 5G modem or CPE that enables 5G connectivity with the small cell. The small cell then connects to the compute node(s) where the 5G Core and services run. In this case, we assume as applications a video streaming app and an object detection app, but it could be any other type of service that communicates with the drone.
Technology validation process
This setup, with the aforementioned combination of hardware, was validated in the i2CAT labs in Barcelona. The validation's purpose was to find the right settings for the small cell and confirm that the capacity of the 5G connection and the edge processing devices is sufficient to serve the generic drone service described above. The tests indeed confirmed that the technologies and hardware chosen can satisfy the requirements, which basically where to transmit a 4k video from the extreme edge device to the edge over the 5G connection in real time and, in addition, to be able to transmit a full HD video from the drone to the edge and to run an object detection algorithm in the edge on top of the streamed video. The validations proved that the technologies could perform well enough in a controlled lab environment. Knowing that the technologies and the specific hardware can implement the drone service, an important next step towards the pilot preparation had to be taken: measuring if the 5G connectivity would be sufficient to cover the whole warehouse and provide constant performance independent from the position of the extreme edge/drone within the warehouse. This led to the preparation of a measurement campaign for the pilot environment.
Pilot-site Performance Measurements
The warehouse indoor space is shown in Figure 2. The large space visible is where drones can fly, approximately measuring 29m x 65m. A protective net separates this “open” space from the rest of the building’s areas, to avoid potential drone accidents. The validations are carried out in the wide space with the main objective to validate whether the private 5G network can provide the necessary coverage and performance across the entire space.
领英推荐
To measure the coverage and performance the following hardware and tools are used:
For the measurements, two types of a continuous stream of data are sent from the extreme edge over the 5G to the application server at the edge: synthetic data (iperf) and a real video stream. Since static setup experiments were already performed in the Barcelona i2CAT lab, in this iteration the extreme edge device is moved with the help of a mobile platform, stopping at the points marked in Figure 3 (A-F), starting at A and ending at F. While the performance in terms of throughput and latency of the data stream is recorded (throughput), the coverage measurement device is placed next to the extreme edge node on the mobile platform to keep track of the connection quality.
20 tests streams (synthetic) of 2 minutes are generated to measure performance at locations A through E, generating 1200 data points. Based on these results (presented below), the locations A, C, and E are used to do video test streaming, as the other points yield very similar performance results (C ~B, D~E).
Measurement Results
This section presents the outcomes of the measurement campaign, focusing first on the synthetic tests with ping and iperf for delay and throughput measurements and concluding with the video streaming results.
Delay Results
The Round-Trip Time (RTT) measurements across all three points of interest showed remarkably consistent results, with average RTT values ranging from 27.19 ms to 28.30 ms and standard deviations around 6.1 ms. Despite varying distances from the 5G cell, the latency remained low and within expected ranges for a 5G network, even at the furthest point. Overall, the distance had minimal impact on RTT performance.
Downlink Throughput Results
The throughput measurements across the three points of interest showed generally high performance, with some differences in stability and fluctuation between protocols and locations. At Point of Interest A, the closest to the 5G cell, UDP throughput was stable at 120-121 Mbit/s, while TCP had an average of 116.5 Mbit/s, fluctuating between 95 and 139 Mbit/s. Point of Interest C, located centrally, saw both UDP and TCP achieve a slightly higher average of 117.5 Mbit/s, though TCP again showed more fluctuations than UDP. At Point of Interest E, despite being the furthest away, UDP throughput exceeded 120 Mbit/s at times, with an average of 121.5 Mbit/s, while TCP averaged 111.5 Mbit/s, showing a slight drop in performance with distance. Overall, the throughput remained strong across all points, with fluctuations more pronounced for TCP and no significant degradation for UDP even at greater distances.
Uplink Throughput results
The uplink throughput results across the three points of interest revealed some differences in performance stability, especially at the furthest location. At Point of Interest A, while there were two instances where both TCP and UDP dropped to 25 Mbit/s, the overall throughput remained strong, with averages of 64.15 Mbit/s for TCP and 53.5 Mbit/s for UDP. In Point of Interest C, the performance was consistent with location A, with no significant drops and averages of 61.65 Mbit/s for TCP and 50.95 Mbit/s for UDP. At Point of Interest E, however, the performance was less stable, particularly for UDP, which struggled more than TCP. The TCP average was still relatively high at 51.2 Mbit/s, though the increased distance appeared to affect the modem's ability to maintain consistent communications.
Video Streaming results
We observe the reliability, or percentage of delivered frames, when transmitting the video stream from the positions A, C , and E from the end device (Raspberry Pi) to the video server (running on the NUC, as 5G edge computing node). During these tests, we can observe that close to the 5G small cell, i.e. when the drone would be flying within approximately 10-20 m of distance, there is a 0.999% frame delivery rate, resulting in almost no frame losses. As such, reliability is very high and meeting the expected standards of a 5G connection. As the end device moves away from the small cell, e.g. at points C and E, we see a degradation of this reliability and during the video stream a few frozen frames appear. Overall, a reliability of 98.15% (point C) and 97.21% (point E) are observed. While the synthetic tests showed that the capacity of the channel should be more enough to carry the <10 Mbit/s of video stream, we can observe that the reliability is not sufficient for guaranteeing a lossless video stream. In consequence, for the pilot, it is recommendable to reconsider the location of the small cell (e.g. in the centre of the warehouse) to maximize the average reliability in the warehouse, or to do let the drone fly always close to the small cell, if possible.
Conclusions
The drone centre use case aims to establish a state-of-the-art infrastructure for deploying a drone operations center in Mora la Nova, Catalonia, while supporting high data rate services. A standalone private 5G network using a small cell was successfully implemented, and the performance validated. The setup, including Raspberry Pi and Intel NUC devices for video processing, demonstrated low CPU and RAM usage, showing capacity for additional tasks. Network tests showed an average RTT of 28.78 ms, zero packet loss, and downlink throughput of 113 Mbit/s, surpassing requirements for 4K video streaming. With a real video stream, only at distances beyond 30 m between the 5G connectivity reveals some issues yielding the necessary reliability for a smooth video transmission. The results confirm the feasibility of using 5G and edge computing for both drone operations and high-speed Internet access, though spectrum allocation and cell placement would need optimization in a real deployment.
In the next step, configurations will be improved in the lab environment and a final deployment will be made with the optimized settings.