ABAUS: Active Bundle AUthentication Solution Based on SDN for Vehicular Networks

Vehicular ad hoc networks (VANETs) are gaining more and more interest in intelligence transportation system research fields. They allow optimized traffic management due to improved vehicle resource usage and real-time information exchanges. However, being in an open environment introduces different security and privacy challenges. Attackers can sniff radio signals and forge the transmitted information leading to sensitive data leaking or compromising. This paper examines the preservation of privacy information in VANET communications. We use the Active Bundle (AB) for vehicle authentication and data preservation based on software-defined networks (SDNs). Our proposal benefits from the SDN infrastructure to guarantee fluent centralized management while using the AB guarantees data integrity and confidentiality throughout its entire lifecycle. Analytical studies and simulations show that our solution efficiently preserves VANET users’ privacy with minimal effects on network transmission quality.


I. INTRODUCTION
A group of vehicles that are moving or stationary and connected by a wireless network is known as a vehicular ad hoc network (VANET).Initially, VANETs were used to provide safety and comfort to drivers in vehicular environments [1], [2].
One of the VANET key features is their ability to connect or any networking infrastructures, such as roadside units (RSUs).RSUs act as access points along the roads.Through dedicated short-range communications, cars can exchange messages with other vehicles nearby or with distant servers [3].Those two communication modes: Vehicle-toinfrastructure (V2I) and Vehicle-to-Vehicle (V2V) are the two basic data exchange models in the vehicular network.Recently, a new model: Vehicle to Everything (V2X) [1], [4], [5] is defined to allow vehicles to communicate with any possible devices which expands widely the eventual use cases.
Nowadays, VANETs are an intelligent transportation system able to provide more than safety information and The associate editor coordinating the review of this manuscript and approving it for publication was Nitin Gupta .traffic control.Recent proposals are presenting new use cases such as trip control and user-friendly, Passengeroriented, environmental, healthcare, and IOT-oriented integration applications.However, VANETs are highly dynamic networks.Connections, data paths, and node density can change instantly.Consequently, network performance may be severely damaged, and communication will be slowed down or even interrupted.Inevitably, the underlying services will fail.Therefore, VANETs, require the use of protocols and techniques with a high level of robustness and efficiency.Different research activities are being conducted to provide reliable routing schemes and adequate service platforms [6], [7], [8].
Security and data protection are among the research fields attracting more attention [9], [10], [11], [12].The wireless characteristics, mobility, and signal sharing are seen as VANETs' most valuable assets, but they are also a source of vulnerabilities.Attacks can sense signals, unveil transmitted data, and forge and broadcast false information to disturb available services.They can even overcharge communication channels, leading to a complete lockout of the network.Sybil, denial of service, blackhole, wormhole, eavesdropping, false position information, and man-in-the-middle attacks are among the most well-known attacks on VANETs [13], [14], [15].
Various security schemes are presented to address those issues and provide a safe and protected network environment [14].Many of them have focused on security infrastructures and protocols, while others have studied security attacks and their impact on the proposed solutions.Most of the propositions focus on basic security services such as availability, integrity, confidentiality, and authenticity [14], [15], [16].But, user privacy is not considered among those basic services.
Ensuring privacy and authenticity are always conflicting needs.Authenticity requires the sharing of identity and sensitive data.On the other hand, preserving privacy involves hiding these settings; thus, meeting those requirements remains a serious challenge.Traditional schemes use an external ''trusted authority'' (TA) and cryptographic methods to authenticate vehicles.Unfortunately, this approach becomes ineffective when the TA is unreachable, or data are lost.Thus, in our proposal, we rely on the software-defined network (SDN) as a suitable infrastructure to support node authentication and anonymous identity management.
Software Defined Networks (SDNs) were recently proposed in [16], [17], [18], [19], [20], and [21] as a reliable architecture for vehicular wireless networks.SDNs offer a separation between the ''control plane'' and the ''data plane''.This means that all the network operations, decisions, rules, and path selection are done by the controllers before forwarding data to various network devices (the data plane components).SDNs play a crucial role in enhancing the capabilities and effectiveness of VANETs by providing a flexible and efficient network management framework, dynamic traffic engineering, quality of service (QoS) provisioning, and security and privacy enhancement.In our proposition, we adopt an SDN as a vehicle identity management infrastructure.A centralized SDN controller (Basic Controller) will store different vehicles' identity information and guarantee the authenticity of each participant.The BC will relay that information to RSU-SDN controllers deployed regionally on the different base stations.Having controllers as a supportive infrastructure for VANET and not part of it will help avoid TA attacks and accelerate authentication operations without extra charge on the VANET communication channels.
To enforce sensitive information protection, we introduce the use of an active data bundle (AB) as a secured data exchange framework.It was proposed in [22] as a selfprotecting scheme.An AB is mainly composed of metadata, sensitive data, and a virtual machine (VM).Metadata sections contain security policies and parameters defined to protect the transmitted data.For example, they can define an encryption algorithm, its public key, and the pseudonyms of authorized nodes to read and access sensitive data.The VM is a light and portable program and not an operating system.The AB creator will compile and construct the VM code after choosing the appropriate security policies and configuring the needed parameters.Finally, the built AB will be forwarded through the network.The VM code is built to perform data evaporation or apoptosis if it detects policy violations.Consequently, any possible receiver is only able to follow the included policies.Otherwise, data will be erased or hidden by the VM and the entire AB will be unuseful [23], [24].This feature ensures data protection all along its entire life cycle.
The contributions of the paper are as follows: 1) Adaptation of the SDN infrastructure to ensure vehicle authenticity, anonymity, and secure communications.2) A flexible and adaptable self-protection mechanism for sensitive data all along its lifecycle with the use of the AB framework.3) A privacy protection and authentication approach.
Vehicle identities are protected by the SDN controllers, and anonymity is guaranteed through the use of random pseudonyms.4) A detailed registration protocol is proposed to check and validate different network components.5) A performance evaluation study to show that our solution ensures privacy preservation with minimal effects on network quality.
The rest of this paper is organized as follows: Section II reviews the related work.In section III, we describe our proposed scheme and give functional details.Section IV provides the experimental setup and the performance evaluation results.Finally, Section V concludes the paper.

II. RELATED WORK
VANETs are an essential part of the intelligent transportation system (ITS).Different aspects are investigated to improve their communication performance.In this section, we focus on proposed solutions to deal with security threats and privacy protection.Various authentication protocols have been proposed for identity verification in the past recent years [25].Most schemes focus on cryptography-based Authentication, Group Signature-based, and Blockchain-Based identification.
Reference [26] introduced a conditional privacy-preserving scheme suited for protecting and ensuring the security of communications and improving network security in the Software Defined Vehicle Network (SDVN) framework.They used a weight-based technique to register vehicles and execute a tow-step detection mechanism to track bad behaviors.The Local Controller (LC) supervises the attributed weights and checks the vehicle's true identity each time the weight is lower than a defined threshold.If the bad behavior is confirmed, the LC contacts the GC(Global controller) to confirm the decision to exclude the vehicle.The proposed scheme aims to reduce computational costs and redundant communication.However, the identity-checking mechanism requires LC-GC communication because LC is not allowed to store vehicle identity information.Therefore the verification process is vulnerable to attacks or communication interruptions.
To overcome the security challenges, [27] proposed a LIAP scheme for VANETs.LIAP stands for Local Identity-Based Anonymous Message Authentication Protocol.It incorporates the use of cryptographic identity instead of transitional security certificates.Vehicles can hold various valid identities to ensure their privacy.This feature provides a distributed mutual authentication mechanism and avoids radio communication for V2V identity verification.However, this feature comes with a high computational cost.
The authors in [28] proposed an anonymous batch authentication (EABA) scheme to reduce the message loss rate of vehicles and roadside units (RSUs).This scheme uses a message classification algorithm and allows receivers to authenticate messages based on the classification result.So, the messages with high priority will be authenticated preferentially.In EABA, RSUs and vehicles share authenticated messages to reduce the workload during network saturation.However, the experimental studies did not cover the effect of data transmission delay caused by batch authentication.
Reference [29] disclosed that signature-based schemes are built on full trusted authority and do not fulfill realworld needs.To fix these issues, the researchers proposed an authentication scheme that does not rely on trusted authorities.Instead, it is based on semi-trusted authority and certificateless signature.However, the scheme has 8 phases based on elliptic curve cryptography to ensure ID verification.Also, there is no key agreement which makes it less secure under network attack.
The authors in [30] proposed a Blockchain-based authentication mechanism.This solution incorporates vehicular IoT services, including trust management and cloud-assisted video reports on vehicular messages.Authentication authorities must authenticate vehicles that access the 5G-VANET.To this end, they ensure vehicles' legitimacy by issuing private keys and valid public-key certificates.The vehicles must pass through the validation process to run on the road and transmit messages.However, blockchain introduces more computational costs due to the ''proof of work'' and ''proof of existence'' needed operations.

III. PROPOSED SOLUTION PRESENTATION
To ensure privacy preservation and prevent sensitive data leaks on VANETs, we propose ABAUS: Active Bundle AUthentication Solution.In our proposal, The Active Bundle (AB) acts like an intelligent mobile program.Sensitive data will be transmitted only on an AB.Each one will carry a payload of data with its metadata.The metadata are sets of configuration parameters, security and privacy policies, and further information needed for data processing or preservation.An AB contains also a portable code (VM).It acts like a ''ready for execution'' unchangeable and self-protected program, which will ensure the basic AB operations.We will use Asymmetric cryptography to encrypt/decrypt and sign sensitive data.
The SDN is a suitable infrastructure to deploy our solution components.A centralized SDN controller (BC) will be the key element.It will handle all vehicle information, and it contains the primary AB security server.It can also delegate part of its functionalities to a second-level controller: the SDN-RSU controllers (RSU-C) which offer partial security services for RSUs.In particular, they will be able to authenticate RSUs and provide them with security configuration parameters and car information to start operating.

A. THE SOLUTION ARCHITECTURE
As mentioned in Figure 1, our solution relies on the SDN infrastructure.The network will consist of the following entities: DMV, SDN basic controller, RSU SDN Controller (RSU-C), RSUs and vehicles: The DMV offers management services for vehicles.Owners submit real documentation to register their vehicles.The registration process leads to a unique vehicle identifier (ID) creation and information storage in the vehicle information base.
The Basic SDN controller (BC) is the key entity of the architecture.In addition to its network responsibilities such as making routing and forwarding plans and passing them to mobile nodes (vehicles), it also provides all needed security and privacy preservation operations.It has a secure communication with the DMV to gain access to the vehicle's ID information base.The BC can also incorporate all or parts of the AB management servers.So, it's responsible for generating and maintaining anonymous pseudonyms for vehicles, cryptographic keys generation, and security policy definition.
The SDN-RSU controllers (RSU-C) are deployed on wireless base stations.They have secure and protected connections with the SDN basic controller to receive security and privacy configuration parameters.BC can delegate to them different security operations such as car pseudonym verification and message authentication.
RSUs: are small and wireless units deployed all over roads.They will relay vehicles to the different SDN nodes.They will be mostly responsible for vehicle authentication and integration in the network and offering different services.
Finally, vehicles are equipped with the necessary wireless communication devices.They can use WAVE standards to contact the RSU and gain different services.
Our proposal ABAUS provides the following operations: • Network join: different network members (vehicles, RSUs, and SDN RSU controllers) have to contact the basic controller when they first join the network to gain network access permission and receive security and identification parameters.
• Message exchange and authentication: After being allowed to join the network, vehicles and RSUs are free to exchange different contents.Upon receiving a new message, each node starts by checking the new encounter parameters, especially its pseudonym and encryption public keys.

B. THREAT AND TRUST MODEL
In our solution, we consider that the DMV and SDN basic controllers are trusted entities.Attacks on those entities are out of this paper's scope.We assume that they can resist any external or internal attacks.Their operations and stored data are well protected and any compromised information can be immediately recovered.SDN-RSU controllers (RSU-C) and RSUs are trusted to correctly perform the proposed solution and provide reliable data, needed parameters, and results; however, they are not trusted to preserve vehicle privacy.They may want to collect vehicles' IDs, location trajectories, or other private information.Thus, they are not allowed to uncover vehicle real IDs.
Vehicles are wireless mobile nodes.They are the most vulnerable units in the network.They can be hacked or receive compromised data.They can also act maliciously to threaten the network safety.They will be able to generate false data and compromise offered services.
External attackers can affect network safety.They can sniff wireless communication and collect private information.They are also able to forge and introduce false messages.As a result, RSUs or other vehicles in the same area will be misled, and the whole network can be disrupted.

C. RSU-C NETWORK JOIN
During the network initialization, the SDN basic controller will authorize the SDN-RSU controllers to integrate the network and start operating.The initialization mechanism is as follows: 1) The SDN-RSU controller sends a network join request using a temporary AB.
2) The SDN basic controller receives the temporary AB, checks the SDN-RSU controller credentials, and sends back the network join response, which contains the permanent security parameters to be used by the RSU-C 3) The RSU-C accepts the new parameters and starts using them.4) The RSU-C will be responsible for part of the RSU units; it therefore requests their information from the SDN base controller.
Figure 2 presents the join process.During step (i) the RSU-C aims to send a join request to the SDN basic controller; however, since this is its first contact with it, no valid encryption and hash parameters are available for AB creation.Therefore, the RSU-C starts by generating temporary encryption parameters.So, it will be able to encrypt and protect their next communications.The temporary AB metadata includes a clear policy that the SDN basic controller is the only entity allowed to decrypt the sensitive data.The RSU-C uses this AB to send the join request with its credentials for verification.
Step (i) permits any new member to send secured data to the SDN basic controller using the temporary encryption keys.The basic controller will verify the credentials (step ii), and if they are accepted it will generate new permanent AB encryption keys and security policies and send the response to the requestor.The new member (SDN-C) receives the join response and can start using its parameters (step iii).
The SDN-RSU controller starts operating by requesting information about the RSUs in its region and under its responsibility (step iv).The request will be packed in using the AB new received parameters.

D. THE RSU NETWORK JOIN
Roadside units (RSUs) are units deployed on the roads to provide services to vehicles; therefore, they must join the network and be verified by RSU-C.Each RSU unit is configured to start by contacting its RSU-C for ID verification and security parameters configuration.The process is detailed as mentioned in Figure 3.The new RSU sends a request join message using a temporary AB.As we mentioned before, the use of a temporary AB requires generating a temporary encryption key in preparation for sending the credentials for verification.The SDN-C will be able to unpack the requestor information and proceed with the verification process.Upon the RSU acceptance, the RSU-C needs to contact the SDN basic controller for permanent encryption/decryption and signing parameters.The SDN basic controller is responsible  for permanent key generation; therefore, it will be instantly updated with any newcomers and be able to control all communication in the network.

E. THE VEHICLE NETWORK JOIN
To be able to join the network, the new vehicle needs to perform two separate steps: offline registration and network integration.
Offline registration is an ordinary administrative process where the vehicle owner provides the necessary documents to the DMV to register his vehicle and confirm its legality.This step leads to storing the vehicle information in the SDN base controller (Figure 4).
After the offline registration is confirmed, the vehicle is allowed to join the network (Figure 5).It starts by generating a temporary AB for its first communication.Then, it sends its identity for verification by the SDN basic controller.Real identity and information are sensitive data; therefore, only the SDN basic controller is allowed to read it for verification and generates a unique ''pseudonym'' for the vehicle.The pseudonym preserves the vehicle's true identity from violations and allows it to communicate through the infrastructure without compromising.
The SDN basic controller verifies the vehicle ID and sends back confirmation and new parameters through the SDN-RSU controller and the correspondent RSU.All intermediary nodes do not have access to the transported data.They only relay it to the vehicle.

F. MESSAGE AUTHENTICATION
After integrating, the network vehicles can communicate with the infrastructure through RSUs to ask for all allowed services and to communicate with other vehicles for any data exchange.
The vehicle uses its permanent AB parameters to send data or ask for a service from the RSU.The RSU uses the VM and the correspondent decryption key of the vehicle to read the transported data.
The sender vehicle starts broadcasting data to vehicle2 (Figure 6).The receiver must check the sender's identity before dealing with it; therefore, it asks the nearest RSU, which provides the answer directly if it has information about the sender's vehicle or asks for it from the RSU-C.Once the vehicle is checked, vehicle2 needs the decryption key to read the transported data, so it searches for it through the network infrastructure.When it gets the answer, it will be able to fully communicate with the sender vehicle.

IV. ANALYSIS AND PERFORMANCE EVALUATION
In this section, ABAUS is evaluated in two aspects.First, we theoretically explain how our scheme achieves different security and privacy protection goals.Second, we defined simulation scenarios to prove the solution's correctness and evaluate its performance.

A. SECURITY ANALYSIS 1) TRACEABILITY
The SDN basic controller (BC) is the only entity allowed to get real vehicle identities from the DMV.Additionally, it generates all permanent encryption/decryption AB parameters and stores new vehicle pseudonyms in its protected database.Different nodes have to use their private keys to sign and encrypt each message before forwarding it to the network.
These conditions guarantee that, in any dispute case, BC can trace down all suspicious data and find the real ID of the malicious attacker.

2) ANONYMITY
BC is the only person allowed to generate a pseudonym during the network join phase.The link between the vehicle's real identity and the attributed pseudonym is stored and highly protected by the BC.During V2V or V2I communications, pseudonyms are included as sender or receiver identifiers.Therefore, there's no possibility of linking the messages to the vehicle's real identity, and privacy protection is guaranteed.

3) ROBUSTNESS
Newly registered vehicles will have their pseudonym in the BC database.Security parameters will be eventually generated during the join process.Message exchanges are allowed only using the AB framework.The VM will react to any malicious tentative to hack the transferred data and decide to partially or evaporate data.

B. PERFORMANCE ANALYSIS
We will evaluate the performance of our scheme.Our proposal for ABAUS is based on two different types of environments: the infrastructure part and the VANET part.The infrastructure part includes the ''basic SDN controller'' and the ''SDN-RSU controller''.Vehicles and RSUs are the VANET part.The RSU is considered a part of the two environments.It is equipped to be able to communicate with vehicles using the VANET radio communication protocol.It has also the ability to communicate with the infrastructure through TCP/IP stuck with a wireless connection.
Our evaluation will cover two basic situations: the vehicle network join phase and the data or service exchange during ordinary communication.We adopt two performance metrics: the average authentication delay and the packet loss ratio.
We start by presenting the experimentation characteristics.Then, we will detail the evaluation of the two basic cases.Finally, our proposal will be compared with EAPP [31], TAAP [32] and LIAP [27] in terms of computational cost, communication cost, and performance metrics.

1) EXPERIMENTATION CHARACTERISTICS a: SIMULATION PARAMETERS
We use the VANET simulator ''Veins'' [33] to test the performance of our scheme.We based our scenarios on a real map of Indianapolis extracted from OpenStreetMap.Vehicle trips are randomly generated by the SUMO tools included in Veins.
The rest of the parameters are detailed in Table 1:

b: THE USED INFRASTRUCTURES
We evaluate our proposal with small, medium, and large infrastructures.
Small Infrastructure: In this case, the SDN infrastructure will include one basic SDN controller, one SDN-RSU controller, and one RSU.Using this site, we will be able to study the performance of our solution under limited resources, where all the vehicles will need to use the same RSU to join the network communication.
Medium Infrastructure: The medium infrastructure will include one basic SDN controller and four SDN-RSU controllers.Each one will manage two RSUs for a total of eight RSUs in the whole network.This size will ensure more network coverage than the small one.RSUs will be deployed in different locations to service important roads.Vehicles will be served quickly upon requesting the network join.
Large Infrastructure: In the last case, we will set up a large infrastructure including one SDN basic controller, four SDN-RSU controllers, and 16 RSUs.With 16 RSUs, we aim to study our scheme under highly overloaded radio communication.Collision and signal interference will be an important challenge.

c: THE EVALUATED COMMUNICATION PHASES
The Vehicle Network Join Phase: The network join phase describes the arrival of a vehicle and its request to be admitted to the network.It involves the process of identity verification by the SDN basic network and providing permanent parameters to be used by the requestor in its later communications.
The Data or Service Exchange Phase: In this phase, we refer to the ordinary communication of vehicles.After being accepted in the network, vehicles can exchange data with each other or with the infrastructure.Before accepting any received data vehicles, RSUs need to check the identity of the senders.

d: THE EVALUATION METRICS
We will use the following metrics to study the solution behavior: • Authentication delay during network join: Different nodes in the network start their communication through ''a join request'' to be admitted on the network.The authentication delay will measure the time from sending the first AB temp request until getting a final response from the SDN basic controller with the requested parameters.
• Authentication delay during data exchanges: Vehicles, after joining the network, will be able to freely communicate with other nodes.Two kinds of communication are possible: V2V and V2I.
• Packet Loss Ratio: the packet loss ratio is defined as the percentage of dropped packets in total sent packets (see Equation 1where D i is the number of dropped packets, S i is the total of sent packets and N the number of vehicles in the network.
• Computational Cost: It refers to the total computing time needed to verify the car's identity.It involves cryptographic operation and database research.Our proposal does not use bilinear pairing, point multiplication, or any cryptographic scheme in the identity verification process.The SDN basic controller validates car identities.It checks car information and attributes pseudonyms based on the recorded data.All communication and data exchange will be encrypted and signed using RSA with 2048-bit keys.
• Communication Cost: It counts the number of bytes required during the authentication process.Our scheme uses ADB in the communication.The ADB includes three parts: metadata, data, and the VM.

2) PERFORMANCE EVALUATION RESULTS a: EVALUATION OF THE VEHICLE NETWORK JOIN PHASE
In this section, we evaluate the process of vehicle integration on the network.Any vehicle, before starting to use the platform services, must be authenticated.It receives a permanent AB parameter necessary for its communications.We measure the delay required to accept the new vehicle and the packet loss ratio of this process.Average Authentication Delay: Figure 7 shows the average authentication delay of vehicle network join over different infrastructure sizes and with vehicle number variation from 20 to 200.We observe that the time required to complete a vehicle registration is around 20 ms regardless of the number of requesting vehicles.The vehicle registration process relies on the SDN infrastructure.Any newcomer will send their request to the nearest RSU.Then, the demand will be forwarded to the SDN-RSU controller and the SDN basic controller to be processed; therefore, VANET radio features and the number of vehicles have a limited impact on the registration process.Vehicle identities will be quickly checked and allowed to communicate through the network services.
Large infrastructure shows slightly better performance.Increasing the number of used RSUs limits the configuration workload and accelerates the registration phase.
Packet Loss Ratio: In Figure 8 we represent the packet loss ratio for different infrastructure sizes and with vehicle number variation.We see that we recorded a low rate in all situations.In the case of small vehicle numbers (20 vehicles), each vehicle encounters a loss ratio of around 1.5% for small infrastructure.Then, this rate decreases when the vehicle number increases.
These observations show that the use of the SDN infrastructure considerably limits individual packet loss since the major part of communication is done outside the VANET.

b: EVALUATION OF THE DATA EXCHANGE PHASE
The communication on a VANET can be between a vehicle and the infrastructure if the vehicle uses a service provided by the network platform.It can also be between vehicles if they will exchange road information or any required data.When this kind of communication starts, the identity of the vehicle must be verified before accepting its data.
In this section, we evaluate the authentication of vehicles during ordinary communications.
Case: Vehicle-to-Infrastructure Communication: When a vehicle asks for an infrastructure service and sends its request to the nearest RSU, the receiver needs to check the requestor's identity before accepting the demand.Thus, we measured the time needed to complete the vehicle authentication.
Figure 9 shows the average authentication delay during vehicle-to-infrastructure communication in different infrastructure sizes with vehicle number variation from 20 to 200.We observe that the RSU needs an average of 26 ms to complete the identity check in a small or medium infrastructure.In the larger topology, which uses 16 RSUs, the checking time increases to reach an average of 28 ms.
These results prove that our proposal enables the RSU to quickly validate the vehicle identity, even with a high number of vehicles, because the verification process is performed on the SDN infrastructure.Competition between vehicles on the VANET will not affect this processing, resulting in reduced processing time and zero packet loss rate.
Case: Vehicle-to-Vehicle Communication: The second case of vehicle identity check is needed when a vehicle receives data from an unknown vehicle, so it is required to ask the infrastructure and validate the sender's identity before communicating with it.
Figure 10 illustrates the average authentication delay during vehicle-to-vehicle communication.We recorded an average of 27 ms with a small topology (one RSU).The delay increases to an average of 29 ms with the medium and large topologies.To verify an unknown node identity, the vehicle sends its request to the nearest RSU and waits for a response.The RSU forwards the request until it reaches the SDN basic controller, which will confirm the identity of the node and return the response.Apart from the vehicle launch request, almost all of the identity verification process is done on the SDN infrastructure.Thus, VANET has limited effects on the performance of the process, and the validation answers are given quickly.The study of the loss rate of individual packets during the authentication of unknown vehicles by other vehicles confirms the observation previously made with the study of delays (Figure : 11.The process has limited effects on network performance.A small topology with one RSU generates an average of a 4.5% individual packet loss rate with 20 vehicles in the network.This is the highest ratio recorded since the infrastructure uses a single RSU, and vehicles have to pass their verification requests to it, leading to increased competition on radio signal occupancy and the loss of packets.
With larger topologies, the individual packet loss ratio considerably decreases.Due to the presence of more RSUs in the network, checking requests will be distributed and competition on radio channel occupation will decrease.

3) COMPARISON WITH OTHER SOLUTIONS
In this section, we compare our proposal to other literature solutions: EAPP [31], TAAP [32], and LIAP [27].We focus the study on the following metrics: computational cost, communication cost, authentication delay, and packet loss ratio.

a: THE COMPUTATIONAL COST
This cost refers to the total computing time consumed during an identity check process.Solutions based on self-verification rely on cryptographic operations like signature control and  decryption with public keys.Those operations are complex and time-consuming.Our proposal uses a central unit, the SDN basic controller, to store all needed information and respond to all identity verification requests.All communication and data exchange will be encrypted and signed using RSA with 2048-bit keys.
We used the pairing-based cryptography library to evaluate the computational time of others' solutions.Table 2 resumes the values recorded for elementary computing functions.
We adopt the description made on [25] to estimate the computational cost of the different studied solutions and we present the results in table 3.
We see that our scheme presents a good cost compared with others.Due to a central check operation done by the SDN basic controller, the consumed computing time is acceptable.

b: THE COMMUNICATION COST
We use the active data bundle as a basic structure for all exchanges in the network.An AB involves three parts: metadata, data, and the VM.Table 4 presents an AB composition and the size of its elements.
Compared to other solutions (Table 5), we present a good communication cost.The size of the AB used in the identity check process is 377 bytes.

c: THE AVERAGE DELAY OF THE AUTHENTICATION PROCESS
The investigated solutions EAPP [31], TAAP [32], and LIAP [27] consider identity check operations during V2I communication with a single RSU.We compared the performance of our solution with them during the same process, and we added the verification during V2V exchanges.Figure 12 shows this comparison.Due to our central verification done by the SDN basic controller, our solution presents the lowest time required for the process.Furthermore, solutions like EAPP [31] and TAAP [32] present an important delay when the number of vehicles in the network increases, while our solution keeps an average delay of around 26 ms.

d: THE PACKET LOSS RATIO
The comparison of the packet loss ratio is given in Figure 13.Our solution shows a high ratio with a small number of vehicles (20).But when the number of vehicles increases, the individual packet loss ratio decreases considerably and our scheme surpasses the others.These results are explained by the fact that we limited the use of VANET communication to only the checking request launched by vehicles, and the rest of the verification process is done on the SDN infrastructure.All the other solutions rely on VANET to validate identities, which results in important packet loss ratios.

C. RESULTS DISCUSSION
Our performance evaluation shows that our proposal can work on different topology sizes.In a small topology with a single RSU, vehicles can quickly join the network in less 38120 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
than 28 ms despite the number of competitors.This average is maintained with larger infrastructures and a higher number of RSUs deployed.Moreover, we found that our proposal exhibits a low network bandwidth impact with a low packet loss rate.Thus, relying on the SDN infrastructure minimizes communication over the VANET radio, which leads to an acceptable loss rate.
The Comparison with literature solutions shows that our scheme maintains the lowest authentication delay and its performance is not affected by the growing number of vehicles.And for the packet loss ratio, our solution shows higher values than the other proposals with vehicle numbers under 100.This is because we used a single RSU to receive all car's communications which increases the radio collisions.Then the ratio decreases when the vehicle number increases and stays under 0.5% better than EAPP [31] and TAAP [32].

V. CONCLUSION
Vehicular Ad Hoc networks are promising communication infrastructure.ITS (Intelligent Transportation Systems) aims to profit from it to improve safety and to give a more interesting travel experience by deploying passenger-oriented applications.Therefore, different related challenges have to faced.Privacy preservation and vehicle authenticity is an emerging issue in this field.
In this paper, we presented ABAUS (Active Bundle AUthentication Solution based on SDN ) to deal with vehicle authentication and privacy preservation by using an AB mechanism as a self-protecting method for data exchange and by integrating the SDN architecture, which offered network scalability and a high level of authenticity.
Performance evaluations show that the proposed solution can authenticate vehicles with a low delay and a negligible overhead.Regardless of the network size, the authentication requests are redirected to the SDN basic controller to be processed, which minimizes the overhead in the VANET and accelerates the authentication process.Vehicles can join the network an average of 28 ms under different topology sizes.The resulting packet loss ratio was acceptable.With a single deployed RSU this ratio varies between 0.5% to 4.5% in the car authentication process and between 0.1% and 1.5% for the network Join process.Larger topologies show better results since they rely on more RSU units which reduces the collision probabilities leading to minimum losses.
In future work, we will study the impact of different attacks on the performance of our proposal.Our objective is to evaluate the robustness and the detection and eradication time necessary for the proposal.

FIGURE 2 .
FIGURE 2. The RSU-C network join process.

FIGURE 3 .
FIGURE 3. The RSU network join process.

FIGURE 7 .
FIGURE 7. Average authentication delay during network join phase with different infrastructure sizes.

FIGURE 8 .
FIGURE 8. Packet loss ratio during network join phase with different infrastructure sizes.

FIGURE 9 .
FIGURE 9. Average authentication delay for vehicle-to-infrastructure communication during data exchange phase with different infrastructure sizes.

FIGURE 10 .
FIGURE 10.Average authentication delay for vehicle-to-vehicle communication during data exchange phase with different infrastructure sizes.

FIGURE 11 .
FIGURE 11.Packet loss ratio during vehicle-to-vehicle communication with different infrastructure sizes.

TABLE 1 .
The simulation parameters.

TABLE 2 .
Execution time of element functions.

TABLE 3 .
Computational cost of different solutions.

TABLE 4 .
Composition and sizes of the used ADB.

TABLE
Communication cost of different solutions.