## 3 Operation and Models of the VANET Testbed
### Network Models
#### 3.2.3 Traffic Controller Model  
As discussed in Sections 1 and 2.4, we only need to survive congestion to meet the QoS requirement of our real-time safety application scenario. This has given us the idea of reducing the complexity of the explicit control algorithm in order to cut down the CPU consumption when the vehicular camera is moving at higher speeds. Our careful study shows that reducing the sending bit rate is the key factor of success, and this can be achieved in two ways: dropping some frames (packets) or reducing quantization level per frame. There are different consequences and tradeoffs. For driving video traffic, the drop pattern is very important to the quality of service as seen by user. Dropping just the even frames or just the odd frames is usually better than dropping both consecutively. The frequency of a drop can be a more critical factor than the percentage of drop. For instance, dropping 10 consecutive packets out of 100 packets is a 10% drop, which is the same as randomly dropping 1 out of 10 packets from a stream of 100 packets. However, the latter is more tolerable than the former in our system. Since there are many more P frames than I frames, we only drop P frames, first even then odd in our testbed. Thus we can use an automatic predictive source control to assist the explicit congestion control. That is, when P frames start piling up, we drop the P-frames by following a particular drop patter. For example, dropping the even frames first and then the odd frames without waiting for control commands to come from the base station. We can also set an upper limit of approximately 25% beyond which the video becomes less comfortable to watch (and may not satisfy customer expectations). According to our industrial partners, changing the quantization level will be the next practical and cost-effective approach to reduce bit rate in terms of complexity and ease of deployment. We lower the quantization level when we use fewer coefficients from the coarse DCT (Discrete Cosine Transformation) algorithm, and thus reducing the packet size as well. Depending on the end-to-end delay, the receiver notifies the sender of the quantization level to use in encoding the subsequent video frames. This method will bring the total bit rate down to 50% of the original coding/sending rate. Beyond 50%, we need to drop the color components, thus leaving the video in its black-and-white mode. In summary, the sending bit rate = frameRate*FrameSize which can be lowered by lowering one or both of the frame rate or frame size. There are tradeoffs between the two. Dropping packets (frames) will lower the frame rate while reducing the quantization level that will lower the resolution. The challenge in lowering the resolution is to keep the user experience/satisfaction high as long as possible, and various experiments have been conducted to find out the optimum point. Although our real GenieView camera has implemented in both methods in firmware to improve user experience, our OPNET model has chosen to drop the frames/packet only. This is reflected in Figures 5 and 6 below where the called party collaborates with the calling party to determine the end-to-end delay based on how our controller uses one byte to notify the source to reduce its sending rate by dropping selected frames as discussed above. We also make use of RTP/RTCP at the application layer to provide an effective feedback mechanism. Figure 5 depicts the video called party (receiver) procedure. Once the variables are initialized successfully, and a connection is established, data transmission can begin upon request. As soon as a frame is received, the frame count is incremented until it reaches the threshold value \(p\). Once \(p\) is reached (e.g., \(p\) = 5 in our experiments), the frame count is reset to zero and the end-to-end delayassociated with the packet is checked.