Harnessing P4 for In-Network Unmanned Aerial Vehicle Collision Avoidance

Harnessing P4 for In-Network Unmanned Aerial Vehicle Collision Avoidance Fabricio E Rodriguez Cesen , Francisco Germano Vogt , Marcelo Caggiani Luizelli , Christian Esteve Rothenberg , G´ eza Szab´ o Telefonica Research, Spain, Universidade Estadual de Campinas (UNICAMP), Brazil Federal University of Pampa (UNIPAMPA), Brazil, Ericsson Research, Hungary Abstract—With the advent of next-generation networks, new applications across multiple domains are gaining traction. This shift demands a redefined network paradigm, where ultrareliable, low-latency communication is key. In this work, we explore and extend the concept of in-network programmability in new directions. Unlike conventional approaches, we leverage P4 data plane programmability to implement an in-network collision avoidance algorithm in a UAV scenario. We evaluate our hardware-based implementation under different conditions, including latency and velocity, demonstrating that it efficiently detects and prevents collisions. Our results show the impact of end-to-end latency and highlight how in-network processing can be a valuable ally for time-sensitive tasks, paving the way for future advancements in hardware-based in-network applications. I. INTRODUCTION With the arrival of the next-generation 5G networks, various industries are set to be transformed. Applications in areas such as industry 4.0, agriculture, IoT, and Unmanned aerial vehicle (UAV) are poised to experience new possibilities [1]. However, with high data transmission volumes and various network services, the network’s capabilities must also keep pace. These require supporting Ultra-low latency (ULL) applications with extremely low loss and delay variation. Despite the significant performance of 5G access networks, both horizontal (e.g., distance, node processing) and vertical (e.g., NIC, OS, hypervisor, application) delays can impact the performance of end-to-end application services (as shown in Figure 1) [2]. Collision avoidance algorithms are critical for ensuring the safe and efficient operation of UAVs, particularly in increasingly congested airspaces. These algorithms are designed to prevent collisions between UAVs, avoid obstacles such as buildings, and, most importantly, protect human lives. Effective UAV collision avoidance algorithms are foundational to the future of unmanned aerial operations, ensuring safety, efficiency, and regulatory compliance in a crowded sky [3]. To this end, UAVs are commonly connected to powerful remote Application Programming Interface (API) for continuous monitoring of the environment and precise interventions. In a programmable network, offloading computational and communication tasks to the network infrastructure offers a transformative collision avoidance approach [4]. Executing actions directly within network devices at line rate yields not Fig. 1: UAV Scenario. only rapid but also reliable, significantly enhancing overall safety and responsiveness in real-time scenarios. This work explores an innovative approach to implementing in-network functions with Programming Protocol-Independent Packet Processors (P4) [5]. We further developed and implemented in P4 hardware an in-network collision avoidance algorithm (first introduced in [6]) for real-time navigation around obstacles and other UAVs. Using the P4 Programmable Patch Panel (P7) [7], [8] high-fidelity network emulation environment we test and evaluate our proposal using a a Tofino hardware switch. Through various scenarios, we demonstrate the superior responsiveness and effectiveness of the in-network approach compared to traditional cloud-based / software solutions. Our proof-of-concept experiments validate the efficacy of our collision avoidance algorithms, confirming their realistic and accurate performance in practical applications. The main contributions of this paper can be summarized as follows: •In-network p4-based collision avoidance algorithm. •Prototype implementation and evaluation. •Open-source software artifact for reproducibility1. II. BACKGROUND The different delay components of the end-to-end application latency, which constitute the delay incurred in exchanging commands and processing data, are shown in Figure 2. It is possible to identify three main components: the application (green), the access (orange), and the Multi-access edge computing (MEC) (red). Each element has its dependencies, such as processing time, transmission, or application components (blue). When adding an in-network solution, it is possible to 1https://github.com/intrig-unicamp/uav 979-8-3315-4345-7/25/$31.00 ©2025 IEEE 328 2025 IEEE 11th International Conference on Network Softwarization (NetSoft) | 979-8-3315-4345-7/25/$31.00 ©2025 IEEE | DOI: 10.1109/NETSOFT64993.2025.11080564 Authorized licensed use limited to: The University of Toronto. Downloaded on August 22,2025 at 17:22:06 UTC from IEEE Xplore. Restrictions apply. Application (UAV) Access MEC (Remote API) Time Command (Position Request) MEC processing Remote API processing Transmission Access Processing Transmission Command execution Command (Position Reply) Command reply Transmission Access Processing Access Processing Transmission Transmission Command execution Command (Collision Avoidance) P4 Switch P4Processing Transmission Fig. 2: End-to-End application latency. reduce the total command time. The response can be made from the P4 device when processing the command, avoiding the MEC related processing. UAVs are designed to navigate from a start position to a destination waypoint, but avoiding collisions remains a key challenge. Implementing an in-network collision avoidance algorithm on a programmable device leverages the benefits of P4 (e.g., high performance, reconfigurability, protocol independence). Offloading functions from remote APIs reduces latency compared to MEC (5–15 ms) or external networks (>10 ms) [9]–[12]. Most existing collision avoidance methods [13] rely on complex mathematical models (e.g., stochastic, Laplace), which limit feasibility for in-network deployment. To address this, we adopt the Real-Time Three-Dimensional Obstacle Avoidance Using an Octomap (3DVFH+) [14] algorithm for its compatibility with P4-based hardware and its comprehensive environmental awareness. 3DVFH+ uses geometric guidance with features like smoother trajectories, secure zones, and histogram-based input, achieving average response times of 300 µs. When comparing remote API processing at the MEC with in-network processing using 3DVFH+, the total collision avoidance response time is summarized in Equation 1. To exemplify this Equation in a real 5G scenario, we can assume horizontal delay values from the literature. Tt= Application z }| { 0.05ms + Access z }| { 2.2ms + MEC z}|{ 5ms + 3DVFH+ z }| { 0.3ms (1) If we deploy the in-network solution at the network’s edge, the total time to process the message reduces since the MEC processing is not required (see equation 2). TtP4= Application z }| { 0.05ms + Access z }| { 2.2ms +P4(2) III. RELATED WORK Network programmability has enabled innovative innetwork approaches that enhance traditional cloud-based models. Prior work has shown that programmable networks can offload computation and improve responsiveness. In [15], [16], an emergency stop for a robotic arm was implemented in-network. This concept is extended in [17], integrating computer vision tasks. MEC architectures [18] bring cloud capabilities closer to the edge; for instance, [19] programs robot actions within P4 switches to reduce overhead. Industrial automation has also adopted in-network processing. In [20], controller logic was offloaded to the data plane, while [21] studies trade-offs across platforms. Realtime control applications are proposed in [22] and [23], using sensor-actuator interactions. [24] presents Netopia, a control framework for robotic arms, and [25] uses Message Queuing Telemetry Transport (MQTT) parsing for automated actions. Edge-based control for Cyber-Physical Systems (CPS) is explored in [26], introducing EdgeP4 for in-network feedback, and [27] proposes in-network path planning based on sensor data. Building on these works, we extend in-network computing to an unexplored domain: unmanned aerial vehicles (UAVs). Our novel collision avoidance algorithm introduces new challenges to the field, broadening the impact of in-network processing in autonomous systems. IV. IN-NETWORK COLLISION AVOIDANCE A. Histogram Representation The 3DVFH+ avoidance algorithm builds on Vector Field Histogram (VFH), a technique from robotics and computer vision that represents the spatial distribution of objects. VFH divides the environment into a grid-like histogram, where each cell encodes directional information about objects or features. In our implementation, histogram cells store binary values indicating object presence (1) or absence (0), such as UAVs or obstacles. Additionally, different weights can be assigned to reflect object priority or cost, enhancing decision-making in avoidance strategies. B. Conflict Management Layers Collision detection requires identifying the positions of surrounding objects and defining safety thresholds to ensure secure avoidance [28], [29]. These thresholds form a layered secure zone around each object, guiding when to trigger avoidance actions. The secure zone consists of three layers: the outer yellow zone - detection, the middle orange zone - warning, and the inner red zone - imminent collision risk. C. Avoidance Process Starting from its initial position, the UAV moves toward a predefined destination while continuously checking for potential collisions based on secure zones. If no overlap with nearby objects is detected, the UAV proceeds uninterrupted. Once it enters a secure zone, the collision avoidance process is triggered. To avoid impact, the UAV is instructed to shift right [30] until it exits the secure area. When the secure zone is no longer intersected, the UAV resumes its original path toward the destination. 329 Authorized licensed use limited to: The University of Toronto. Downloaded on August 22,2025 at 17:22:06 UTC from IEEE Xplore. Restrictions apply. D. In-network Processing Given the advantages of implementing the collision avoidance algorithm in P4, Algorithm 1outlines the core logic for collision detection and response. Parser: On arrival, the P4 parser extracts packet headers. Message: In ingress control, the message type and content are verified. Depending on this, the packet is either processed or forwarded. Forward: Packets are forwarded if: •They originate from the remote API or client. •No obstacle is detected. Position from Client: Checks if the message is a position reply from the client. Obstacle: If an object (e.g., UAV or obstacle) is detected nearby, a secure zone is validated. If no obstacle is found, the message is sent to the remote API. Otherwise, the 3DVFH+ algorithm is triggered. Update Histogram: Position updates from UAVs modify a histogram, maintained using registers and tables, to reflect object positions. Collision Avoidance: When triggered, a copy of the packet is used to craft a new message directing the UAV to avoid the obstacle. Set Position: A new position is generated based on the UAV’s relative location. Modify Packet: The original packet is modified with the updated UAV position, preserving TCP session integrity with the remote API. Mirror Packet: A clone of the packet is sent to the remote API to maintain TCP synchronization. E. Communication Messages The messaging process relies on structured formats that enable peers to exchange information efficiently. These messages, treated as headers, can be parsed during in-network P4 processing. Each message type follows a specific structure to ensure accurate identification of source, destination, and relevant data. As communication is TCP-based, every message expects a corresponding response. Algorithm 1 P4 algorithm Input: Parse Packet Headers Output: (Original packet) or (Modify packet and Mirror Packet) 1: if P ackettype is UAV message then 2: if Messagetype is getpositionreply then 3: if UAV position is Obstacle secure area then 4: Collision Avoidance 5: else 6: if UAV position is Other UAV position then 7: Collision Avoidance 8: Update UAV Histogram 9: else 10: Forward 11: else 12: Forward Fig. 3: Collision avoidance algorithm + P7. V. EVALUATION A. Testbed We now analyze and experimentally evaluate our collision avoidance algorithm. The P7 emulator enables configuring link metrics to simulate realistic network conditions, as shown in Fig. 3. The P4 code and metric configurations run on a Tofino switch, while UAV physics and control are simulated in CoppeliaSim 1 , running on a separate server. Link 2 models the 5G access/edge, and link 4 represents the MEC or cloud. Collision logic is executed in the switch 3 , and the remote API 5 communicates with UAVs via a Python script. CoppeliaSim models UAVs, flight logic, and environment objects. Simulations run on a Lenovo ThinkServer RD640 (Xeon E5-2620v2, 64GB RAM, dual-port 10G NIC, Ubuntu 22.04, CoppeliaSim 4.6.0 rev8). The P4 algorithm executes on a Barefoot Tofino Wedge100B (BFN-T10-032D, Xeon D1517, 32 x 100G ports, Ubuntu 22.04). The remote API, implemented in Python, manages UAV control (destination, formation, actions) over TCP. It runs on a Supermicro SYS-5018D-FN8T (Xeon D-1518, 64GB RAM, dual-port 10G NIC, Ubuntu 22.04). B. Results To validate the collision avoidance logic implemented in P4, we introduce varying link metrics (e.g., latency, packet loss) between the switch and the remote API. This setup allows us to observe UAV behavior under different network conditions. Our evaluation considers multiple scenarios, including varying delays between the P4 switch and the remote API, different UAV velocities, and a comparison between in-network and remote API-based responses. 1) In-network Control: The in-network control activates when collision avoidance is required, validating messages exchanged with the remote API. To evaluate our proof-ofconcept, we examine the UAV’s behavior in different scenarios, starting with basic avoidance when entering a secure area, followed by tests with increasing UAV velocities. The yellow zone is defined as the detection area; the avoidance process must begin when an object enters it and continue until the UAV exits. Figure 4illustrates a scenario where the P4-based switch handles the avoidance logic. With a 5 ms delay to the remote API, two UAVs follow paths through static obstacles, as shown in Fig. 4a and Fig. 4b. When the UAV enters the yellow zone, the collision is detected, and a new path is generated to exit the secure area. 330 Authorized licensed use limited to: The University of Toronto. Downloaded on August 22,2025 at 17:22:06 UTC from IEEE Xplore. Restrictions apply. 0.0 0.0 0.2 0.2 0.4 0.4 0.6 0.6 0.8 0.8 1.0 1.0 1.2 1.2 1.4 1.4 1.6 1.6 1.8 1.8 2.0 2.0 2.2 2.2 2.4 2.4 2.6 2.6 2.8 2.8 3.0 3.0 3.2 3.2 3.4 3.4 3.6 3.6 3.8 3.8 4.0 4.0 4.2 4.2 4.4 4.4 4.6 4.6 4.8 4.8 5.0 5.0 0.0 0.0 0.2 0.2 0.4 0.4 0.6 0.6 0.8 0.8 1.0 1.0 1.2 1.2 1.4 1.4 1.6 1.6 1.8 1.8 2.0 2.0 2.2 2.2 2.4 2.4 2.6 2.6 2.8 2.8 3.0 3.0 3.2 3.2 3.4 3.4 3.6 3.6 3.8 3.8 4.0 4.0 4.2 4.2 4.4 4.4 4.6 4.6 4.8 4.8 5.0 5.0 UAV0 path UAV1 path Obstacle Obstacle zone 1 Obstacle zone 2 Obstacle zone 3 (a) UAV path. 0 20 40 60 80 100 Time Step 1 2 3 Obstacle zone UAV0 UAV1 (b) Collision detection. 0 20 40 60 80 100 Time Step 1 2 3 Obstacle zone 0.66m/s 1.33m/s 2.66m/s 4m/s 5.33m/s 6.66m/s 8m/s (c) Different velocities. 0 20 40 60 80 100 Time Step 1 2 3 Obstacle zone 5ms 10ms 15ms 30ms 60ms 90ms 120ms (d) Different latency. Fig. 4: In-network collision avoidance. Velocity is another key factor. Different applications require UAVs to operate at various speeds. To evaluate performance under such conditions, we used the same path (Fig. 4a) and varied UAV velocity from 0.66 m/sto 8 m/s, with the P4 switch handling avoidance logic. Figure 4c shows UAV’s response. As velocity increases, the UAV tends to enter deeper into the orange and red zones, despite correct detection. This suggests that higher speeds require faster in-network reaction times to ensure effective collision avoidance. 2) Remote API Control: The secure area plays a key role in collision detection. To further analyze avoidance behavior, we evaluate the UAV’s path upon entering the secure zone and compare outcomes under varying conditions. For this analysis, the yellow zone is defined as the detection area. The collision avoidance algorithm must activate when a UAV enters this zone and continue until it exits. To assess remote API control under network constraints, we use P7 to introduce different latency values on the link between the API and application. In this scenario, the in-network logic is disabled, and the remote API handles avoidance. UAV velocity is fixed at 0.66 m/s, while latency increases from 5 ms (baseline, Eq. 1) to 120 ms. Figure 4d shows that as latency rises, the remote API’s response is delayed, causing the UAV to approach the obstacle before adjusting course. At higher delays, avoidance becomes ineffective, increasing the risk of collision. 3) In-network vs. Remote API Control: To compare the performance of the in-network solution with remote API control, we use the same environment setup (path, obstacles, velocity) while toggling P4 processing and adjusting the delay to the remote API. This evaluation highlights the advantage of in-network control when rapid response is critical. The tests varied the delay to the remote API from 5 ms to 120 ms, with UAV velocity fixed at 0.66 m/s. Results show that as latency increases, the UAV travels deeper into obstacle zone before initiating avoidance, raising the risk of collision. In contrast, the in-network solution triggers avoidance early, resulting in safe distances regardless delay. Remote API control is limited by external factors, such as MEC or cloud latency, which affect timely responses. When combined with higher UAV velocities, latency can make collision avoidance unreliable or impossible. By offloading critical actions to the data plane, the innetwork approach eliminates dependency on remote processing, ensuring fast, consistent responses and preserving application performance under varying network conditions. VI. RESOURCE UTILIZATION A. Headers and Parser Our UAV P4 implementation defines 10 headers—9 parsed from incoming packets and 1 for custom collision responses. Compared to a baseline L2/L3 P4 program with ∼5 headers, our solution adds 5 UAV-specific headers. The parser includes 23 states, more than a basic program (6 states), to handle UAV-specific processing. B. Deparser and Checksum We validate two checksums (IPv4 and Transmission Control Protocol (TCP)) using Tofino’s built-in engines, staying within hardware limits without extra configuration. C. Ingress Processing Three tables are used: two exact-match (5000 entries each) and one range-match table sized to the number of UAVs. This results in ∼4.2% Static Random-Access Memory (SRAM) and 9.3% Ternary Content Addressable Memory (TCAM) usage. Using range matches reduces histogram entries from 49 to 4 per UAV (∼92% savings), crucial for scaling. Five actions are implemented—four for simple assignments and one for collision avoidance. Each UAV needs five if/else conditions, with one added per new UAV. UAV positions are stored in registers; each UAV uses a pair, plus registers for collision state and TCP tracking. Figure 5presents an overview of resource utilization along the different stages available. This scenario serves as a baseline for multiple UAV deployments. D. Traffic Manager One mirror session is used for avoidance responses. Tofino supports up to 1023 sessions, enabling flexible packet replication based on application needs. 331 Authorized licensed use limited to: The University of Toronto. Downloaded on August 22,2025 at 17:22:06 UTC from IEEE Xplore. Restrictions apply. 123456789101112 Pipeline Stages Action Data Bus Bytes Exact Match Result Bus Exact Match Search Bus Gateway Hash Bit Logical Table ID Meter ALU SRAM Ternary Result Bus VLIW Instruction Exact Match Input Xbar 0 50 100 Percentage (%) Fig. 5: Resource consumption of different UAV deployments. The color bar indicates the percentage of utilized resources. E. Comparative Analysis We use a simple switch program as a baseline to evaluate resource usage. This program, implementing basic L2/L3 forwarding, provides a clear reference point for understanding Tofino Native Architecture (TNA) resource consumption on a Tofino switch. It serves as a benchmark to compare against more advanced P4 implementations. Key metrics considered include hash bits, SRAM, TCAM, Very Long Instruction Words (VLIW) actions, stateful Arithmetic Logic Units (ALUs), gateways, meter ALUs, logical table IDs, and the Ternary Result Bus. VII. CONCLUSIONS AND FUTURE WORK This work introduced an in-network collision avoidance algorithm fully implemented in the data plane. We addressed the challenges of hardware adaptation and demonstrated the benefits of executing time-critical logic close to the application layer. Using the P7 emulator, we evaluated performance under realistic network conditions. Results show that in-network processing with P4 enhances collision avoidance, especially under low-latency scenarios, where relying solely on remote APIs can lead to delays and potential collisions. By embedding logic within the network, our approach ensures faster and more reliable responses. Future research will explore the security aspects of innetwork processing, focusing on privacy and threat mitigation. Additionally, expanding this approach to other domains—such as healthcare or autonomous delivery—could unlock new realtime applications powered by programmable networks. ACKNOWLEDGMENT This work was supported by Ericsson Telecomunicac¸ ˜ oes Ltda., and by the Sao Paulo Research Foundation (FAPESP), grant 2021/00199-8, CPE SMARTNESS and grants 2020/05183-0 and 2023/00794-9. Also, it was supported by Foundation for Research of the State of Rio Grande do Sul (24/2551-0001394-6). This work has been partially supported by the European Union’s Horizon Europe project under grant agreement No. 101070473 (FLUIDOS). REFERENCES [1] A. Gupta et al., “A survey of 5g network: Architecture and emerging technologies,” IEEE Access, vol. 3, pp. 1206–1232, 2015. [2] M. M. Azari et al., “Coexistence of terrestrial and aerial users in cellular networks,” IEEE Transactions, vol. 17, no. 6, pp. 3942–3957, 2018. [3] S. Hayat et al., “Survey on unmanned aerial vehicle networks for civil applications,” IEEE Communications, vol. 18, pp. 2624–2661, 2016. [4] A. Sapio et al., “In-network computation is a dumb idea whose time has come,” in ACM HotNets. ACM, 2020, pp. 150–157. [5] P. Bosshart et al., “P4: Programming protocol-independent packet processors,” SIGCOMM Rev., vol. 44, no. 3, pp. 87–95, Jul. 2014. [6] F. Rodriguez et al., “Offloading robotic and uav applications to the network using programmable data planes,” in 2023 IEEE Conference on NFV-SDN, 2023, pp. 207–212. [7] ——, “P4 Programmable Patch Panel (P7): An Instant 100G Emulated Network on Your Tofino-based Pizza Box,” in ACM SIGCOMM’22 Demo and Poster Session, 2022. [8] ——, “Towards multiple pipelines network emulation with P7,” in IEEE NetSoft, Madrid, Spain, Jun. 2023. [9] S. D. A. Shah et al., “SDN Enhanced Multi-Access Edge Computing (MEC) for E2E Mobility and QoS Management,” IEEE Access, vol. 8, pp. 77 459–77 469, 2020. [10] S. Das et al., “PON Virtualisation with EAST-WEST Communications for Low-Latency Converged Multi-Access Edge Computing (MEC),” in 2020 OFC, 2020, pp. 1–3. [11] N. Nikaein et al., “LL-MEC: Enabling Low Latency Edge Applications,” in IEEE CloudNet, 2018, pp. 1–7. [12] Q. Yuan et al., “Toward Latency-Optimal Placement and Autoscaling of Monitoring Functions in MEC,” IEEE Access, vol. 8, 2020. [13] S. Huang et al., “Collision avoidance of multi unmanned aerial vehicles: A review,” Annual Reviews in Control, vol. 48, pp. 147–164, 2019. [14] S. Vanneste et al., “3DVFH+: Real-Time Three-Dimensional Obstacle Avoidance Using an Octomap,” in MORSE 2014, 2014, pp. 89–100. [15] F. Rodriguez et al., “In-network p4-based low latency robot arm control,” in CoNEXT. NY, USA: ACM, 2019, p. 59–61. [16] ——, “Towards low latency industrial robot control in programmable data planes,” in IEEE NetSoft. IEEE, 2020, pp. 165–169. [17] R. Glebke et al., “Towards executing computer vision functionality on programmable network devices,” in CoNEXT Workshop ENCP, 2019. [18] Y. Hu et al., “Mobile edge computing a key technology towards 5g,” ETSI, vol. 11, pp. 1–16, 2015. [19] W. Wang, “5g mobile platform with p4-enabled network slicing and mec,” 9 2019. [20] J. Vestin et al., “FastReact: In-network control and caching for industrial control networks using programmable data planes,” in ETFA, vol. 1. IEEE, 2018, pp. 219–226. [21] I. Kunze et al., “Investigating the applicability of in-network computing to industrial scenarios,” in IEEE ICPS, 2021, pp. 334–340. [22] S. Laki et al., “In-Network velocity control of industrial robot arms,” in USENIX NSDI, Renton, WA, Apr. 2022. [23] J. Vestin et al., “Fastreact: In-network control and caching for industrial control networks using programmable data planes,” CoRR, vol. abs/1808.06799, 2018. [24] Z. Wang et al., “Industrial Knee-jerk: In-Network Simultaneous Planning and Control on a TSN Switch,” in MobiSys. ACM, 2023. [25] A. Atutxa et al., “Achieving low latency communications in smart industrial networks with programmable data planes,” Sensors, vol. 21, no. 15, p. 5199, 2021. [26] N. K. Gnani et al., “Edgep4: A p4-programmable edge intelligent ethernet switch for tactile cyber-physical systems,” 2023. [27] T. V. Doan et al., “In-network path planning for autonomous driving,” in IEEE NFV-SDN, 2023. [28] G. Migliaccio et al., “Conflict detection and resolution algorithms for uavs collision avoidance,” Aeronautical Journal, vol. 118, 2014. [29] J. Tang et al., “Systematic review of collision-avoidance approaches for unmanned aerial vehicles,” IEEE Systems Journal, vol. 16, no. 3, 2022. [30] X. GUAN et al., “A survey of safety separation management and collision avoidance approaches of civil uas operating in integration national airspace system,” Journal of Aeronautics, 2020. 332 Authorized licensed use limited to: The University of Toronto. Downloaded on August 22,2025 at 17:22:06 UTC from IEEE Xplore. Restrictions apply.