# Coordination of Congestion and Awareness Control in Vehicular Networks
## 1 Introduction
The adaptation of communication parameters can also influence the operation and performance of other protocols. For example, reducing the transmission power to control the channel load can also change the network topology, decrease the number of connected neighboring vehicles, and thereby influence the operation of topology control protocols [12]. Different protocols can operate over the same parameters and can provide contrary instructions regarding the configuration of such parameters. The interactions among protocols can provoke unintended and negative adaptation loops [13] that reduce the network performance and the applications' effectiveness (defined as the capacity to satisfactorily meet the vehicles' application requirements). It is therefore critical that protocols are designed considering their direct or indirect interactions. To do so, one methodology is the integration of interacting protocols. The integration methodology can lead to short-term performance gains because the integrated solution must be specifically designed for the protocols that are integrated. However, it also has non-negligible disadvantages that motivated this study:  
* Constrained evolution. With the integration methodology, the evolution of a system or standard will be constrained, and possibly limited by the adopted integrated solution. This is the case because any evolution of the interacting protocols would require a revision of the design of the integrated solution. * Tailored designs. Different integrated solutions will be needed based on the protocols that are being integrated. The integration of different protocols requires different designs that are specific for the protocols to be integrated [14]. * Limited modularity. The integration methodology does not fully preserve the modularity of the layered protocol stack. Interacting protocols are integrated in a novel solution that does not follow modular design guidelines. Enabling cross-layer interactions while preserving modularity is a challenge still to be solved [15; 16]. * Coexistence. It is not easy to integrate two different cross-layer protocols. There is no widely accepted cross-layer design coexistence methodology [13; 14]. This study is motivated by the limitations that have just been described, and that result from trying to solve conflicts between interacting protocols through their integration. To tackle these limitations, this paper proposes an alternative methodology for the cross-layer coordination of interacting protocols that can simultaneously coexist and operate in vehicular networks. The proposed methodology (COMPASS, cross-layer coordination of multiple vehicular protocols) solves negative interactions between protocols that operate over the same communication parameters by coordinating their operation rather than integrating them. COMPASS has been initially designed as a means to coordinate congestion and awareness control protocols in vehicular networks. However, this study will also demonstrate that COMPASS can coordinate other interacting protocols. In particular, this study considers the coexistence of congestion, awareness, and topology control. This paper will also demonstrate that COMPASS has a very low computational complexity. Figure 3 conceptually illustrates the difference between the integrated and coordinated (i.e., COMPASS) methodologies. The figure considers two protocols that adapt communication parameters \(p_{1}\) and \(p_{2}\) at the same or different layers of the protocol stack. When operating independently, a conflict situation can occur if the protocols require different settings for \(p_{1}\) and \(p_{2}\) to achieve their respective objectives (Figure 3a). The problem can be solved by designing a solution that integrates the two conflicting protocols, and results in a configuration for the \(p_{1}\) and \(p_{2}\) parameters that satisfies the two original protocols (Figure 3b). On the other hand, the proposed COMPASS methodology does not require modifying the original protocols (Figure 3c).