TOWARD ZERO DELAY VIDEO STREAMING By Hothaifa Tariq Al-Qassab A DISSERTATION Submitted to Michigan State University in partial fulfillment of the requirements for the degree of Electrical Engineering -Doctor of Philosophy 2018 ABSTRACT TOWARD ZERO DELAY VIDEO STREAMING By Hothaifa Tariq Al-Qassab Video streaming has been growing rapidly since the beginning of this century and it is expected to continue growing. Meanwhile, transmission delay is a well-known problem in video streaming and it has been addressed by many prior works that demonstrated the feasibility of reducing packet delays over the Internet by employing a variety of end-to-end techniques. This thesis consists of two parts that introduce new video streaming frameworks over the Internet and over connected-vehicle networks, respectively. Our objective in the first part of this thesis is to improve video streaming over the Internet. The emerging of new technology such as the HTTP-based Adaptive Streaming (HAS) approach has emerged as the dominant framework for video streaming mainly due to its simplicity, firewall friendliness, and ease of deployment. However, recent studies have shown that HAS solutions suffer from major shortcomings, including unfairness, significant bitrate oscillation under different conditions and significant delay. On the other hand, Quality-of-Service (QoS) based mechanisms, most notably multi- priority queue mechanisms such as DiffServ, can provide optimal video experience but at a major cost in complexity within the network. Our objective in this thesis is to design an efficient, low complexity and low delay video streaming framework. We call our proposed Internet streaming framework Erasable Packets within Internet Queues (EPIQ). Our proposed solution is based on a novel packetization of the video content in a way that exploits the inherent multi-priority nature of video. An important notion of our proposed framework is Partially Erasable Packet (PEP). Furthermore, to evaluate our framework performance, we developed an analytical model for EPIQ that shows significant improvements when compared to the conventional and multi-priority queue video transmission models. Under congestion, a best-effort AQM router can simply erase an arbitrary portion of a PEP packet starting from its tail where we denote this process as Partial Erasing (PE). To complement partial erasing in the AQM, a rate control protocol similar to TFRC is proposed to ensure fairness for video and non-video traffic. Our results show that EPIQ provides improvements in video quality in terms of PSNR by at least 3dB over traditional video streaming formworks. In addition, packet loss ratio and delay jitter performance are comparable to the optimal video streaming mechanism that is offered by multi-priority systems such as DiffServ. The main objective of the second part of the thesis is to develop a vehicle active safety framework that utilizes video streaming and vehicle-to-vehicle (V2V) communication for driver warning. Most prior efforts for V2V safety applications have been limited to sharing vehicle status data between connected vehicles. We propose a Cooperative Advanced Driver Assistance System (C-ADAS) where vehicles share visual information and fuse it with local visuals to improve the performance of driver assistance systems. In our proposed system, vehicles share detected objects (e.g., pedestrians, vehicles, cyclists, etc.) and important camera data using the DSRC technology. The vehicle receiving the data from an adjacent vehicle can then fuse the received visual data with its own camera views to create a much richer visual scene. The sharing of data is motivated by the fact that some critical visual views captured by one vehicle are not visible or captured by many other vehicles in the same environment. The experimental results showed that our proposed system performed as intended and was able to warn drivers ahead of time, and consequently, it could mitigate major accidents and safe lives. To my family… iv ACKNOWLEDGMENTS First of all, I wish to express my great gratitude to my advisor, Dr. Hayder Radha, for his guidance and support throughout all stages of this research. His advice and encouragement have provided me with the skills needed to develop and refine this research. Special Thanks for Dr. Subir Biswas, Dr. Jian Ren and Dr. Guoliang Xing for agreeing to serve on my committee. I would like to acknowledge and thank Michigan State University (MSU) for allowing me to conduct my study and research on campus. I also wish to thank all my friends and colleagues in the Electrical and Computer Engineering departments at MSU. Many thank to all my friends who have assisted and supported me in so many ways during my study. Lastly, I would like to express my great gratitude to my mother, father, brothers and sisters for all their support and encouragement for me. v TABLE OF CONTENTS LIST OF TABLES ..................................................................................................................... viii LIST OF FIGURES ..................................................................................................................... ix Chapter 1 Introduction ............................................................................................................1 1.1 Video Streaming ..................................................................................................................1 1.2 Video Streaming Related Work ...........................................................................................3 1.3 Multimedia Priority Dropping .............................................................................................5 1.4 Multimedia Priority Dropping Related Work ......................................................................6 1.5 Vehicle to Vehicle Safety Systems ......................................................................................7 1.6 Vehicle to Vehicle Safety Systems Related Work ..............................................................8 1.7 Summary of Contributions .................................................................................................10 1.8 Thesis Organization ...........................................................................................................11 Chapter 2 EPIQ System Design and Analysis .....................................................................13 2.1 EPIQ System Overview .....................................................................................................13 2.2 Systems Analytical Model ................................................................................................15 2.2.1 EPIQ .....................................................................................................................15 2.2.2 Best Effort .............................................................................................................23 2.2.3 Multi Priority Queue (MPQ) ..................................................................................26 2.3 Experimental Evaluation ...................................................................................................30 2.3.1 Experimental Setup ...............................................................................................30 2.3.2 Experimental Results ............................................................................................31 Chapter 3 EPIQ System Implementation ...........................................................................34 3.1 Active Queue Management ...............................................................................................34 3.1.1 EPIQ-Random Early Detection (EPIQ-RED) ........................................................34 3.1.2 Stability analysis of EPIQ-Random Early Detection algorithm (EPIQ-RED ........37 3.2 Rate Control ......................................................................................................................42 3.2.1 EPIQ-TCP Friendly Rate Control Protocol (EPIQ-TFRC) ...................................42 3.3 Experimental Evaluation ...................................................................................................45 3.3.1 EPIQ-RED .............................................................................................................45 3.3.2 EPIQ-TFRC ..........................................................................................................50 Chapter 4 EPIQ Applications ...............................................................................................52 4.1 Video On Demand (VOD) Experimental Evaluation .......................................................52 4.1.1 Experimental Setup ...............................................................................................52 4.1.2 Experimental Results ............................................................................................54 Chapter 5 Vehicle to Vehicle Safety System ........................................................................60 5.1 Cooperative Advanced Driver Assistance System (C-ADAS) Overview .........................60 5.2 C-ADAS Architecture ........................................................................................................61 vi 5.3 C-ADAS Design and Operation .......................................................................................67 5.4 Experimental Setup ...........................................................................................................73 5.5 Experimental Results ........................................................................................................80 Chapter 6 Conclusions ..........................................................................................................86 BIBLIOGRAPHY ........................................................................................................................87 vii LIST OF TABLES Table 2.1: Stochastic model parameters ........................................................................................17 Table 3.1: Comparison between stable and unstable AQM performance .....................................46 Table 3.2: EPIQ-TFRC event loss calculation methods comparison ............................................51 Table 4.1: AQM performance of EPIQ, DiffServ and DASH .......................................................55 Table 4.2: Network resources sharing fairness of EPIQ, DiffServ and DASH ............................56 Table 4.3: Transmission and video quality of EPIQ, DiffServ and DASH ...................................57 Table 5.1: Variables used in our proposed system calculations ....................................................69 Table 5.2: Proposed system (CPCAS) calculations results ..........................................................84 viii LIST OF FIGURES Figure 2.1: The mapping of multi-priority video content from an EPIQ Video Set (left) to Partially Erasable Packets of an EPIQ Packet Set (right ...............................................................14 Figure 2.2: EPIQ vs. conventional packetization ..........................................................................19 Figure 2.3: EPIQ FGS vs. EPIQ MGS packetization ....................................................................21 Figure 2.4: EPIQ FGS vs. EPIQ MGS utilization .........................................................................23 Figure 2.5: BE FGS vs. BE MGS packetization ............................................................................25 Figure 2.6: BE FGS vs. BE MGS utilization .................................................................................25 Figure 2.7: MPQ FGS vs. MPQ MGS utilization ..........................................................................27 Figure 2.8: FGS utility for EPIQ, BE and MPQ ............................................................................28 Figure 2.9: MGS utility as a function of video-set size for EPIQ, BE and MPQ ..........................29 Figure: 2.10: PSNR of EPIQ and MPQ for AVC stream ..............................................................32 Figure 2.11: PSNR of EPIQ and MPQ for SVC stream ................................................................33 Figure 3.1: Linearized control system ...........................................................................................39 Figure 3.2: Unstable RED instantaneous queue size .....................................................................46 Figure 3.3: Stable RED instantaneous queue size .........................................................................47 Figure 3.4: Comparison between stable and unstable AQM throughput ......................................48 Figure 3.5: Instantaneous queue size of example 1 .......................................................................48 Figure 3.6: Channel utilization of example 1 .................................................................................49 Figure 3.7: Instantaneous queue size of example 2 .......................................................................49 Figure 3.8: Channel utilization of example 2 .................................................................................50 Figure 3.9: Comparison between ALI and EWMA throughput ....................................................51 Figure 4.1: Simulation topology ....................................................................................................53 ix Figure 4.2: Application to application delay of EPIQ, DiffServ and DASH .................................58 Figure 5.1: Pedestrian collision scenario .......................................................................................61 Figure 5.2: An integrated system for multi-modal sensor data sharing and fusion .......................63 Figure 5.3: Example of baseline system architecture ....................................................................64 Figure 5.4: System architecture with object localization, positioning, and trajectory estimation .65 Figure 5.5: Proposed system (Cooperative Pedestrian Collision Avoidance System (CPCAS)) operation flowchart ........................................................................................................................68 Figure 5.6: Top-view schematic of collision scenario with variables ...........................................72 Figure 5.7: Pin hole model and image transpose calculations .......................................................73 Figure 5.8: Cohda MK5 transceiver...............................................................................................74 Figure 5.9: Emlid GNSS receiver ..................................................................................................76 Figure 5.10: H.264 frame delay .....................................................................................................76 Figure 5.11: MJPEG frame delay ..................................................................................................77 Figure 5.12: H.264 vs. MJPEG bandwidth usage ..........................................................................78 Figure 5.13: H.264 vs. MJPEG bandwidth with scaled image ......................................................79 Figure 5.14: DSRCs test route .......................................................................................................80 Figure 5.15: Bandwidth between two DSRC units ........................................................................81 Figure 5.16: Packet delay between two DSRC units .....................................................................82 Figure 5.17: The delay of proposed system (CPCAS ....................................................................83 Figure 5.18: A sample of CPCAS system image fusion results ....................................................85 x Chapter 1 Introduction 1.1 Video Streaming Video streaming has been growing rapidly since the beginning of this century and it is expected to continue growing. In 2015, the video traffic occupied 70% of total internet traffic and it is expected to reach 82% by the end of 2020. With rapid growth of internet traffic led by video traffic, the Internet busy hours will double before the end of this decade [1]. One of the most popular video streaming solutions today is based on the HTTP Adaptive Streaming (HAS) [2]. HAS client uses HTTP signals to request video chunk with certain bit-rate from the server. The user estimates the TCP throughput, which is used to carry video stream data, to select the corresponding video chunk from the server. This method is called Pull-Based video streaming. It is more suitable for Over-The-Top (OTT) streaming services that do not need high QoS. HTTP-based Adaptive Streaming (HAS) has emerged as the dominant framework for video streaming mainly due to its simplicity, firewall friendliness, and ease of deployment [3]. HAS solutions rely on popular protocols, such as HTTP and TCP, and on standard network services supported currently by the best-effort Internet. An important example of HAS is the well-known and popular MPEG Dynamic Adaptive Streaming over HTTP (DASH) standard that is supported by many major industry players [2]. Consequently, HAS has been receiving a great deal of attention, and many efforts have been proposed toward improving its performance and addressing many of its technical challenges. Some of the primary challenges that have been highlighted and studied by recent efforts include HAS’s inefficiency in using network resources, and its inherent reliance on TCP, which leads to key issues such as delays and a highly 1 undesirable oscillatory behavior that changes the streamed video bitrate and its quality profile rather frequently [4][5][6]. Recent studies have been proposed to improve the performance of HAS technology by improving the rate adaption algorithm and its approach for estimating available bandwidth (e.g. [7][8][9]). Meanwhile, the popularity of multimedia applications and the unprecedented growth of video traffic over the best-effort Internet have arguably aggravated DASH’s challenges and led to a noticeable increase in the frequency and severity of network congestion events [7][9][11]. All of these challenges and issues have resulted in well- documented problems in degrading the end users’ Quality-of-Experience (QoE). More importantly, and as highlighted recently by key marketing studies[12][13], continued degradation in consumer’s QoE could lead to a negative impact on the overall HAS and Over-The-Top (OTT) video market in a very significant way. Another type of a video streaming method is called Push-Based streaming. In this streaming method the server keeps streaming video contents until the client interrupts or stops the server. The server collects information from the client and determines the sending rate. This method usually relies on multimedia transport protocol (like Real-Time Streaming Transport Protocol (RSTP)) rather than TCP. RSTP provides an efficient and low latency medium to multimedia contents. Since this method provides low latency, it is often used for real time streaming applications such as video conference and video broadcasting. One important advantage of Push- based method is Multicast support which is essential in broadcasting. However, the Push-based method has a high overhead on the servers and requires special multimedia servers which make it not commercially profitable as the HTTP/TCP Pull-based method [3]. Additionally, because it uses especial multimedia transport protocol, the Push-based method is not network firewall 2 friendly. Nowadays, real-time transport protocol use is limited to video conference applications like Skype, Google Hangout and Apple Facetime. In addition to smooth video streaming, Multimedia Transport protocol also provides a congestion control mechanism that is essential for fair network resources sharing. For a multimedia transport protocol to achieve the high quality of experience it has to offer the following: a) low network latency and jitter b) high data rate and low queueing delay c) fast response to any change in network bandwidth d) can handle fluctuation in the send video bit rate due to variable rate video coding e) the congestion control mechanism has to be TCP friendly, and f) react to both explicit and implicit congestion indications from the network [14]. 1.2 Video Streaming Related Work HAS is currently the most used technology for video streaming. There have been several works that study the performance of commercial HAS solutions. In [7] the authors summarize the drawbacks of the conventional HAS systems. These drawbacks include: (a) Unfairness among video and non-video flows; (b) Oscillation in the requested video bit rate; and (c) Inefficient video bit-rate selection; and a forth drawback, (d) large delays, especially for live streaming, was studied in [15]. To improve the performance of HAS, several approaches were proposed. The authors of [9] proposed a four-step model (estimate, smooth, quantize and schedule) to design a rate adaptation algorithm. Several studies proposed using control theoretic approaches to govern the rate adaptation process. For example, in [8] proportional integral derivative (PID) controller is used. A stochastic Markov Decision Process (MDP) approach was proposed in [16] to maximize video quality. In [17] the author suggests using an online algorithm to adapt the video bitrate to achieve 3 a stable video quality experience. Scalable Video Coding (SVC) was proposed by [18] and [19] to minimize the required storage for video files and to increase the supported video rates. In [20], the authors proposed a scheduling algorithm to deliver different SVC priority packets over HTTP. The authors in [15] suggested using new a HTTP 2 to reduce the HTTP delay. Regarding Push based method, One of the first real time protocol is the TCP Friendly Rate Control protocol (TFRC)[21] which is a rate-based protocol and the main part of IETF Real Time protocol (RTP). Rate-based protocols offer a smooth video transmission by using TCP sending rate equation. The early Multimedia protocol is focused on maintaining TCP friendliness by using packet loss as the sole indication for congestion in the network, similar to the loss based TCP[22]. However, loss based algorithms tend to fill bottleneck queues and cause buffer bloating [32] . Delay based congestion control algorithms represent the best alternative to loss based congestion control algorithm since they react to increase buffer size [22]. However, it is well known that delay based congestion control algorithms don’t share resources fairly with loss based congestion control algorithms [14]. New real time streaming protocols like Network Assisted Dynamic Adaptation (NADA) and Google Congestion Control (GCC) use delay in addition to packet loss in computing the sending rate to achieve smooth video streaming[14] [22]. IETF Real Time Communication for Web (RTCWeb) proposes to uses GCC algorithm for real time video communication. GCC uses a loss based rate calculation algorithm at the sender, but a delay based rate calculation at the receiver. The algorithm uses both rates to compute the appropriate sending rate [23]. However, the author in [22] found that GCC does not share bottleneck bandwidth fairly with other flows. Another recent algorithm is Network Assisted Dynamic Adaptation (NADA). The algorithm combines packet loss, one-way delay and packet marking into a composite signal that is sent periodically from the receiver to the sender. The 4 sender uses the composite signal to compute a reference sending signal and a rate shaping buffer to achieve a smooth sending rate. Results show that NADA[14] achieves good results in multiple video stream scenarios while it achieves mixed results when competing with TCP flows. 1.3 Multimedia Priority Dropping Quality of service (QoS) is one of the most interesting topics for in computer networking nowadays. A network with QoS provides better performance than best-effort to end flows. Applications such as multimedia requires high quality QoS characteristics (low delay and packet loss) for end to end data flow that the current best effort internet does not offer. Significant research efforts have been made to improve the current internet [24] . It is well known that delivery of optimal video over variable bandwidth networks, such as the Internet, can be achieved by exploiting the multi-priority nature of video content. A primary example of a video-streaming framework that can achieve consistent high-quality video delivery is based on multi-priority queuing of the video packets. In particular, DiffServ [25] has emerged as the leading multi-priority video queueing solution. Under DiffServ, the video stream is divided into sub streams that are marked with different dropping precedence. As packets travel in the DiffServ network, low priority packets are dropped during congestion. To reduce queue management overhead and overall network complexity, the number of DiffServ priority queues is limited to only a few. Another related framework is based on a single network node that utilizes Active Queue Management (AQM) in conjunction with Priority Dropping, or AQM-PD. The single node may use single or multiple queues. Using a single queue with a priority dropping mechanism causes significant overhead when compared with DiffServ. When multi queue is used it is limited to few to reduce 5 complexity. Consequently, despite the broad support for DiffServ within network routers, it has not been utilized in a significant way, and certainly not at the level that HTTP Adaptive Streaming (HAS) based solutions have been employed and used. 1.4 Multimedia Priority Dropping Related Work Priority-based video transmission is a vast area that emerged from the early days of video streaming. Here, we briefly outline a very short list of key solutions that are relevant to the proposed EPIQ framework. In particular, complete system solutions that include end-to-end solutions with full network support and are not limited to network edge solutions like PET (Priority Encoding Transmission) and Unequal Error Protection (UEP) that are widely used in lossy wireless interface (i.e. network edge) One of the first successful efforts to introduce QoS guarantees was DiffServ. Its scalable and distributed mechanism made it the most widely deployed QoS supported technology nowadays[25] . One early example for exploiting unequal priority of video packets using DiffServ was proposed in[26][27]. To take advantage of DiffServ, the packets of a video stream are divided and marked using a rather sophisticated mechanism to adhere to certain ISPs’ policies. The authors of [28] proposed a DiffServ, UMTS and DVB cross-technology system solution that provides priority dropping to video streams across all systems. Because DiffServ packets marking polices are defined by the ISPs not by the end users, any network condition changes inside the DiffServ network would force video packets remarking to maintain adherence to ISPs’ policies[29][30]. However, to overcome DiffServ packet marking polices, authors of[31] proposed a simple differentiated service by supporting multi service profiles (e.g. low delay) for video streams. 6 Other mechanisms were proposed to improve priority-based video transmission using AQM. In general, an AQM algorithm operates on a single network device queue to improve channel utilization and minimize network delay and congestion (See[27] for a comprehensive survey about AQM.). In recent years, AQM has also been proposed to solve buffer bloating within Internet queues[32]. AQM with priority dropping (AQM-PD) provides the desired video stream priority packet dropping. In REDN3[33] , a multi queue AQM algorithm was proposed where each queue use Random Early Detection (RED) [34] algorithm with different packet dropping probability to provide priority dropping. Similarly, the authors in [35] proposed PID-PD, a single queue algorithm that employs proportional-integral-derivative (PID) controller to perform AQM and a sorting algorithm that sorts packets according to their dropping precedence. An analytical model of best effort video transmission is proposed in[36]. The model shows the importance of priority dropping over random dropping in layered video streams. In addition, the author proposed a multi queues mechanism that has different dropping precedence and congestion control algorithm to mark the video packets according to network condition. However, all of the proposed solutions that use multi queues to support video priority dropping have a limited number of queues. If the number of the video priority levels is more than the number of queues then the usefulness (or utility) of the packets delivered to the video decoder cannot be guaranteed. 1.5 Vehicle to Vehicle Safety Systems Vehicle-accident related fatalities, especially those caused by human errors exceed one million every year worldwide [37]. In response to such statistics, a variety of safety measures have been proposed. In particular, in the United States, the US Department of Transportation (USDOT) in 7 collaboration with state-level DOTs and experts nationwide have pursued the development of the Dedicated Short-Range Communications (DSRC) technology and related standards, which are designed for significantly improving safety measures through vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications [38]. The USDOT pilot test program concluded that DSRC can reduce vehicle related accidents significantly. The USDOT also issued a recommendation that the DSRC technology should be mandated for all new light vehicles in the near future [39]. One important category of vehicle-related accidents involves pedestrian-vehicle collision. In the US in 2015, the number of pedestrian fatalities caused by vehicle accidents was 5,376, a 23% increase from 2009. Pedestrians’ fatality is one of the few categories that experienced an increase in the past few years. Furthermore, most of the pedestrian accidents happen in urban areas [40]. One of the many accident scenarios that involve pedestrians is when a stopping vehicle occludes a crossing pedestrian from being viewed by other vehicles. A second passing vehicle’s driver only notices the presence of a crossing pedestrian after the pedestrian is within a very close proximity to the second vehicle. In such scenario, the passing vehicle driver may fail to stop the vehicle in a timely manner, due to the close proximity to the pedestrian, and this leads to a potential injury or even fatality for the pedestrian. 1.6 Vehicle to Vehicle Safety Systems Related Work DSRC is designed to support a variety of Vehicle to Infrastructure (V2I) and Vehicle to Vehicle (V2V) safety applications. In academic literature, extensive research has been done on vehicle communication applications. One of the important applications that rely on DSRC for active safety is C-ADAS. However, many of these safety applications, for example cooperative 8 adaptive cruise control (CACC)[41][42] Cooperative Active Blind-Spot Assistance (CABSA) [43] and Cooperative Frontal Collision Avoidance (CFCA)[44], use DSRC to share only vehicle status information to the surrounding vehicles ( i.e. no radar, lidar or visual information is shared) .See [45] for a comprehensive survey about C-ADAS . In this section we will focus on the work that is related to video streaming over DSRC. Video streaming for safety applications is challenging because such applications require low end-to-end delay and good visual quality. In[46][46] the authors suggest using radar to determine distances between vehicles for efficient power control and to enhance the video quality. In [47]the authors proposed using adaptive MAC that adjusts the retransmission limit based on channel condition. In [48] and [49] the authors proposed using hybrid DSRC/LTE system. The authors suggested using QoS-aware and handover algorithm to switch between the two communication interfaces[50]. From a safety application prospective, in [51][52] the authors proposed using video transmission in overtaking maneuver assistance system (see-through system (STS)). The authors of[53], further improved the system by using adaptive channel coding and heuristic-based power control algorithm. To the best of our knowledge, STS is the only safety application that has been proposed to improve road safety. STS only provides visual information without any additional information. Meanwhile, our proposed system processes and shares both visual and computational information to further improve road safety. A variety of new vehicle models typically include an Advanced Driver Assistance System (ADAS) that helps prevent pedestrian and other forms of accidents. The success of such system usually depends on the distance between the moving vehicle and pedestrian and on the vehicle speed [54]. On the other hand, standard DSRC’s Basic Service Messaging (BSM) application only shares information about the vehicle conditions and status [55]. 9 1.7 Summary of Contributions In this thesis, we introduce novel solutions for video streaming and vehicle safety systems. Our contribution can be summarize to two topics as follows; a) Video streaming: We proposed a novel video streaming framework that is capable of delivering optimal and consistent quality-of-experience similar to the quality promised by DiffServ while requiring minimal low-complexity network support similar to the support provided by standard and popular AQM algorithms over the best-effort Internet. We refer to our framework as Erasable Packets within Internet Queues (EPIQ). There are two important aspects of the proposed EPIQ framework. First, EPIQ is based on a novel packetization of the video content in a way that exploits the inherent multi-priority nature of video. In short, each EPIQ packet consists of multiple segments, and where each segment consists of video data of a different priority (see Fig. 2.1). The highest priority segment is placed next to the packet header whereas the lowest priority segment is placed at the tail of the packet. For example, an EPIQ packet can include Intra-coded frame (I-frame) bytes next to the header, followed by Prediction frame (P-frame) bytes, and then Bi-directional (B-frame) bytes at the tail of the packet. This novel packetization enables the second major aspect of the proposed EPIQ framework. Under congestion, a simple AQM mechanism can be realized where a network router could drop (or erase) only small portions located toward the tail of EPIQ packets instead of dropping complete packets as traditionally done by current routers. Hence, EPIQ enables a novel partial erasing paradigm within the network. Thus, we refer to an EPIQ packet as Partially Erasable Packet (PEP). Throughout this dissertation, we will use the two terms “EPIQ packets” and “PEP packets” interchangeably. It is important to note that EPIQ does not require multi-priority queues or highly complex marking algorithms. There is no need to maintain state information of any set 10 of separate flows or multiple queues. EPIQ can be realized using a single queue, and the only added complexity is that the router needs to distinguish between PEP packets and traditional packets. b) Vehicle Safety: We propose a novel Cooperative Advanced Driver Assistance System (C- ADAS) and we call it Cooperative Pedestrian Collision Avoidance System (CPCAS). The system could improve vehicle safety significantly, and consequently, it could save thousands of lives and prevent many injuries annually. Our system’s aim is to improve road safety by enabling vehicles to share sensors information to improve their on-board active safety systems and driver assistance system. Our novel system design is flexible and comprehensive because it can share any type of sensor information with other vehicles. Here, we mainly focus on visual information sharing in reducing pedestrian accidents. In particular, the system shares vehicle’s visual and data information about detected objects that are occluded from other surrounding vehicles. Our proposed system includes a novel selective sharing algorithm. Specifically, the system provides low latency information sharing that enables the driver and active safety systems to make a real- time emergency decision. The low latency is attributed to DSRC equipment and, more importantly, to our selective sharing algorithm. We present results that are based on actual road tests. We conducted our experiments using DSRC compatible devices and off the shelf sensors to validate our system performance and functionality. 1.8 Thesis Organization The remainder of the Thesis is organized as follows. • Chapter 2 presents the EPIQ framework and its analytical model. 11 • Chapter 3 describes the detailed aspects of EPIQ including the AQM (EPIQ-RED) and rate control mechanisms (EPIQ-TFRC). • Chapter 4 presents our extensive ns-2 based simulation results. • Chapter 5 presents our vehicle to vehicle safety system design and implementation • Chapter 6 provides a brief summary of the dissertation 12 Chapter 2 EPIQ System Design and Analysis 2.1 EPIQ System Overview Traditional random packet dropping by the network could cause severe degradation in the quality of user experience of streamed video applications. This quality-of-experience degradation is usually manifested by frequent video-freeze events [36]. A root cause of this phenomenon is the well-known dependency among video packets and the inherent multi-priority nature of compressed video content. The proposed EPIQ framework mitigates these issues through a novel packet design that we call a Partially Erasable Packet (PEP) structure. A PEP structure is conceptually simple, and it is illustrated in Fig. 2.1. For any set of compressed video frames, we can identify different levels of priority for the content of such set. These levels could correspond to different picture types (i.e., I, P, and B frames) of a non-scalable video stream; or, they could correspond to different layers of a scalable video frame (i.e., a base-layer and multiple enhancement layers); or, a combination of both. Whatever the case, a video stream can be divided into different priority levels as shown in Fig. 2.1. Under EPIQ, we partition the video content of each priority-level and distribute that content into multiple PEP packets. More importantly, we place the highest priority content next to the header while placing the lowest priority content at the tail end of the packet. All other priority levels are placed progressively between the highest and lowest priority level content between the header and the tail of the packet as shown in Fig. 2.1. For the sake of clarity in the presentation and analysis, we present a few definitions associated with the proposed EPIQ framework and PEP structure. EPIQ Video Set (EVS) represents a set of prioritized video content. In general, EVS could represent any set of video 13 frames that can be partitioned into multiple priorities. For example, an EVS can correspond to a GoP for non-scalable video. Figure 2.1: The mapping of multi-priority video content from an EPIQ Video Set (left) to Partially Erasable Packets of an EPIQ Packet Set (right) EVS could also correspond to a single scalable frame that includes multiple layers of a scalable video stream. Hence, an EVS represents a video content that can be partitioned into multiple priority levels (the left side of Fig. 2.1). EPIQ Packet Set (EPS) represents the set of PEP packets that carry the content of one EVS. Thus, we divide each EVS priority level into different segments that we distribute among the packets of an EPS. Although not necessarily the case, in Fig. 2.1, each EVS priority level is divided into equal-size segments, which are uniformly distributed among the EPS packets. The novelty and power of the proposed EPIQ packet structure is that it enables a simple and best-effort-like queue management mechanism while mimicking and achieving the benefits of multi-priority queue management approaches. During congestion, and instead of dropping a complete packet, a router can now simply erase an arbitrary portion of a PEP packet starting from its tail. It is important to note that the router does not have to be aware of the number of 14 priority segments or their sizes within a PEP packet. Based on a RED-like AQM algorithm, the router can decide the size of the portion to be dropped from any randomly selected set of PEP packets. Hence, this partial erasing paradigm leads to dropping low-priority content and preserving high-priority content. Consequently, an EPIQ streaming solution can achieve the performance of complex multi-queue systems while maintaining the low-complexity of best- effort solutions without the need to manage a large number of queues or maintain the state information of a large number of flows. The only added complexity for an EPIQ-based solution is that the router needs to simply identify if the packet has a traditional structure or if it is a PEP packet. This requirement can be simply achieved, for example, by using the IPv4 header’s differentiated services code point (DSCP) and flag fields. Also, to increase the speed of the packets selection process, the router could maintain a list that points to the starting locations of the PEP packets in the queue. Finally, it is worth noting the following. For a given EPIQ packet set, the EPIQ sender usually generates equal-priority packets since each PEP packet contains the same priority levels. This notion reinforces the need for single queue AQM management since all PEP packets are, in general, equally important. 2.2 Systems Analytical Model In this section, we develop an analytical model for the performance of the proposed system. This analytical model is intended to provide an insight into how our system performs in comparison with other traditional streaming systems. 2.2.1 EPIQ Our analysis is applied to an EPIQ packet set (EPS) that carries the content of multi-priority video. An EPIQ packet set can represent the content associated with a single scalable video 15 frame that is mapped onto this packet set. Or, an EPS set can carry the content of a complete GoP of scalable or non-scalable frames. In general, successful decoding of low-priority data requires successful delivery and decoding of higher-priority data; otherwise, lower-priority data become useless even if they are delivered. Hence, regardless of the form of an EPIQ packet set, it is crucial to evaluate the utility of the data delivered. Thus, our objective here is to quantify the performance of our system by measuring the utility of the delivered data to the decoder. This is crucial for achieving optimal video delivery since reducing congestion by dropping video content should have minimal detrimental effect on video quality. Let (cid:1) be the probability of dropping a packet within the network under traditional best-effort streaming (e.g., using HAS or RTP). If the average size of a packet is (cid:2) bytes, then (cid:1) is also the probability of dropping (cid:2) bytes. Under the proposed EPIQ framework, (cid:1) becomes the probability of erasing the same number ((cid:2)) bytes from PEP packets in the network queue. Hence, in either case, (cid:1) represents the average loss rate. Further, Fig. 2.2 shows an example for mapping a traditional scalable video frame with (cid:3)(cid:4) packets into an EPIQ packet set using the same number (cid:3)(cid:4) of Partially Erasable Packets (PEPs). Let (cid:5)(cid:6) be the size of one EPIQ packet set in bytes. Since (cid:2) is the packet size in bytes, for For our analysis, we use a set of parameters that are outlined and described in Table 2.1. both the traditional and EPIQ packetization we have the following: (2.1) (cid:5)(cid:6)=(cid:3)(cid:4) ⋅(cid:2) 16 Table 2.1: Stochastic model parameters Parameter (cid:3)(cid:4) (cid:2) (cid:3)(cid:10) (cid:11) (cid:11)̅ ∆ (cid:5)(cid:6) (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) (cid:5)(cid:18)(cid:19) (cid:5)(cid:20) Description Number of packets in an EPIQ packet set (EPS). For consistency, this is the same number of packets used to packetize the corresponding video data according to a traditional approach. Size of each packet in bytes. This can be the average size of a packet when the packets have variable sizes. Or, it can be a constant if the same size used for all transmitted packets. Number of packets (from an EPIQ packet set) that are subjected to partial erasing. Number of bytes that are erased (or “deleted”) from each of the (cid:3)(cid:10) Partially Erasable Packets (PEPs) of an EPIQ packet set. Note that (cid:11) The expected value of (cid:11). varies from one EPS to another. Expected loss in one layer Total number of bytes in an EPIQ packet set: (cid:5)(cid:6)=(cid:3)(cid:4)⋅(cid:2) Erasable Packets (PEPs). The total number of bytes that are erased (lost) by a router due to a congestion event. Under EPIQ, this erasing takes place over (cid:3)(cid:10) Partially For consistency, (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) also represents the total number of bytes lost due to (cid:5)(cid:14)(cid:15)(cid:16)(cid:17)=(cid:11)⋅(cid:3)(cid:10) packet dropping under a traditional approach. The number of bytes of an EPS that become useless (or unused by the video decoder) due to a loss/erasing event. Useful data, measured by number of bytes from an EPIQ packet set, that are used by the video decoder: (cid:5)(cid:20)=(cid:5)(cid:6)−(cid:22)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)+(cid:5)(cid:18)(cid:19)(cid:24) 17 Note that Eq. (2.1) is valid for both our proposed solution and a conventional system. One of the important aspects of our proposed analysis is that it maintains consistency in terms of the amount of lost data in comparison with a conventional system. To capture this consistency, let (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) be the number of bytes that would be lost in a conventional system due to packet dropping. Now, if the probability of dropping a packet is (cid:1), then the expected value of the number of bytes to be lost within an EPIQ packet set can be written as: (cid:25)(cid:26)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:27)=(cid:1)⋅(cid:5)(cid:6) (2.2) (traditional and EPIQ). number of bytes lost due to erasing portions of multiple packets. Either case, we use the same Similarly, we use (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) to represent the total number of bytes lost from an EPIQ packet set due to partial erasing. Note that in a conventional system, (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) corresponds to the number of bytes lost due to dropping complete packets; while in our proposed solution (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) represents the value for (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) for the sake of consistency and fairness when comparing the two solutions To capture our partial erasing (PE) process for distributing the loss (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) bytes over multiple packets, we define two parameters (cid:3)(cid:10) and δ(cid:29). Fig. 2.2 shows an illustrative example, where (cid:3)(cid:10)= 3 packets that have been randomly selected by the network for partial erasing. In general, each that the Fig 2.2 shows that the (cid:3)(cid:10)=3 selected packets are contiguous. This is not necessarily selected packet that is subjected to partial erasing encounters a different level of erasing. Note the case; contiguous packets are shown in the Fig 2.2 mainly for ease of presentation. Also, the dropped portions are arbitrary, and they do not have to coincide with the border of video slices within the selected PEP packets. While there are many PEP packets in the queue, the EPIQ AQM algorithm can select any number of PEP packets. As our analysis and simulations will demonstrate, optimum video quality can be achieved by selecting the maximum possible number 18 of packets in the queue for partial erasing. This process, however, leads to a variable number when congestion occurs at the network, then at the receiver, we may observe anywhere from a ((cid:3)(cid:10)) of packets (from a given EPIQ packet set) that encounter partial erasing. Consequently, single packet to a maximum number of (cid:3)(cid:4) packets that have suffered from partial erasing for a given EPIQ packet set. Hence, under congestion, (cid:3)(cid:10) is a uniform random variable with a probability mass function (cid:31) !. It is important to note that we are assuming that the erasing The second parameter in this analysis, (cid:11)̅, represents the average number of bytes that are erased from the (cid:3)(cid:10) packets selected for partial erasing. Consequently, for an EPIQ based loss happens at the slice boundary. We call this EPIQ Fine Grain Scalability (FGS) model. event, on average, we have the following: (cid:11)̅=(cid:25)"(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:3)(cid:10) # (2.3) Figure 2.2: EPIQ vs. conventional packetization Now, we would like to compute the amount of useful data received by the decoder. Let (cid:5)(cid:20) be the useful data (measured in bytes) recovered from one EPIQ packet set (EPS), which consists of 19 (cid:3)(cid:4) PEP packets. As illustrated in Fig. 2.2, the useful portion is the lower part of PEP packets that belong to the same EPIQ packet set. Hence, under this model, on average, erasing a set of (cid:11)̅ bytes from the (cid:3)(cid:10) packets that have been subjected to partial erasing will, on average, cause (cid:11)̅ bytes from all other (cid:22)(cid:3)(cid:4)−(cid:3)(cid:10)(cid:24) packets of an EPIQ packet set to become useless. Consequently, we have the following: (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)$%&=(cid:5)(cid:6)−(cid:11)̅⋅(cid:3)(cid:4)=(cid:5)(cid:6)−(cid:25)"(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:3)(cid:10) #⋅(cid:3)(cid:4) +*-.(cid:22)(cid:3)(cid:10)(cid:24)(cid:25)(cid:26)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:27) (cid:25)"(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:3)(cid:10) #≅(cid:25)(cid:26)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:27) (cid:25)/(cid:26)(cid:3)(cid:10)(cid:27) (cid:25)(cid:26)(cid:3)(cid:10)(cid:27) −()*(cid:22)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17),(cid:3)(cid:10)(cid:24) (cid:25),(cid:26)(cid:3)(cid:10)(cid:27) (2.4) (2.5) Here, we assume that: (a) the variation in (cid:3)(cid:10) value is rather small relative to its mean; and (b) the correlation between (cid:5)(cid:14)(cid:15)(cid:16)(cid:17) and (cid:3)(cid:10) is also small relative to the expected value of (cid:3)(cid:10). Our simulation results confirm that these assumptions are quite reasonable. This leads to the first order approximation of Eq. (2.5). Hence, Or, (cid:25)"(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:3)(cid:10) #≅(cid:25)(cid:26)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:27) (cid:25)(cid:26)(cid:3)(cid:10)(cid:27) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)$%&=(cid:5)(cid:6)−(cid:25)(cid:26)(cid:5)(cid:14)(cid:15)(cid:16)(cid:17)(cid:27) (cid:25)(cid:26)(cid:3)(cid:10)(cid:27) ⋅(cid:3)(cid:4) (2.6) (2.7) (2.8) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)$%&=(cid:5)(cid:6) 01− (cid:1).(cid:3)(cid:4)(cid:25)(cid:26)(cid:3)(cid:10)(cid:27) 3=(cid:5)(cid:6) 01−2.(cid:1).(cid:3)(cid:4) 1+(cid:3)(cid:4)3 In the FGS model we assume that the erasing happens at the EPIQ slice boundary. We would consider the FGS an ideal model for our system performance when we have Multi Grain 20 Scalability (MGS) coding like Scalable Video Coding (SVC). In practice, the lower priority frames tend to be small, thus it is more likely to experience drop at the boundary rather than experiencing partial erasing. When a layer experiences partial erasing the whole layer become useless. Fig. 2.3 shows the difference between the two models. Figure 2.3: EPIQ FGS vs. EPIQ MGS packetization As we stated earlier, the EPIQ Packet Set (EPS) may carry one frame and its enhancement layers or a GoP frames. Let’s assume that each PEP consists of 5 slices (cid:22) 6(cid:31)…68(cid:24) and a slice size of 9: bytes. Low priority layers are small which results in small slices size that reduces our similar size of ; such that useless data. However, for simplicity, let’s assume all layers that are carried by one EPS have a (2.9) 8 (cid:5)(cid:6)=(cid:3)(cid:4) <=9: (cid:31) >=(cid:3)(cid:4) (cid:22)5∗;(cid:24) Even losing the smallest portion of a layer will result in a useless layer. Since we are assuming equally sized slices, then we can find the useless portion of the layer ∆ in one PEP using (cid:26)(cid:5)(cid:20)(cid:27) in Eq. (2.8) as (2.10) ∆= @ (cid:26)(cid:5)(cid:20)(cid:27);∗(cid:3)(cid:4)−A (cid:26)(cid:5)(cid:20)(cid:27);∗(cid:3)(cid:4)BC . ; 21 The expected usefulness for our MGS model (cid:26)(cid:5)(cid:20)(cid:27)D%& can be rewritten as follows To further normalize the models, we define a utility function E: (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D%&=(cid:5)(cid:6)−(cid:22)(cid:11)̅+∆(cid:24)⋅(cid:3)(cid:4) (2.11) (2.12) (2.13) (2.14) (2.15) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27) E= (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)FGHGI:(cid:17)J Where (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)FGHGI:(cid:17)J is the channel capacity which is: (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)FGHGI:(cid:17)J=(cid:3)H(cid:22)1−(cid:1)(cid:24) E(cid:10)(cid:4)KL_$%&= (cid:5)N−(cid:11)(cid:29)⋅(cid:3)O 1−(cid:1) E(cid:10)(cid:4)KL_D%&=(cid:5)N−(cid:22)(cid:11)(cid:29)+∆(cid:24)⋅(cid:3)O 1−(cid:1) A comparison between the two models is shown in Fig. 2.4. It is clear that the ideal model (FGS) performs better than the MGS model. However, we can notice that increasing the number of layers in each packet improves the performance. Hence, we can improve the performance by increasing the size of EPIQ Packet Set (EPS) 22 y t i l i t U 1 0.8 0.6 0.4 0.2 0 0 20 40 60 Channel Capacity EPIQ-FGS EPIQ-MGS-3 EPIQ-MGS-8 140 160 180 200 80 100 120 Np: Video set size Figure 2.4: EPIQ FGS vs. EPIQ MGS utilization 2.2.2 Best Effort In Best Effort (BE) video transmission, all video packets are treated equally regardless of the packets contents priority. Similar to our proposed system, EPIQ, we measure the performance of the BE system by computing the usefulness of the received packets. An analytical model for Fine Granularity Scalability (FGS) stream is developed in[36] for Best Effort streaming. The model can be used to measure the performance of a packet with sequential dependency. Using the same terminology for EPIQ, let (cid:1) be the probability of packets dropping and (cid:3)(cid:4) be the number of distance between two packets drop locations is a geometric random variable. If packet P packets in a video set. The video set can be GoP or SVC frame. Now, let us assume that the 23 experiences packet loss, then P−1 packets are useful. The expected usefulness of BE can be written as: ! :V(cid:31) ! :V(cid:31) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)Q(cid:10)RST==(cid:22)P−1(cid:24)(cid:22)1−(cid:1)(cid:24):U(cid:31)(cid:1) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)Q(cid:10)RST=(cid:1)=(cid:22)P−1(cid:24)(cid:22)1−(cid:1)(cid:24):U(cid:31) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)Q(cid:10)RST=(cid:1) = Y(cid:22)1−(cid:1)(cid:24)(cid:14) ! :V(cid:31) !U(cid:31) !U(cid:31) :VZ :VZ (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)Q(cid:10)RST=(cid:31)UHH (cid:22)1−(cid:22)1−(cid:1)(cid:24) !) The two summations terms can be reduced to : W + = (cid:3)(cid:4)(cid:22)1−(cid:1)(cid:24):U(cid:31)(cid:1) :V !X(cid:31) +(cid:3)(cid:4)(cid:22) 1−(cid:1)=(cid:22)1−(cid:1)(cid:24):U(cid:31) +(cid:3)(cid:4)(cid:22) 1−(cid:1) =(cid:22)1−(cid:1)(cid:24)(cid:14) (cid:24) (cid:24) (2.16) (2.17) (2.18) (2.19) Similar to the EPIQ system , we developed an MGS model for the Best effort system. Fig 3.5 shows the difference between the FGS and the MGS models of BE system. The expected usefulness for the MGS model of the Best Effort model can be written as 8 (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)Q(cid:10)[ST=<=6: :V(cid:31) 8 >\](cid:22)1−(cid:1)(cid:24)^_ :V(cid:31) ‘ (cid:22)1−(cid:22)1−(cid:1)(cid:24)^abc(cid:24) (2.20) Similar to EPIQ, we compare the utilization of the MGS and the FGS models of the BE system. Fig. 2.6 shows a comparison between the two Best Effort models. It is clear that the FGS model performs better than the MGS model. 24 Figure 2.5: BE FGS vs. BE MGS packetization 1 0.8 0.6 y t i l i t U 0.4 0.2 Channel Capacity BE-FGS BE-MGS-3 BE-MGS-8 0 0 20 40 60 100 80 120 Np: Video set size 140 160 180 200 Figure 2.6: BE FGS vs. BE MGS utilization 25 2.2.3 Multi Priority Queue (MPQ) In MPQ, the system manages a number of queues where each queue has a different packet dropping precedence. Hence, (cid:3)(cid:4) packets are enqueued into MPQ system according to packet importance. In an ideal scenario, only packets that belong to the lowest priority queue are dropped during congestion. In that case, we can consider Eq.(2.12) to represent the expected useful data of the last queue (least important) of the MPQ system while higher priority queues do not experience any packet dropping. Assuming that the MPQ system has 9 queues and each queue can accommodate 5: packets, then, the useful data of the MPQ system (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)L can be expressed in terms of the variable (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)Ld , which is the expected usefulness of the 9(cid:17)e queue. Thus, Eq. (2.11) can be rewritten as: dU(cid:31) (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)LRST==5: :V(cid:31) +(cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)Ld (2.21) Where (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)Ld is the expected usefulness of the 9(cid:17)e queue. Eq. (2.13) can be rewritten as: (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)LRST=(cid:22)(cid:3)H−5d(cid:24)+ 1−(cid:1)d(cid:1)d (cid:22)1−(cid:22)1−(cid:1)d(cid:24)(cid:24)8f It is important to note that (cid:1)d is not the same as the (cid:1) that is found in Eq.(2.12); however, it is related to it. (cid:1)d can be calculated using the following relationship : +(cid:1)=(cid:1)(cid:22)1+(cid:3)H−5d5d (cid:24) (cid:1)d=(cid:1)g(cid:3)H−5dh 5d (2.22) (2.23) 26 To develop our MGS model for the MPQ system, we use the same concept that we used in developing the FGS model. Using the BE MGS model as our reference, the MGS model for the MPQ system can be written as follows: ^f (cid:25)(cid:26)(cid:5)(cid:20)(cid:27)D(cid:4)L[ST==6: : 8 :V^f jk](cid:22)1−(cid:1)d(cid:24)^_ +i=6: 8 :V^f l (cid:22)1−(cid:22)1−(cid:1)d(cid:24)^abc(cid:24) (2.24) The FGS and MGS performances of the MPQ system are shown in Fig. 2.7. It is evidently that the FGS performs better performance. Furthermore, we can measure the performance of the MPQ system by comparing the number of priority queues with the number of packets carried. The best performance can be achieved when both the number of priority queues and the number of video layers are the same. 1 0.8 0.6 y t i l i t U 0.4 0.2 Channel Capacity MPQ-FGS MPQ-MGS-3 MPQ-MGS-8 0 0 20 40 60 100 80 120 Np: Video set size 140 160 180 200 Figure 2.7: MPQ FGS vs. MPQ MGS utilization 27 The utility function represents the ratio of the useful information received relative to channel capacity. Fig. 2.8 shows a comparison of the utility as a function of the number of packets in an significantly higher levels of useful data to the receiver when compared with BE. In addition, it EPIQ packet set ((cid:3)(cid:4)) for EPIQ, MPQ and BE FGS models. It is obvious that our system delivers also outperforms MPQ with 3 priority queues usefulness. For example, EPIQ at (cid:3)(cid:4)=20 Further illustrate the difference, when (cid:3)(cid:4)=100, EPIQ achieves 89% while MPQ-3 and BE achieves 90% utility while MPQ-3 and BE achieve 85.5% and 40% utility respectively. To could only maintain 76% and 10% respectively. Our extensive simulations will further validate the results of this model. 1 0.8 0.6 y t i l i t U 0.4 0.2 Channel Capacity EPIQ-FGS MPQ-FGS BE-FGS 0 0 20 40 60 120 80 Np: Video set size 100 140 160 180 200 Figure 2.8: FGS utility for EPIQ, BE and MPQ 28 1 0.8 0.6 y t i l i t U 0.4 0.2 Channel Capacity EPIQ-MGS-3 EPIQ-MGS-8 MPQ-MGS-3 MPQ-MGS-8 BE-MGS-3 BE-MGS-8 0 0 20 40 60 100 80 120 Np: Video set size 140 160 180 200 Figure 2.9: MGS utility as a function of video-set size for EPIQ, BE and MPQ Fig. 2.9 shows a comparison of the utility as a function of the number of packets in an EPIQ packet set ((cid:3)(cid:4)) for EPIQ, MPQ and BE MGS models for a frame with 3 and 8 layers. For the case of MPQ, we used 3 priority queues. For the 3 layers video, only the lowest layer experienced packet loss while for the 8 layers video, the last two layers experienced packet loss. It is obvious that for the 8 layer frame, our system delivers a higher level of useful data to the receiver when compared with the BE and MPQ models. It is also clear that MPQ achieves optimum performance when only the lowest priority experiences lost at the lowest priority queue. In other words, the MPQ model achieves the optimum performance when the number of queues equals the number of layers. It is important to note that the BE model with 8 layers has 29 higher utility than BE with 3 layers. Hence, utility increases as the number of layers increases. Our extensive simulations will further validate the results of this model. 2.3 Experimental Evaluation In this section we discuss the experiment that is conducted to verify our model 2.3.1 Experimental Setup We used the ns-2 simulator to implement the EPIQ framework. The simulation topology consisted of a sender, receiver and a middle box that represents the congested network. The video content was generated and evaluated using JVT reference software[56], SAEF framework [57] and Open SVC Decoder[58]. We simulate both AVC and SVC [59] video stream of Park Run video sequence encoded at 50 FPS and GoP of size 8. The SVC stream consisted of one base layer and two enhancement layers and GOP of size 8. Both streams have Peak Signal to Noise Ratio (PSNR) quality of 36.6 dB. We evaluated the performance of our proposed method and multi-priority systems at packet loss probability (cid:1) of 1%, 5%, 10%, 20% and 30%. Best effort video transmission results were not included in our experiment because the results were always showing the same result of 17dB which is the same as random noise data. Therefore, we only compared our model with Multi-Priority Queue system. a) EPIQ To configure EPIQ, we need to determine the content of our EPS and the number of packets to be erased during congestion. For the AVC video stream, we specified that each EPIQ video set (EPS) carry the content of one GoP, which consists, in our simulations, of 8 frames. In the SVC case, we have chosen two different configurations; in the first configuration; the EPS carried the content of one SVC frame (3 layers), while in the second configuration, the EPS carried the 30 content of one SVC GoP frames. As stated earlier in the analysis section, any number of EPS packets can be selected during congestion. b) Multi Priority Queue (MPQ) In the multi-priority system case, one queue is assigned for each priority in the congested node so that during congestion the lowest priority queue drops its packets. For AVC stream, we decided to use the most common number of priority queues which is three based on frame types (I, P and B) classification. In a second scenario, we decided to use the maximum number of possible priorities that the video supports to capture the frame’s dependency. In such ideal case, the number of priorities is the GoP size, which is eight in our configuration. For SVC video, first we decided to use three priority queues and assign the highest priority to the base layer while the second and third (lowest priority) are assigned to the first and second enhancement layers respectively. In another SVC scenario, similar to AVC 2nd scenario, we set the number of priorities to the maximum number of priorities that can be supported by the SVC stream. In such case, the number of priorities is set to the GoP size multiplied by the number of video layers (i.e., the total number of priorities is 24 in the ideal SVC case). 2.3.2 Experimental Results Fig..2. shows the average PSNR of the received video of both EPIQ and the multi-priority solution for the AVC stream case. Our proposed method (EPIQ-GoP), on average, is both 6dB better than the system supporting three-priority queues (Pri-3) within the network, and only 0.8 dB less than the significantly more complex (ideal) eight-priority system (Pri-8). The reason behind the poor performance of the three-priority system is that although it gives highest priority to I and P frames, it assigns the same lowest priority to all B frames without taking into 31 consideration the dependability among B frames. Meanwhile, the eight-priority system takes into consideration all frame dependencies with added overhead of managing eight queues rather than three. On the other hand, our system employs a single queue without complex management or significant overhead, and its performance is independent of the number of priority levels that are carried by the video packets. ) B d ( R N S P 35 30 25 20 15 10 0 EPIQ-GoP Pri-8 Pri-3 0.05 0.1 0.15 0.2 0.25 0.3 Packet dropping probability p Figure: 2.10: PSNR of EPIQ and MPQ for AVC stream Fig. 2.5 shows the results of SVC video streaming for both EPIQ and the multi-priority system. For the three-priority queues (Pri-3), it is noticeable that the PSNR values do not change even when the number of dropped packets increases. The reason for such behavior is that the decoder is only decoding the first enhancement layer. Similar to the AVC case, not all of layer two (enhancement layer) packets have the same priority. Our proposed system performance with EPS carrying only one frame content (EPIQ-Frame) is 3 dB better than the three-priority systems (Pri-3). It is important to note that EPIQ with EPS carrying GoP (EPIQ-GoP) achieves, on 32 average, virtually the same performance of the ideal high-complexity 24 -priority system (Pri- 24); the difference in performance is only 0.3dB. ) B d ( R N S P 37 36 35 34 33 32 31 30 0 EPIQ-GoP EPIQ-Frame Pri-24 Pri-3 0.05 0.1 0.15 0.2 0.25 0.3 Packet dropping probability p Figure 2.11: PSNR of EPIQ and MPQ for SVC stream 33 Chapter 3 EPIQ System Implementation To implement the concept that we discussed in previous chapter, we use Active Queue Management (AQM) that exists in the network nodes. So in this chapter, we first discuss our proposed AQM algorithm. Also, to complement our AQM role, we implement rate control algorithm which is discussed in the second part of this chapter. 3.1 Active Queue Management In this section we propose a mechanism as a part of our framework. The goal of the algorithm is to maximize the performance of Partial Erasing process in addition to its role as AQM algorithm. 3.1.1 EPIQ-Random Early Detection algorithm (EPIQ-RED) Despite the many AQM approaches that have been proposed, only a few have been incorporated in Internet routers and are being used in practice[27]. Hence, we are interested in focusing on employing existing AQM algorithms and concepts that have been used in practice in conjunction with the proposed EPIQ framework. In particular, our AQM algorithm is built on the popular Random Early Detection (RED) algorithm[60]. In light of efforts that studied, analyzed, and improved RED [60][61], we designed our algorithm by taking these approaches into consideration; and we call our approach EPIQ Random Early Detection (EPIQ-RED). It is important to note that we use Byte version (Byte mode) and packet marking (Explicit Congestion Notification (ECN)) of the RED algorithm. Under RED, the AQM algorithm drops a packet entering the queue with a certain probability when the queue size operates within certain thresholds. Here, (cid:1)G represents the AQM algorithm packet dropping probability, and nGop is the queue average size in bytes. The 9Pq(cid:17)e and 9-r(cid:17)e 34 parameters are the RED maximum and minimum thresholds, respectively. To calculate the dropping probability (cid:1)G, we modified the original RED algorithm by fixing the 9-rH parameter of RED to 1. Thus leading to: (cid:1)G=(cid:22)nGop−9Pq(cid:17)e(cid:24) 9-r(cid:17)e−9Pq(cid:17)e The advantage of fixing the parameter 9-rH is to have a continuous linear dropping probability. Discontinuity in the dropping probability has a negative effect on the performance (3.0) [61][21]. Many studies have proposed a modified RED that enables automatic parameters configuration; however, in many cases such configuration is dynamic in nature. In our case, we introduce simple modifications to the original RED, where we take into consideration the proposed EPIQ system requirements in terms of delivering optimal video performance while selected for partial erasing might belong to multiple EPIQ packet sets that belong to multiple maintaining RED automation. One key EPIQ-RED parameter is (cid:3), which is related to (but not the same as) the parameter (cid:3)(cid:10) described in Chapter 2. Here, (cid:3) represents the number of PEP packets that are selected randomly from the queue for partial erasing. These (cid:3) packets that are users. On the other hand, (cid:3)(cid:10), which was employed by our analysis in Chapter 2, is the number of single receiver). Hence, under EPIQ-RED, (cid:3) PEP packets, which may belong to one or more for an optimal EPIQ performance, we need to have the value of (cid:3) as large as possible. packets within a single EPIQ packet set that suffer from partial erasing (as observed by a given EPIQ packet sets, are randomly selected from the queue for partial erasing. As explained earlier, Consequently, it is possible that all the PEP packets that belong to the same EPS can be selected. Assuming that we have different EPIQ packet sets with different sizes in the queue, under EPIQ- RED, we set (cid:3) to some maximum value (cid:3)dGs. Here, (cid:3)dGs can be thought of as the maximum 35 (cid:3)=9Pq (cid:22)n(cid:10)L,(cid:3)dGs(cid:24) number of packets of an EPIQ packet set. However, in cases when (cid:3)dGs is larger than the current number of PEP packets in the queue, (cid:3) is set to the current number of EPIQ packets in the queue n(cid:10)L. Hence, Recall that PEP packets have a size of (cid:2) bytes. Although it is possible to erase more than one packet size (cid:2) of bytes at a time, we use the RED standard queue management procedure where different non-EPIQ flows. The amount of data that are erased from each of the (cid:3) selected packets is represented by (cid:11): one packet is dropped (or erased) at a time. This is also important to achieve fairness with (3.1) (3.2) (cid:11)=(cid:2)(cid:3) It is important to note that in our design of EPIQ-RED, we take into consideration that the network queues might have a mix of EPIQ and traditional packets. Hence, to accelerate the process of packet erasing, EPIQ-RED has to maintain the location and the number of EPIQ packets in the queue. A virtual list can be used to point to the location of the EPIQ packets in the queue. The minimum number of packets for RED threshold 9Pq(cid:17)e is usually set to a number of bytes equivalent to five packets as recommended by [60][62]. However, and since we are planning to spread the erasing process over as many EPIQ packets as possible, a small queue will affect EPIQ transmitted video quality as shown in Eq. (3.1)-(3.2). Thus, we set the minimum threshold 9Pq(cid:17)e as the maximum between the RED recommended threshold and the average value of the EPIQ packet set size (cid:3)t(cid:4). On the other hand, a large queue will cause long delays. As prevents buffer-bloating. Hence, we set 9-r(cid:17)e as the minimum between: (a) The number of discussed in [32], limiting the number of packets in the queue reduces packet latency and 36 is because EPIQ video content will most likely occupy more than half of the queue. Setting packets in the queue (cid:3)L(cid:22)u(cid:24) that is equivalent to a u=0.2 second packet delay; and (b) Twice the maximum size (cid:3)dGs of an EPIQ packet set. The motivation for choosing twice the size of (cid:3)dGs, 9-r(cid:17)e to 2(cid:3)dGs allows (cid:3)dGs or a higher number of PEP packets in the queue. Hence, in terms of bytes, we employ the following expressions for 9Pq(cid:17)e and 9-r(cid:17)e: 9-r(cid:17)e=(cid:2)⋅9Pq(cid:22) (cid:3)L(cid:22)u(cid:24),2⋅(cid:3)dGs(cid:24) To have a more stable queue we let 9Pq(cid:17)e and 9-r(cid:17)e be increasing functions and updated The algorithm works by evaluating (cid:1)G for every incoming packet. If the packet that is marked to be dropped is a Partially Erased Packet (PEP), the packet is enqueued and (cid:3) PEP 9Pq(cid:17)e=(cid:2)⋅9-r (cid:22)5,0.5(cid:3)t(cid:4)(cid:24). every 5 minutes. In Section 3.3, we show the stability of our proposed AQM algorithm. (3.3) (3.4) packets are randomly selected from the queue by using the virtual list and are partially erased; and only one packet is marked as lost. If it is not a PEP packet, the packet is dropped. Thus, we guarantee fairness between the different data types of traffic in the queue. 3.1.2 Stability analysis of EPIQ-Random Early Detection algorithm (EPIQ-RED) To prove the functionality of our proposed algorithm, we used the linearized TCP model that was developed in [61]. The proposed model paved the way for the control theoretic AQM algorithm. The following is a brief review. Starting with the fluid model of a network that consists of a TCP sender, AQM and receiver. wx(cid:22)y(cid:24)= 1z(cid:22)y(cid:24)−w(cid:22)y(cid:24)wgy−z(cid:22)N(cid:24)h 2zgy−z(cid:22)y(cid:24)h nx(cid:22)y(cid:24)=w(cid:22)y(cid:24)z(cid:22)y(cid:24)(cid:3)(cid:22)y(cid:24)−{ (cid:1)(cid:22)y−z(cid:22)y(cid:24)(cid:24) 37 (3.5) (3.6) Where w,n,z,{,(cid:3) -q| (cid:1) are expected TCP windows size in packets, expected queue length in packets, round trip time, link capacity, number of TCP session and probability of packet marking/dropping, respectively. Since the TCP model is a nonlinear system, the model must be linearized to be able to do classical linear system analysis. The linearization process starts with defining an equilibrium point (wZ,nZ,(cid:1)Z(cid:24) when wx(cid:22)y(cid:24)=0 -q| nx(cid:22)y(cid:24)=0 , So that Where NH is propagation delay. The TCP model is linearized about the equilibrium points. Using Taylor series linearization method, the linearized model after simplification is (3.7) (3.8) (3.9) (3.10) (3.11) (3.12) (3.13) (3.14) Where Where wx =0 ⇒ wZ,(cid:1)Z=2 nx=0 ⇒wZ=zZ{(cid:3) wx =0 ⇒ wZ,(cid:1)Z=2 (cid:11)wx(cid:22)y(cid:24)= 2(cid:3)zZ,{(cid:11)w(cid:22)y(cid:24)−zZ{,2(cid:3),(cid:11)(cid:1)(cid:22)y−zZ(cid:24) (cid:11)nx(cid:22)y(cid:24)= (cid:3)zZ(cid:11)w(cid:22)y(cid:24)− 1zZ(cid:11)n(cid:22)y(cid:24) (cid:11)w=w−wZ (cid:11)n=n−nZ (cid:11)(cid:1)=(cid:1)−(cid:1)Z The control system for the linearized system is depicted in Fig 3.1. 38 AQM Control Law {(cid:22)~(cid:24) (cid:134)U(cid:16)(cid:135)(cid:136) O(cid:17)IH(cid:22)~(cid:24) O(cid:127)(cid:18)(cid:128)(cid:18)(cid:128)(cid:22)~(cid:24) Figure 3.1: Linearized control system From the above system, since both poles are negative the system is stable. Let assume that W {(cid:22)(cid:2)(cid:24) is the AQM control function. Since RED is a low pass filter then the transfer function of the system can be represented as [ low pass filter analysis] (3.15) (3.16) (3.17) (3.18) (3.19) O(cid:17)IH= zZ{,2(cid:3), ~+2(cid:3),zZ,{ O(cid:127)(cid:18)(cid:128)(cid:18)(cid:128)= (cid:3)zZ(cid:2)+ 1zZ {(cid:22)~(cid:24)={(cid:129)(cid:128)(cid:130)(cid:22)~(cid:24)= 6(cid:129)(cid:128)(cid:130) ~(cid:131)+1 OdGs 6(cid:129)(cid:128)(cid:130)= 9-r(cid:17)e−9Pq(cid:17)e (cid:131)=Y)(cid:132)(cid:128)(cid:22)1−(cid:133)(cid:127)(cid:24) (cid:11) Where Hence, the system transfer function can be written as: 39 {(cid:22)~(cid:24).O(cid:22)~(cid:24)= 0{,2(cid:3)3(cid:134)U(cid:16)(cid:135)(cid:136) 6(cid:129)(cid:128)(cid:130) 0~+ 2(cid:3)zZ,{3(cid:137)~+ 1zZ(cid:138)(cid:137) ~(cid:131)+1(cid:138)=(cid:139)(cid:22)~(cid:24)(cid:134)U(cid:16)(cid:135)(cid:136) Lemma For all (cid:3)∈ (cid:26)(cid:3)U,∞(cid:24) and zZ∈ (cid:22)0,zX(cid:27) , then if (cid:133)p is chosen based (cid:133)p= ∝9Pq(cid:143) 2(cid:3)U (cid:22)zX(cid:24),{, 1zX(cid:144), 0<∝<0.5 Then 6(cid:129)(cid:128)(cid:130) and (cid:131) satisfy the following condition (cid:22)2(cid:3)U(cid:24), ≤(cid:147)(cid:133)p(cid:131),,+1 6(cid:129)(cid:128)(cid:130)(cid:22)zX{(cid:24)/ Proof: And the closed-loop system Eq. 3.20 will be stable ∀(cid:3)∈(cid:26)(cid:3)U,∞(cid:24) and zZ∈ (cid:22)0,zX(cid:27) let ~=(cid:149)(cid:133) then we can rewrite Eq. 3.20 as follows: 6(cid:129)(cid:128)(cid:130)0{,2(cid:3)3 (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)(cid:134)U(cid:150)(cid:151)(cid:135)(cid:136)= The magnitude of (cid:22)(cid:149)(cid:133)(cid:24)(cid:134)U(cid:150)(cid:151)(cid:135)(cid:136) :- The transfer function (cid:139)(cid:22)(cid:149)(cid:133)(cid:24) can be rewritten as: (cid:137)(cid:149)(cid:133)(cid:131) +1(cid:138)0(cid:149)(cid:133)+ 2(cid:3)zZ,{3(cid:137)(cid:149)(cid:133)+ 1zZ(cid:138) (cid:152) (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)(cid:134)U(cid:150)(cid:151)(cid:135)(cid:136)(cid:152)=| (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)| 6(cid:129)(cid:128)(cid:130)(cid:22)zZ{(cid:24)/ (cid:22)2(cid:3)(cid:24), (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)= (cid:137)(cid:149)(cid:133)(cid:131) +1(cid:138)(cid:154)(cid:149)(cid:133)2(cid:3)zZ,{+1(cid:155)(cid:154)(cid:149)(cid:133)1zZ+1(cid:155) Suppose (cid:3)∈ (cid:26)(cid:3)U,∞(cid:24) and zZ∈ (cid:22)0,zX(cid:27), in this case if (cid:3)U→∞ and zX→0 (3.20) (3.21) (3.22) (3.23) (3.24) (3.25) 40 Where (cid:133)p : gain cross-over freq. For stability requirements, it is required that This implies that (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)→(cid:139)(cid:157)(cid:22)(cid:149)(cid:133)(cid:24)=6(cid:129)(cid:128)(cid:130)(cid:22)zX{(cid:24)/ (cid:22)2(cid:3)U(cid:24), (cid:137)(cid:149)(cid:133)(cid:131) +1(cid:138) ,∀(cid:133)∈(cid:158)0,(cid:133)p(cid:159) (cid:152) (cid:139)(cid:157)g(cid:149)(cid:133)ph(cid:152)≤1 6(cid:129)(cid:128)(cid:130)(cid:22)zX{(cid:24)/ (cid:22)2(cid:3)U(cid:24), (cid:160)1+(cid:133)p(cid:131),, ≤1 (cid:22)2(cid:3)U(cid:24), ≤(cid:147)(cid:133)p(cid:131),,+1 6(cid:129)(cid:128)(cid:130)(cid:22)zX{(cid:24)/ The phase of (cid:139)(cid:22)(cid:149)(cid:133)(cid:24)(cid:134)U(cid:150)(cid:151)(cid:135)(cid:136) :- ∠(cid:139)(cid:22)(cid:149)(cid:133)(cid:24)(cid:134)U(cid:150)(cid:151)(cid:135)(cid:136)=−(cid:133)zZ −tanU(cid:31)(cid:137)(cid:133)(cid:131)(cid:138)−tanU(cid:31)(cid:154) (cid:133)2(cid:3)zZ,{(cid:155)−tanU(cid:31)(cid:154)(cid:133)1zZ(cid:155) Again if (cid:3)∈ (cid:26)(cid:3)U,∞(cid:24) and zZ∈ (cid:22)0,zX(cid:27), and for stability requirement (Nyquist stability criterion), it is needed to have ∠(cid:139)g(cid:149)(cid:133)ph(cid:134)U(cid:150)(cid:151)¥(cid:135)(cid:136)>−180 −(cid:133)pzX −tanU(cid:31)(cid:137)(cid:133)p(cid:131)(cid:138)−tanU(cid:31)(cid:154) (cid:133)p2(cid:3)U (cid:22)zX(cid:24),{(cid:155)−tanU(cid:31)i(cid:133)p1zXj+¤>0 Let 41 (3.26) (3.27) (3.28) (3.29) (3.30) (3.31) (3.32) (3.33) If O(cid:129)(cid:128)(cid:130)=9Pq (cid:143) 2(cid:3)U (cid:22)zX(cid:24),{, 1zX(cid:144) The idea to achieve condition Eq. 3.32 above, we choose (cid:131) such that the {(cid:22)~(cid:24) will dominate the closed-loop system, to do that it is needed to choose (cid:151)¥' ≤O(cid:129)(cid:128)(cid:130) (cid:133)p≤O(cid:129)(cid:128)(cid:130)→(cid:133)p(cid:131) ≤O(cid:129)(cid:128)(cid:130) −(cid:133)pzX −tanU(cid:31)(cid:137)(cid:133)p(cid:131)(cid:138)−tanU(cid:31)(cid:154) (cid:133)p2(cid:3)U This implies that the term If the inequality Eq. 3.35 satisfied, then it implies that inequality Eq. 3.32 will be satisfied. Therefore, let (cid:22)zX(cid:24),{(cid:155)−tanU(cid:31)i(cid:133)p1zXj≤−¤2 (cid:133)p=0.1O(cid:129)(cid:128)(cid:130) (3.34) (3.35) (3.36) In this analysis, we evaluated the RED stability boundaries. We will use Eq. (3.22) of analysis to make sure that our proposed system is stable. 3.2 Rate Control In this section, we propose a mechanism as a part of our framework. The goal of the algorithm is to maximize data rate and share network resources fairly with other network flows . 3.2.1 EPIQ- TCP Friendly Control Protocol (EPIQ-TFRC) The channel between the sender and the receiver should be monitored to ensure high-quality video delivery. Because of the changing condition of the network, rate control is necessary to 42 maintain quality video streaming while ensuring fairness to other competing real-time and non- real-time sessions. Based on the reported available bandwidth, the sender adjusts the sending rate of the video stream. In general, the rate control mechanism that is used in video transmission either relies on the traditional Transmission Control Protocol (TCP) or multimedia oriented TCP friendly protocols. Each has its own advantages and disadvantages. The most popular video streaming mechanism, DASH, employs HTTP/TCP to transport video over the network. The video rate is adjusted according to reported available bandwidth by TCP. Other methods include Real-time Transport Protocol (RTP). Several congestion control mechanisms were proposed to be used in conjunction with RTP[3] like TFRC[21] GCC[22] and Kelly[62]. Equation based congestion control methods are the most widely used with RTP. Protocols like Datagram Congestion Control Protocol (DCCP)[63] and TCP-friendly Rate Control Protocol (TFRC) are well known RTP solutions. The congestion algorithm can be implemented as an application that uses UDP as a transport layer. Equation based control protocols use TCP response function to estimate the sending rate: N= (cid:2) z(cid:160)2(cid:1)3 +y(cid:135)(cid:6)“@3(cid:160)3(cid:1)8C(cid:1)(cid:22)1+32(cid:1),(cid:24) (3.37) where N is the sending rate in bytes/sec. while (cid:2),z,(cid:1) and y(cid:135)(cid:6)“ are the packet size, round trip time, study state loss event rate and TCP retransmission timeout, respectively. The loss event is defined as a packet loss within a single Round Trip Time (RTT). Since our proposed solution does not drop whole packets but partially erases them, using a multimedia oriented rate control protocol is easier to implement. It is possible to employ TCP in conjunction with the EPIQ framework. However, mapping partially erased packets into equivalent conventional packet loss is a complex task. Our objective is to employ a rate control algorithm that achieves fairness with 43 other flows that share the network resources yet is compatible with our novel solution. Hence, we propose a modified TCP-Friendly Rate Control protocol (TFRC) and refer to it as EPIQ- TFRC which is implemented as an application and uses UPD as a transport protocol. It is also important to note that we use Explicit Congestion Notification (ECN) mode of the TFRC algorithm. The TCP response function (Eq.(3.37) ) is used by TFRC to achieve TCP-friendly sending rate that maintains fairness with other TCP flows in the network. In our proposed solution, evaluating the round trip time z and TCP time-out y(cid:135)(cid:6)“ is similar to the proposed methods that are used in the TFRC standard[21]. In a conventional network, packet dropping is considered an indication of congestion. Meanwhile, in our solution we drop only portion of the packets and we only mark one of the partially erased packets using ECN bit in the header. The receiver detects only marked packets as a congestion indicator. Using ECN mode of the TFRC standard, packet loss is calculated such that we achieve fairness with other TCP flows in the network. After computing the packet loss, we use Exponential Weighted Moving Average (EWMA) to compute the packet event loss (cid:1) as shown in Eq. (3.31). Where (cid:1)I(cid:18)(cid:129) is the current loss probability reported by TFRC while (cid:1)(cid:128)o(cid:128)(cid:19)(cid:17) and › are the event (cid:1)(cid:128)o(cid:128)(cid:19)(cid:17)a«‹=›∗(cid:1)I(cid:18)(cid:129)+(cid:22)1−›(cid:24)(cid:1)(cid:128)o(cid:128)(cid:19)(cid:17)(cid:15)(cid:14)(cid:130) (3.38) probability that is used to calculate current sending rate as Eq.(3.30) and history parameters respectively. The standard TFRC/RFC 5348 protocol uses Average Loss Interval (ALI) method to compute the event loss rate (cid:1). ALI response to network changes is better than EWMA. On the other hand, under EPIQ, we observed that EWMA provides smoother video transmission than the ALI averaging method. 44 Since the packet size (cid:2) in the TFRC standard is fixed, our solution has to be adaptable to case the packet is less than the desired packet size (cid:2). Because the zero padding is at the tail of the such scenario. One possible resolution to this constraint is to pad the tail of a packet with zeros in packet, the padding is first dropped during congestion. This method can be enforced on all EPIQ packets to provide extra protection to video slices during heavy congestion. In Section (3.3) we discuss the fairness of our rate control protocol. Another modification to standard TFRC that we included is a video streaming profile control algorithm. EPIQ-TFRC selects the appropriate video transmission rate (video quality profile) by calculating the running average of sending bitrate using: z(cid:157)fiH(cid:16)=(cid:143)flz(cid:157)(cid:22)P−1(cid:24)+(cid:22)1−fl(cid:24)z(cid:22)P(cid:24) P>1 z (cid:22)1(cid:24) P=1 (3.39) We used fl=0.8 in our simulation. z(cid:157)(cid:22)P(cid:24) represents the average sending rate at event P where, here, the event duration is 10 seconds. Also, reducing the quality profile of the video is allowed only if the playback buffer size is less than 5 seconds. Hence, based on the running average and the playback buffer size, the closest video quality profile is selected. 3.3 Experimental Evaluation In this section, we validate our proposed EPIQ-RED and EPIQ-TFRC by simulation. 3.3.1 EPIQ-RED The main role of AQM algorithm is to improve channel utilization, minimize delay and prevent network collapse during congestion. Our work is based on the original Random Early Detection (RED) algorithm. In Fig. 3.2 we show an example of unstable RED performance while Fig 3.3 shows a stable RED performance of the same network configuration. The instantaneous queues 45 size is changing rapidly which causes poor performance. The unstable AQM causes low channel utilization. Fig. 3.4 depicts a comparison of low and high channel utilization of Fig 3.2 and Fig 3.3 respectively. Due to unstable AQM, only 15% of the bottleneck bandwidth was utilized. The average network delay can affect network performance negatively. However, delay jitter has far worse implication than average delay on applications like multimedia and broadcasting. Furthermore, Table 3.1 shows the different parameters results for both stable and unstable AQM. 350 300 250 200 Unstable RED ) s t e k c a p ( e z i s e u e u Q 150 100 50 0 0 20 40 60 80 100 120 140 160 180 200 Seconds Figure 3.2: Unstable RED instantaneous queue size Table 3.1: Comparison between stable and unstable AQM performance Avg. Throughput Ch. Utilization Delay (ms) Delay Jitter (ms) Unstable AQM 2.8 Mbps Stable AQM 13.4 Mbps 15 97 220 240 42 16 It is clear from Table 3.1 that a stable AQM performance is necessary to have optimum network performance. 46 We tested our proposed EPIQ-RED algorithm with different network configuration to verify its performance. Fig. 3.5 shows instantaneous queue size of 75Mbps channel. The 9Pq(cid:17)e and 9-r(cid:17)e are set to 75 and 575 respectively. Also, Fig 3.6 shows the network utilization of the bottleneck channel. Our AQM converges to 100% channel utilization and has minimal delay jitter. ) t e k c a p ( e z s e u e u Q i 600 500 400 300 200 100 0 0 Stable RED 20 40 60 80 100 120 140 160 180 200 Seconds Figure 3.3: Stable RED instantaneous queue size It is clear that our proposed algorithm has a stable network configuration. In another network configuration, the channel is set to 15 Mbps and 9Pq(cid:17)e and 9-r(cid:17)e are set to 35 and 125 respectively. Fig. 3.7 and 3.8 depict the instantons queue size and channel utilization. Similar to the previous network configuration, the performance of our proposed queue is optimal. 47 s p b M 16 14 12 10 8 6 4 2 0 0 Stable-RED Unstable-RED 20 40 60 80 100 120 140 160 180 200 Seconds Figure 3.4: Comparison between stable and unstable AQM throughput ) t e k c a p ( e z i s e u e u Q 1400 1200 1000 800 600 400 200 0 0 EPIQ-RED 10 20 30 40 50 60 70 80 Seconds Figure 3.5: Instantaneous queue size of example 1 48 s p b M 80 70 60 50 40 30 20 10 0 0 EPIQ-RED 10 20 30 40 50 60 70 80 Seconds Figure 3.6: Channel utilization of example 1 ) t e k c a p ( e z i s e u e u Q 100 80 60 40 20 0 0 10 20 30 40 50 60 70 80 90 100 Seconds Figure 3.7: Instantaneous queue size of example 2 49 s p b M 14 12 10 8 6 4 2 0 0 EPIQ-RED 10 20 30 40 50 60 70 80 90 100 Seconds Figure 3.8: Channel utilization of example 2 3.3.2 EPIQ-TFRC The main role of the rate control algorithm is to provide maximized data rate while simultaneously sharing network resources fairly with other flows. In this section, we will test our proposed EPIQ-TFRC and compare our proposed EWMA with ALI algorithm. Fairness is an important attribute of the rate control algorithm. To test the fairness of EPIQ-TFRC, the test network consists of three video streaming users, three TCP users and a bottleneck link of 15 Mbps. We tested EPIQ-TFRC with both EWMA and ALI. We tested EWMA with three history values of 0.5, 0.7 and 0.9. Table 3.2 shows the comparison of EWMA to ALI. The algorithms were tested on fixed (F) and varied (V) bottleneck link bandwidth. The standard deviation of video flows represents the fairness between video flows, while the video share ratio represents the fairness between video flows and TCP flows. It is clear that ALI has the best performance in a fixed network. However, on a network with varying bandwidth, ALI has the worst fairness. On the other hand, we can see that EWMA 0.7 has optimum performance 50 in a fixed and varied bottleneck network. Fig. 3.9 shows the performance of EWMA and ALI on a varied bandwidth bottleneck. It is clear that EWMA 0.9 has the best performance. However, it is less fair to other flows in the network. From the Table 3.2, we consider using EWMA 0.7 as the optimum method to compute packet loss average (cid:1). Table 3.2: EPIQ-TFRC event loss calculation methods comparison Loss Calculation Intra-fairness Intra-fairness EIPQ share ratio EIPQ share Method STD (%)-F STD (%)-V (%)- F ratio (%)- V EWMA 0.5 EWMA 0.7 EWMA 0.9 ALI s p b M 14 12 10 8 6 4 2 0 0 6.3 3.5 9.2 1.15 12 4.6 1.15 3.7 49.9 49.8 52.7 49.6 47.7 49.6 49 44.1 EWMA-0.5 EWMA-0.7 EWMA-0.9 ALI 10 20 30 40 50 60 70 80 Seconds Figure 3.9: Comparison between ALI and EWMA throughput 51 Chapter 4 EPIQ Applications In this chapter we discuss the application of EPIQ system. EPIQ framework can applied on both Video On Demand (VOD) and delay sensitive live streaming. 4.1 Video On Demand (VOD) Experimental Evaluation Most of today’s video traffic is generated by VOD websites like Netflix and YouTube. Also, most VOD providers use DASH technology as their streaming framework because of its simplicity and economic feasibility. In this section we will compare our proposed framework, EPIQ, with DiffServ and DASH. 4.1.1 Experimental Setup We used the ns-2 simulator to implement the EPIQ framework. As shown in Fig. 4.1, we employed the widely used bar-bell topology with multiple sources connected to a single bottleneck link with 800 packet queue size. In our experiments we used two bottleneck link bandwidth scenarios. In the first scenario, the capacity of the bottleneck link was set to 200 Mbps, which we refer to as Fixed (F) bottleneck, while in the second scenario, the bottleneck link bandwidth varied between 200Mbps and 60Mbps, thus we denote this configuration as Varied (V) bottleneck. Meanwhile the rest of the links were fixed to 350 Mbps. In our simulations, the traffic is generated by two equal member application groups where each group has 10 sources (users). The first group is setup as FTP/TCP traffic generator while video streaming applications are setup as the second traffic group. For the video content, we used JSVM [56] and OpenSVCDecoder [58] to both generate trace files for our simulations and to evaluate the received video quality. Eight High Definition (HD) video sequences[64] , with 52 total video duration of 80 seconds, were encoded as a single video streaming sequence in our simulation. The video was encoded as AVC stream at 30 FPS. Four versions of the video were generated to simulate different video quality profiles. The video supports the following quality profiles: 2, 3.5, 5.1, and 10 Mbps. To evaluate the performance of our system, we compare it with commonly used video streaming methods. In the following subsection, we discuss the configuration related to each system. Figure 4.1: Simulation topology A) EPIQ Our proposed EPIQ video streaming system was configured according to Chapter 3. In our simulations, each AVC GoP represents one EPIQ video set (EVS), and it was carried by one EPIQ packet set (EPS). EPIQ-RED and EPIQ-TFRC were preconfigured to the ns-2 default parameters. B) Multi Priority Queue (MPQ) Multi-based video streaming is the prominent traditional solution to benefit from the priority structure of video. Our multi-queue comparison model is based on DiffServ. We implemented a simple multi-queue similar to the one found in[26]. The AQM for DiffServ employs two sets of queues. The first set of queues is for streaming data and the second set, which consists of a single 53 queue, is used for FTP data. The multimedia queue set is divided into three virtual queues (Green, Yellow and Red) with each having different dropping precedence. The most important video traffic is queued in the Green queue while the least important is queued in the RED queue. At the sender, the AVC video stream was divided into three different priority streams. We used a simple packet marking method where the packets are marked based on frame type (i.e. I, P and B frames). In the mentioned method, I frames packets have the highest priority and B frames packets have the lowest priority. Also, to control the video sending rate we used standard TCP Friendly Congestion Control (TFRC) protocol[21]. Similar to the EPIQ system, the AVC quality profile was selected in a similar manner. The system used the default ns-2 TFRC and DiffServ parameters. C) HTTP Steaming Nowadays, one of the most widely used video streaming algorithm is Dynamic Adaptive Streaming over HTTP (DASH). DASH video traffic is streamed over best effort Internet. Hence, in our simulations, Drop Tail was used as the AQM algorithm in the bottleneck network. At the sender, The H.264 AVC video Quality profiles were used as DASH supported bitrates similar to EPIQ and DiffServ systems. In standard DASH, data are transported using TCP, which provides bandwidth estimate to the application layer to adjust the sending rate accordingly. We used the DASH standard method to control the selected video bitrate. 4.1.2 Experimental Results In this section we present the results of our experiment. A) AQM Stability 54 Our EPIQ-RED algorithm shares the core principles of RED. According to Eq. (3.3)-(3.4), 9Pq(cid:17)e and 9-r(cid:17)e are set automatically to 79 and 412 packets, respectively, while the average queue size is 120 packets. We found that our algorithm is relatively stable in comparison to what is found in [34] and consistent with RED performance that we discussed in previous section. Table 4.1 shows AQM performance of the three systems. Table 4.1: AQM performance of EPIQ, DiffServ and DASH Avg. Thro. (Mbps) Ch. Utilization Delay (ms) Delay Jitter (ms) EPIQ-F DiffServ-F DASH-F EPIQ-V DiffServ-V DASH-V 196.1 195.6 186.8 117.2 116.8 113.9 98 97.5 93.4 99.3 98.5 96.5 18 17 18 20.5 21.6 43 2.8 6.3 4.5 4.5 3.4 8.3 It is clear from Table 4.1 that EPIQ and DiffServ performances are close in all aspects. However, DASH didn’t achieve the full channel utilization as well as it had the highest end to end delay compared to EPIQ and DiffServ. Drop-tail buffers are widely known for not achieving full channel utilization. B) Congestion Control Congestion control is necessary to achieve smooth video streaming while maintaining fairness with other flows in the network. For a completed 80 seconds simulation, the average share ratios are show in table 4.2. It is clear that DiffServ-TFRC and EPIQ-TFRC connections provide a higher level of fairness toward FTP/TCP than DASH and DiffServ. It is important to note that 55 despite the fact that we introduce changes to the original TFRC work, we find our system operates within original TFRC boundaries. Table 4.2: Network resources sharing fairness of EPIQ, DiffServ and DASH Video Fairness Video Fairness Video share ratio Video share STD (%)-F STD(%)-V (%)- F ratio (%)- V EPIQ DiffServ DASH 3.7 32 44 4.6 36 17 100.6 104.2 80.4 99.2 102.4 82.5 It is clear from Table 4.2 that DiffServ has the highest share ratio where 100% mean FTP and Video sessions share bottleneck bandwidth equally. However, DiffServ video sessions have high STD network share values compared to EPIQ, indicating that the difference in data rate between DiffServ video sessions flows are high. The difference in video means some users experience very high quality video streaming while other users experience low quality. On the other hand, DASH suffers from low network resources sharing ratio in addition to high video share STD similar to DiffServ. C) Video Quality A key goal of our work is to provide high quality video transmission. The performance metrics used to evaluate the quality of the received video traffic include the average Peak Signal to Noise Ratio (PSNR) of the luminance (Y) component, packet retransmission, delay, average download, and video quality profile changes. Also, we compared the performance of two startup buffer sizes of 5 seconds and 15 seconds. In our simulations, retransmissions were allowed only for I frame packets of the AVC video for both EPIQ and DiffServ. Meanwhile, the retransmission 56 function was allowed for all DASH packets, which include both control packets and video streaming packets because of the necessity of all packets to DASH operation. Table 4.3: Transmission and video quality of EPIQ, DiffServ and DASH App. Packet Avg. Quality Change PSNR (dB) Delay Retransmit Download 5 s. 15 s. 5 s. 15 s. (msec) (%) (Mbps) EPIQ-F 19.2 0 DiffServ-F 17.5 0.02 DASH-F 393 0.163 EPIQ-V 24.2 0 DiffServ-V 22.6 DASH-V 403 0.17 0.48 9.88 10.08 8.75 5.8 2.2 1.8 3.2 3.5 1.8 1.6 2.5 3.4 37.5 38.0 34.4 34.8 33.6 34.0 35.5 36.2 5.92 3.1 2.56 32.5 33.4 5.0 4.5 4.8 32.5 34.5 We tested our proposed solution and computed the average results for the performance metrics that we stated earlier. All results represent the average per user over 80 seconds, where this average is evaluated over 10 video sessions corresponding to the 10 users in our simulations. Important performance parameters include application to application data delay. Table 4.3 shows the average delay parameters in both fixed and varied bottleneck bandwidth of the three mechanisms as seen by user application layer. EPIQ delay is slightly higher than DiffServ because the EPIQ receiver forwards the received data to the application after receiving all EPS’s packets. DASH on the other hand, has very high delay because it relies on TCP to deliver data. Both the packet retransmission process and the TCP buffer contribute to the delay. Fig. 4.2 shows a comparison between EPIQ, DiffServ and DASH application to application Delay. 57 Regarding retransmission, EPIQ did not retransmit any packet while DiffServ retransmitted 0.02% and 0.17% of the total number of packets transmitted in fixed and varied bottleneck bandwidth respectively. Because DASH uses HTTP/TCP, it retransmitted 0.16% and 0.48% of the total packets in both fixed and varied bottleneck respectively. Also, as shown in Table 4.3, DiffServ has the highest download rate compared to EPIQ and DASH, because it has the highest network share ratio as shown in Table 4.2. 1.4 1.2 1 0.8 0.6 0.4 0.2 ) d n o c e s ( y a e D l DASH DiffServ EPIQ 0 0 10 20 30 Second 40 50 60 Figure 4.2: Application to application delay of EPIQ, DiffServ and DASH Also shown in Table 4.3, the performance of the different video transmission mechanisms from the user prospective with startup buffering of 5 seconds and 15 seconds. It is crucial to highlight that EPIQ achieves on average 4.0 dB and 2.3 dB in PSNR improvements over DASH in fixed and vary bottleneck respectively. Furthermore, EPIQ outperforms DiffServ by 3.15 dB and 2.3 dB in fixed and varied bottleneck respectively. Although the average DiffServ video session had the highest average download rate compared to both EPIQ and DASH video users’ sessions, DiffServ had the lowest average PSNR. The main reason is that DiffServ users had high video 58 share STD as we explained earlier which causes some sessions to have poor PSNR. Regarding video quality-profile changes (which correspond to bitrate changes), DASH suffers from around 30% more quality changes when compared to EPIQ and DiffServ while DiffServ and EPIQ have close profile changes. Note that neither EPIQ, DiffServ nor DASH suffer from any stalling. It should be clear from these results the importance of quality/bitrate adaptation, such bitrate changes are necessary to avoid video stalling. (During the stalling time, the video playback stops for buffering.) 59 Chapter 5 Vehicle to Vehicle Safety System 5.1 Cooperative Advanced Driver Assistance System (C-ADAS) Overview The development of connected-vehicle technology, which includes vehicle-vehicle and vehicle- infrastructure communications, opens the door for unprecedented active safety and driver- enhanced systems. In addition to exchanging basic traffic messages among vehicles for safety applications, a significantly higher level of safety can be achieved when vehicles and designated infrastructure-locations share their sensor data. For example, while cameras installed in one vehicle can provide visual information for mitigating many avoidable accidents, we envision a whole new level of improved safety paradigm where visual data captured by multiple vehicles are shared and fused for significantly more optimized active safety and driver assistance systems. Under this example, we envision a new system where cameras installed on multiple vehicles and infrastructure-locations share and fuse their visual data and detected objects in real-time. The transmission of camera data and/or detected objects (e.g., pedestrians, vehicles, cyclists, etc.) can be accomplished by many communication methods. In particular, such communications can be accomplished using the emerging Dedicated Short-Range Communications (DSRC) technology. The vehicle receiving the visual data from an adjacent vehicle, for example, can fuse the received visual data with its own camera views to create a much richer visual scene. The sharing of visual data is motivated by the fact that some critical visual views captured by one vehicle or by an infrastructure-location are not visible or captured by many other vehicles in the same environment. Sharing such data in real-time provides an invaluable new level of awareness that can significantly enhance a driver-assistance, connected vehicle, and/or autonomous vehicle’s safety-system. An example of such scenario is illustrated in the Fig. 5.1, where the view captured 60 by the “U-Haul” van is fused by an adjacent-vehicle camera view. This enables the adjacent vehicle’s active-safety system and/or driver to clearly recognize that there is a pedestrian crossing; without such fusion the vehicle’s system/driver would be completely oblivious to the presence of the pedestrian. It is worth noting that the proposed new framework can be used by new driver-assistance systems, and it can be employed by future connected/autonomous vehicles. Figure 5.1: Pedestrian collision scenario 5.2 C-ADAS Architecture Fig. 5.2 illustrates the architecture of our concept which is applicable to both autonomous and human driven vehicles. The system can be generalized to include any form of the following three sensor types: 1. Position Sensors: This includes any GPS-based and IMU sensors. 2. Active Sensors: This includes radars, lidars, and ultrasonic sensors. 3. Passive Sensors: This includes vision cameras and multi-spectral imaging sensors. 61 An integrated two subsystems architecture is shown in Figure Z. The architecture includes the following two subsystems: A) A Capture-and-Transmit (CAT) subsystem that includes all sensors devices , sensor fusion, object detection, classification, tracking, trajectory estimation, ego motion estimation and other objects’ absolute and relative position estimation, object selection for sharing with remote vehicles or the infrastructure, and compression, multiplexing, communication and transportation functions and modules. B) A Receive-and-Fuse (RAF) subsystem that receives objects’ position and description data captured by other remote entities (e.g., other vehicles and/or infrastructure entities) and fuse this data with locally detected objects to create a complete view of the 3D environment surrounding the vehicle. The final fused data and objects can be used by an autonomous system for path planning, selection. The fused data and objects can also be used by an HMI system and can be displayed for human use (e.g., a driver in a manually-driven vehicle or for occupants in an autonomous vehicle). 62 Figure 5.2: An integrated system for multi-modal sensor data sharing and fusion In Fig. 5.3, we describe the baseline architecture for the proposed system using a camera sensor as an example. However, the system can employ any sensor modality including lidars, radars, ultrasonic sensors, etc. A more powerful system can be realized by the fusion of the multimodal-sensor system. For example, one possible realization is a system that employs any combination of camera, lidar, radar, and/or ultrasonic sensors. Within each vehicle, the proposed system will include a video capturing unit (i.e., camera(s) and lenses) and object detection/recognition processor (e.g., for pedestrians, cyclists, other vehicles etc.) in addition to a complete chain of compression/decompression, streaming, and fusion units. Fig. 5.3 illustrates a simplified architecture that includes: (a) the transmission section within the vehicle transmitting the video and detected objects; and (b) the receiver section within the vehicle that is receiving the video and objects. (Both vehicles will also include the other receiver/transmitter sections, which are not shown for simplicity.) The video cameras and object detection/recognition can be based on any state-of-the-art cameras or visual systems that are capable of object detection, classification, and/or recognition. 63 Video Capture Video Compression Video & Object Streaming (Transmission) Object Detec on & Recogni on Detected objects Video Capture Object Detec on & Recogni on DSRC Network Detected objects Video & Object Fusion Video Decompression Video & Object Streaming (Receiving) Remote detected objects Display l i e c h e V g n i t t i m s n a r T i l e c h e V g n v e c e R i i Figure 5.3: Example of baseline system architecture In cases of sensor modalities that generate a large amount of data, the need for data compression could become necessary. Hence, in the case of using visual sensors, video compression/decompression will be critical for achieving efficient communication among the vehicles and/or infrastructure. Any state-of-the-art video coding standards or technologies that are either standalone or built-in within popular cameras can be used. The video-streaming framework can be based on advanced solutions or popular standards such as the Real-Time Streaming Protocol (RTSP). The wireless network can be based on underlying DSRC transceivers that adhere to the Intelligent Transportation System of America (ITSA) and 802.11p WAVE standards, and which are certified by the US DOT. Other communication mechanisms can also be used, including traditional wireless and cellular services such as LTE, 5G, or other mechanisms. The system is applicable for single-lane, double-lane, and any multi-lane roadways and highways in urban or rural environments. Furthermore, the system includes intelligence that utilizes localization and mapping algorithms in conjunction with real-time messages to enable a vehicle or an infrastructure-location to determine if its video and/or detected objects can be 64 utilized by other nearby vehicles. For example, in a three-lane road, vehicles driving in the middle-lane can broadcast their video; this will enable vehicles driving on both the right and left lanes to receive the middle-lane vehicle’s videos and fuse them with their own visuals. Figure 5.4: System architecture with object localization, positioning, and trajectory estimation Fig. 5.4 also highlights the integration of key modules of the baseline system (red) with other modules (blue). Examples of particular solutions for the baseline system models are shown in the Fig 5.3 as well. For instance, video compression is shown based on the popular H.264 standard. However, any other video compression (or even uncompressed video stream over high- bandwidth communication links) can be used. The overall system includes the following modules and functions: 1 Object detection and classification: There are many options under this area. Here, we list three examples. First, deep learning approaches that use visuals (only) or fused sensor data (e.g., visuals-plus-lidar signals) can be employed. Due to the high-complexity of 65 deep learning, a second option is to employ traditional computer vision object detection and classification methods that can operate fast and reliably in real-time. A third option would be to employ a sensor platform (most notably camera) that supports built-in object detection such as a Mobileye vision system. 2 Selective object sharing and emergency detection: The system has to be selective towards which objects to share with other vehicle(s). In principle, there is no point in sharing objects that can be observed and detected by other vehicles. This decision can be determined through intelligent 2D/3D localization and mapping algorithms of the 2D/3D scene surrounding the vehicles. The system could identify emergency situations when the vehicle detects objects that can’t be observed by other vehicles, and hence it declares an emergency that triggers the rapid transmission of the detected occluded objects. 3 Integrated fusion and localization: As mentioned above, the system has to perform highly accurate fusion and localization of multiple objects, both captured remotely and locally. In addition to cameras, lidar and GPS-based localization can play a key role in this integrated fusion-localization framework. a. RTK GNSS: RTK GNSS is a high accuracy system that provides up to 1 cm localization. It allows a very accurate estimation of object distances and visual fusion. High end GNSS fuses IMU (Inertial Measurement Unit) measurements with GNSS signal to improve location accuracy. b. Lidar and Radar: A 360 degrees Lidar can measure the distance between the car and various objects to build a 3D model of the vehicle surroundings. This technology can achieve around 10 cm accuracy and is very useful when the GNSS service is not available. Radar provides robust sensing under a wide range of 66 weather conditions. It is also an excellent modality for estimation of range and object motion trajectory. c. Fusion and Localization: GNSS service might not always be available or reliable. lidar-based localization can also suffer from degradation under many scenarios. By analyzing the surrounding environment and positioning accuracy, an Integrated Fusion-Localization paradigm fuses GNSS and lidar (and possibly other sensors) data and computes the most accurate positions. Fusing IMU measurements with both lidar and GNSS data also contributes to overall system reliability and stability. Lidar can also play a role in a fused camera-lidar learning based on object detection and classification. 4 Human-Machine Interface (HMI) and cockpit integration: For vehicles operated by human drivers, the final presentation of the fused visual data is another crucial component. This can be achieved by using visual and audible warnings, and a variety of display devices such as Head-Up Display (HUD) or dashboard display.. 5.3 C-ADAS Design and Operation In order to share information between vehicles, a connection has to be setup between the connected vehicles. By default, DSRC equipment periodically sends Basic Safety Messages (BSM) [55]. 67 B: Sends beacons (vehicle status and object detection status) B: Sends vehicle and detected objects information A: Receives B’s beacons A: Processes B’s information Yes A: Displays fused video to the driver A: Is B still streaming No No A: Vehicle of Interest (VoI) No Yes A: Pedestrian crossing detected Yes A: Enables Cooperative Pedestrian Collision Avoidance System (CPCAS) A: Alerts the driver A: Disables CPCAS System B: Sends video stream with other information A: Processes video stream Figure 5.5: Proposed system (Cooperative Pedestrian Collision Avoidance System (CPCAS) ) operation flowchart The messages contain vehicle status and applications information. In our system, we are assuming that all vehicles have Pedestrian Collision Avoidance System (PCAS) also known as Pedestrian Automatic Emergency Braking (PAEB) system, which is available in many new vehicles [65] nowadays. The PCAS system can detect crossing pedestrians and apply breaks 68 when it detects imminent collision. We call our system Cooperative Pedestrian Collision Avoidance System (CPCAS). Table 5.1: Variables used in our proposed system calculations Variable (cid:176) (cid:5) { – (cid:133) | Y (cid:134) . fl › q 5 Δ(cid:181) Description Vehicle A Vehicle B Pedestrian Expected collision point Vehicle width Vertical distance between vehicle A and B (similar to Δ‡ ) Horizontal distance between vehicle A and B (similar to Δ· ) Distance between vehicle B and pedestrian Horizontal distance between pedestrian and vehicle B Angle between vehicle A and pedestrian Angle between vehicle B and pedestrian Euclidian distance between vehicle A and pedestrian Euclidian distance between vehicle B and pedestrian Difference between camera A and camera B altitude Fig. 5.5 shows our system operation flowchart and a corresponding sketch illustrating a typical scenario involving two vehicles (Vehicle A and Vehicle B) and a pedestrian. Fig. 5.6 shows a top view of Fig. 5.5 with the variables that we use in our calculations. In addition, Table 69 5.1 defines the variables that are used in our system parameter calculations. The reported locations could be measured in any distance units. For example, they could be in meters as used in the Universal Transverse Mercator (UTM) coordinate format. Also, we consider the camera location as our vehicle reference location. If more than one pedestrian is detected, we perform the same calculations for each pedestrian. Meanwhile, it is possible to combine two pedestrians, who are adjacent or in close proximity, as one pedestrian. Here, and for illustrative purposes only, we focus on a single pedestrian crossing. Each vehicle has a Vehicle of Interest (VoI) list that includes all vehicles that may share useful information to the ego-vehicle. For our proposed system, the criteria includes: (a) the other vehicle transmitting the visual information should be heading in the same direction, and it is already ahead of the receiving ego-vehicle (b) the vehicle the pedestrian; for example, in our experiments the distance between the transmitting vehicle and with clear view of the pedestrian should have a distance Y that is within a certain threshold from the pedestrian has to be less than 50 meters (i.e., Y<50) (c) no more than two lane horizontal distance (cid:134) . When vehicle B detects a pedestrian crossing, it estimates the pedestrian distance Y as follows; Y=¶Jze•e (5.1) Where ¶J is the focal length and ze and •e are the real pedestrian height in meter and height in image pixels, respectively. When one of vehicle A’s Vehicle-of-Interest (VoI) lists sends a BSM that contains information regarding a possible pedestrian detection, the egovehicle A starts the driver alert processing and requests more information about the detected pedestrian. Once the requested information is shared, vehicle A estimates both Distance to Collision (DTC) and 70 Time to Collision (TTC) regarding point D, which represents the expected position of the pedestrian where a potential collision may occur, as shown in Fig. 5.6. –N{=Y+| NN{=–N{(cid:2)‚ Where (cid:2)‚ is the speed of vehicle A (e.g., in meters per second). Our goal is to warn the driver five seconds before collision. After vehicle B receives a request for video streaming, vehicle B shares only the Region of the image containing the detected pedestrian, also called Region of Interest (RoI). Before sending the RoI to vehicle A, the RoI is compressed into a video stream. When the vehicle receives the first image of the video stream, it has to determine if it is within the local camera Horizontal Field Of Viewing (HFOV). Hence, we calculate angle ∠fl as follows, (5.2) (5.3) (5.4) (5.5) Where ∠fl=arctan0.+(cid:134)|+Y3 .=tan(cid:22)›(cid:24)∗Y Note that . might be negative if ∠› is negative. The ∠› is estimated by vehicle B. A simple way to estimate an object’s horizontal angle is by measuring the average horizontal object pixels’ locations to the camera Horizontal Field of View (HFOV) as follow; ∠›=»…‰(cid:190)2 −0 ¿¿dGs∗»…‰(cid:190)3 (5.6) 71 — ˘(cid:22)`˙,ˆ˙(cid:24) β ˛ ˜(cid:22)`¯,ˆ¯(cid:24) (cid:192)(cid:22)`´,ˆ´(cid:24) α ˝ ˚ ¨(cid:22)`(cid:201),ˆ(cid:201)(cid:24) ¸ ˇ (cid:204) Figure 5.6: Top-view schematic of collision scenario with variables When ∠› is positive, the object is on the left side of the camera and vise versa. Now if ∠fl is larger than the HOFV of vehicle A, only audible warning is made to the driver. Otherwise, the pedestrian image is transposed on the local video stream image. As shown in Fig. 5.7, using the camera pinhole model, we transfer the object from camera B image plane to camera A image plane as follows, Δ·,Δ(cid:181) -q| Δ‡ are the differences in coordinate between the two cameras’ locations which are similar to variables shown in Fig.5.5 . Both variables · -q| (cid:181) are estimated from camera B using: ¿(cid:31)=¶s(cid:22)·+Δ·(cid:24) ‡+Δ‡ *(cid:31)=¶J(cid:22)(cid:181)+Δ(cid:181)(cid:24) ‡+Δ‡ (5.7) 72 ·=‡∗¿,¶s (cid:181)=‡∗*,¶J (5.8) After imposing the detected object on camera A image, the fused image is presented to the driver. The process is repeated until vehicle B stops sharing detected object information. To avoid sharing unnecessary information, vehicle B stops sharing detected object information when the object is no longer in front of the vehicle and visible to other vehicles (i.e. .>(cid:151), (cid:24). It is important to note that shared sensors information might be updated at a different rate. As a result, time (clock) synchronization between the two vehicles is necessary. Figure 5.7: Pin hole model and image transpose calculations 5.4 Experimental Setup In this section, we discuss our experiment setup. We divided our experiment into two parts. In the first part, we collected on-road data and in the second part we evaluated the performance of our system using the collected data. 73 A) Data collection Our experimental setup consists of two vehicles (SUV and Sedan). We installed a Cohda MK5 DSRC transceiver ( shown in Fig. 5.8), Global Navigation Satellite System (GNSS) and a dashboard camera (DashCam) on each vehicle. Although DSRC transceivers are equipped with GNSS, we opted to use our own separate Real-Time Kinematic (RTK) GNSS because RTK- GNSS offers a high-accuracy location estimates when compared to standalone GNSS that is used in DSRC transvers. In our experiment, we used Emlid Reach RTK GNSS receiver (shown in Fig 5.9), which is a low-cost off-the-shelf device [66]. To store the collected data, all sensors on each vehicle are connected to a laptop that has Robotic Operation System (ROS) installed on it. We connected the two vehicles’ laptops via DSRC transceivers during the data collection to synchronize laptop clocks. In addition, we conducted a bandwidth test experiment between two vehicles to verify the available bandwidth and to emulate channel performance when conducting the experiment in the lab. Figure 5.8: Cohda MK5 transceiver The RTK-GNSS output was set to the maximum limit of 5Hz and the camera to 24 Frame Per second (FPS). The DSRC data rate channel was set to 6 Mbps. We performed our experiment on the Michigan State University campus and surrounding areas (as shown in Fig. 5.14) with 74 wide ranging speed limits up to 55 kilometer-per-hour (kph). All of our experiments were conducted during daytime. In the first part, we collected channel bandwidth data while driving at a speed ranging between 0 and 55 kph; and the distance between the two vehicles’ DSRC transceivers ranged from 5 to 100 meters. In the second part, we simulated a pedestrian pre- collision scenario which was coordinated by our test team. B) Lab experiment In our lab setup, we conducted two experiments. In the first experiment, we compared the performance of two video coding and streaming techniques. The techniques are H.264 encoding and Motion JPEG. The goal of the experiment was to determine which method is more suitable for our work. We used two ROS supported PCs that are connected to each other directly via Ethernet cable. We used wired connection instead of DSRC wireless connection to minimize the network queuing delay effect. Our goal was to measure the bandwidth and the delay of each encoding technique. We configured the H.264 encoder to use the zero latency profile to minimize the delay. However, this configuration reduced the compression efficiency and increased the streaming bandwidth. For Motion JPEG, we used the standard JPEG compression. We tried to match the PNSR of both video streaming techniques as close as possible. H.264 encoder uses dynamic compression techniques that change the image compression quality. Our most important objective was to transport the visual information with minimal delay. 75 Figure 5.9: Emlid GNNS receiver ) s d n o c e s ( y a el D 0.02 0.018 0.016 0.014 0.012 0.01 0.008 0.006 0.004 0.002 0 H.264 Delay 20 40 60 80 100 120 140 160 Frame Figure 5.10: H.264 frame delay Fig. 5.10 and Fig. 5.11 shows the average frame end to end delay for H264 and MJPEG, respectively. The H264 encoder had almost four times the delay of MJPEG. In fact, the average start up delay for H264 was 15 ms, meanwhile MJPEG had only a 4ms delay. It is worth noting 76 that a 15 ms delay is considered acceptable for streaming. However, H264 suffers from a 560 ms startup delay which is very high compared to only 6 ms for MJPEG. Furthermore, the biggest advantage of H.264 is bandwidth saving, hence, we compared the bandwidth used by the two techniques. A comparison between the MJPEG and H.264 bandwidth for 3 seconds of the test video is shown in Fig. 5.12. MJPEG-Dealy -3 x 10 12 11 10 9 8 7 6 5 4 3 ) s m ( y a e D l 2 0 20 40 60 80 100 120 140 Frame Figure 5.11: MJPEG frame delay 77 MJPEG H.264 3000 2500 2000 s p b K 1500 1000 500 0 0 5 10 15 20 Frame 25 30 35 40 Figure 5.12: H.264 vs. MJPEG bandwidth usage Our algorithm is made flexible by only sharing regions of interest (ROI), in other words, only portions of the image is shared. To show the effectiveness of our selective sharing in reducing the required bandwidth; we simulated selective sharing by resizing the original frame resolution and then compared its transmission bandwidth with the original frame size. An MJPEG bandwidth compression of a 480x640 image from 100% to 10% of the original size is shown in Fig. 5.13. At the 100% scale, the bandwidth H.264 and MJPEG are 550Kbps and 1750Kbs respectively. The MJPEG bandwidth is three times that of H.264 at 100% . However, the needed bandwidth is reduced to less than half when the image size is decreased to 10% of the original. Moreover, we reduced the file size online without shutting down the streaming process. Such online resolution change is only possible using MJPEG and not with H.264. If a change in resolution occurs, then the encoder and decoder have to reset, causing a 550 ms delay. In our application, the image resolution is always changing from frame to another. By combining 78 selective sharing with MJPEG, we could achieve minimum delay and bandwidth with frame changing size flexibility. In our second experiment, we used two ROS supported desktop PCs that were connected with stationary DSRC transceivers. The distance between the two transceivers was fixed to 5 meters. To emulate the moving vehicle, based on our road test findings, we added a random delay of 5 to 15 milliseconds to the channel and set the maximum channel bandwidth to 2.8Mbps. Both PCs have core I7 processors and one PC has NVIDIA GTX 1080ti GPU. The GPU capable PC represents vehicle B, while the other PC represents vehicle A. We implemented our proposed system components as ROS nodes. H264 MJPEG 1800 1600 1400 1200 1000 800 600 400 200 s p b K 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Scale Figure 5.13: H.264 vs. MJPEG bandwidth with scaled image We used the You Only Look Once (YOLO) object detection algorithm in our lab experiment [67]. We trained the algorithm for pedestrian detection using Visual Object Classes (VOC) dataset [68]. Also, we used Motion JPEG (MJPEG) as our video/image encoding/decoding 79 technique. Using ROS replay feature, we replayed our pedestrian pre-collision scenario data and evaluated our system performance. 5.5 Experimental Results Fig. 5.15 and Fig 5.16 show a sample of DSRC bandwidth and packet delay test results, respectively. During this sample results, the distance between the two vehicles was between 90 to 120 meters and at a speed of 55 kph. The average bandwidth and delay were 2.85 Mbps and 34.5 ms respectively. We found that DSRC equipment can carry high quality video stream with minimal delay. Similar findings are found in [52]. Figure 5.14: DSRCs test route Object detection algorithm YOLO was able to process 8-10 FPS which is considered acceptable. However, it is possible to achieve higher processing using automotive oriented 80 hardware. As we discussed in Section 5.3, after a pedestrian is detected, the pedestrian distance and angle is estimated. The Region of Interest (ROI) is extracted from the original image and sent to the video/image encoder. Our MJPEG encoder compresses each image individually as JPEG image. This compression method saves a significant amount of time compared to other advance video compression techniques as we shown in our experiment. The average compressed image size is 3.5KB which is much smaller than sharing the full image at high quality setting. However, we limit the video streaming rate to 5 Hz similar to GNSS update rate to achieve best accuracy. Pedestrian distance Y and ∠› are sent at the detection rate which is 8 to 10 Hz. Figure 5.15: Bandwidth between two DSRC units Fig.5.17 depicts the delay at every step of operation, where overall delay is between two consecutive images fusions including the display of the final fused image. The average overall delay is 200 ms which is similar to the video sharing rate of 5 Hz, mainly due to the fact that the 81 GNSS update is limited to 5 Hz. The fusion processes delay average is 33 ms and includes the delay caused by calculation, fusion and synchronization between remote and local data. Meanwhile the average channel object detection delays are 10ms and 122ms respectively. It is clear that the sum of the fusion, channel and object detection is less than overall delay, suggesting the 200ms delay is not processing delay but due to the 5Hz update rate of GNSS. It is possible to increase the information sharing rate by a) improving object detection processing rate without decreasing detection accuracy b) increasing GNSS rate. Figure 5.16: Packet delay between two DSRC units 82 Figure 5.17: The delay of proposed system (CPCAS). Table (5.2) shows the calculations that are conducted during our pre-collision interaction which lasted 2.4 seconds. During that interaction, the driver is warned about pedestrian crossing. A sample of the fused images is shown in Fig. 5.18. 83 Table 5.2: Proposed system (CPCAS) calculations results Time (seconds) Speed (m/s) DTC (m) TTC (seconds) 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 8.98 8.94 8.65 8.64 8.49 8.31 7.77 7.64 7.64 7.10 6.52 6.13 20.1 19.1 17.99 16.5 15.62 14.4 12.79 11.5 10.8 10.1 9.4 9.1 2.25 2.18 2 1.9 1.8 1.61 1.53 1.47 1.42 1.41 1.43 1.4 84 (a) (c) (b) (d) (e) (f) Figure 5.18: A sample of CPCAS system image fusion results 85 Chapter 6 Conclusions In the first three sections of this thesis, we developed a novel approach, Erasable Packets within Internet Queues (EPIQ), for video streaming. EPIQ provides high quality video transmission with minimal network complexity. Under congestion, EPIQ works by erasing portions of multiple video packets within a network queue rather than the conventional packet dropping mechanism. We developed analytical models for our proposed solution for ideal and non- ideal operation then we verified them using simulation. We further introduced EPIQ-RED AQM, based on the well know RED algorithm, to implement our partial packet erasing. Furthermore, to maintain fairness and to control the rate of competing video streams, we presented EPIQ-TFRC. Our simulation results show that our system can achieve better performance than both multi- queue and HTTP-based video streaming. In summary, the proposed EPIQ solution introduces a new paradigm in video streaming by partially erasing packets to control congestion in the network while maintaining the highest video transmission quality. In the last section of this thesis, we proposed a new Cooperative Advance Driver Assistance system (C-ADAS) that will potentially reduce the number of pedestrian accidents significantly. Our proposed system tries to eliminate obstruction of view problem that vehicle drivers face every day. Our system achieves low end-to-end delay .We introduced a selective sharing algorithm that decided what to share and with whom, thus minimizing the amount needed bandwidth for visual information sharing. Our proposed system can be utilized with various types of sensors to improve its performance. Our experiment shows that our system can achieve the desired results with minimum bandwidth usage and low delay. 86 BIBLIOGRAPHY 87 BIBLIOGRAPHY [1] “White paper: Cisco VNI Forecast and Methodology, 2015-2020,” Cisco. [Online]. Available: networking-index-vni/complete-white-paper-c11-481360.html. [Accessed: 20-Nov-2016]. http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual- [2] MPEG-DASH. ISO/IEC 23009, Retrieved November 16, 2015 from http://mpeg.chiariglione.org/standards/mpeg-dash [3] A. Begen, T. Akgul, and M. Baugher, “Watching Video over the Web: Part 1: Streaming Protocols,” IEEE Internet Computing, vol. 15, no. 2, pp. 54–63, Mar. 2011. [4] S. Akhshabi, L. Anantakrishnan, A. C. Begen, and C. Dovrolis, “What happens when HTTP adaptive streaming players compete for bandwidth?,” in Proceedings of the 22nd international workshop on Network and Operating System Support for Digital Audio and Video, 2012, pp. 9–14. [5] S. Akhshabi, S. Narayanaswamy, A. C. Begen, and C. Dovrolis, “An experimental evaluation of rate-adaptive video players over HTTP,” Signal Processing: Image Communication, vol. 27, no. 4, pp. 271–287, Apr. 2012. [6] R. Kuschnig, I. Kofler, and H. Hellwagner, “An Evaluation of TCP-based Rate-control Algorithms for Adaptive Internet Streaming of H.264/SVC,” in Proceedings of the First Annual ACM SIGMM Conference on Multimedia Systems, New York, NY, USA, 2010, pp. 157–168. [7] J. Jiang, V. Sekar, and H. Zhang, “Improving Fairness, Efficiency, and Stability in HTTP- Based Adaptive Video Streaming With Festive,” IEEE/ACM Trans. Netw., vol. 22, no. 1, pp. 326–340, Feb. 2014. [8] G. Tian and Y. Liu, “Towards Agile and Smooth Video Adaptation in Dynamic HTTP Streaming,” in Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies, New York, NY, USA, 2012, pp. 109–120. [9] Z. Li, X. Zhu, J. Gahm, R. Pan, H. Hu, A. C. Begen, and D. Oran, “Probe and Adapt: Rate Adaptation for HTTP Video Streaming At Scale,” IEEE Journal on Selected Areas in Communications, vol. 32, no. 4, pp. 719–733, Apr. 2014. [10] “Inside The Netflix/Comcast Deal and What The Media Is Getting Very Wrong,” Dan Available: Rayburn http://blog.streamingmedia.com/2014/02/media-botching-coverage-netflix-comcast-deal- getting-basics-wrong.html. [Accessed: 22-Jul-2016]. 24-Feb-2014. - StreamingMediaBlog.com, [Online]. 88 [11] M. Nagy, V. Singh, J. Ott, and L. Eggert, “Congestion Control Using FEC for Conversational Multimedia Communication,” in Proceedings of the 5th ACM Multimedia Systems Conference, New York, NY, USA, 2014, pp. 191–202. [12] “Viewer Experience Report 2015,” Conviva. [Online]. Available: http://www.conviva.com/conviva-viewer-experience-report/vxr-2015/ [13] F. Dobrian, V. Sekar, A. Awan, I. Stoica, D. Joseph, A. Ganjam, J. Zhan, and H. Zhang, “Understanding the Impact of Video Quality on User Engagement,” in Proceedings of the ACM SIGCOMM 2011 Conference, New York, NY, USA, 2011, pp. 362–373. [14] [X. Zhu and R. Pan, “NADA: A Unified Congestion Control Scheme for Low-Latency Interactive Video,” in 2013 20th International Packet Video Workshop, 2013, pp. 1–8. [15] R. Huysegems, J. van der Hooft, T. Bostoen, P. Rondao Alface, S. Petrangeli, T. Wauters, and F. De Turck, “HTTP/2-Based Methods to Improve the Live Experience of Adaptive Streaming,” in Pro. of the 23rd ACM Intern. Conf. on Multimedia, NY, USA, 2015, pp. 541–550 [16] D. Jarnikov and T. Ozcelebi, “Client intelligence for adaptive streaming solutions,” in 2010 IEEE International Conference on Multimedia and Expo (ICME), 2010, pp. 1499–1504 [17] Z. Li, A. C. Begen, J. Gahm, Y. Shan, B. Osler, and D. Oran, “Streaming Video over HTTP with Consistent Quality,” in Proceedings of the 5th ACM Multimedia Systems Conference, New York, NY, USA, 2014, pp. 248–258 [18] M. Grafl, C. Timmerer, H. Hellwagner, W. Cherif, and A. Ksentini, “Evaluation of hybrid Scalable Video Coding for HTTP-based adaptive media streaming with high-definition content,” in World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2013 IEEE 14th International Symposium and Workshops on a, 2013, pp. 1–7 [19] Y. Sánchez de la Fuente, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer, W. Van Leekwijck, and Y. Le Louédec, “iDASH: improved dynamic adaptive streaming over HTTP using scalable video coding,” in Proceedings of the second annual ACM conference on Multimedia systems, 2011, pp. 257–264 [20] R. Kuschnig, I. Kofler, and H. Hellwagner, “An Evaluation of TCP-based Rate-control Algorithms for Adaptive Internet Streaming of H.264/SVC,” in Proceedings of ACM SIGMM Conference on Multimedia Systems, New York, NY, USA, 2010, pp. 157–168 [21] S. Floyd, M. Handley, J. Padhye, and J. Widmer, “Equation-based Congestion Control for Unicast Applications,” in Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, New York, NY, USA, 2000, pp. 43–56 [22] L. De Cicco, G. Carlucci, and S. Mascolo, “Experimental Investigation of the Google Congestion Control for Real-time Flows,” in Proceedings of the 2013 ACM SIGCOMM 89 Workshop on Future Human-centric Multimedia Networking, New York, NY, USA, 2013, pp. 21–26 [23] S. Loreto and S. Pietro Romano, “Real-Time Communications in the Web: Issues, Achievements, and Ongoing Standardization Efforts,” IEEE Internet Computing, vol. 16, no. 5, pp. 68–73, Sep. 2012 [24] J. W. Evans and C. Filsfils, Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice. Morgan Kaufmann, 2010. [25] D. Clark and W. Fang, “Explicit Allocation of Best-effort Packet Delivery Service,” IEEE/ACM Trans. Netw., vol. 6, no. 4, pp. 362–373, Aug. 1998. [26] Juha Heinanen and Roch Guerin. A Two Rate Three Color Marker. IETF RFC 2698, 1999. [27] R. Adams, “Active Queue Management: A Survey,” IEEE Communications Surveys & Tutorials, vol. 15, no. 3, pp. 1425–1476, 2013. [28] T. Pliakas, G. Kormentzas, and C. Skianis, “End-to-end QoS issues of MPEG-4 FGS video streaming traffic delivery in an IP/DVB/UMTS network,” European Journal of Operational Research, vol. 191, no. 3, pp. 1089–1100, Dec. 2008 [29] J. Shin, J.-G. Kim, J. Kim, and C.-C. Jay Kuo, “Dynamic QoS mapping control for streaming video in relative service differentiation networks,” Eur. Trans. Telecomm., vol. 12, no. 3, pp. 217–229, May 2001 [30] V. Firoiu and X. Zhang, “Best Effort Differentiated Services: Trade-off Service Differentiation for Elastic App.,” in in Proc. IEEE ICT 2000. [31] P. Hurley, J.-Y. Le Boudec, P. Thiran, and M. Kara, “ABE: providing a low-delay service within best effort,” IEEE Network, vol. 15, no. 3, pp. 60–69, May 2001. [32] J. Gettys and K. Nichols, “Bufferbloat: Dark Buffers in the Internet,” Commun. ACM, vol. 55, no. 1, pp. 57–65, Jan. 2012 [33] Y. Li, X. Gong, W. Wang, X. Que, and J. Ma, “An Autonomic Active Queue Management Mechanism to Improve Multimedia Flow Delivery Quality,” in 2010 International Conference on Communications and Mobile Computing (CMC), 2010, vol. 1, pp. 493–497. [34] S. Floyd and V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance,” IEEE/ACM Trans. Netw., vol. 1, no. 4, pp. 397–413, Aug. 1993 [35] Y. Xiaogang, L. JiQiang, and L. Ning, “Congestion Control Based on Priority Drop for H.264/SVC,” in International Conference on Multimedia and Ubiquitous Engineering, 2007. MUE ’07, 2007, pp. 585–589 90 [36] S. R. Kang, Y. Zhang, M. Dai, and D. Loguinov, “Multi-layer active queue management and congestion control for scalable video streaming,” in 24th International Conference on Distributed Computing Systems, 2004. Proceedings, 2004, pp. 768–777 [37] “Intelligent Transportation Systems - Connected Vehicle Pilot Deployment Program.” n.d. Accessed October 17, 2017. https://www.its.dot.gov/pilots/pilots_nycdot.htm. [38] Matthew Lynberg. 2016. “U.S. DOT Advances Deployment of Connected Vehicle Technology to Prevent Hundreds of Thousands of Crashes.” Text. NHTSA. December 15, 2016. https://www.nhtsa.gov/press-releases/us-dot-advances-deployment-connected- vehicle-technology-prevent-hundreds-thousands. [39] 2016. “Pedestrian Safety.” Text. NHTSA. September 9, 2016. https://www.nhtsa.gov/road- safety/pedestrian-safety. [40] Geronimo, D., A. M. Lopez, A. D. Sappa, and T. Graf. 2010. “Survey of Pedestrian Detection for Advanced Driver Assistance Systems.” IEEE Transactions on Pattern Analysis (7):1239–58. https://doi.org/10.1109/TPAMI.2009.122. Intelligence Machine and 32 [41] Lidstrom, K., K. Sjoberg, U. Holmberg, J. Andersson, F. Bergh, M. Bjade, and S. Mak. 2012. “A Modular CACC System Integration and Design.” IEEE Transactions on Intelligent Transportation Systems 13 (3):1050–61. https://doi.org/10.1109/TITS.2012.2204877. [42] Sawade, O., B. Schäufele, J. Buttgereit, and I. Radusch. 2014. “A Cooperative Active Blind Spot Assistant as Example for Next-Gen Cooperative Driver Assistance Systems (CoDAS).” Intelligent Vehicles Symposium Proceedings, 76–81. https://doi.org/10.1109/IVS.2014.6856570. In 2014 IEEE [43] Xiong, G., H. Li, Y. Jin, J. Gong, and H. Chen. 2017. “Collision Avoidance System with Cooperative Adaptive Cruise Control in Highway Entrance Ramp Environment.” In 2017 18th 549–53. https://doi.org/10.1109/ICAR.2017.8023664. on Advanced Robotics International Conference (ICAR), [44] Sawade, O., and I. Radusch. 2015. “Survey and Classification of Cooperative Automated Driver Assistance Systems.” In 2015 IEEE 82nd Vehicular Technology Conference (VTC2015-Fall), 1–5. https://doi.org/10.1109/VTCFall.2015.7391161. [45] Belyaev, E., P. Molchanov, A. Vinel, and Y. Koucheryavy. 2013. “The Use of Automotive Radars in Video-Based Overtaking Assistance Applications.” IEEE Transactions on Intelligent (3):1035–42. https://doi.org/10.1109/TITS.2013.2248731. Transportation Systems 14 [46] Asefi, M., J. W. Mark, and X. S. Shen. 2012. “A Mobility-Aware and Quality-Driven Retransmission Limit Adaptation Scheme for Video Streaming over VANETs.” IEEE 91 Transactions https://doi.org/10.1109/TWC.2012.030812.111064. Wireless on Communications 11 (5): 1817–27. [47] Mir, Z. H., and F. Filali. 2014. “On the Performance Comparison between IEEE 802.11p and LTE-Based Vehicular Networks.” In 2014 IEEE 79th Vehicular Technology Conference (VTC Spring), 1–5. https://doi.org/10.1109/VTCSpring.2014.7023017. [48] Dreyer, N., A. Moller, Z. H. Mir, F. Filali, and T. Kurner. 2016. “A Data Traffic Steering Algorithm for IEEE 802.11p/LTE Hybrid Vehicular Networks.” In 2016 IEEE 84th Vehicular https://doi.org/10.1109/VTCFall.2016.7880850. (VTC-Fall), Technology Conference 1–6 [49] Brahim, M. Ben, Z. Hameed Mir, W. Znaidi Global Status Report on Road Safety, 2015. [Online]. Available: http://www.who.int/violenceinjuryprevention/roadsafetystatus/2015/en/ [50] F. Filali, and N. Hamdi. 2017. “QoS-Aware Video Transmission Over Hybrid Wireless 5:8313–23. Vehicles.” Access IEEE Network https://doi.org/10.1109/ACCESS.2017.2682278. Connected for [51] Olaverri-Monreal, C., P. Gomes, R. Fernandes, F. Vieira, and M. Ferreira. 2010. “The See- Through System: A VANET-Enabled Assistant for Overtaking Maneuvers.” In 2010 IEEE Intelligent Vehicles Symposium, 123–28. https://doi.org/10.1109/IVS.2010.5548020. [52] Gomes, P., C. Olaverri-Monreal, and M. Ferreira. 2012. “Making Vehicles Transparent Through V2V Video Streaming.” IEEE Transactions on Intelligent Transportation Systems 13 (2):930–38. https://doi.org/10.1109/TITS.2012.2188289. [53] Belyaev, E., A. Vinel, K. Egiazarian, and Y. Koucheryavy. 2013. “Power Control in See- Through Overtaking Assistance System.” IEEE Communications Letters 17 (3):612–15. https://doi.org/10.1109/LCOMM.2013.012213.122362. [54] Kenney, J. B. 2011. “Dedicated Short-Range Communications (DSRC) Standards in the (7):1162–82. Proceedings IEEE the 99 United of https://doi.org/10.1109/JPROC.2011.2132790. States.” [55] Naus, G. J. L., R. P. A. Vugts, J. Ploeg, M. J. G. van de Molengraft, and M. Steinbuch. 2010. “String-Stable CACC Design and Experimental Validation: A Frequency-Domain Approach.” (9):4268–79. https://doi.org/10.1109/TVT.2010.2076320. on Vehicular Technology IEEE Transactions 59 [56] Joint Video Team, “Reference software,” http://iphome.hhi.de/suehring/tml/ [57] A. Detti, G. Bianchi, C. Pisa, F. S. Proto, P. Loreti, W. Kellerer, S. Thakolsri, and J. Widmer, “SVEF: an open-source experimental evaluation framework for H.264 scalable video streaming,” in IEEE Symposium on Computers and Communications, 2009. ISCC 2009, 2009, pp. 36–41 92 [58] M. Blestel and M. Raulet, “Open SVC decoder: a flexible SVC library,” in Proceedings of the international conference on Multimedia, 2010, pp. 1463–1466 [59] H. Schwarz, D. Marpe, and T. Wiegand, “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 17, no. 9, pp. 1103–1120, Sep. 2007 [60] V. Jacobson, K. Nichols, K. Poduri, and C. Systems, “RED in a Different Light,” 1999 [61] C. V. Hollot, V. Misra, D. Towsley, and W.-B. Gong, “ A control theoretic analysis of RED,” in IEEE INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings, 2001, vol. 3, pp. 1510–1519 [62] F. P. Kelly, A. K. Maulloo, and D. K. H. Tan, “Rate Control for Comm.Netw.: Shadow Prices, Proportional Fairness and Stability,” The Journal of the Operational Research Society, vol. 49, no. 3, pp. 237–252, 1998 [63] E. Kohler, M. Handley, S. Floyd, Datagram Congestion Control Protocol (DCCP), IETF RFC4340, March 2006 [64] Derf’s short video collection.” http://media.xiph.org”. [65] andrew.currin.ctr@dot.gov. 2016. “Safety Technologies.” Text. NHTSA. September 8, 2016. https://www.nhtsa.gov/equipment/safety-technologies. [66] “Reach.” . Emlid (blog). Accessed October 17, 2017. https://emlid.com/reach/. [67] Redmon, Joseph, and Ali Farhadi. 2016. “YOLO9000: Better, Faster, Stronger.” ArXiv:1612.08242 [Cs], December. http://arxiv.org/abs/1612.08242. [68] “The PASCAL Visual Object Classes Homepage.” Accessed October 17, 2017. http://host.robots.ox.ac.uk/pascal/VOC/. 93