## 3 Operation and Models of the VANET Testbed
### Protocol Layers and Operations  
With reference to Figure 2, an RSU (BS 1 or BS 2) has the capability of handling up to N cars simultaneously. Each car/MS (Mobile Station) is associated with the closest RSU in the coverage area. Safety driving video packets are routed and given priority by recognizing their service class and scheduling type. For example, the silver service class and the rtPS (real-time Polling Service) scheduling [17] are assigned to the safety video. For each service class, there is a maximum sustainable traffic and reserved traffic rates (e.g., 384 kbps for the silver service class). Each video packet arriving from the higher layer at a MS is expected to be within a size limit. Otherwise, it will be segmented before being encapsulated into a PDU (Protocol Data Unit) with the appropriate header information, and then transmitted. For example, video packets longer than 1500 B must be segmented to fit the SDU (Service Data Unit) for the silver (safety video) service. The driving video traffic is generated from the application layer when an MS wants to transmit. We use UDP (User Datagram Protocol) as the transport layer protocol to cater for the end-to-end delivery of packets. RTP (Real Time Protocol) is used at the application layer to combat the possible unreliability in UDP. RTP is a real-time streaming protocol designed for streaming audio and video. In conjunction, we use RTCP (Real-Time Transport Control Protocol) for controlling, signaling and quality service monitoring. The unique nature of driving video traffic is due to its burstiness and persistence. The size of each frame generated is dependent on its previous frames and the driving speed, and the exact time a frame is generated or received also depends on previous frames and road conditions. These two correlated uncertainties contribute to the high variable bit rate characteristics of driving video communication. Coupled with the real-time and accuracy requirement of our safety applications, these factors pose a  
Figure 2: Vehicle camera network operation. modeling challenge. Of the various video codec schemes that have been developed e.g., MPEG2/4, H.263/4, we have chosen the MPEG4 video compression for our vehicular cameras and studied its traffic model for our testbed. Our array-based MPEG encodes the input video into three types of compressed frames called the I, the Peven, and the Podd frames. I-frames are compressed using intra frame information only. Peven or Podd-frames are coded similarly but with motion compensation for even or odd lines respectively according to the previous I frame. Depending on the vehicle driving speed or congestion condition, Peven and Podd frames may be dropped alternatively, or altogether. In general, I-frames are 10 times bigger than P frames. After coding, the frames are arranged in a deterministic order, which is called GOP (Group Of Pictures). This pattern is not specified hence different coders may use different patterns for subsequent GOPs. A common feature, however, is that all video frames exhibit strong time dependent correlations among themselves. This gives rise to different queuing statistics and time-dependent rush hour congestion phenomenon. This is the subject of streaming traffic analysis and modeling later on, as well as the need for a delicate adaptive congestion controller design. Each car has a WiMAX capability in transmitting (and receiving) at the physical and the MAC layers after receiving the safety video packets from (and delivering to) the network layer. At the MAC layer, the destination address is examined and the nearest RSU is chosen to handle the request. The packet is sent to that RSU, and further forwarded accordingly. In our investigation, the IP cloud in Figure 2 can be set to its default values and acts a router. The server is configured to accept packets generated by our simulator. As suggested above, we shall use mobile WiMAX technology at the physical and MAC layers for our VANET.