## 5 Performance Evaluation Using OPNET Testbed  
With the simulation platform established, we can now evaluate the performance of a practical controller through measurements of different performance measures using different network parameters such as network size and driving speeds, and different protocol parameters.  
There are two network sizes we use to evaluate the scalability of our explicit congestion control algorithm: a small network consisting of 10 cars and 2 RSUs, and a larger network of 30 cars and 2 RSUs. Each car in these networks has a maximum sustainable traffic rate of 384 Kbps. With reference to Figure 2, the link between the RSU and the backhaul network was a DS3 link with a capacity of 44.736 Mbps. Section 4.4 has also provided the values of other parameters.  
Each simulation took 3600 s, which is determined to be a good duration for the performance measures to converge. The following are the definitions of the performance measures we used in our investigation:  
1. End-to-End Delay (in seconds): This is defined as the time duration from the instant when a packet is generated at the source node (e.g., the safety camera on board a car) until the time it is received at the destination node. This performance measure presents a wholistic view of the time components in video capture, encoding and network delay before an end user visualizes the images. In real-time traffic, this parameter is very critical as it shows how \"current\" the information at the end user (e.g., a law enforcement officer) is. Since we track this at the application layer, the end-to-end delay also takes into account compression delay and all other delays incurred along the communication path and system;
2. Jitter: Jitter is defined to be the variation of end-to-end delay between consecutive packets. If two consecutive packets leave the source node with time stamps _t1_ and _t2_ and arrive at the  
Figure 14: Highway scenario.  
destination at time _t3_ and _t4_ after reassembly and playback, then the jitter will be represented by Equation (5). \[\mathrm{Jitter}=(t4-t3)-(t2-t1)\] Negative jitter means that the packets where received in different time range _i.e._, \((t4-t3)<(t2-t1)\);
3. Visual MOS Rating: This rating is a subjective parameter that measures the quality of video received by the server, judging the end-user experience. This measure was borrowed from the same parameter used to measure the MOS (Mean Opinion Score) in voice. Using the definition given by the ITU-T recommendation G.107 [58], the score R is given by \[R=Ro-Is-Id-Ie+A\,\] (6) where _Ro_ is the SNR (Signal to Noise Ratio); _Is_ is the simultaneous impairment factor; _Id_ represents impairment caused by delay; _Ie_ is the equipment impairment factor as a result of low-bit codecs and packet loss and \(A\) is the advantage factor that compensates for the loss cause by other factors. To customize this parameter for video evaluation, we have created a testbed case with all the \"ideal\" conditions. We allocate one base-station to one car so that there is more than sufficient bandwidth, hence keeping R as high as possible. We obtained a Visual MOS value of 3.6 that we should use as a reference to represent the best visual experience and 1 the worst visual experience, which is plot as the Y-axis in Figure 15.
4. Buffer Overflow Percentage: This measure is the fraction of time during which arriving packets find the buffer at the Subscriber Station full and are not served. This measure implicitly reflects the percentage of time video packets lost due to buffer overflow.