## 3 Proposed Method
### Implementation Framework  
This section describes the implementation of the proposed architecture for vehicular data (Camera, LiDAR, and RADAR) in 5G VANETs. To implement the functional requirements, four Ubuntu Virtual Machines (VMs) with two cores and 2 GB RAM were deployed as SDVs. At the gNB, one Ubuntu VM with four cores and 2 GB RAM was deployed to host the edge datacentre. The implementation of the proposed architecture followed a software-defined approach. In software-defined networking, network applications are deployed to manage network functions. A novel event-driven SD-WAN framework (Figure 3) was deployed using the available resources on VMs to orchestrate and manage the flow of communication between SDVs and vehicular application servers hosted by the gNB. As illustrated in Figure 3, the data plane performs packet forwarding and traffic classification, and assigns Slice IDs (an identifier used to classify data flows based on QoS class requirements) via OpenFlow-enabled switches. The control plane manages dynamic flow decisions and routing logic, enabling the programmable handling of vehicular communication through SDN Controllers. Additionally, the application plane hosts the SDN control logic responsible for generating flow rules, monitoring link conditions, and orchestrating real-time access management policies. The virtual network was simulated using Mininet (v2.3) and Python (v3.8) APIs to create a topology linking each SDV to the gNB using a dedicated VXLAN transport tunnel. A star topology was adopted, where each SDV serves as a hub for ten connected sensors  
Figure 3: Event-Driven SD-WAN framework for identity, data and dynamic access management in 5G communication systems. Solid arrows illustrate the direction of communication flow on the network, whilst dotted arrows indicate real-time communication between the control and data plane. that communicate with an embedded SDN gateway for local data pre-processing before transmission to the gNB. On each SDV, we simulated six Camera sensors transmitting approximately 105,260 bytes/second, three LiDAR sensors transmitting 2632 bytes/second, and two RADAR sensors transmitting 10.5 bytes/second to the SDN gateway. The decision regarding the amount of data generated by each sensor was informed by [20], although a significantly lower ratio was implemented due to the testbed capacity. The proposed framework operates via a joint controller algorithm deployed on SDVs and at the gNB. Upon connection, the SDN Controller installs flow rules on OpenFlow tables 0 and 1 at the SDN gateway and gNB. Figure 4 illustrates the end-to-end flow of vehicular data from collection to offloading, which is aligned with the SDN architecture and Open Systems Internetworking (OSI) model. The flow diagram is divided into two main blocks--Data Collection and Pre-Processing at the SDN gateway, and gNB Processing and Data Offloading at the edge servers. Each block highlights the interplay between the data plane (OSI Layer 2) and the control plane (OSI Layer 3) in orchestrating packet flow and ensuring adequate data handling through OpenFlow tables. At the SDN gateway, incoming vehicular data is first verified for authenticity using the pre-assigned network ID in OpenFlow table 0 at the data plane. If valid, the data proceeds to Table 1, where port matching and Slice ID assignment are performed within the data plane. The control plane monitors these processes and provides the decision logic used to verify the network parameters. Once a valid Slice ID is assigned, the packet is forwarded through a VXLAN link to the gNB. The VXLAN operation simulates underlay  
Figure 4: System flow diagram. Layer 2 transport tunnelling, which is essential for virtualising the network links within the SDN architecture. Upon arrival at the gNB, data is routed into OpenFlow table 0, where the VXLAN input port is validated at the data plane. The control plane logic verifies the corresponding port ID.