- Research Article
- Open Access
A Cooperative Congestion Control Approach within VANETs: Formal Verification and Performance Evaluation
© M. S. Bouassida and M. Shawky. 2010
- Received: 1 June 2009
- Accepted: 15 December 2009
- Published: 8 February 2010
The main objective of congestion control is to best exploit the available network resources while preventing sustained overloads of network nodes and links. Appropriate congestion control mechanisms are essential to provide effcient operation of a network. Ensuring congestion control within vehicular ad hoc networks faces special challenges, due to the specificities of such environment (High mobility of nodes, high rate of topology changes, high variability in nodes density and neighborhood configuration, broadcast/geocast communication nature, etc.). In this context, we present in this paper a cooperative and fully distributed congestion control approach, based on dynamic scheduling and transmission of priority-based messages, to ensure reliable and safe communication architecture within VANET. Messages priorities are dynamically evaluated according to their types, the network context, and the neighboring nodes configuration. Considering the context of high reliability and real-time response required for intervehicular communications (including emergency breaking notification for example), we propose a complete validation method of our congestion control algorithms, taking into account reliability, temporal, and operational aspects.
- Congestion Control
- Neighborhood Context
- Service Channel
- Congestion Control Mechanism
- Safety Message
To present our contributions, this paper is structured as follows. In Section 2, we present related work concerning congestion control approaches within MANETs. Section 3 presents our cooperative congestion control approach. The real applicability of our approach is validated through formal verification, simulations and performance evaluations, that we present in Section 4. Finally, Section 5 concludes this paper, presenting the implementation of our congestion control scheme in the context of the European Integrated Project SAFESPOT (http://www.safespot-eu.org/), and details our future work concerning the real tests methodology we envisage to validate this implementation.
Congestion control is a challenging subject in mobile ad hoc networks, mainly because of the shared nature of the wireless multihop channel and the frequent changes of the network topology. Indeed, routes changes due to dynamic and mobility of nodes result in unsteady packet delivery delays and packet losses, which should not be considered as congestion control faults. In addition, the use of a shared multihop channel allows only one data transmission at a time within the interference range of a node. Thus, congestion in ad hoc networks affects a whole area and not only overloaded nodes . During the last years, several congestion control approaches have been presented, dedicated to operate within ad hoc networks. In this section, we cannot claim to present an exhaustive study of these approaches. However, we distinguish two congestion control techniques for wireless networks: end-to-end and hop-by-hop families. End-to-end protocols aim to ensure flows fluidity between senders and receivers, without worrying about the internal relay nodes, whereas hop-by-hop congestion control methods take into consideration the capacities of the internal links. We present hereafter some protocols belonging to these two approaches.
2.1. End-to-End Congestion Control Approaches within MANETs
The TCP-F (TCP-Feedback) approach, proposed by Chandran et al. , consists of disabling the TCP congestion mechanisms in case of network-induced, non-congestion related, losses and time-out events. Each sender is notified when routing failure or route change occur, to freeze its TCP state values (timers and window sizes).
In the proposal of Rath et al. , an end-to-end congestion control technique is presented, carried out by TCP and physical layers. The adaptive windows based congestion control mechanism used by TCP for wired network may not be appropriate for wireless network. This is due to the time varying nature of a wireless channel and interference from other nodes causing packets loss, which is different from packets loss due to congestion. But TCP's congestion control mechanism does not distinguish between packets loss due to congestion and that due to bad channel or interferences; it rather applies the same congestion control mechanism for both. For this reason, within the proposed cross layer approach, the MAC layer changes transmission power as per the channel condition and interference received from the neighboring nodes, whereas the TCP layer controls congestion using Reno-2 windowing flow control.
The protocol presented in  updates the flow control model for a TCP-like method and extends it to the context of wireless network. It proposes two new congestion control schemes. The first one employs a static algorithm while the second applies a dynamic one. Both algorithms modify the number of connections that a single user has with the network and thus provide an appropriate number of connections, opened at the application layer by a sender.
2.2. Hop-by-Hop Congestion Control Approaches within MANETs
The authors in  show that congestion control techniques intended to operate within wired networks are not suitable for wireless environment, and that a cross layer hop-by-hop redesign is needed to consider the nature of wireless communications. Indeed, with TCP, a flow can only obtain congestion feedback from every directed link along its path. However, nearby links not directly on the path can interfere with this flow because the fundamental difference between wireless and wired environment is that wireless communications are of a broadcast nature.
In the same point of view, Yi et al. argue in  that hop-by-hop schemes are feasible over a wireless network. Such techniques provide feedback about the congestion state at a node to the hop preceding it. This preceding node then adapts its transmission rate according to this feedback. Feedback is typically provided according to the queue length at the congested node. If the queue length exceeds a threshold, congestion is indicated and the preceding node is notified in order to decrease its transmission rate. Consequently, hop-by-hop schemes require to have per-flow state management for intermediate nodes, which induces scalability problems. However, in a wireless network, the number of flows per node is of much smaller order than in the Internet. Further, wireless networks usually have per-flow queuing because of packet scheduling, and the fact that different users are at different locations, thus requiring different physical layer strategies (such as the channel coding and modulation of the power level). The congestion control proposed in this paper is thus based on a hop-by-hop approach, which is shown to converge in the absence of delay and allocates bandwidth to various users in a proportionally-fair manner. The proposed hop-by-hop algorithm is established according to the queue length and the feedback delays. However, the utility and validity of the sent data are not considered within this technique, hence it is not adapted to the specific context of vehicular ad hoc highest transmission priority.
Another congestion avoidance protocol, named C3TCP , is also founded on link capacity measurements and adjustment of the outgoing data rate according to these measurements, at each sender node side. This solution requires the introduction of an additional module within the IEEE 802.11 protocol stack in order to carry out the capacity measurements. The same principle was used by Rangwala et al. in  to establish a congestion control scheme for static wireless mesh networks: a distributed rate controller estimates the available capacity within each neighborhood and divides it to contending flows.
Zhang et al.  investigate congestion control problems in multihop wireless networks, with time varying link capacities. By modeling time variations of capacities as perturbations of a constant link, the authors propose a primal-dual congestion control algorithm and prove its trajectory stability without feedback delays consideration. However, in the presence of delay, they define theoretical conditions for the technique to be locally stable. Both proposals presented in  and  are derived from the studies carried out by Kelly et al. . In the context of vehicular ad hoc networks, the same authors (Zang et al.) present in  a congestion control approach for safety applications. The basic idea of this scheme is to identify congestions using event-driven detection and measurement, and to manipulate MAC transmission queues for IEEE 802.11p, in order to ensure the safety messages sent on the control channel. The event-driven congestion detection is triggered reactively whenever a high priority safety message is recognized to guarantee the QoS of the safety applications, while the measurement based congestion detection consists of measuring the channel usage and comparing it with a defined threshold. However, the effective transmission of the safety messages is not guaranteed because the neighborhood context and the effective bandwidth sharing are not considered.
The congestion control approach proposed in , dedicated to operate within vehicular ad hoc networks, consists of adapting transmissions to the available bandwidth in a hop-by-hop manner. Thus, nodes transmitting information with a high utility for VANET will be allowed to consume a larger share of the available bandwidth. A priority is evaluated for each packet, depending on its utility and size. Then, an instantaneous data rate is determined, according to the computed priority. The utility of messages is evaluated at the application layer and do not consider the neighborhood context in terms of density and dynamics of nodes. In addition, this approach generates a communication overhead, due to the context exchange between neighbor nodes in order to share the available bandwidth between them, without considering the capacity and the congestion state of the forwarder nodes.
Torrent-Moreno et al. present in  a fair bandwidth sharing approach for VANETs. This approach consists of limiting the wireless load resulting from the periodic messages, by requiring a strict fairness among the vehicles. The authors assume a constant packet generation rate, and propose a centralized power control algorithm that provides the optimum transmission range of every node. This proposal was formally validated. However, simulations have been carried out under idealistic conditions, assuming that interferences between nodes transmissions follow a deterministic model. Moreover, the proposed algorithm requires synchronization between vehicles, which generates communication overhead.
In order to define a congestion control approach within vehicular ad hoc networks, several constraints should be considered, related to the characteristics of the environment and also to high quality of service (QoS) required for the safety-oriented data. On one hand, as argued in , end-to-end congestion control approaches are not suitable for wireless ad hoc networks. Indeed, within these approaches, relay nodes context are not considered, and thus, interferences, collisions and transmission problems are neglected. However, the required quality of service of a transmission can be defined by the sender.
On the other hand, hop-by-hop approaches suffer from lack of scalability, when the number of transmitted flows increases within the network. However, it is known that the size of the transmitted data within VANET is small, due to the dynamic nature of this environment, and to the nodes limitations in terms of storage and computation capacities. It is thus admitted that hop-by-hop congestion control approaches are more suitable for VANET, while considering the required quality of service of the transmitted data, as for the end-to-end approaches. Hop-by-hop congestion control approaches, described above, present some disadvantages (communication and computation overheads, reactive congestion control techniques, idealistic verification frameworks, etc.). In addition, several parameters are not completely considered within these protocols, such as the velocity of the sender node, the appropriate choice of the next forwarders, the validity and the utility of the sent messages according to the neighborhood context and the required QoS.
Cooperative and adaptive congestion control approach: approach dynamically adaptable to the neighborhood and the context of VANET, while taking into consideration the required QoS metrics (in terms of reliability and delays) especially for emergency and safety messages.
Hop-by-hop approach: to deal with the capacity of relay/forwarders nodes and in order to efficiently share the effective bandwidth between neighbors nodes, while considering the required quality of service as for the end-to-end congestion control approaches.
Cross-layered approach in order to ensure a dynamic and reliable messages scheduling and transmissions processes, while remaining adapted to the IEEE 802.11p underlying standard.
Applicative layer congestion control approach, in order to define packets priorities according to their application, their utilities and validities in the network and the neighborhood context.
The basic idea of our applicative-layer congestion control approach is to define policies, in order to dynamically and cooperatively schedule messages transmission in the network. Messages scheduling is carried out according to priorities, evaluated as a function of the utility of the concerned messages, the sender application and the neighborhood context. The messages transmission in the vehicular network is carried out in an efficient and cooperative manner, by favoring vehicles holding the highest-priority messages to send. Therefore, our approach is divided into three steps that we present hereafter: dynamic priority assignment, message scheduling and cooperative message transmission.
3.2. Priority Assignment
Messages will be assigned a priority by application initiating. The relative time of transmission of each priority level will however vary as network density increases: medium and low priority packets being delayed to allow high priority packets to be sent without delays. The priority of a packet is composed of 2 fields: the first is static, deduced from the application type and the second is dynamic, obtained from the specific context of the VANET (neighborhood density) and determined by the congestion control module. The size of the message, the dynamic and static fields are combined to obtain the overall priority indicator ( ).
3.2.1. Static Factor from Application Class
is the priority affected to single hop emergency messages to notify an important event without delay. The safety of vehicles depends on this kind of messages. Regarding Multihop and Geocast communication it is assumed that only the first hop can have the priority .
is the priority affected to the network layer beacons.
is the priority affected to high priority safety applications.
is the priority affected to normal safety applications.
is the priority affected to low priority applications.
3.2.2. Dynamic Factor from Network Context
We present in the following how our congestion control approach evaluates the dynamic priority factor of sent messages (a part of this work has been carried out jointly with the VANET research group in the HEUDIASYC laboratory).
Node Speed Consideration
Message Utility Consideration
The dynamic factor considers also the utility of the sent message, according to the number of its retransmissions by the neighborhood, in case of periodic or geocast messages. Thus, when a node has to send a periodic or geocast message , and receives the same message , sent by another node (cf. Figure 4), it should calibrate the dynamic factor of the message , in order to take into account the zone covered by the node , compared to its communication range zone ( with R is the communication range). The smaller is the covered zone, the higher is the priority to send the message. The dynamic factor is thus equal to the ratio between the total zone covered by the receiver and the already covered zone (CZ):
We demonstrated that the covered zone CZ by the node B (doubly hatched in Figure 4) at the side of the node A is evaluated as follows (we note the distance between A and B, and R the range of A and B):
Message Validity Consideration
3.3. Messages Scheduling
Each node schedules its messages according to their priorities, in the appropriate channel. The Car to car Communication Consortium (C2C CC) considers two VANET wireless channels (control and service channels), each used for different traffic .
Control Channel (CCH)
The control channel is primarily used to transmit beacons and high/first hop priority traffic. All messages that are necessary to maintain the VANET are transmitted on this channel, especially the network layer beacons. Furthermore, high priority messages (emergency notifications) are sent on this channel. Normally, such messages occur on an event basis. With multihop communications, only the first hop will require high priority.
Service Channel (SCH1)
This channel is available for safety applications with lower priority. Here periodic messages could be sent. This channel should also be used by forwarders of multihop and geocast messages. A second service channel (SCH2) is intended to short distance peer to peer VANET communications, with reduced power level. However, this service channel is currently unused.
Hence, we split the scheduling process into two phases: static and dynamic, presented hereafter:
3.3.1. Static Scheduling
The static scheduling process consists of dispatching messages according to their priorities, into the suitable communication channel queues. Thus, , and priority messages are affected to the control communication channel queue, whereas and priority messages are affected to the service queue.
3.3.2. Dynamic Scheduling
Periodically, each node triggers a rescheduling process, which scans the messages queues, and computes the overall priority indicator for each message (considering the dynamic factor of each priority, presented above). The rescheduling process then reorders the messages according to their new computed priorities.
Considering that the number of messages sent within the control channel is smaller than the number of messages sent within the service one, we adopt the following policy: when the service channel is overloaded and the control channel is free, messages within the service queue are switched to the control one, and considered as high priority messages. We estimate that the service channel is overloaded if the number of messages in the queue exceeds a defined threshold, called "Service Channel Congestion Threshold".
3.4. Cooperative-Based Messages Transmission
Messages transmission process sends the highest priority message within the corresponding channel, whenever it is free. However, sending high priority packets via the control channel is preemptive, compared to packets sent via service channel. Indeed, in order to send high priority packets with the minimum delay, lower priority packets emission is freezed, even if their corresponding channel is free. We divide our cooperative transmission technique into two main mechanisms that we present hereafter: the available bandwidth sharing and the next forwarder selection for the multihop communication case. These procedures require the modification of the periodic beacon structure, that we present later.
3.4.1. Bandwidth Sharing
Concerning the dynamic use of the bandwidth within VANET, the IEEE 802.11p underway standard supports three mandatory user data rates 3 Mbit/s, 6 Mbit/s and 12 Mbit/s within a 10 Mhz channel, and some optional data rates up to 27 Mbit/s. The most robust data rate is the 3 Mbit/s one. This rate must be shared among all applications and vehicles inside the interference range. In order not to saturate the provided bandwidth and to allow a reliable transmission of the emergency messages, the bandwidth offered to VANET application per 10 Mhz is equal to the half of the total bandwidth.
The simplest way to share the available bandwidth to the neighbors is to divide it equitably between them, as follows. Let denotes the number of neighbors of a node. The effective bandwidth that a vehicle can use within the vehicular network is thus computed as
However, such a solution treating all the neighbors equitably does not favour higher-priority messages holders to use the available bandwidth, nor avoids eventual collisions and interferences. The suitable solution to eliminate these drawbacks is to offer the available bandwidth to the transmitter node whose message holds the highest priority compared to the messages of its neighbors.
In order to notify its neighbors about the priority of the first message it has to send, each vehicle includes this information in its beacon structure, as presented in Section 3.4.3. Therefore, as for the token ring communication protocol, a node can use the available bandwidth only if it holds the highest-priority message (it does not receive any beacon notifying the occurrence of a higher-priority message holder within its neighborhood). In the same way, when a node receives beacons notifying the presence of higher-priority messages than messages that it will send (the first messages in its queues), it freezes its transmission.
When two vehicles have to send two messages with the same priority, as for the FIFO scheduling model, the available bandwidth will be devoted to the first vehicle who notifies the priority of its message. The time of a first notification corresponding to a message priority should thus be included in the beacon structure. Note that generally, messages corresponding to a vehicular application have the same priority; consequently, the priority notification sent within beacons is not frequently modified.
3.4.2. Next Forwarder Selection
In the case of multi-hop inter-vehicular communications, the choice of the next forwarder is essential in order to enhance the performances of the communication architecture. Therefore, the next forwarder should be chosen as the less congested node within the neighborhood. In this context, we propose to define the congestion level principle as follows:
The congestion level of a node (expressed in seconds) is evaluated as the ratio between the total size of messages to send by the available theoretical bandwidth (cf. Equation (6)). This parameter evaluates the required time (in seconds) in order to send all the waiting messages stored in the queues, using the effective bandwidth (according to the number of neighbors).
Therefore, a vehicle chooses the neighbor with the smallest congestion control, as a next forwarder. In order to notify its neighbors about its congestion level, each vehicle includes it within its beacon structure, as presented in Section 3.4.3. The congestion control level can also be used by each node to control its internal congestion: for example, if this level exceeds a defined threshold, the lowest-priority messages will be deleted.
3.4.3. Periodic Beacon Structure
Formal modeling and verification. This validation step deals with the reliability and operational aspects of our congestion control approach, to verify reachability, safety, liveness and no deadlock properties.
Simulations and performance analysis. This second step verifies temporal and operational constraints by measuring the delays of messages before their sending on the appropriate queue, and the service packets-loss rate.
4.2. Formal Verification
Formal verification of a hardware or software system consists of proving or disproving the correctness of intended algorithms/approaches underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.
In our context, the quality of service of a system is composed of a constraints set (delays, response time, data rate, etc.). The system operation ensures the required QoS if it satisfies the needed constraints. Automata allow to model dynamic control aspects of a system operation. These models, in addition to temporal mechanisms (called temporized automata), are suitable to specify temporal QoS constraints [18, 19].
In this context, and in order to verify and validate formally our congestion control technique, we propose to specify it using temporized automata, through the UPPAAL (http://www.uppaal.com/) integrated tool environment for modeling, validation and verification of real-time systems. UPPAAL is developed in collaboration between the Department of Information Technology at Uppsala University, Sweden and the Department of Computer Science at Aalborg University in Denmark. To present our validation process, we first start by presenting an overview of temporized automata and the UPPAAL tool. Then, we present our objectives, simulations and results.
4.2.1. Temporized Automata
In a temporized automaton, transitions between states are conditioned by temporal constraints on clock variables. An elementary temporal constraint is a boolean property in which a clock variable is compared to a constant integer. Extended temporized automata enhance temporized automata by providing the possibility of manipulation of non-temporal variables. In the following description, we do not distinguish between "temporized automata" and "extended temporized automata".
is a finite set of actions,
is a finite set of states,
is the initial state,
is a finite set of clocks,
is a finite set of variables,
is the set of transitions. A transition is a tuple ( ) indicating that, starting by the state , the automaton executes the action , if the constraint is satisfied; clocks of are reset, variables of are updated and the new state is .
4.2.2. The UPPAAL Modeling, Validation and Verification Tool of Real-Time Systems
Reachability properties. These properties ask whether for a given state formula , there exists a path starting at the initial state, such that is eventually satisfied along that path. Reachability properties do not by themselves guarantee the correctness of the system, but they validate the basic behavior of the model.
Safety properties. These properties ask whether a bad result will never happen, or an awaited result is invariantly true.
Liveness properties. These properties are of the form "an awaited result will eventually happen". With this type of properties, response conditions can be verified as follows "whenever is satisfied, eventually will be satisfied".
No Deadlock property. This property verifies if there is no any state where there are no outgoing action transitions, neither from the state itself or any of its delay successors.
4.2.3. UPPAAL Simulations and Results
- (i)The message manager automaton (cf. Figure 6): this subsystem is responsible for generating messages and sending them to the congestion control module, which will process them according to their priorities. To simplify our simulation platform, and without loss of generality, we consider hereafter two levels of priorities (high priority packets sent through the control channel and low priority packets transmitted in the service channel).
The congestion control message enqueueing automaton (cf. Figure 7): this sub-system is responsible for the reception of messages from the message manager and for their addition to the appropriate queues. A synchronization message is required to transit from the Idle state to the one. The automaton switch to the state after adding the high priority message to the appropriate queue. The addition of a low priority message follows the same process, with the difference that the congestion control module can deny sending a message if the service channel is overloaded (number of low priority messages ). Note that when the service channel is overloaded and there is no high priority packets to send, a low priority message can be sent via the control channel. This message is thus dequeued from the service queue list and enqueued in the control channel one.
The congestion control message dequeueing automaton (cf. Figure 8): this subsystem is responsible for withdrawing messages from the control and service queues and transmit them to the transmission engine. The synchronization messages between the congestion control message dequeueing automaton and the transmission engine one are and .
- (iv)The transmission engine automaton (cf. Figure 9): this sub-system is responsible for the messages effective transmission on the appropriate channels. A sending error rate of (The sending error rate is defined in the context of the SAFESPOT European Integrated project.) is chosen. When an error occurs during message sending, the automaton switches to the Error state.
No deadlock in the operation of our messages priorities-based scheduling approach. All states of the modeled automata have successors.
All states of the modeled automata are eventually reachable.
All the high priority messages are effectively sent on the control channel. However, some low priority packets can be deleted, due to service channel congestion (bounded service messages queue).
The transmission of high priority messages is preemptive comparing to the emission of low priority messages. Service messages are sent only when there is no any control message in the queue of the control channel.
In addition, the emission of a high priority message is carried out without delay. All the high priority messages are considered as emergency, requiring thus to freeze the emission of lower priority messages.
We tried then to carry out the second validation step provided by UPPAAL: the model checking verification, after specifying our verification objectives (queries) via a description language. However, this verification step did not succeed due to memory limitations. Indeed, the number of states and variables in UPPAAL can make the model-checking verification process very constraining and complex . Although the success of the model checking verification step may validate explicitly the correctness of the verification objectives (by exploring all the possible paths in the graph), we can affirm nevertheless that our priority-based scheduling approach is correct, considering the results of the first verification step (consisting of validating with success the use-cases corresponding to the congestion control scheme operation: sending high-priority and low-priority messages on the control and service channels resp.).
4.3. Performance Evaluation and Analysis
messages generation rate: number of messages generated by the messages manager per second,
mean message size, in order to consider the necessary delay to send each message, according to the effective bandwidth,
mean number of neighbors, in order to evaluate the effective theoretical bandwidth available for each node.
From these simulations, we show that the service packets-loss rate is affected by the three parameters of our analysis. Indeed, it increases with the increase of the messages generation rate, the mean size of messages and the mean number of neighbors. However, the service packets-loss rate remains almost negligible in most cases of the network context and the ego node charge. Note that messages sent on the control channel cannot be lost or dropped. Their transmission is preemptive comparing to messages sent on the service channel.
The delays of the control and service packets before their effective emission are also affected by the three parameters of our simulations. These delays increase with the increase of messages generation rate, the mean size of messages and the mean number of neighbors. We note that the delays concerning the control messages are low, and do not exceed in the worst cases 60 ms. QoS requirements for the high priorities messages are thus satisfied, which is a challenging issue for the emergency alerts dissemination within VANETs. However, the delays of the service messages is almost 1 s for the "normal" context of network and charge, and can reach 3 s in the worst cases.
In addition, our priority-based congestion control technique is dynamically adaptable to the context of the neighborhood, taking into consideration the local density and messages priorities in order to evaluate the optimal bandwidth sharing process between neighbor mobiles. Indeed, Figure 15 and Figure 16 illustrate the adaptability of our congestion control method to the variation of the mean number of neighbors: its performances in terms of delays and service packets loss-rate are very promising in the "normal" context of vehicular environment (e.g., the average number of potential communication neighbors within a four highway lanes context is appreciatively four ).
As a conclusion of the performance evaluation step, we believe that our congestion control approach within VANETs satisfies the objectives identified in Section 2.3. Mainly, fast and reliable communication scheme is guaranteed for the control channel, and an acceptable communication rate is ensured through the service one, according to the priorities of the messages and the QoS policies established by the applicative layer.
We considered in this paper the congestion control issue within vehicular ad hoc networks. We summarized in a first step existing research work on this topic, then we presented our cooperative congestion control approach, based on dynamic messages scheduling and transmission, considering the network load and the neighborhood context. Then, we validate the efficiency and the real operability of our congestion control technique through two principal steps: formal verification and validation, and performance evaluation and analysis. The formal verification step, carried out via the UPPAAL tool, proved the reliability of our congestion control technique in terms of reachability, safety, liveness, and no-deadlock properties, whereas the performance evaluation step considers the delays of messages before their effective sending in the appropriate queue, and the service packets-loss rate.
Congestion Control Module.
Within the congestion control module, two queues are implemented, one for the control channel messages and one for the service channel messages. The dotted edge in Figure 18 represents the possibility of switching messages from the service channel queue to the control channel one, when needed. In addition, four threads are implemented, a main thread receiving messages from the input modules, and the others are intended to schedule and send messages, and control the charge of the node.
Input modules redirect messages to the congestion control module. The message manager module generates new messages, to be sent within the control or service channel, and the reception engine sends received messages to be forwarded by the congestion control module.
The output module that receives messages from the congestion control module is the transmission module. Each message received from the congestion control module is affected to the corresponding channel to be effectively aired.
The congestion control module interacts with the parameters modules. From the neighbor table module, the congestion control module evaluates the network and the neighborhood context, to recompute dynamically the messages priorities. The congestion control module interacts also with QoS policies module in view of the general quality of service policies, according to the priority of the transmitted messages.
Subsystem tests. This first step consists of testing the congestion control component individually (tests of each method according to its expected values and real results).
Integrated system tests. This step consists of testing the VANET router architecture, and the interactions between the different sub-systems.
Vehicles tests. This final step consists of testing several VANET routers to validate the operational distributed behaviour of all the VANET network. A special attention will be given to the evaluation of the bandwidth consumption and the charge of the nodes, in order to validate the reliable transmission of emergency messages within VANET.
- Zang Y: Study on message dissemination algorithms for cooperative danger warning applications based on inter-vehicle communications. Proceedings of the 3rd International Workshop on Wireless Community Networks (COMNETS '08), 2008, Hangzhou, ChinaGoogle Scholar
- Zang Y, Stibor L, Reumerman HJ: Neighborhood evaluation of vehicular ad-hoc network using IEEE 802.11p. Proceedings of the 8th European Wireless Conference, 2007, Paris, France 5.Google Scholar
- Minack E: Evaluation of the influence of channel conditions on Car2X communications, Ph.D. thesis. Chemnitz University; November 2005.Google Scholar
- Lochert C, Scheuermann B, Mauve M: A survey on congestion control for mobile ad hoc networks. Wireless Communications and Mobile Computing 2007, 7(5):655-676. 10.1002/wcm.524View ArticleGoogle Scholar
- Chandran K, Raghunathan S, Venkatesan S, Prakash R: Feedback based scheme for improving TCP performance in ad-hoc wireless networks. Proceedings of the 18th International Conference on Distributed Computing Systems, May 1998, Amsterdam, The Netherlands 472-479.Google Scholar
- Rath HK, Sahoo A, Karandikar A: Cross layer based congestion control in wireless networks for TCP Reno-2. Proceedings of the 12th National Conference on Communications (NCC '06), April 2006, Delhi, IndiaGoogle Scholar
- Chen M, Abate A, Sastry S: New congestion control schemes over wireless networks: delay sensitivity analysis and simulations. Proceedings of the 16th IFAC World Congress, January 2005, Prague, Czech RepublicGoogle Scholar
- Raghunathan V, Kumar PR: A counterexample in congestion control of wireless networks. Proceedings of the 8th ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM '05), October 2005, Montreal, Canada 290-297.Google Scholar
- Yi Y, Shakkottai S: Hop-by-hop congestion control over a wireless multi-hop network. IEEE/ACM Transactions on Networking 2007, 15(1):133-144.View ArticleGoogle Scholar
- Kliazovich D, Granelli F: Cross-layer congestion control in ad hoc wireless networks. Ad Hoc Networks 2006, 4(6):687-708. 10.1016/j.adhoc.2005.08.001View ArticleGoogle Scholar
- Rangwala S, Jindal A, Jang K-Y, Psounis K, Govindan R: Understanding congestion control in multi-hop wireless mesh networks. Proceedings of the 14th Annual International Conference on Mobile Computing and Networking (MOBICOM '08), September 2008, San Francisco, Calif, USA 291-302.View ArticleGoogle Scholar
- Zhang G, Wu Y, Liu Y: Stability and sensitivity for congestion control in wireless networks with time varying link capacities. Proceedings of the 13th IEEE International Conference on Network Protocols (ICNP '05), November 2005, Boston, Mass, USA 401-411.View ArticleGoogle Scholar
- Kelly F: Charging and rate control for elastic traffic. European Transactions on Telecommunications 1997, 8(1):33-37. 10.1002/ett.4460080106View ArticleGoogle Scholar
- Zang Y, Stibor L, Cheng X, Reumerman H-J, Paruzel A, Barroso A: Congestion control in wireless networks for vehicular safety applications. Proceedings of the 8th European Wireless Conference, 2007, Paris, France 7.Google Scholar
- Wischhof L, Rohling H: Congestion control in vehicular ad hoc networks. Proceedings of IEEE International Conference on Vehicular Electronics and Safety Proceedings, October 2005, Xian, China 58-63.Google Scholar
- Torrent-Moreno M, Santi P, Hartenstein H: Fair sharing of bandwidth in VANETs. Proceedings of the Second ACM International Workshop on Vehicular Ad Hoc Networks (VANET '05), September 2005, Cologne, Germany 49-58.View ArticleGoogle Scholar
- IEEE P1609.4 : Wireless access in vehicular environments (wave) multichannel operation. Draft Standard November 2005.Google Scholar
- Alur R, Dill DL: A theory of timed automata. Theoretical Computer Science 1994, 126(2):183-235. 10.1016/0304-3975(94)90010-8MathSciNetView ArticleMATHGoogle Scholar
- Cavalli A: Ingénierie des protocoles et qualité de service, Réseaux et Télécoms. Lavoisier Hermes, Paris, France; 2001.Google Scholar
- David A: Uppaal2k: small tutorial. Report Version October 2002., (3.2.11):Google Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.