## 2 Related Works
### Higher-Layer Protocols for VANET  
Real-time data has an arrival deadline to reach its destination, or else its information is no longer valid. TCP (Transport Control Protocol) [8] and UDP (User Datagram Protocol) [9] are protocols that have been used but were found to not be effective. TCP is best used for lossless data transfer as it ensures packet delivery via packet retransmission. This poses a problem for real-time traffic, as there is no time for retransmission [10]. UDP can be better for real-time video traffic, but unfortunately still cannot guarantee real-time nor loss performance because their flows cannot adapt their rates to congestion control mechanisms at the router [37]. They can provide the best-effort service only since they have no priority over TCP flows. Congestion will also lead to random jitter and eventually loss, as video traffic becomes prevalent in f VANET. Although in theory TCP or UDP should not be affected by the choice of physical transmission medium such as fiber optic, they often perform poorly in wireless networks [38] because their design and implementations were carefully optimized for wired networks. RTP (Real-time Transport Protocol) [11] is a protocol designed for end-to-end real-time transport of video traffic. However, it does not take many performance issues into account including channel outage, traffic congestion, the effect of overheads in uncast/multicast applications, and the end-to-end delay in a mobile environment. In summary, the behavior of these protocols in the VANET environment are quite different as the wireless medium is prone to interference from forces of nature and manmade effects, and the situation is exacerbated when transmitter and/or receiver are moving. Various works have been conducted on congestion control in wired environments [39], wireless environments [40, 41] and VANET [42]. Congestion control protocols can also be classified into two main types [39]: window-based and rate-based. The window-based congestion control algorithms adjust the window-size according to the level of congestion detected in the network. Algorithms like RED (Random Early Detection) [43], its TCP variants (like Tahoe [44], NewReno [45]), and AIMD (Additive Increase and Multiplicative Decrease) [44] fall under this category. This type of control usually corresponds to the implicit congestion control as congestion is detected at the receiver through the observation of events such as packet loss. So many algorithms in this type of approach can cause fluctuations in the source sending rates, thus producing non-smooth throughput and low link utilization. These are evidently not effective for real-time video streaming [46] in practice. Rate-based congestion control algorithms on the other hand, allow each source in the network to directly adjust its sending rate based on the congestion notification received, and usually from the router that knows the state of the network. TFRC (TCP Friendly Rate Control) [47] and API-RCP (Adaptive PI Rate Control Protocol) [39] falls under this category. API-RCP presents an effective way to calculate the source-sending rate based on the queue deviation, and is quite capable of producing steady queue length to meet the bandwidth requirement of a driving camera. The rate-based control usually makes use of explicit congestion control due to the nature of its operation (as a contrast to the implicit control discussed earlier). However, this type of control may not be effective when a vehicle is moving because constant updating of the router due to motion consumes more CPU resources. Eventually, the CPU cannot catch up with the events arising from high speeds. Most of the algorithms mentioned previously are built on top of TCP and have only been tested in wired networks. In wireless networks, delay is caused mostly by wireless interference rather than network congestion. Quite often packets are stored in a buffer waiting for proper bandwidth allocation before they can be delivered.