WEVCast: practical implementation and testing of ...

WEVCast: practical implementation and testing of effective multicast services for Wi-Fi Networks Pasquale PACE, Gianluca ALOI Department of Electronics, Computer and System Sciences (DEIS) - University of Calabria Via P. Bucci 42C, Rende 87036, ITALY {ppace,aloi}@deis.unical.it Abstract — In this paper we present the successful implementation of WEVCast (Wireless Eavesdropping Video Casting) [2] a new mechanism to improve the performance of multicast streaming video over wireless networks. It is well known that the standard IEEE 802.11 protocol has no specific mechanism for multicast transmission and it always uses the base transmission rate (i.e., 1/6 Mbps for 802.11 b/g) because it simply implements multicasting using broadcasting. On the contrary, WEVCast system allows network devices to switch in overhearing mode in order to capture video packets; moreover, a simply feedback mechanism, based on RSSI messages periodically sent by the client nodes, has been added and managed by the sender node to dynamically adjust the transmission data rate. A detailed testbed has been implemented to validate our study and the quality of the received video content has been analyzed throughout the BVQM software. Obtained results show that WEVCast is a valid solution to realize a simple and cost-effective wireless hot-spot for multimedia contents delivery. Keywords - Multimedia content delivery, wireless multicast, overhearing, Quality of Experience-QoE.

I.

INTRODUCTION

The large use of broadband wireless local area networks (WLANs) IEEE 802.11g has greatly increased the demand for wireless delivery of high quality video within home and enterprise environments. They represent the cheapest and fastest growing network technologies in the wireless communication field. This advance of wireless pervasive technology is generally proven by the fact that most of our personal digital assistants (PDAs), laptops and consumer electronics include by default a Wi-Fi interface. In addition, widely deployed IEEE 802.11 Wireless LANs can be also one of the promising candidates for delivering Wireless IPTV [1] applications comprising convergence of communication, computing and content, as well as integration of broadcasting and telecommunication. Since more and more places are covered by hotspots, this will allow travelers at airports or at rail stations to use their PDAs and watch television broadcasts or news; thus, at the same time, we can be overrun with all kinds of multimedia applications and multicasting video transmission, instead of streaming individually each video flow resulting in a much more efficient use of the shared wireless medium. Starting from this modern communication scenarios, multicast transmission over wireless networks is a fundamental function because of the inherently broadcast-oriented nature of the wireless networks. This means that a packet can be intercepted by all nodes in the sender’s transmissions range making multicast transmission an effective method to send

packet to a group of receivers. However, multicast transmission over WLANs presents severe drawbacks (i.e., Channel-state Indifference, too simple adaptation rate mechanism, absence of MAC-layer retransmission) as explained in the introduction section of [2] making the performance of Broadcast Multicast Services (BMS) very poor when one or more clients belonging to the multicast group are affected by a degradation in terms of link quality. These limitations have been addressed in the last few years proposing different approaches; in particular, Gopal et al. [3] explored and analyzed the feasibility of wireless networks to sustain video multicast applications. They have shown that control packets overhead in 802.11 DCF mode cause significant bottleneck for simultaneous multicast streams. In order to alleviate this problem they suggested to use 802.11 PCF mode, a statistical multiplexer and smarter queues in the wireless access point. The problem of the receivers with potentially different connection bit rate and very limited feedback information to the sender has been analyzed by [4]. The solution combines scalable source coding based on client rate adaptation coupled with channel packet erasure coding. Another work that proposes an explicit rate adaptation mechanisms based on the quality of experience perceived by the users, is presented in [5] whilst the reliability improvement in multicast scenario is the goal of [6] and [7]: the first paper proposed a new protocol called Batch Mode Multicast MAC (BMMM) which reduces the number of contention phases also reducing the time required for a multicast/broadcast setup; the latter approach [7] used a Raptor code-based forward error correcting scheme right above the medium access control layer in order to ensure the reliability of the video delivery. Finally, in [8] the authors proposed HIMAC scheme adding two new mechanism: Unary Channel Feedback (UCF) and Unary Negative Feedback (UNF) to address the “Channel-state Indifference” and “Demand Ignorance” shortcomings of IEEE 802.11 protocol respectively. Despite the presented schemes, our approach aims at being more effective and easy to be implemented in real network adapters without any change to the standard communication protocol stack. It is based on sending video packets to a single Target Node (TN) in unicast mode while the other nodes within the Access Point coverage area can switch in overhearing mode to automatically “eavesdrop” the video transmission [2]. In this work we implemented and tested the WEVCast solution exclusively integrating and using open source software easily downloadable from Internet in order to demonstrate the extreme compatibility of the WEVCast system architecture with all off-the-shelf wireless technology. In particular, the access point used for testbed is the Linksys WRT54GL on which we installed the DD-WRT firmware v24 SP2 [9] [10];

the bash programming language of Ubuntu Linux has been exploited [11] to implement several scripts on client and server components; furthermore, VLC Media Player [12] has been configured to send and receive multimedia contents. In this paper, security aspects are out of the main scope because we supposed to work in a simple open wireless environment even if we used hacking techniques like MAC/IP-spoofing. According to this choice, we recall that the implemented architecture is well suited for the following application scenarios in open wireless environments as described in [2]: 1. In a shopping mall can be easily implemented a small IPTV network for customers in order to provide detailed video advertisements or discount promotions for specific stores; 2. In home environments, a generic user wishes to replicate a single video content on different terminals (TV, PC, . . .) placed in different rooms; 3. In a congress meeting held in several rooms equipped with a wireless digital camera, each participants to the conference, seated in a specific room, could wish to watch the talk given in other rooms. The rest of paper is organized as follows: Section II presents the feasible implementation of the WEVCast architecture composed by server and client components. Section III presents the techniques for Objective Video Quality Evaluation and an overview of software tool used in our testbed. Section IV presents the results obtained from an experimental evaluation of WEVCast over Wi-Fi LAN with a self-modified firmware DD-WRT installed on the Linksys access point and finally, conclusions and future research directions have been discussed in Section V. II.

WEVCAST ARCHITECTURE IMPLEMENTATION

The WEVCast architecture is shown in figure 1, it consists of a single Target Node (TN), many WEVCast Client Nodes (CNs) and a Server Component (SC). The CN is a laptop that runs Ubuntu Linux with VLC Media Player and the server component is composed by a Linksys Access Point and a single server computer on which are stored multimedia video content to be delivered.

in the WEVCast mode operation starting the specific client script and providing MAC-Address, IP-Address and wireless interface. After few buffering seconds, video packets are overheard and VLC Media Player installed on the generic CN, can reconstruct multimedia flows. A more detailed description of the theoretical WEVCast operation together with an extensive simulation analysis, has been provided in our previous work [2]; thus, in order to save space, we warmly invite the reader to have a look to the contents of that paper because, in this work, we are mainly interested in the presentation of technical details for the practical implementation of the WEVCast system. A. Client Component The generic WEVCast Client Node is based on OS Ubuntu Linux and the VLC Media Player software to receive video packets. Ubuntu Linux allows to easily create an overhearing network device modifying MAC-Address and adding hidden IP-Alias. Having forced the MAC-Address change through a Linux command line, the client can overhear video flows directed to TN. This modification is not sufficient to pass video data to higher levels. We know that RTP delivery consists of an IP-Address coupled with a specific Port Number. In order to deliver video data to the “Application” level we need to create an IP-Alias adding the specific IP-Address of the TN. Specifically, the generic network device overhears video flows at MAC level, then, thanks to the IP-Alias configuration, it can open the IP-packets to reconstruct video data. In addition we also programmed another Linux bash script running on the CN that periodically send 30 ping messages to the server. This software routine allows to generate RSSI (Received Signal Strength Indication) signals which are used by a specific algorithm running on the SC to set the best transmission data rate as explained in the next subsection. In order to create a user-friendly and cross-platform system, the WEVCast software routines, to be run on the generic CNs, have been loaded in a bootable USB Pen Drive using Linux Live USB Creator (fig. 2.a)[15].

(a)

(b)

Figure 2. a) Control Panel LiLi USB Creator. b) Booting OS Ubuntu Linux. Figure 1. WEVCast Architecture.

The basic operation of the WEVCast system is as follows: the server starts one or many video unicast sessions with the TN; other nodes who want to receive video content can switch

This application utility allows to boot an OS Linux directly from external hard drive without any modification to original OS. An embedded USB Drive has been created with all software and WEVCast scripts required. The generic user simply inserts WEVCast USB Drive into a free USB Port,

boots Linux in “Persistent Mode” (fig. 2.b), selects favorite channel and enjoys the video broadcast (fig. 3).

Figure 3. Video content received by the generic Client Node.

B. Server Component and Rate Adaptation strategy The SC implements a simple multimedia transmission to the TN using VLC Media Player to send video content in RTP packets [16] at IP-Address of the TN. When CNs activate overhearing mode, the wireless router cannot distinguish different CNs because of the MAC address spoofing and IP address alias procedures implemented in the network settings of the generic CN; thus, if the generic CNs work in overhearing mode, the router cannot decide the best transmission data rate for all CNs since the transmission rate only depends by the feedback messages received from the TN. A simple solution to overcome this drawback could consist in placing the TN in worst position, at the bound of the coverage area. This naïve solution could be considered too much conservative because it does not take into account the real conditions of all CNs in terms of their link quality; for example, just think of the situation in which most users are in good channel conditions, but the transmission rate of the SC would still be set at the minimum value (i.e. 6Mbps for the IEEE 802.11g) due to the poor positioning of the TN. On the contrary, our feasible solution aims at dynamically adapting the transmission rate of the SC according to the average link quality conditions of all CNs involved in the overhearing process. Following this main intuition, we programmed a simple script in the firmware of the router with the aim of managing the RSSI messages periodically received from the CNs to support an effective rate adaptation strategy. The algorithm works according to the following steps: 1.

Each 30 seconds it records 30 RSSI (one per second) received by the CNs working in overhearing mode

2.

It counts how many RSSI values belong to each of the intervals in the table I representing a Rate Map specifically designed for our testbed

3.

If more than 50% of the received RSSI messages belong to a specific range then the router will change the transmission rate respecting the combinations shown in the Rate Map table.

In this way it is possible to offer a QoE (Quality of Experience) level to the CNs in agreement with the average wireless link conditions of all the CNs involved in the WEVCast system. This approach seems to be a good compromise resulting more fair for users located in different zone as we will demonstrate in section V, and less conservative respect to always force all users to transmit at the lowest base rate.

TABLE I.

DATA RATE MAP

RSSI [dB]

< -75

[-74; -60]

[-59; -40]

> -40

TX Rate

6 Mbps

9 Mbps

12 Mbps

18 Mbps

1) WMM (Wi-Fi MultiMedia) The wireless router used for our testbed supports the WMM (Wi-Fi MultiMedia) function [21] making possible to configure QoS options by setting parameters on existing queues for different types of wireless traffic. Thanks to this feature, we can set different minimum and maximum wait times for the transmission of packets in each queue based on the requirements of the multimedia content to be sent. Queues automatically provide minimum transmission delay for Voice, Video, multimedia and mission critical applications also relaying on best-effort parameters for traditional IP data. As an example, time-sensitive Voice & Video, and multimedia are given effectively higher priority for transmission (lower wait times for channel access) while other applications and traditional IP data which are less time-sensitive but often more data-intensive, are expected to tolerate longer wait times. The correct configuration of this feature can really improve the performance of the WEVCast system. III.

VIDEO QUALITY MEASUREMENT

Video processing and transmission systems may introduce some amounts of distortion or artifacts on the video signal, so video quality evaluation is a significant issue for multimedia contents delivery architecture. Objective video evaluation techniques are mathematical models that approximate results of subjective quality assessment but they are based on criteria and metrics that can be measured objectively and automatically evaluated by a software program. Objective methods are categorized based on the availability of the original video signal which is considered to be of high quality (generally not compressed). The main goal of many objective video quality metrics is to automatically estimate average users (viewers) opinion on a quality of video processed by the system. Sometimes however, measurement of subjective video quality can also be challenging because it may require a trained expert to judge it. The video sequences are shown to the group of viewers and then their opinion is recorded and averaged to evaluate the quality of each video sequence; however, details of testing may vary greatly. The most traditional way for the objective evaluation of digital video quality consists into the calculation of the signalto-noise ratio (SNR) and peak signal-to-noise ratio (PSNR) between the original video signal and signal passed through this system. PSNR is the most widely used objective video quality metric; however, PSNR values do not perfectly correlate with a perceived visual quality due to non-linear behavior of human visual system. For this reason, a number of more complicated and precise metrics have been recently developed such as UQI, VQM, PEVQ, SSIM and CZD. In particular, VQM [17] provides an objective measurement for perceived video quality. It measures the perceptual effects of video impairments including blurring, jerky/unnatural motion, global noise, block and color distortion combining them into a single metric. The testing results show that VQM metric has a high correlation with subjective video quality

assessment, for this reason it has been adopted by ANSI as an objective video quality standard.

can argue that the experiments have been carried in “real” network conditions.

The Institute for Telecommunication Sciences (ITS) [18] has developed a video quality metric (BVQM) software tool that performs automated batch processing of multiple video clips to objectively assess their video quality [19].

We first demonstrated the bad functioning of standard multicast mode; then, we presented a sequence of experiments supporting mobile CNs with and without RSSI control messages support. Finally, we demonstrated the advantages of using WMM configuration to guarantee a good QoE level for video flows while transmitting delay tolerant data traffic.

BVQM provides a graphical user interface (GUI) to select the video clips for the batch process. Processing consists of calibrating the processed video clips and calculating their associated video quality metrics. Users can manually set calibration values or choose between several automated calibration options. Multiple video quality model options are also available. After processing, BVQM displays the results graphically and provides text file reports. All results are available for viewing or export to spreadsheet software. Then, it is possible to specify a calibration algorithm and a video quality model. Calibration attempts to remove impairments from the processed video sequence that viewers either do not see or do not care about. The Video Quality Measurement results window shown in figure 4, displays an example of results obtained from the GUI. Results may be viewed either graphically, as text reports or as exported spreadsheet files.

Figure 5. Active wireless networks during the testbed.

A. Video content characteristics Video content to be delivery during the testbed have been codified with Apple Quicktime 7 PRO [13] using H.264/MPEG4-AVC that is a video codec widely employed in different hardware devices able to guarantee high video quality and efficiency with small file dimension [14]. Moreover, in order to assurance high video quality and preserve bandwidth consumption, all videos have been codified using a fixed bit rate of 1500 kbit/s (average value) with a resolution of 640 × 272 pixel @ 25fps. We would like to remark that in the implemented WEVCast testbed, we did not allow to use transmission data rate higher than 18Mbps because we verified that this value can guarantee best performance in overhearing mode. Using transmission rate in a range between 6-18Mbps assures to achieve a throughput of 5-10 Mbps making possible to send up to four video flows at the same time. Concerning the video quality measurement, we selected “Full Reference Calibration” [20] and we used the default value for the Temporal Registration Uncertainty consisting of the maximum expected uncertainty (in seconds) of the temporal registration between the processed and original video files. Finally, we considered excellent video quality if the VQM average value is in a range between 0.2 and 0.4.

Figure 4. Video Quality Measurement Results.

IV.

B. Standard Multicast scenario Figure 6 shows the placement of SC and CNs within the testbed area. The main objective of this test consists in evaluating the standard behavior of multicast transmission over WLAN. The obtained results will be used as a reference to be compared with those obtained by the WEVCast system.

EXPERIMENTAL EVALUATION AND RESULTS

In this section, we present the experimental evaluation of WEVCast architecture throughout an ad-hoc WLAN testbed using the Linksys wireless router with a self-modified DDWRT firmware. The testbed consists of one AP and 3 clients distributed on a floor of our research laboratory. The experiments have been carried out in the 2.4GHz band (802.11g) and since there were many active b/g networks in the building during the experiment, as confirmed by figure 5, we Figure. 6: Standard Multicast scenario.

In particular, the video server sent to multicast group a single video content codified with different data rate: 570kbps, 800kbps, 1000kbps, 1200kbps and 1500kbps. At the lowest bit rate (i.e., 570kbps), both CNs obtained a VQM average score around 0.38. At second step, 800kbps, the performance on multicast mode is significantly worse, both CNs obtained a VQM average score around 0.67. Third and fourth steps demonstrated bad performances of multicast protocol for high data rate flows; in particular, loss rate at 1000kbps reached value of 18.7% (VQM average score equal to 0.9) and at 1200kbps or at 1500kbps the losses were too high (more than 40%) to reconstruct the video at the receivers. We would like to remark that this poor performance is mainly due to the fact that the standard IEEE 802.11 protocol achieves multicasting at the MAC layer using broadcasting mechanisms always setting the base transmission rate which may be much lower than the highest acceptable rate for some multicast neighbors. Figure 7 summarizes the obtained results for the standard multicast scenario.

(a)

(b)

Figure 9. First 90 seconds VQM Score – a) CN_1 – b) CN_2.

The next analysis consists in enabling RSSI control messages from CNs to the server allowing the server to dynamically adjust the transmission data rate value according to the Data Rate Map presented in table I. In these conditions the CN_1 obtained a VQM average score of 0.35 and the CN_2 a value of 0.38. The details of VQM measurement of single parsed clips is shown in figures 10.a and 10.b respectively.

Standard Multicast Scenario 60% 50,0%

Loss Rate

50%

43,4%

40%

(a)

30% 18,7%

Figure 10. First 90 seconds VQM Score enabling RSSI control messages from CNs to the Server – a) CN_1 – b) CN_2.

20% 10% 0,7%

1,2%

0% 570

800

1000

(b)

1200

1500

Data Rate [Kbps]

Figure 7. Loss rate varying the Data Rate in standard multicast scenario.

C.

WEVCast Scenario Figure 8 shows the scenario in which the WEVCast system architecture has been tested. The video server initiated a unicast RTP session with the TN (represented by the laptop with the target on the screen placed very far from the SC) while other laptops (CNs) started a WEVCast session. After a small setup phase for the overhearing procedure, both CNs were able to reconstruct data flow and enjoy the video content transmitted to the TN. During this first analysis, the RSSI control messages from CNs to the SC were disabled; however, both CN_1 and CN_2 obtained a satisfactory VQM average score of 0.2 and 0.38 respectively. The details of VQM measurement of single parsed clips is shown in figures 9.a and 9.b.

Figure 8. WEVCast Testbed n° 1. The laptop with target on screen is the TN; the laptops with pirate’s flag are CNs.

These obtained performances have prompted us to conduct a new test in order to verify that the CN’s RSSI control mechanism coupled with the rate adaptation strategy described in section II.B, allows to guarantee a certain “fairness” between CNs placed in very disparate positions (closer or farther) respect to the TN. The new transmission scenario is shown in figure 11 where the TN has been moved towards a room nearest the SC while CN_2 has been moved in a room very far from the TN.

Figure 11. WEVCast Testbed n° 2. One CN is very far from the TN whist the other CN is very close to the TN.

Figure 11 summarizes the WEVCast system performances during all the conducted tests; we have shown the VQM values varying the distance and the position of CNs in order to validate the goodness of the proposed approach in several realistic conditions. In particular, STEP 1 and STEP 2 represent scenarios depicted in figure 8 and 11 respectively whilst in STEP 3 and STEP 4 the two transmission scenarios are tested again enabling the CN’s RSSI control mechanism. Going into details, we would like to remark that in STEP 1, CN_1 is positioned in the same room of the SC whilst CN_2 is placed in another room, 10 meter far from the SC while the TN is placed

in the worst position (figure 8-testbed n°1). In STEP 2 (figure 11-testbed n°2) TN has been moved to a better position closer to the SC and CN_1; for this reason the CN_2 measured a higher value of VQM mostly due to the great distance from the TN. In STEP 3 and STEP 4, thanks to the CN’s RSSI control mechanism, both CN_1 and CN_2, despite the position of the TN, achieved a quite similar VQM average score demonstrating as the proposed approach guarantees a certain fairness degree by providing the same benefit to all CNs. CN_1

CN_2

0,5 0,45

multimedia contents over Wi-Fi networks proposed in [2]. Unlike many previous schemes, WEVCast does not require any changes to the standard IEEE 802.11 protocol and it can be deployed in existing and standard Wi-Fi networks. WEVCast architecture based on an overhearing scheme coupled with a simple and smart rate adaptation mechanism, uses pseudobroadcast to improve the poorest performance of multicast mode over Wi-Fi networks. Open source software and a selfmodified DD-WRT firmware for the Linksys router have been used to execute testbed experiments that demonstrated the goodness of the proposed approach. Future research directions consist in the implementation of security scheme well suited for the communication in overhearing mode in order to prevent outsider eavesdropping and data manipulation

0,4

REFERENCES

VQM

0,35 [1]

0,3 0,25

[2]

0,2 0,15

[3]

0,1 STEP 1

STEP 2

STEP 3

STEP 4

[4]

Fig. 11: VQM values of CNs in different transmission scenarios.

D.

WMM – Wi-Fi MultiMedia analysis In this test, we enabled the WMM support provided by the DD-WRT firmware of the Linksys router. In particular we used different values, shown in figure 12, for the Arbitration InterFrame Spacing (AIFS) shortening or expanding the period a CN has to wait before it is allowed to transmit its next frame according to different traffic sources such as Background, Best Effort, Video and Voice data flows. After this proper configuration, we activated an FTP session and we sent a big file to a CN from the SC starting, at the same time, a WEVCast session. The bandwidth on the wireless link quickly saturated at maximum value supported by the WLAN as shown in figure 12 but, although data traffic load on the wireless link was really high, we obtained a VQM average score equal to 0.27 for the multimedia content sent throughout the WEVCast session. This result demonstrated the effectiveness of the WMM support which allows to use the SC for general purpose network.

[5]

[6]

[7]

[8]

[9] [10] [11] [12] [13] [14] [15] [16] [17]

[18] [19] Fig. 12: Wireless Bandwidth Monitoring.

V.

CONCLUSIONS

In this paper we have effectively implemented and tested the WEVCast system for effective transmission of multicast

[20]

[21]

M. Gidlund and J. Ekling, “VoIP and IPTV distribution over wireless mesh networks in indoor environment”, IEEE Transactions on Consumer Electronics, Vol. 54, Issue: 4, 2008, pp: 1665-1671. P. Pace and G. Aloi, “WEVCast: wireless eavesdropping video casting architecture to overcome standard multicast transmission in Wi-Fi networks” TELECOMMUNICATION SYSTEMS – Springer – Online First™, 2 July 2011, DOI: 10.1007/s11235-011-9533-1. S. Gopal, K. Ramaswamy, C. Wang, “On Video Multicast over Wireless LANs”, IEEE Conference on Multimedia and Expo, June 2004. I. Kozintsev, J. McVeigh, “Improving last-hop multicast streaming video 802.11” International Conference on Broadband Networks – BROADNETS, October 2004. K. Piamrat, C. Viho, A. Ksentini, J.M. Bonnin, “Rate adaptation mechanism for multimedia multicasting in wireless IEEE networks”, International Conference on Broadband Networks – BROADNETS, November 2009. Min-Te Sun, L. Huang, A. Arora, Ten-Hwang Lai, “Reliable MAC Layer Multicast in IEEE 802.11 Wireless Networks”, International Conference on Parallel Processing, December 2002. M. Samokhina, K.Moklyuk, S. Choi, J. Heo, “Raptor Code-Based video multicast over IEEE 802.11 WLAN” IEEE VTS Asia Pacific Wireless Communications Symposium – APWCS, August 2008. A. Chen, D. Lee, G. Chandrasekaran and P. Sinha, “HIMAC: High Throughput MAC Layer Multicasting in Wireless Networks”, IEEE International Conference on Mobile Ad hoc and Sensor Systems – MASS, 2006. Wiki DD-WRT, http://www.dd-wrt.com/wiki/index.php/Main_Page DD-WRT Development Web Page, http://www.ddwrt.com/wiki/index.php/Development Ubuntu Community, http://www.ubuntu.com/community Wiki VideoLan Media Player, http://wiki.videolan.org/Main_Page Apple.com, “MPEG-4 - The new standard for multimedia on the Internet, powered by QuickTime”. APPLEWhite Paper. [Online] http://images.apple.com/quicktime/pdf/H264_Technology_Brief.pdf. Live Linux, http://www.linuxliveusb.com/how-to.html “RTP: Real Time Protocol” Schulzrinne, H. S. Casner, R. Frederick and V. Jacobson, RFC 1889. M. H. Pinson, S. Wolf, “A New Standardized Method for Objectively Measuring Video Quality” IEEE Transactions on Broadcasting, Vol. 50, No. 3, pp. 312-322, September 2004. ITS Video Quality Research, http://www.its.bldrdoc.gov/vqm/ M. H. Pinson and S. Wolf, “Batch Video Quality Metric (BVQM) User’s Manual”, NTIA Handbook HB-08-441b, November 2007. ANSI T1.801.03 – 2003, “American National Standard for Telecommunications – Digital transport of one-way video signals – Parameters for objective performance assessment,” American National Standards Institute. Available at www.ansi.org. S. Choi, J. del Prado, S. Shankar N, S. Mangold, “IEEE 802.11e Contention-Based Channel Access (EDCF) Performance Evaluation”, IEEE International Conference on Communications –ICC, June 2003.