TCaS‐VN: A novel V2V communication scheme to improve traffic control and safety in vehicular cloud networks

Road accidents and traffic congestion are the unavoidable consequences of the growing number of vehicles on the road. Conventional management systems are not effective in mitigating these issues. However, a range of technologies, including sensors, processors, vehicle‐based resources, and mobile cloud computing, can help solve traffic and safety problems. Vehicular cloud networks, a cutting‐edge technology for the development of intelligent transportation systems, face significant challenges, such as ensuring reliable service providers that maintain stable connections between vehicles. Roadside units (RSUs) play a crucial role in these networks, but they come with several drawbacks, including high costs, imbalanced load distribution, and unreliable connections. To address these issues, we propose the Traffic Control and Safety in Vehicular Networks (TCaS‐VN) algorithm, a cloud‐based sharing services framework for vehicles that eliminates the need for RSUs. This approach offers several advantages, including a twofold improvement in the lifetime of clusters, the elimination of noncluster head nodes, a 54% reduction in overhead, a 58% reduction in service search time, and a success rate of over 95% in service provisioning.


| INTRODUCTION
According to a survey conducted by the World Health Organization (WHO), 1 road traffic accidents result in more than 1.35 million deaths and over 50 million injuries each year.These accidents are the leading cause of death for individuals aged 5 to 29, and are ranked as the eighth leading cause of global fatalities.The cost of traffic-related deaths also accounts for 3% of a country's gross domestic product.Moreover, the growing number of vehicles on the road leads to a number of other issues, including the consumption of large amounts of gasoline, increased levels of environmental pollutants, stress and health problems for drivers, and a higher rate of road accidents.
The traditional methods may not be satisfactory for reducing the growing fatalities and economic damages of traffic collisions.Thus, the necessity for more advanced techniques for providing road safety, such as Vehicular Ad hoc Networks (VANET),2 is being felt.Although applying VANET techniques increases road safety, they face many issues such as low Quality of Service (QoS), node movements, bandwidth limitations, and link disconnections, which are the main reasons forcing researchers toward better methods. 3,4The advancement of cloud computing technology, combined with the availability of numerous sensors, fast processors, and large-capacity memory storage in vehicles, offers a unique opportunity to provide on-demand services. 5ltoweissy et al 6 and Olariu et al 7 were among the first to explore the integration of vehicular networks with cloud computing.Since then, many studies, such as those conducted by Balouchzahi et al 8 and Jafari et al, 9 have been undertaken to find efficient methods for service delivery and discovery in vehicular cloud networks.These studies all rely on the use of road side units (RSUs).Although RSUs offer numerous benefits in vehicular networks, they suffer by severe issues.In certain scenarios, such as high-or low-density areas, it is difficult to ensure reliable end-to-end communication, which is a crucial element in the delivery of safety messages.In addition, the unequal distribution of vehicles causes load imbalance issues in RSUs, 10 which exacerbates network outages.Moreover, there are numerous circumstances in which RSUs are inaccessible (e.g., in rural or remote areas) or challenging to implement.Therefore, we need a trustworthy platform to transmit safety and emergency communications in the aforementioned scenarios.Utilizing the vast resources of vehicles is essential to developing such a platform.Meneguette et al. proposed the first method of service provisioning independent of RSUs.However, it faces numerous challenges, including a short cluster lifetime and a low rate of service success.Consequently, their method is ineffective for safety services.
This paper aims to create a highly stable vehicular cloud network without using RSUs to reach a high service success rate.We propose TCaS-VN framework: "Traffic Control and Safety in Vehicular Networks," which is based on a novel clustering method to form a stable network of vehicles for providing safety and traffic services.The contributions of this study are listed below: • Improving the stability of the network while reducing overhead to overcome poor connectivity issues.
• Improving the success rate of service provisioning for assuring the success of safety services as well as traffic management.
• Improving the functionality of the proposed method in any traffic conditions.
The TCaS-VN framework is expected to overcome the limitations of traditional vehicular networks and provide a reliable and efficient platform for future intelligent transportation systems.The proposed method is evaluated through simulations, and the results demonstrate that TCaS-VN can significantly improve the performance of vehicular cloud networks in terms of stability, efficiency, and service provisioning success rate compared with existing methods.
The remainder of this paper is organized as follows: Section 2 reviews related works in clustering methods as well as provisioning services in vehicular networks.The proposed framework and its challenges and solutions are introduced in Section 3. Performance evaluation of the proposed framework is discussed in Section 4. Finally, Section 5 concludes the paper.

| RELATED WORKS
Our proposed framework relies on two techniques: clustering and service provisioning.We discuss the existing clustering and the service provisioning methods in Sections 2.1 and 2.2, respectively.

| Clustering methods in vehicular networks
Rawashdeh and Mahmud 11 proposed a cluster formation method based on the similar characteristics of vehicles.According to their position, speed, and direction, all vehicles in the network are classified into stable and unstable groups.Stable neighbors are vehicles in close proximity (within a certain radius) whose average speed is greater than the threshold value.The vehicle with the slowest speed among the stable neighbors forms the first cluster.The vehicles with different speeds form a second cluster.In the proposed method, the cluster head will consist of a vehicle with a high number of stable neighbors, a close proximity to its stable neighbors, and a speed comparable with the average speed of its stable neighbors.
Loss of cluster head connection is one of the problems in the clustering methods.Bali and Singh proposed a method based on leadership nodes 12 to solve this issue and improve the stability of clusters.In this paper, the nodes with more connectivity degrees than the threshold value are selected as leadership nodes.Also, the authors suggested a variable, called aggregate relative velocity (ARV), which is based on the contention-based scheme. 13The vehicle with the lowest ARV value is selected as the cluster head.
Arkian et al, 14 with the use of V2I and V2V communications, offered a method for traffic information generalization in light traffic conditions.The authors suggested the Befit factor as the criterion for cluster selection.This criterion comprises three variables: the time it takes for a vehicle to leave the intersection (T leave ), the closeness of the vehicle speed to the average speed (ψ v ), and neighboring degree (D n ), which represents the number of neighbors with speeds lower than the threshold value.In this method, the vehicles with speeds less than the threshold value form a cluster.After cluster creation, each member is evaluated by its Befit factor values, and the vehicle with the highest value is chosen as the cluster head.After that, cluster heads send all the cluster's information, such as average speed, position, and number of members, to the roadside units.As the final step, a cloudlet is formed to make the road traffic information accessible.
Arkian et al. in another work 15 presented a method based on fuzzy clustering and Q-learning resource management.In this method, the cluster heads are selected based on fuzzy logic.Decision and service provider selection improved with the help of the Q-learning method.The authors also suggested a few ways to optimize resource allocation.The cloud platform used in the study has traditional architecture accessed through the internet.
Bhoi et al 16 proposed a routing method in vehicular cloud networks, called RVCloud.This study utilizes the traditional cloud platform to form the vehicular cloud network.The authors focused on solving the connection loss problem in the network by employing data transmission through the cloud platform.If a vehicle wants to send data to a nonneighbor vehicle, it sends it as a beacon to the nearest RSU.The two RSUs with the least distance from the destination vehicle are selected using cloud computing.Among these two, the RSU with the least sending delay is chosen to send data to the destination.The computational speed is high since all of the computations are carried out in the cloud platform.

| Resource allocation and search protocols in the vehicular cloud networks
Researchers develop numerous searching and allocating services methods for various services in vehicular networks.Location discovery service is the most important one in this domain.It consists of two architectures: hierarchical and flat.A brief review of these methods has been presented in the rest of this section.
In terms of hierarchical architecture, Ashok et al 17 proposed the EMBLS method, and Garg et al 18 proposed the HLMS method, which is an improved version of EMBLS.In both works, servers chosen based on the location and speed of the vehicles assist in providing the location discovery service.Depending on their level, these servers respond to a service request.For instance, in the first level of the EMBLS method, the intersection leaders (ILs) are chosen from the cars at busy intersections.Vehicles near busy intersections close to the city center are chosen as location servers (LSs) on the second level.Similar to EMBLS, the HLMS method employs a two-level map.However, there are four level one sections in each level two section.The nodes with the lowest velocity are chosen as the level one center's LS, and the remaining nodes (servers), referred to as RS, are chosen from the level two centers and congested intersection.The cars send their request to the closest IL or RL as the first step in the service provisioning process.The sender employs either the LSs or RSs if no response is received.In other words, the request is sent to LSs if the ILs are unable to locate the vehicle.The main concept behind these studies is to segment the map into various levels and sections in order to deliver the service with the least amount of data transmission.
The second category of service provisioning methods is flat architecture.The flat architecture method known as VQPLS was developed by Zaki et al. 19 This method reduces the rate of service failures through the use of quorum systems.Based on the position and speed of the vehicles at the intersections, the majority of eligible LSs are chosen.The main location server (MLS) is selected to be the node with the lowest speed among its neighbors and the lowest distance at its intersection.The so-called passing location service (PLS) of these servers then selects a few nodes to form a quorum.In the event that the primary servers fail, these nodes serve as backup servers.Also, these servers reduce the MLSs' overhead.
Balouchzahi et al. offered a method to overcome the problem of nodes with high mobility, improve the service success rate, and decrease the search time duration. 20To do so, they selected the best locations for RSU placement.After that, a peer-to-peer network is created that makes connections among RSUs.This framework provided an infrastructure for various safety services, traffic management, and entertainment, but it is limited to peer-to-peer networks.
The previous works in vehicular networks have primarily focused on finding methods for forming stable clusters, finding optimal locations for RSUs placement, and improving the service discovery rate using RSUs.However, these approaches that rely on RSUs face challenges in low-or high-density areas due to the difficulties in implementing and installing them, and they may not be secure in such areas.Our proposed algorithm, therefore, utilizes the resources of vehicles rather than RSUs to form stable clusters for provisioning traffic and safety services.This approach is different from previous works that focus on RSU-based algorithms.The closest existing effort to our proposed algorithm is the SERVitES approach, 21 which aims to improve the search and resource allocation process for V2V communication.However, the SERVitES approach has a low cluster lifetime and a low success rate of services, making it unsuitable for safety and traffic services, which require priority messages.As such, our proposed algorithm aims to provide an efficient service provisioning algorithm that addresses these issues by utilizing the resources of vehicles and overcoming the limitations of RSUs in low-density areas.

| TCAS-VN: THE PROPOSED SYSTEM
This paper proposes a novel method (TCaS-VN) that eliminates any external elements in the vehicular network infrastructure to provide highly stable clusters with a high success service rate.To do so, each vehicle should manage and share its resources with other vehicles.The architecture of TCaS-VN consists of two significant parts: network implementation and resource management.In Section 3.1, we offer a novel clustering algorithm and cluster head selection method to form a stable network of vehicles.In Section 3.2, a resource-efficient algorithm for service discovery and assignment is presented.

| Network implementation
In order to form a reliable network for allocating and sharing resources, a robust cluster head selection method is crucial.This method comprises three crucial elements, which are explained in Section 3.1.1.Furthermore, a novel clustering algorithm consisting of five steps (namely, entering the network; finding the neighbors, election, cluster formation; and joining a cluster) will be thoroughly discussed in Sections 3.1.2to 3.1.6.Before diving into the specifics, the necessary variables and assumptions will be outlined.
The nodes (vehicles) in this network are classified into three states, that is, ND (nondefined), CH (cluster head), and MV (member vehicle).A variable isCHhelper defines the vehicle that is a member of two or more clusters, facilitating communication between clusters and the members of clusters.The main variables of the proposed clustering method are presented in Table 1.
The first approach to increasing clusters' stability is to divide the map into equal cells.For example, a map with an area of 16 km 2 is divided into four cells, each of which is 4 km 2 .As a result, the coordinates of the cells are stated as and x ¼ 2-4 km, y ¼ 2-4 km.This arrangement prevents the formation of clusters where their members are far from each other, improving the network's stability.Table 1 presents the variables and their definitions.

| Proposed cluster head selection method
Cluster head (CH) selection is an important step in forming stable clusters.Among multiple criteria for choosing the best candidates for cluster heads, we propose a linear method consisting of the following criteria: • Average speed • The number of neighbors • The time of being in a cell One of the essential criteria in selecting a cluster head is the average speed of vehicles in the network.According to the references Rawashdeh and Mahmud 11 and Singh and Bali, 12 a vehicle is considered a CH candidate if its velocity is roughly equivalent to the average velocity of its adjacent vehicles.In previous methods, RSUs are responsible for deciding which vehicle is a better choice for acting as CH and aggregating vehicles' information in the network.Since there is no external unit such as RSU to aggregate data in our proposed scheme, we define a method for calculating the average speed.A common solution is for vehicles to periodically transmit their velocity to nearby vehicles.This, however, will result in network congestion.Consequently, our solution uses statistical analysis of vehicle speeds to determine the mean speed.
Vehicle velocity is represented by a probability distribution function (PDF).Schnabel 22 and Rudak 23 modeled the velocity of vehicles by using a normal distribution function with the average μ and variance of σ 2 .The probability density function (pdf) and PDF are defined as below: Through numerical calculations, Rudak et al, 23 reported the statistical measurement of vehicle velocities, shown in Table 2.They also proved that Pðv ≤ μ þ σÞ ¼ 84:13% and Pðv ≤ μ À σÞ ¼ 15:87%.In other words, approximately 15% of the vehicles deviate more downward or above from the average speed.Therefore, vehicles with speeds between μ AE σ in each speed limit can be a suitable selection for CHs.The average speeds in Table 2 are appropriate choices for speedThreshold, which is used to calculate speedFactor.speedFactor is the speed criterion in our method, used for choosing the best cluster head.CalculateSpeedFactor, formulated in Equation ( 3), is a reward and punishment function for calculating speedFactor.A vehicle will be rewarded if its speed is roughly equivalent to the average speed of vehicles in the network (with a 20% offset value); it will be penalized if its velocity falls outside the range specified.In other words, if a vehicle moves with the average speed of the vehicles in the network, it can be a better option for acting as a cluster head.
The second term of our proposed method is cellTime.The longer a vehicle stays in a cell, the more qualified it is to be a cluster head.Therefore, the time duration for each vehicle stays in a cell (called cellTime vj ) is defined in Equation ( 4).
Another critical factor in the cluster head selection is the number of adjacent vehicles moving in the same direction.A vehicle with more neighbors is a better candidate to serve as a cluster head because it is able to communicate with more vehicles.A vehicle determines the number of its neighbors through the exchange of numerous packets with adjacent vehicles.We define a variable N SDV to indicate the number of vehicles moving in the same direction.This variable is calculated by two functions: CalculatePS (specifying the mutual paths between vehicles) and CalculateNSDV (measuring N SDV with the help of the angle and direction of vehicles).The implementation of these two functions took into account the avoidance of additional overhead.
Each of the mentioned criteria can individually assess the qualification of a vehicle to be a cluster head.However, clusters formed with only one of these characteristics are insufficiently stable.For example, a fast-moving vehicle with many same-directional neighbors is not a good candidate for cluster head because it leaves the cell in a short amount of time, thereby causing the cluster to lose its cluster head in a short amount of time.Accordingly, a more comprehensive criterion is required to accommodate these aspects.To do so, we defined the cluster head selection factor (CSF) in Equation ( 5) as a linear combination of all three criteria.
The impact of criteria is controlled by their weighted coefficients under the condition that As a result, a vehicle with the most CSF will be an ideal cluster head.

| The first stage: Entering the network
In the beginning, all vehicles are in the ND state, that is, none of them are members of a cluster.Consequently, each vehicle willing to join a cluster should send a WSM message with the title of HelloMSG.The content of this message is as follows: < ID, CSF > ID represents the identification of a vehicle (node) and CSF contains the CSF of the sender.Any vehicle in the same cell, regardless of its state, will receive this message.After receiving HelloMSG, the vehicle responds to the message with respect to its state.If the vehicle's state is ND, it compares the message's CSF value with its CSF value.If its CSF value is greater than HelloMSG, the receiver identifies itself as a possible cluster head candidate.Thus, it sends the CH_CandidateMSG message, which consists of the following information: < ID, state, CSF > However, if the receiver's CSF value is lower than the sender's value or the receiver is already a member of a cluster (its state is CH or MV), it sends a HelloResponseMSG including the following information: < ID,state, CSF, ID_CH > state is the state of the sender, and ID_CH is the identification of the cluster head (note that if a sender has no cluster head, its value will be null).The flowchart is presented in Figure 1.

| The second stage: Finding the neighbors
Each vehicle sending the HelloMSG message waits a certain amount of time for a response.This response time is equal to TTF Â TransmissionTime.If no response is received during this time, that is, its state remains ND, it declares itself as a cluster head and forms a cluster by sending the CH_selectionMSG message.
If a vehicle receives a HelloResponseMSG, it checks the state of the sender first.If the sender's state is ND, the receiver compares the CSF values.If its value is greater than the response message, it declares itself as a cluster head candidate by sending the CH_ CandidateMSG message.Otherwise, it becomes MV and waits for the CH_SelectionMSG message to join a cluster.The final scenario happens when the sender's state is MV or CH.In that case, the receiver joins the cluster by sending a JoinMSG message to the corresponding ID_CH only if the joining conditions are satisfied.
There are a few issues that may be overlooked at first sight.One is that the sender's state may be changed during the response waiting time.In other words, the sender's state has changed to MV but still has no cluster head.Our solution to this issue is that the sender waits for a certain amount of time.By that time, the sender begins to form its own cluster if a cluster head has not yet been located.If a vehicle receives a response message from a MV node with no cluster head, this poses a problem because it makes the responded JoinMSG message impractical and increases overhead.However, our proposed algorithm avoids this issue because the cluster head's ID is verified before the JoinMSG message is sent.The flowchart of this procedure is illustrated in Figure 2.

| The third stage: Election
The cluster head candidates send the CH_CandidateMSG message in order to participate in the cluster head election.Every other ND node present in the same cell receives this message.Their CSF values will be compared, and if one considers itself the winner (higher value), it will declare itself a proper cluster head by sending the CH_SelectionMSG message with the following information: < ID, ID_CH, CSF > Otherwise, the receiver's state changes to MV and waits for a cluster to join.Similar to stage two, the formation of MV nodes with no cluster head is possible; therefore, a timer is required.Each vehicle waits for a certain amount of time after CH_CandidateMSG message is sent.If no CH_SelectionMSG message is received, the sender becomes the cluster head and forms a cluster by sending CH_SelectionMSG messages.The flowchart of this stage is presented in Figure 3. we define a message called relayMSG and a variable for limiting cluster hops called hop th ).If it exceeds the hop th value, the receiver ignores the message and forms a cluster on its own.Conversely, the CSF comparison procedure is executed if the value is below the threshold.If it is lower than the sender's value, the receiver sends the JoinMSG message to the selected cluster head.This message contains the following information: < ID, CSF > However, if the CSF value is higher than the sender's CSF, the sender is not qualified to be a cluster head, and the receiver waits for another message.It is noteworthy to mention that this approach prevents the possible repetitive change of cluster that may occur in stage 5.The flowchart of this stage is presented in Figure 4.
To facilitate resource sharing among vehicles and better communication, we define the variable CHhelpers for helping cluster heads.In this stage, more than one CH_SelectionMSG message may be received from different nodes.Some of them are assigned as CHhelpers (isCHhelper becomes true) so that they can assist the cluster heads with the tasks of resource allocation or searching.

| The fifth stage: Joining a cluster
Vehicles send a JoinMSG message if they want to join a chosen cluster head.The cluster head checks the senders' CSF values.If the received CSF values are lower than its value, it accepts them as cluster members.After that, the accepted vehicles send the beaconMSG to their cluster head periodically.This message includes the following information: < ID, ID_CH, state, isCHhelper, RES, resAccess > This information includes the sender's ID, its state, its CHhelper condition (whether or not a CHhelper), available resources, and resource accessibility condition.
However, if any of the received messages have a higher CSF than the current cluster head, it suggests that this new member is more qualified than the present cluster head.On this occasion, other members of the cluster are notified of the new cluster head via the WarningMSG message.By doing so, clustering instability will be avoided.The WarningMSG message consists of the following information: < ID_CH_NEW, ID_CH_OLD > Every member of the cluster saves the information of the new cluster head after the WarningMSG is received and shares their information with the new cluster head by sending the BeaconMSG message.Also, the cluster information should be transferred to the new cluster head.This task is done through the ReorganizingMSG message, which has the following format: < memberNumber,memberID > The first element represents the number of cluster members, and the second one contains the IDs of the cluster members.After the ReorganizingMSG is received, the new cluster head updates its member list and the information of the cluster with beacon messages.This procedure is illustrated in Figure 5.

| Resource management
After forming stable clusters, members of each cluster can communicate with their own members or members of other clusters.Therefore, the next step is developing a method that efficiently allocates resources.Accordingly, an algorithm is needed to manage members' resources and allocate the required services.In this section, we propose a resourceefficient algorithm based on exchanging messages between the requester and provider.
Resources in the vehicular clouds are classified into three groups: computational, network, and storage.Each of them attains one of the following four states: • Free: Unutilized resources are referred to as free.
• Searching: If a vehicle searches for specific resources, it will remain in the searching state until the requested resources are found.• Busy: If a vehicle is supposed to allocate its resources, it will remain busy until the service provisioning procedure begins or fails.• Allocation: As soon as the resource allocation procedure begins, both resource-using and resource-providing vehicles enter the allocation state.
The variables of this algorithm are presented in Table 3.
The time required to provide a service varies between services.Therefore, the ServiceDurationFunction function is defined so that the algorithm is simulated with more accuracy.This function assigns the correct duration of time to each service.The proposed service provisioning method consists of three steps, shown in Figure 6.
According to Figure 6, each vehicle that needs a resource sends its request as a ReqMSG message with the following information: < ID, ID_REQ, RES, resAccess > This message contains the identification of a vehicle (node) the requested vehicle's ID, required resources, and the accessibility of the resources.In the beginning, the vehicle sends this message to its cluster members.The CHhelpers react to this request by searching for the required resources.If the CHhelpers find any node (among the connected members) with the required resources, they save the node's ID.This node will help the requestor when it cannot find other nodes to provide its required resources.On the other hand, if any member can provide the requested resources, send a ReqResponseMSG message.Then it changes its state to "busy" to prevent other vehicles from accessing its resources.The message contains the following information: < ID, ID_REQ, resAccess > The requestor waits a specified amount of time for a ReqResponseMSG after sending the request.During this time, if the ReqResponseMSG is received, the requestor responds with resReadyMSG message to notify the provider that the procedure has begun.The provider changes its state to "allocation" and begins service provisioning.The Ser-viceDurationFunction function has previously calculated the duration of this procedure.At the end of the procedure, both vehicles set their resources to the "free" state, allowing any other vehicle to request their use.There are a few conditions at this stage that should be pointed out.If the requestor does not receive the ReqResponseMSG message after a predetermined amount of time, it attempts to obtain assistance from its CHhelper or cluster head.Another possible scenario happens when no vehicle in its cluster can provide the resources.In this case, CHhelpers and the cluster head help the requestor by sending its request message to other clusters.
In order to clarify the above procedure, the flowchart is presented in Figure 7.

| TCaS-VN challenges and solutions
One of the most significant challenges in vehicular cloud networks is the high mobility of nodes and ever-changing topology.In order to overcome this challenge, we used three techniques as follows: • Dividing map into equal cells to better control each cell and its vehicles.
• Selecting the most stable cluster heads for each cluster by proposing a novel cluster method.
• Employing timers to control nodes that lose their clusters or do not join a cluster.
In addition to the above solutions, at the end of each stage in Sections 3.1.2-3.1.6,we discussed the common issues and our solutions.We overcome the mentioned challenges by forming stable clusters using the proposed clustering algorithm.As previously stated, the initial stage of forming a cluster involves choosing an ideal cluster head that remains in a cell for a sufficient duration with a higher number of neighbors and moves at a speed close to the average rate.This forms the basis for establishing a reliable cluster.Additionally, timers are utilized to ensure that each node becomes a part of a cluster.Implementing these techniques can lead to the formation of stable clusters with minimal changes in the cluster head.This can effectively address issues related to unreliable end-to-end connections, poor service availability, and network failures.
Maintaining a cluster after its formation is of great importance, since it may become unstable after its formation due to many reasons.These reasons and our solutions are listed below: 1. Leaving the cluster: Leaving the cluster may happen under two circumstances.Either a vehicle leaves its cluster or loses connection with the cluster head.Under both of these conditions, the vehicle can search for a new cluster by sending the HelloMSG message.Moreover, the cluster head will be informed of this disconnection since no BeaconMSG is received.2. Cluster head change: Cluster head changes happen when more qualified members are found.If cluster heads are not assigned properly at the first step, the possibility of these changes will increase, leading to overhead and network instability.By using WarningMSG and ReorganizingMSG messages and creating stable clusters at the first step using our proposed cluster head selection method, we create stable clusters that do not require changing their cluster heads.3. Clusters interference: Cluster head interference happens when two cluster heads are in the vicinity of each other and may cause instability.In this situation, the node with higher CSF will become the cluster head, and the other node functions as a CHhelper.
In order to improve the success rate of services and availability of resources, which is crucial for exchanging safety messages, we introduce a variable called CHhelpers, which assists cluster heads.This will facilitate communication and enable more efficient sharing of resources among vehicles.
Last but not the least, congestion and the high loss rate of packets are inevitable outcomes of creating clusters because vehicles exchange many packets to form clusters.Therefore, we define a criterion including all congestion-related factors (in both the MAC and application layers) to defeat it.This criterion is utilized in the algorithm's implementation.Inspired by, 11 transmission time factor (TTF) is identified as follows: In Equation ( 6), CW min and CW max are the minimum and maximum values of the contention window size in the IEEE 802.11p standard, respectively.hop th is the upper threshold for the maximum steps of a message, and u is a factor that takes account of a vehicle's position and speed.In Equation (7), θ is a coefficient between 0 and 1, P norm and V norm are the normalized values of the vehicle's position and velocity, respectively, as Equation ( 8) shows.
where P mid is the map center and μ in Equation ( 8) is the average velocity of the vehicles with respect to the maximum allowable velocity.

| PERFORMANCE EVALUATION
In this section, the simulation procedure will be introduced in Section 4.1, and the results will be analyzed in Section 4.2, the final discussion regarding the efficiency of TCaS-VN will be presented in Section 4.3.

| Simulation setup
We emulated the proposed framework on a machine with a 2.6 GHz Intel Core i7 CPU with 4 cores and 16 GB of RAM using OMNET++ network simulator version 5, 24 SUMO traffic simulator version 0.25.0, 25 and VEINS network framework version 4.4. 26In order to validate the proposed method in a real-world condition, a city traffic scenario with intersections and other traffic limitations is generated by SUMO.In other cases, such as highways and freeways, vehicles move in a constant pattern; therefore, the algorithm does not face any particular challenges.In addition to considering vehicle density and distribution, the simulation is conducted in two different traffic conditions, that is, heavy and light, to assess the algorithm's functionality in different situations.The studied map is extracted from the OpenStreetMap website. 27s shown in Figure 8, a part of Tehran's downtown near the Amirkabir University of Technology is selected for simulation.This map has an approximate area of 9 km 2 .
Every vehicle has up to three types of shareable resources, any of which are allocated to the requestor.The time duration of services is different, which varies between 5 and 50 s.Also, the request generation rate is set to 30 requests/s.
In this simulation, the MAC layer's data transmission rate is 18 Mbps, and the data transmission power is 2.2 mW.The two-ray ground propagation model 28 is used.Thus, the data transmission range is 300 m.Other parameters are shown in Table 4.
For increasing the accuracy of analysis, speed limits are considered for vehicles.The limits are 5, 10, 15, 20, 25, and 30 m/s (18 to 108 km/h).The number of vehicles is selected according to the size of the map so that the simulation will be conducted under low and heavy traffic conditions.Also, for more accurate simulations, the simulation is repeated with different seeds and a confidence level of 95% for each case.
The evaluation metrics are classified into two groups: clustering and service provisioning.
• Clustering metrics 1.Average cluster head duration: the average amount of time a node spends in cluster head (CH) state.2. Average cluster member duration: the average time a node remains a member.

| Result evaluation
We compare the performance of TCaS-VN with the SERVitES method 21 ; to the best of our knowledge, it is the only algorithm that has similar conditions (not using RSUs).To demonstrate that TCaS-VN outperforms RSU-based algorithms, we compared it with ARV, 12 which creates clusters using stringent criteria.In terms of service provisioning, HLMS, 17 a well-known service discovery algorithm employing RSUs, is used for service provisioning.We compared the algorithms under two distinct traffic conditions, that is, low and high, with different speed limits and vehicle distributions.In each scenario, we evaluate the performance of clustering and service provisioning.

| Low traffic scenario
In the light traffic condition, as shown in Figure 9A, the average time it takes for a node to remain as a cluster head decreases with the increase in vehicle speed, since the faster a vehicle moves, the less time it remains in the cluster.
Compared with the SERVitES method, the TCaS-VN improves this metric by almost two times due to the rapid initial cluster formation and the improved cluster head selection mechanism.Figure 9B shows the average MV duration, indicating that members' life of a cluster reduces with the increase in vehicle speed.Compared with the SERVitES method, this criterion is improved by 59.59%.According to Figure 9A,B, TCaS-VN forms more stable clusters and vehicles remain longer in their clusters than the ARV algorithm, which is based on RSUs.Consequently, disconnections, which usually happen in vehicular networks with RSUs, will decrease significantly.As a result, traffic and safety messages transfer to a more stable network in less time.It is worth mentioning that the first cluster in TCaS-VN is created in less than 0.3 s, which is 62% better than the SERVitES algorithm.Also, the average time for creating a cluster is about 1.217 ms.Increasing the average number of clusters, which is illustrated in Figure 9C, is factor contributing to this enhancement.
The increased number of clusters may cause issues only if the cluster head change rate is high.According to Figure 9D, this rate is less than 0.33 nodes in TCaS-VN, whereas it is 5.88 nodes in SERVitES, which has significantly fewer clusters.As a result, due to low cluster head change, our algorithm works properly.Also, both non-RSU-based algorithms outperform ARV, which shows that creating stable clusters without using RSUs leads to longer clusters.
The number of nodes without clusters must be as small as possible in order to guarantee that a network can fulfill all requests for safety services.In TCaS-VN, the average number of nodes without clusters is 1.77, whereas this rate is 35.95% and 51.54% higher in SERVitES and ARV, respectively.
Since there is no RSU available, the vehicles must handle the network load.Consequently, a noticeable increase in the number of packet exchanges may be expected.However, according to Figure 9F, this number has significantly decreased.The results show that regarding all messages (excluding beacons), TCaS-VN has a 54.39% and 57.16% improvement compared with SERVitES and ARV, indicating that the proposed clustering algorithm improves cluster stability with less overhead.Using the technique of CHhelpers determination and the proper use of HelloMSG messages are the reasons for such an improvement.
The rest of this section is devoted to the evaluation of service provisioning.The first criterion is the time required to find the requested service's resources.According to Figure 10A, the searching time is reduced by 32% and 58.77% compared with SERVitES and HLMS methods, respectively.This improvement is achieved due to better utilization of the control nodes, that is, the cluster heads and CHhelpers.
In order to use TCaS-VN for safety applications, all safety services must be satisfied.According to Figure 10B, the service success rate of the SERVitES method is 34.95%, indicating that more than 65% of requests fail.This rate for the HLMS method is even worse, 32.36%.However, the average rate of TCaS-VN is 95.36%, indicating that most of the requests are satisfied with a shorter waiting time.
A comparison concerning overhead was conducted, and the results are shown in Figure 10C.In some iterations of the SERVitES algorithm, the number of sent packets for some nodes is abnormally high, which shows that the SER-VitES method has remarkable deficiencies in particular cases.Therefore, these data have been eliminated for better comparison.Also, the different number of requests and clusters in each run affects the number of packets.Therefore, the higher number of packets in service provisioning in TCaS-VN is justified by a lower waiting time and 95.36% service success rate.Furthermore, our method reduces average total overhead by 16%.Finally, it should be mentioned that the rate of resource availability is greater than 90% in all algorithms.

| High traffic scenario
All previous simulations were conducted under a heavy traffic scenario to push our framework under a more complex and challenging network.The results are reported in Figures 11 and 12.
Compared with low traffic conditions, as expected, the average MV and CH times decreased due to the increased number of clusters and vehicles.This reduction for CH duration is on average 17.73% in TCaS-VN, 32.31% in SERVitES algorithm, and 30.33% in ARV, suggesting that our method works better under high traffic conditions.In addition, the number of cluster heads increases as the number of nodes increases.More importantly, TCaS-VN reduces the cluster head changes to nearly zero and decreases the number of cluster-less nodes significantly.The TCaS-VN has the smallest increase in packet overhead during cluster creation.These results reveal that TCaS-VN can create stable clusters in more complicated networks, that is, in high-density conditions.
In terms of service provisioning, Figure 12 demonstrates that the searching time has slightly increased by 0.3% compared with low traffic conditions, while this rate is approximately 6% for the SERVitES and HLMS methods.The high success rate (92.62%) is maintained in TCaS-VN, while this rate is reduced by 20.65% in the SERVitES and 20.32% in HLMS.The TCaS-VN maintains its superiority with a 19.94% increase in overhead, while for the SERVitES and HLMS methods, it reaches up to 351.01% and 109% increment, respectively.The results demonstrate that TCaS-VN can exchange safety and traffic messages with a 92% success rate.

| Discussion
In this section, we conducted various experiments to evaluate the TCaS-VN framework for delivering safety and traffic services in vehicular networks.In order to evaluate the performance of our algorithm, we compared it with RSU-based and non-RSU-based algorithms.Creating stable clusters is the first and foremost element of provisioning any services in a vehicular network.Thus, we assessed the cluster head and member duration.The results show that in both scenarios (low-density and high-density), TCaS-VN outperforms the previous methods and creates clusters with more than 3 min of lifetime, enough time to exchange multiple messages (sending in ms).The cluster loses its stability when it loses many members or changes its cluster heads regularly.The results reveal that more than 98% of vehicles in TCaS-VN do not change their states, demonstrating the stability of clusters.However, the increasing number of clusters in TCaS-VN compared to SERVitES and ARV suggests that our algorithm creates clusters with fewer members, which may reduce the service success rate.However, the average success rate of 93% demonstrates that the service success rate does not decrease.The number of nodes without clusters is important for provisioning services for all vehicles.This rate for our algorithms is, on average, 1.77 nodes, which is a remarkable rate for regular services.However, this is a disadvantage for safety services, as all vehicles should be able to exchange messages and access the resources they require.In other words, this rate ought to approach zero.
In addition to cluster stability, cluster creation time is crucial for the exchange of safety and traffic messages.This time in TCaS-VN is less than 1.2 ms on average, which is a proper time.Finding a vehicle to provide service for a requested vehicle should be as low as possible.This number in TCaS-VN is on average less than 3.68 ms; besides, the high success rate, 93.5%, proves the practicability of creating clusters in service provisioning, especially safety and traffic services.Since our algorithm is based on exchanging messages, it increases the overall overhead; however, no congestion or service failure is reported.
All evaluation results reveal the superiority of TCaS-VN over SERVitES, ARV, and HLMS.TCaS-VN, like the SER-VitES method, outperformed conventional RSU-based methods, such as ARV, 20 APPROVE, 29 and TB. 11As a result, the experiments verify the efficiency of TCaS-VN in providing services, especially traffic and safety in vehicular networks.Future research will focus on enhancing the success rate, particularly for priority vehicles, reducing the proportion of nodes without clusters to zero, and implementing the algorithm in real-world scenarios.

| CONCLUSION
This paper presents the TCaS-VN method, which is a resource-sharing approach for vehicular networks.The method aims to provide safety and traffic services with minimal delay and high packet delivery ratio, without using roadside units.This technique can help manage traffic and decrease the likelihood of traffic-related injuries.The proposed method involves a clustering algorithm that selects cluster heads based on factors like duration of staying in a cluster, average speed, and number of nearby vehicles.Additionally, an algorithm is used to exchange, find, and allocate resources within clusters.The simulation results demonstrate that the proposed method significantly improves cluster lifetime and stability (by reducing cluster head changes), service provisioning, reduces overhead, and lost packets in the MAC layer.With a 58% improvement in service searching time and a 95% success rate, the TCaS-VN method proves to be superior to previous methods and effective in controlling traffic and safety messages.Therefore, this paper concludes that the TCaS-VN method is a viable option for providing safety and traffic services in vehicular networks.

1
The first stage of Traffic Control and Safety in Vehicular Networks (TCaS-VN) clustering algorithm.HEDAYATI MAJDABADI ET AL.

3. 1 . 5 |
The fourth stage: Cluster formation In this stage, ND or MV vehicles are waiting for a CH_SelctionMSG message to form a stable cluster.After receiving a message, either MV or ND compares the number of hops between itself and the sender (for creating multi-hop clusters, F I G U R E 2 The second stage of Traffic Control and Safety in Vehicular Networks (TCaS-VN) clustering algorithm.

F
I G U R E 3 The third stage of Traffic Control and Safety in Vehicular Networks (TCaS-VN) clustering algorithm.

F I G U R E 4
The fourth stage of Traffic Control and Safety in Vehicular Networks (TCaS-VN) clustering algorithm.

F
Abbreviation: TCaS-VN, Traffic Control and Safety in Vehicular Networks.

F I G U R E 7
The service provisioning algorithm of Traffic Control and Safety in Vehicular Networks (TCaS-VN).

F
I G R E 9 (A-F) Clustering metrics results (low traffic condition).

F
I U R E 1 0 (A-C) Service provisioning metrics results (low traffic condition).F I G U R E 1 1 (A-G) Clustering metrics results (high vs. low traffic condition).HEDAYATI MAJDABADI ET AL.

F
I G U R E 1 2 (A-C) Service provisioning metrics results (high vs. low traffic condition).

1
Main variables of the TCaS-VN clustering algorithm.
Abbreviation: TCaS-VN, Traffic Control and Safety in Vehicular Networks.HEDAYATI MAJDABADI ET AL.