Scalable WiFi Media Delivery through Adaptive Broadcasts

Sayandeep Sen, Neel Kamal Madabhushi, Suman BanerjeeUniversity of Wisconsin-Madison

Abstract

Current WiFi Access Points (APs) choose transmissionparameters when emitting wireless packets based solelyon channel conditions. In this work we explore thebenefits of deciding packet transmission parameters in acontent-dependent manner. We demonstrate the benefitsspecifically for media delivery applications in WiFi en-vironments by designing, implementing and evaluating asystem, calledMedusa. In order to keep the APs rela-tively simple, we implement theMedusafunctions in amedia-aware proxy. More specifically, when forwardingour media traffic,Medusarequires that APs simply usethe WiFi broadcast feature, and that they refrain frommaking decisions on which wireless packets to retrans-mit, or what PHY rates such packets should be trans-mitted at. Instead we combine these typical link layerfunctions with a few other content-specific choices, inthe proxy. Through detailed experiments across diversemobility and interference conditions we demonstrate theadvantages of this scheme for both unicast and multicastmedia delivery applications. The advantages are partic-ularly substantial in multicast scenarios, whereMedusawas able to deliver a 20 Mbps HD video stream simul-taneously to 25 clients, using a single 802.11 AP, withgood to excellent PSNR.

1 IntroductionRobust delivery of rich media content over wireless linksis an increasingly important service today. As moreand more high quality media content becomes availablethrough the Internet, the user expectation of accessingsuch content over their wireless enabled devices continueto grow. Examples include users watching on-demandshows and movies from sources such as Hulu and Net-Flix, students in a university campus interested in fol-lowing online lectures while sitting in the cafeteria, andemployees in a company watching a company-wide pre-sentation by their CEO, whether at home, at work, orwhile sitting in a coffee shop. While the widely deployedWiFi technology can provide adequate performance forrelatively lower quality media streams, the user experi-ence when watching high quality streams (e.g., HD qual-ity content) leaves much to be desired. In this paper, weattempt to push the envelope of media delivery perfor-mance for WiFi systems, by exploiting some knowledgeof media content in making transmission parameter se-lection at the wireless transmitter (APs). While our pro-posed approach applies equally to unicast as well as to

multicast scenarios, the biggest advantage of the systemarises in the multicast case where multiple users are in-terested in the same content.

A target campus application and challenges:The ITdepartment of the UW-Madison campus is interested inproviding high quality broadcast of specific educationalcontent through its intranet. Such capability would allowstudents sitting in dormitory rooms, in union buildings,in cafeterias, and in libraries, to follow the classroom.Further, the system would also allow easy and conve-nient dissemination of live guest lectures from remotelocations, without requiring the guest lecturer to visit thecampus. While the wired backhaul has sufficient capac-ity to carry such media traffic, initial experiments by theIT department revealed obvious performance problemson the WiFi based last hop. In particular, they observedthat even if 3 users connected to a single 802.11g APattempted to watch thesameHD video stream, the per-formance of the system was abysmally poor1.

The poor performance of media delivery over WiFifor multiple users requesting the same content, is a com-bined effect of three factors: (i) HD quality video placesa high bandwidth demand on the wireless medium —commercial HD encoders, such such as the StreamboxSBT3-9200 [6], create content with data rates rangingfrom 512 Kbps to 30 Mbps, (ii) WiFi typically employs802.11 unicast mode for sending similar content sepa-rately to each user, and (iii) the WiFi transmitter makesvarious configuration choices, e.g., PHY transmissionrates, number of re-transmission attempts, etc., for eachwireless packet, without any knowledge of the relevanceof its(packet’s) contents to end applications. In this pa-per, we design and implement a system calledMedusa—Media delivery using adaptive (pseudo)-broadcasts, thatcan efficiently address issues (ii) and (iii).

1.1 Medusa approachThe 802.11 transmitter typically transmits packets inthe FIFO order and makes multiple decisions for eachwireless packet transmission. This include channel con-tention, i.e., when to attempt wireless transmission, se-lection of the PHY rate for the packet, and the numberof re-transmission attempts to make in case of failures.In this paper we contend that many of these decisions,namely PHY rate selection, number of re-transmission

1An 802.11n AP can potentially scale performance to upto 10-12users watching such HD content simultaneously. The typicalnumberof users in busy parts of campus is often much higher.

attempts for each packet, and the order of packet trans-missions, are better made by taking the “value” of thewireless packet to the application into account as well.Let us consider MPEG-encoded [4] video content thatconsists of I-, P-, and B- video frames. Given that apacket carrying I-bits is more important, the PHY rateof such a packet can be picked more conservatively, thanvalue-unaware rate adaptation algorithms, e.g., Sam-pleRate [8]. This would ensure that the loss probabilityof packets carrying I-bits are particularly low. Similarly,if the wireless channel capacity is scarce and packet er-rors are high, then it is more important to devote greaterre-transmission effort for packets carrying I-bits, thanpackets carrying P- and B-bits.

Hence inMedusa, we offload these decisions for ourmedia traffic to a media-aware proxy that can inter-pret the value of the data. More specifically, APs inMedusano longer perform link-layer re-transmissions orPHY rate selections. Instead, the proxy examines thevalue of each packet to applications, and instructs APs to(re)transmit these packets in a certain order and at speci-fied PHY rate.

Prior work, e.g., Trantor [21], has considered a modelin which a centralized controller decides transmissionparameters, e.g., PHY rates, transmit power, etc. for dif-ferent APs and clients in an entire enterprise WLAN. Ata high level, our proposal of proxy-based PHY rate se-lection and re-transmissions may appear similar. How-ever, there is a fundamental difference between the twoproposals. Trantor suggests a centralized rate selec-tion in a content-agnostic manner, based solely on po-tential interferences between different conflicting wire-less links. The approach inMedusaaugments this de-cision by incorporating knowledge aboutvalue of thepacket contents to applicationsin deciding the PHY rateof packets, the order in which they should be transmit-ted, and the number of re-transmission attempts to bemade. It also optionally utilizes simple network codingapproaches [23] to improve efficiency.

Unicast vs broadcast vs pseudo-broadcast:In a sce-nario where multiple users are requesting the same con-tent (the same media stream, for example), we advocatethe use of 802.11 standard’s broadcast mode of opera-tion. The choice is motivated by the observation thata 802.11 broadcast packet can be used to communicatecontent simultaneously to all receivers. This would sub-stantially reduce the load on the wireless medium. How-ever, MAC-layer broadcast packets do not elicit MAC-layer acknowledgments from receivers, leaving the trans-mitter unaware of losses on the wireless channel. This isa problem for any broadcast-based wireless system, asthe transmitter can no longer decide which packets re-quire re-transmissions. Further, absence of loss infor-mation makes it impossible to determine an appropriate

Video Server

Medusa Proxy

Client

Client

Client

Client

Video Packets

Medusa Packets

Reception report

1) Priority estimation 2) Packet ordering3) Network coding 4) Recp. report processing

Figure 1: Schematic of theMedusashared media deliv-ery system.

PHY rate adaptation mechanism. Hence, we incorpo-rate higher layer acknowledgments from the clients tothe proxy, that help the latter in making these decisionsfor the APs in a content-dependent manner.

In a single user scenario, we could use 802.11 unicasttransmissions. However, even in such settings, it is pos-sible to exploit ER-style network coding opportunitieswhen transmitting wireless packets [23]. Such networkcoded packets, by definition, have multiple intended re-cipients. Broadcast-based 802.11 packets are suitable tofacilitate this enhancement as well.

Lack of MAC-layer acknowledgments is problematic,however, for one more link layer decision that has tobe taken by the APs — channel contention. Lack ofacknowledgments indicating packet losses, prevent APsfrom inferring how the MAC layer backoff countersshould be adjusted. Given the lack of MAC-layer ac-knowledgments for broadcast packets, the existing meth-ods for channel contention are likely to fail. Hence, weuse pseudo-broadcast packets inMedusato communi-cate all broadcast media content, analogous to what wasproposed in COPE to deliver network coded multicastdata [18]. In pseudo-broadcast, 802.11 unicast mode isused where one of the receivers is picked at random tobe the explicitly stated (unicast) recipient, while otherintended recipients simply overhear the packet. MAC-layer acknowledgments arrive from the explicit recipient,and backoff parameters can be appropriately adjusted.Note that these MAC-layer acknowledgments are inter-preted by the APs solely for the backoff adjustment func-tion, and not used by the proxy to decide PHY rate, trans-mission order, or eligibility for re-transmission of pack-ets.

Medusa system overview: Figure 1 shows aschematic of different aspects of theMedusasystem,including an unchanged media server, a media-awareMedusaproxy, and APs and clients with minor software-level changes. TheMedusaproxy intercepts all IP pack-ets corresponding to various video frames and relays

them to the AP for transmission. The proxy instructsthe AP to use 802.11 pseudo-broadcast for each wirelesspacket (irrespective of whether it is part of a multicastor a unicast stream) and also informs the AP what spe-cific PHY rate to transmit the packet at. TheMedusaproxy makes these decisions, using a combination offour mechanisms:(i) WiFi reception reports:Each clientprovides a periodic reception report to the proxy aboutvarious wireless packets that it did or did not receive.While analogous to Reception Reports in RTCP [24],the reception reports inMedusadiffers from those inRTCP in the detailed MAC layer information that is car-ried in Medusafor rate adaptation and re-transmissionpurposes.(ii) Estimating the value of a packet to me-dia applications:Not all packets are of equal impor-tance to receivers. When the wireless channel capacityis scarce, the value of each packet determines the choiceof PHY rate and the number of re-transmission attemptsto be made to deliver the packet. We use a simple perpacket value assignment function at theMedusaproxyto determine the priority level of each packet encapsu-lating a media stream.(iii) PHY rate adaptation and re-transmissions for broadcast packets:We design a PHYrate adaptation and re-transmission strategy for broad-cast wireless packets that cannot depend on MAC-layeracknowledgments. Our rate adaptation scheme istwo-paced.A conservative baseline PHY rate is identified ata slow timescale, and an individual PHY rate for eachpacket is chosen subsequently using an algorithm calledInflate-Deflate. (iv) Packet order selection and networkcoded re-transmissions:We modify the ordering of me-dia packets from traditional FIFO, especially when thechannel quality is poor. Under bad channel conditions,it is beneficial to prioritize packet transmission basedon packet “value”. This would increase the probabilityof successful reception of important packets. Further,the transmission order is also selected such that thereare proxy-initiated re-transmission opportunities for themore important packets. During re-transmissions, wealso leverage the gains of ER-style network coding.

Key contributions: Summarizing, the key contribu-tions of this work is two-fold:

(i) We propose an intuitive design of a pseudo-broadcast based WiFi system for media delivery at highvideo rates. The design incorporates various aspects ofrate adaptation, re-transmission, and packet priorities,coupled with higher-layer feedback.

(ii) We integrate all of these ideas together into a func-tional Medusasystem and present detailed evaluation ofthis system. Our results show thatMedusaprovides ro-bust, high-bandwidth (upto 20 Mbps), HD quality me-dia delivery to tens of co-located WiFi users interested inthe same content, all sharing the same WiFi AP, across a

range of channel conditions and mobility scenarios. Ourtechnique is applicable to unicast media delivery scenar-ios as well.

2 Medusa design overviewWe describe the design ofMedusaby using the exam-ple of MPEG4-encoded [4] video delivery over wireless.In MPEG4 the video content is partitioned in an inde-pendently decodable sequence of pictures, called Groupof Pictures (GOP). Each GOP has frames of three dif-ferent types: I, P and B. Each frame, in turn are brokendown into multiple packets which are then transmittedover wireless channel.

At the receiver, the I frames can be correctly decoded,as long as all constituent packets are received. For decod-ing P packets, the successful reception of previous I or Pframe in sequence is also necessary. Finally, to decode aB frame, the previous as well as the next I or P frame insequence are needed. Put another way, an I frame doesnot depend on any other frame, while P frames depend onanother frame and B frames depend on two other frames.

As described,Medusainvolves an unchanged mediaserver, a media-aware proxy, and APs and clients, withsmall software modification. The only change in theAP is to create a single functionality — for each packetforwarded by the proxy to the AP, the proxy should beable to specify the PHY rate of transmission. The APsimply accepts each such packet (which can be an orig-inal packet, a previously transmitted packet, or a net-work coded packet) and transmits them using the pseudo-broadcast mode using the PHY rate specified by theproxy. The AP continues to perform back-off decisionsindependently based on MAC-layer acknowledgmentsreceived for its pseudo-broadcasts. The client is modi-fied to incorporate WiFi reception reports targeted to theproxy. These reception reports include a higher layer ac-knowledgment (ACK) bitmap, and is sent infrequentlyby the clients, roughly once every 100 packets or 100 ms.Since the proxy knows the PHY rates at which differentpackets were transmitted, it can use these reception re-ports to infer packet losses observed by different clientsat different PHY rates.

Based on this simple setup, the design problem ofMedusacan be stated as,

For a set ofk video packets (including both originalpackets and packets that need re-transmissions), deter-mine the order of transmission and PHY rates for thepackets, and pass this information along with the pack-ets to the APs. Further, determine whether some of thesepackets should be network coded, and whether some ofthem should be discarded.

We present a particular solution to the above problemin the rest of this section that exploits knowledge of thevalue of each packet to applications.

While we describe our scheme for MPEG4 video, ourapproach generalizes to any other media encoding, wherethe content is structured in layers, and there are differentlevels of priority (value) for each layer.

2.1 Determining value of packetsAs mentioned above successful decoding of video framesmight need reception of other video frames. Hence, allelse being equal, the value of each video packet dependson how many other packets (or bytes) depend on thispacket for correct decoding of various video frames. Nat-urally, I-frame packets become more important than P- orB-frame packets. The value of video packets is also in-fluenced by its impending playback deadline and that ofother dependent video frames. Packets for video framesthat are approaching display deadline are more impor-tant. Finally, given that many packets are relevant tomore than one client (true for original and re-transmittedand network coded packets), the value of a packet shouldalso grow with the number of intended recipients.

Previous research on video encoding for streaming [9,12, 19, 26] has proposed LP based techniques for deter-mining the priority of video frames. Such techniquestypically utilize a directed acyclic graph (DAG) of videoframe dependencies along with a (empirical/theoretical)channel error model to determine relative value forframes.

While such sophisticated designs of packet value cancertainly be used, in this paper we consider a relativelyeasy to compute function to determine packet value toapplications that illustrates its usefulness in making rateadaptation, re-transmission, packet ordering, and net-work coding decisions based on the worth of packet con-tents.

In our scheme, we assign a weight,X , to each videoframe, based on how many bytes the frame can help de-code (including itself). This weight is given to all con-stituent packets of this frame. Our media-aware proxyknows the video encoding process, and can calculateX by buffering and observing packets corresponding toeach GOP before making transmission decisions. Wenext assign a weight,C, proportional to the number ofintended recipients of each packet. Finally, we assigna third weight,D, based on the delay until the displaydeadline of this frame. We normalize all these weights tothe same scale, and assign the value of the packet to bethe product of these normalized weights, thus,

Value= X × C/D.

2.2 Determining a base PHY rateOur PHY rate selection process is two paced. Initially,we compute a conservative PHY rate for all the packets.If channel capacity is abundant, all packets will simplybe transmitted at this rate to enhance the possibility of

successful reception. However, if the channel is errorprone, then some of these rates will be updated, as de-scribed in Section 2.3. The timescale for adapting basePHY rate depends on the reception report frequency ofclients (roughly every 100 ms in our current implemen-tation).

We pick the highest PHY rate such that the expectederror probability of the packets at all clients would bebelow a certain threshold (set to a low value) as thebase PHY rate. By retaining PHY rate information forall transmitted packets, the proxy, on receiving ACKbitmaps from client, can infer the necessary error rates.In case statistics for certain PHY rates are missing (pos-sibly because no packets are sent at these rates), standardinterpolation techniques can be used to estimate the ex-pected error rates.

An important distinction of our broadcast rate assign-ment from typical 802.11 unicast rate assignment algo-rithms( [8, 30]) is that, it does not favor a higher rate tomerely increase the channel utilization. Instead it tries toensure high reception probability across multiple broad-cast receivers (who might have diverse channel condi-tions).

Another distinction ofMedusarate adaptation fromunicast stems from inability ofMedusato adapt quicklyto changed network conditions, due to delayed ACKs.This can result inMedusapersisting at high data rateeven when channel quality has deteriorated resulting inhigh errors. To ensure that such a situation does notoccur, we update the error characteristic of the PHYrates with a EWMA function with heavy weight on his-tory(thus preventing it from reacting to transient fades ofthe channel).

Transmitting packets at base PHY rate ensures thatthe packets have a good likelihood of successful recep-tion. However, if the base rate of the system is too low(say, due to presence of clients with bad channel quality)which limits successful transmission of all video packetsbefore their respective deadlines. Under such circum-stances, we selectively increase the transmit rate of dif-ferent packets in a certain order as described next.

2.3 Packet order and actual PHY rateThe problem of deciding the video packet schedule whilemaximizing the delivered quality across a group of usersis known to be NP-complete [12]. Hence, we use aheuristic algorithm for packet ordering. We now de-scribe our mechanism to determine the transmission or-der and PHY rate of packets, using an algorithm, we callInflate-Deflate.The heuristic schedules a batch of pack-ets in each round. For ease of exposition we assume thepresence of a virtual timeline and our goal is to placepackets on this timeline and determine their PHY rate.Placing the packets at a given timeslot signifiesschedul-

Figure 2: Packet ordering and final rate assignment car-ried out byMedusa.

ing the transmission of the packet at that instant. Packets(including retransmission candidates) are added onto thetimeline in the decreasing order of packet value (as cal-culated in Section 2.1), i.e., higher valued packets areplaced first, and lower valued packets later.

We describe our algorithm for ordering packets nextand illustrate it with a toy example. We considerA, B, C, D, E, F andG as the seven packets which needto be transmitted (Figure 2). The width of a packet sig-nifies the time required to transmit the packet at its basePHY rate. Initially we try to place each packet at itsidealtimeslot — a time by which it needs to be transmittedso that it can be re-transmitted multiple times in case ofconsecutive losses. Also, the latest timeslot at which apacket can be placed is when it just makes its playbackdeadline for the slowest client, called thedeadline slotfor the packet. The reason for not placing a packet atthe earliest available slot, is to ensure that packets whichhave lower value but have an earlier deadline than themore important packets still get a chance to be scheduled.When the current time is past a packet’s deadline slot,and it is not required for decoding any other packet atany receiver, the packet can be discarded. We now walkthrough the example of how different packets get placedon the scheduling timeline using the following cases.

Case-I (Sufficient time is available to schedule allpackets at ideal time-slot):This scenario is depicted inFigure 2(a). Here, packetsA, B, andC are scheduled attheir ideal timeslot. Also, the packets are assigned theirbase rates.

Case-II (Ideal slot occupied by a higher valuedpacket): Under realistic settings, contention from othertraffic sources and the necessity to retransmit different

packets would mean that scheduling all packets at theirideal slot might not be possible. We depict such a sit-uation in Figure 2(b), in this case scheduling packetDat its ideal slot would lead to an overlap with packetC.We mandate that the packet with the lower value be theone which gets moved around. We find a best fit timeslotin the schedule for the lower valued packetD. Note byconsidering packets in order of their value implies thatonly the current packet needs to be moved.

Case-III (No slots left at current PHY rate): In ex-treme case, we might be unable to find a big enough timeslot for a packet, for example in Figure 2(c) we are un-able to find a timeslot big enough to fit packetF at itsbase rate, before its deadline. In such a case, we increasethe data-rate of the packet, we call this operationDeflateas it results in shortening the packet dimensions on thetransmission timeline. For example, we were able to fitF on the timeline after deflating operation. In this op-eration, we keep trying to find a best-fit timeslot for thepacket by increasing its rate. This process continues tillwe find a slot to fit the packet, or we exhaust all rateswithout being able to fit the packet on the timeline. Thiswould imply the inability to schedule the packet in thecurrent round. We show this in Figure 2(d). PacketGcould not be placed in the timeline even at the highestPHY rate and hence, had to be left out from current iter-ation.

Case-IV (Compensating for rate optimization):Packets with only a few intended recipients(say, oneswith bad channel quality) would have lower value. Thus,such packets would potentially be transmitted at higherrates. This might lead to drastic degradation in receivedvideo at clients with bad channel quality. To remedy this,we carry out a round of rate re-assignment before send-ing out the packets. We call this operationInflate as itdecreases the rate of some packets, thus, increasing theirsize on the transmission timeline. Note that the inflateprocess does not increase the size of the timeline itself.Inflating is carried out by going through the list of activeclients and calculating the expected distortion in videoquality, they would suffer if the packets are sent out ac-cording to current plan. In case the expected quality of aclient falls below a certain minimum threshold, we findout the packet which can increase the expected quality ofreception the most and we decrease the rate of transmis-sion of the packet. We then try and compensate by deflat-ing a few other packets which would minimally decreasethe quality of video at clients. This process is illustratedin Figure 2(e). In this example packetF is deemed avaluable packet for a client with poor channel quality andhence, its rate is reduced, while the transmission rates ofD andE are increased as a compensation.

Note thatInflate, might lead to overall reduction inquality of video received over all clients. We keep it in

order to ensure that a minimal quality of video is servedto each client.

We would like to note that once this order has beendetermined,we do not delay the transmission of pack-ets until the scheduled timeslot. Instead the packets aresent out at the next transmission opportunity. This en-sures that we get even more opportunities to retransmitthe packets before its deadline expires. The virtual time-line and time slots are, thus, used only to determine theorder of transmissions and the corresponding rates.

An interesting aspect of the PHY rate selection usingInflate-Deflate is that many packets can get transmittedat distinct rates based on the rate assignment algorithm.As a consequence, the proxy can get feedback on a largerange of PHY rates from the clients, without having toexplicitly raise the base PHY rate. This is another dif-ference between the rate adaptation and error rate esti-mation technique employed byMedusafrom unicast rateadaptation techniques such as SampleRate [8].

2.4 Re-transmission planningWe discuss the three inter-related components of re-transmission planning next.

Timeout estimation: A key issue in planning for re-transmissions is to determine the timeouts accurately —under-estimating would lead to redundant packet trans-mission, while over-estimation would lead to video pack-ets missing their playback deadline. Since each clientreception report acknowledges a block of packets, wehave to adjust the round trip time and the timeout cal-culations, to account for additional delays incurred inclients. We adopt a TCP-like Exponentially WeightedMoving Average (EWMA) mechanism for RTT estima-tion, which takes into account this change. Furthermore,we re-compute the value for all packets that become eli-gible for re-transmissions, and use this new value to de-termine the packet transmission ordering and PHY rate.

Network coded re-transmissions:As packet errors atdifferent locations occur independently, multiple clientswould potentially (not) receive different packets from aset of consecutive transmissions. This allows us to de-ploy a simple XOR-based coding [23] of packets to bere-transmitted, to further optimize channel utilization.Inour system, we XOR-code a group of packets, only ifthey satisfy the following rule:Out of a set of packets tobe re-transmitted, if a subset of packets can be found suchthat each intended recipient of a specific packet has re-ceived all other packets in the subset , then the subset canbe network coded.Such coding opportunities occur fre-quently in the proxy, as MAC-layer re-transmissions arenot used inMedusa. The algorithm for network codedre-transmissions is shown in Algorithm 2.1.

A key decision in our design is to determine the setof packets to be coded after the packet order has been

Algorithm 2.1: NETCODE(P )

INPUT P: set of coding candidates,arranged in decreasing order of packet valuesCoding set: Set of packets to be codedPi.client set: Set of clients interested inPi

OUTPUT S: set of coded packetsfor eachPi ∈ P

do Coding set← φfor eachPj ∈ P , j > i

do{

if is coding worthy(Pj , Coding set) = truethen Coding set← Pj

if Coding set 6= φ

then

X ← make coded packet(Pi, Coding set)X.rate← Pi.rateS ← X

elseS ← Pi

return (S)procedure IS CODING WORTHY(Pj , Coding set)for eachCi ∈ Coding set

do{

if Pj .client set ∩ Ci.client set 6= φdo return ( false)

return ( true )

decided. This is done to keep the packet ordering algo-rithm simple, as otherwise the algorithm would have todeal with coded packets (with multiple constituent pack-ets of different values), while deciding the sending orderand rate. A coded packet is always transmitted with theintended PHY rate of the first packet in the set. This en-sures that the probability of error in receiving the firstpacket at its intended receivers is not hampered, whileopportunistically delivering other packets in the codedset to their respective clients. At the client side all re-ceived packets (natively or from network coded packets)packets are maintained till their deadline expires. Thisis done to ensure that packets coded with previously re-ceived packets can be recovered. The client sends backacknowledgment for packets which are successfully de-coded as part of reception reports.

Delayed Packet discard: The deadline for packetdelivery shifts over the duration of a streaming session.We initially set it to the playback deadline of the frame,which is calculated using the following formula,

Deadline =FrameseqnoFrame Rate+ Playback buffer size+ δ,

where, the deadline is number of seconds from thetransmission time of the first video frame, Frameseqnois the sequence number of the frame. Frame Rate is thenumber of frames that the video player needs to displayin a second. Playback buffer size is the amount of time

(in seconds) that the receiver can store the video beforeit needs to start decoding the frames. And,δ is a smalltime constant added to account for initial frame delay.

Once the playback deadline of a packet expires, we re-set the deadline for delivering its constituent packets tothat of the next frame which depends on the successfulreception of the packet for decoding. This goes on untilthe packet is delivered to all clients, or the deadlines ofall the frames which depend on the current packet haveexpired. We drop the packet from our system at that in-stant.

Similarly, at client, we discard a packet only if its play-back deadline has expired and the packet is not useful fordecoding any other frame.

3 Putting it all togetherWe have implemented theMedusaproxy and client. Theimplementation consists of about 3.5K lines of C code.We stream video using the Evalvid tools package [1].We modified Evalvid to provide information about de-pendency structure of video frames, frame type of thegenerated packet and the deadline of the packet. TheMedusaproxy runs as an application level process. Wemodified the MadWiFi driver to carry out per-packet rateassignment. Per packet rate assignment is achieved byspecifying the target rate in a header of the video packetand then extracting it out of the packet inside the AP’sdriver.

At the client, theMedusamodule keeps informationregarding number of packets received and the channelquality. The module passes the received video pack-ets to video playback software such as VLC [7] andMPlayer [5], for displaying. It also keeps a copy of re-ceived packets, till the expiry of their deadline for decod-ing other packets.

4 EvaluationTo study the performance ofMedusawe have experi-mented with upto 25 users that are associated to a sin-gle AP(operating in 802.11g mode) and attempting toreceive HD quality video from theMedusaproxy. Oursetup consists of 30 laptops with Atheros wireless driverrunning Linux operating system.Wireless conditions: The experiments were done on auniversity building floor. We broadly classify our wire-less environment into three types: (i)Low-lossenviron-ment - corresponding to specific client locations wherethe packet error rates were 5% or less; (ii)Medium-lossenvironment - corresponding to locations where packeterror rates were in the range of 5-15%; and (iii)High-lossenvironment - corresponding to locations where packeterror rates were in excess of 15%. For the set of experi-ments reported, an experiment location did not shift fromone to another in the course of experiment.

MOS Rating of video quality PSNR range

Excellent > 37Good 31-37Fair 25-31Poor 20-25Bad < 20

Table 1: Table mapping the MOS based user perceptionof video quality to the PSNR range

Video setup: We experimented with different videoclips, in this paper we present results for the Mobile cal-ender video clip [3] replayed back to back to run for 2minutes. The video was encoded at rates of 5, 10, 15 and20 Mbps using FFmpeg [2] tool with H264 codec. Wehave repeated each experiment for 20 runs. For our ex-periments, we used a fixed playback buffer of 10 secondsat clients. We intend to evaluate the benefits of adaptivelymodifying the playback buffer size in future.Metrics: We compare the performance of differentschemes in terms of Peak Signal-to-Noise Ratio (PSNR),jitter, and overall network load imparted.

PSNR:Is a standard metric for measuring the relativequality of video streams [13,20]. The PSNR of a video iswell correlated with the perceived quality of video expe-rienced by the user. The relationship between user per-ception expressed in Mean Opinion Score (MOS)and thePSNR range were detailed in [17, 22] and are summa-rized in Table 1.

Jitter: We measure the Instantaneous Packet DelayVariation(IPDV) [14] of received packets as a measureof jitter of the delivered video stream. This metric com-plements the PSNR metric which is oblivious to the de-lay and jitter of the delivered video, as it assumes thepresence of an infinite playback buffer. High jitter valuesignifies a bad performance.

Network load: We measure the load placed on thenetwork by different schemes in terms of the a) num-ber of packets transmitted in air and also in terms ofamount of air-time occupied by the packets sent by dif-ferent schemes.Compared schemes:We compare the performance ofMedusato the following alternate schemes.

BDCST: This scheme uses WiFi broadcast to transmitpackets. However, unlike normal WiFi broadcast, thePHY rate is chosen to maximize the video PSNR per-formance averaged across all clients. The PHY rate isselected by sending about 30 seconds of traffic at differ-ent rates.

UCAST-INDIV: In this scheme we send the videostream to each client using isolated WiFi unicast, in se-quence. For example, if there are two clients, we firstsend the entire video to client 1 and then the same video

0 5

10 15 20 25 30 35 40 45

0 5 10 15 20 25

PS

NR

(dB

)

Client count

UCAST_INDIVMEDUSA

BDCSTUCAST_SIMUL

Figure 3: Plot showing the average per client PSNR ofdifferent scheme when serving 25 clients with a 20 Mbpsvideo stream, under medium loss conditions. The meanand the variance (errorbars) are shown.

separately to client 2 using WiFi unicast. This schemegives a quality bound forMedusa.

UCAST-SIMUL: In this scheme we send the video traf-fic to all the clients simultaneously using normal WiFiunicast with SampleRate rate adaptation. This is the tra-ditional method for wireless data delivery.

Note that in all of these alternate schemes describedabove, there is no proxy and the APs and clients areunmodified, i.e., the APs take PHY rate adaptation andpacket re-transmission decisions, while clients do notneed to send out reception reports.

To evaluateMedusawe first look at the overall systemperformance in the multicast (Section 4.1) and the uni-cast (Section 4.2) cases. We then look at contribution ofvariousMedusacomponents to the overall performancein Section 4.3. Specifically, we investigate benefits ofrate adaptation in Section 4.3.1 and the performance ben-efits due to retransmissions in Section 4.3.2.

4.1 Overall performance (multicast)We begin by evaluating the performance of theMedusasystem in terms of its scalability for multicast traffic sce-narios. We do so by — increasing number of clients andincreasing video rates.

Scalability in the number of clients: We comparehow different schemes can support HD video deliveryto a large number of co-located WiFi clients. Figure 3shows the performance of a highly loaded system with25 clients (all receiving the same 20 Mbps video stream)at medium loss locations. We find thatMedusaperformsclose toUCAST-INDIV(difference of 3-4 dB with 25clients) with increasing client count, and is significantlysuperior to all other schemes.

Also, we find that there is a graceful degradation inMedusaperformance when the number of clients is in-

creased from 1 to 25. But even with 25 clients, the aver-age PSNR value is around 37 while BDCST performanceis around 27 (a 10 dB difference). The gradual degrada-tion in performance ofBDCSTis because of the almostsimilar nature of errors experienced at each client(10-15% packet error).

The performance of UCAST-SIMUL suffers as802.11a/g technology cannot support more than 2streams with 20 Mbps rate(20 + 20 = 40 Mbps net load).

Scalability in video rate: We fix the number of clientsto 10 and evaluate how the performance scales with in-creasing video rate — from 1 Mbps to 20 Mbps. Weshow the results separately for clients in good, mediumand bad channel conditions in Figures 4(a), (b) and (c)respectively.

For good channel condition we observe thatUCAST-SIMULquickly degrades in performance with increase invideo rates. Even at 5 Mbps (where the aggregate load isexpected to be5 × 10 Mbps = 50 Mbps), a lot of packetlosses and buffer underflows occur.BDCSTperformsbetter and provides a more gradual performance degra-dation across the different rates. However,Medusaout-performs both and performs identical toUCAST-INDIV.

With worsening channel condition as shown in Fig-ure 4(c) the performance of all schemes suffered. An in-teresting observation is thatthe performance ofUCAST-INDIV became worse thanMedusa as the traffic load(video rate) increased above 15 Mbps. This is dueto “head-of-line” blocking in AP wireless NICs in theUCAST-INDIVcase. Essentially, when various P- or B-packets are encountering losses, the AP spent significanteffort in re-transmitting these packets, while more im-portant I-packets waited behind. The lack of knowledgeabout the value of different packets, prevented the APfrom devoting an appropriate amount of re-transmissioneffort for more important packets.Medusaexplicitly ad-dresses this problem and hence, led to improved perfor-mance.

4.1.1 Jitter variation of Medusa

We present the results for Jitter(measured as IPDV) inFigure 5. The experiment involved 10 users. Jitter in-creases with an increase in the number of clients, forall the schemes. However, the jitter ofMedusais sig-nificantly lower than bothBDCSTandUCAST-SIMUL.The jitter ofUCAST-SIMULincreases exponentially withthe number of clients. This can be attributed to the factthat with increasing number of clients the amount of datanecessary to be transmitted becomes more than the net-work capacity. This results in a cascade of video packetdrops in AP buffers and missing of deadlines. The jit-ter for BDCSTalso grows with the number of clients, asthe number of candidates who can loose packets has alsoincreased. Also, we note that the slope of increasing jit-

0

10

20

30

40

50

20151051

PS

NR

(dB

)

Video Rate(in Mbps)

UCAST_SIMULMEDUSA

BDCSTUCAST_INDIV

(a) Goodchannel

0

10

20

30

40

50

20151051

PS

NR

(dB

)

Video Rate(in Mbps)

UCAST_SIMULMEDUSA

BDCSTUCAST_INDIV

(b) Mediumchannel

0

10

20

30

40

50

20151051

PS

NR

(dB

)

Video Rate(in Mbps)

UCAST_SIMULMEDUSA

BDCSTUCAST_INDIV

(c) Badchannel

Figure 4: Average PSNR for 10 clients averaged over 20 runs asa function of the video rate under varying channelconditions.

0

50

100

150

200

1 2 3 4 5 6 7 8 9 10

Jitte

r(in

mse

c)

Number of Clients

UCAST_INDIVBDCST

MEDUSAUCAST_SIMUL

Figure 5: Average jitter experienced by 10 clients undermedium channel conditions for 20 runs.

ter forMedusais lower than that ofBDCST, signifying amore gradual increase.

4.1.2 Induced network loadApart from providing video quality commensurate witheach user’s channel quality, a good video multicast sys-tem should induce minimal additional network load. Wecompare the network load imparted byBDCST, UCAST-INDIV andMedusain Table 2. We calculate the addi-tional load placed in terms of the amount of airtime occu-pied by the packets (product of data-rate and packet size)which were transmitted using the different schemes. Theresults are normalized by the amount of airtime taken byBDCST. Table 2 shows thatMedusahas an overhead of4% for good channel conditions, which goes up to 30%under bad channel conditions. This overhead is to com-pensate for the 1-5% of errors that occur in good channelconditions. The channel induced losses go upto 15%-25% when the channel conditions are bad in our settings,forcingMedusato inject an extra 30% traffic into the net-work. Hence,Medusadoes not place unecessarily hightraffic load over the network.

ChannelCond. BDCST UCAST-INDIV MedusaGood 1 10.12 1.04

Medium 1 10.26 1.1Bad 1 11.40 1.3

Table 2: Airtime occupied by different schemes normal-ized to that ofBDCSTfor 10 clients watching a 5 Mbpsvideo, averaged over 20 runs, under varying channel con-ditions.

The above observation would seem to contradict withthe fact thatMedusauses a conservative rate-adaptationmechanism which should significantly increase its net-work resource usage. However, we find that conservativerate-adaption while increasing the relative time occupiedby individual packets also suffers less packet loss. Thus,keeping the overall network utilization low. We presentfurther results in support of this statement in Section 4.3.

4.1.3 Interaction with other trafficWe investigate the performance ofMedusain presenceof multiple uncorrelated traffic sources in Section 4.1.3.Since we do not introduce any new end-to-end conges-tion control mechanism inMedusa we do not presentin depth results on the interaction ofMedusawith TCPflows. In our experiments, introducing aMedusaflowwithout congestion control along with multiple TCPflows results inMedusaflow forcing the TCP flows toshare only the residual bandwidth amongst themselves.We plan to implement a congestion controlled version ofMedusaas part of our future work. We depict the impactof UDP flows onMedusaperformance, in Figure 4.1.3.

We vary the number of background UDP flows, eachat 4 Mbps, and compare the behavior ofMedusaoperat-ing with a 10 Mbps video for 10 clients. The presenceof multiple UDP streams causes a reduction in the qual-ity of video seen at the clients for all schemes. How-ever,MedusaoutperformsUCAST-INDIVas the numberof background flows is increased (around 7dB better for

0

10

20

30

40

50

20161284

PS

NR

(dB

)

Background traffic(in Mbps)

MEDUSAUCAST_INDIV

MED-noORDERBDCST

Figure 6: Average PSNR for 10 clients averaged over20 runs in presence of background UDP flows undermedium channel conditions. Video rate is 10 Mbps.

4 background flows). We find that these gains ofMedusaare mainly due to our intelligent packet (re)-transmissionordering that mitigates the head-of-line blocking prob-lem in UCAST-INDIV.We show this explicitly by alsointroducing a new scheme, calledMedusa-noORDER,in which the packet re-ordering mechanism ofMedusais disabled. The performance ofMedusa-noORDER isquite similar to that ofUCAST-INDIV.

4.2 Overall performance (unicast)To evaluate the performance ofMedusain serving multi-ple unicast video streams, we have increased the num-ber of video flows from one to four in increments ofone. We select the client randomly from a pool of 15clients. Each experiment was run 20 times with a 5 Mbpsvideo stream. There were other uncorrelated backgroundflows (total of 5 Mbps) running during each experimentWe plot the results of our observation in Figure 7. Inunicast traffic settings, the gains inMedusaarrive fromcontent-dependent rate selection, intelligent packet or-dering and re-transmissions, as well as network codedre-transmissions. The broadcast advantage is availableonly for these network-coded re-transmissions, and notfor original packets. With unicast video destined to 4clients, the aggregate load is 20 Mbps, which is quitesignificant. Under good channel conditions,Medusastilldelivers an average PSNR of 40 dB, which is very sim-ilar to UCAST-INDIVand is 9 dB greater thanUCAST-SIMUL.This gain is even larger (18 dB) under bad chan-nel conditions.

4.3 Micro-benchmarks of Medusa compo-nents

We now evaluate the effect of individual design choiceson overall system performance. We look into perfor-mance of rate adaptation under diverse channel condi-

tions in Section 4.3.1. The performance of networkcoded retransmissions is evaluated in Section 4.3.2 andthe overall contribution of different components is sum-marized in Section 4.3.3.

4.3.1 Rate adaptation inMedusaAn important aspect ofMedusais its ability to adapt thePHY rate based on channel conditions. We investigatethe performance of these mechanisms next.Impact of conservative base PHY rate adaptation:Welook at the effects of using a conservative rate adaptationalgorithm inMedusaon the overall system performance.We conduct experiments with a 5 Mbps video rate to 10clients in good, medium and bad channel conditions. Weran Medusawith a conservative (err thresh = 0.02)and an aggressive (err thresh = 0.18) rate adaptationalgorithm. Here, errthresh signifies the maximum ex-pected error rate which we are willing to tolerate forany PHY rate. We also ran the experiment withUCAST-INDIV. All the experiments we repeated for 20 runs. Fig-ure 8(a, b) show the CDF of PHY rates assigned by dif-ferent schemes under the good and the bad channel con-ditions. We observe,Medusa-conservative assigns lowerPHY rates to packets than unicast, while the aggressivealgorithm assigns data rates higher than the conservativescheme, but lower than the unicast scheme. To highlightthe benefits of conservative rate adaptation, we plot thenumber of extra bytes transmitted, as a fraction of over-all video size, and the PSNR of the resulting video underdifferent channel conditions when using conservative,aggressive and unicast rate adaptation in Figure 8(c). Forthe UCAST-INDIVwe plot the number of packets aver-aged by number of clients present. The following obser-vations can be made from the plot,

• Under good channel conditions, an aggressive aswell as a conservative scheme would lead to similarnumber of packet losses(1%). Under such circum-stances, all three schemes offer similar video qualityand send similar amount of traffic over the network.From Figure 8(a), we find that around 80% (74%)ofpackets were transmitted at 24 Mbps or higher ratein UCAST-INDIV(Medusa-aggressive), in contrastto only 30% formMedusa-conservative. Hence, us-ing an aggressive rate adaptation would had beenbeneficial in this case, as it would lead to networkbandwidth conservation.

• For medium and bad loss environments,Medusa-conservative sends around 20% and 10% packetsat 24 Mbps or higher.UCAST-INDIVsends about40% and 11% packets at 24 Mbps of higher. Incontrast,Medusa-aggressive sends about 60% and20% of its packets at 24 Mbps or higher. This is be-cause of the slowness of the feedback process which

0

10

20

30

40

50

1 1.5 2 2.5 3 3.5 4

PS

NR

(dB

)

Number of streams

UCAST_INDIVMEDUSA

UCAST_SIMUL

(a) Goodchannel

0

10

20

30

40

50

1 1.5 2 2.5 3 3.5 4

PS

NR

(dB

)

Number of streams

UCAST_INDIVMEDUSA

UCAST_SIMUL

(b) Mediumchannel

0

10

20

30

40

50

1 1.5 2 2.5 3 3.5 4

PS

NR

(dB

)

Number of streams

UCAST_INDIVMEDUSA

UCAST_SIMUL

(c) Badchannel

Figure 7: Overall performance ofMedusafor unicast-only media traffic. Upto 4 clients shown, each requesting aseparate media stream with 5 Mbps video rate, under different channel conditions.

10 20 30 40 50 60 70 80 90

100

544836241812

Per

cent

ile

Data Rate (in Mbps)

Medusa-conservativeMedusa-aggressive

UCAST-INDIV

(a) Goodchannel

0 10 20 30 40 50 60 70 80 90

100

362418126

Per

cent

ile

Data Rate (in Mbps)

Medusa-conservativeMedusa-aggressive

UCAST-INDIV

(b) Badchannel

0

10

20

30

40

50

60

70

BadMediumGood

PS

NR

(dB

)

Channel condition

1.011.01

1.011.06

1.211.1

1.171.32

1.22

Medusa-conservativeMedusa-aggressive

UCAST

(c) Performance under various channel condi-tions

Figure 8: CDF of packet rates assigned when transmitting 5 Mbps video to 10 clients in different channel conditionsusing different rate adaptation mechanisms. The bars in plot (c) shows performance of the schemes in terms of PSNR.The numbers in plot (c), on top of each bar, depict the normalized extra traffic in number of bytes sent by each scheme,relative toBDCST.

makes theMedusa-aggressive algorithm slow to re-act to changes in channel conditions. The perfor-mance of theMedusa-aggressive scheme suffers be-cause of its inability to adapt quickly as shown inFigure 8(c). The number of packets transmitted bythe conservative algorithm is around 15% less thanMedusa-aggressive. This is expected, as the highthreshold value ensures that we would make veryfew errors. The aggressive algorithm also leads toworse video quality(in PSNR) when the network re-souces are scarce, precisely because of their inef-ficient network resource usage. Worsening chan-nel conditions makes the difference in video qual-ity about 6-12 dB(Medusaconservative andUCAST-INDIV have an advantage overMedusa-aggressive).

Thus, except under good channel conditions, keeping aconservative rate leads to better network resource utiliza-tion, while the quality is maximized in all conditions byadopting a conservative rate adaptation.Impact of mobility on rate adaptation: To study the ef-fect of mobility and its impact of adaptation mechanisms,we performed targeted mobility experiments, where werepeatedly moved one user between a high-loss and a

Figure 9: Adaptation of different scheme with targetedmobility, for video at 20 Mbps rate.

low-loss location, while all the other clients stayed sta-tionary at the low-loss location. The mobile client movedfrom the low loss to the high loss location (across a wall)quickly, stayed there for about 4 seconds, and returned.We show the adaptation performance ofMedusain com-parison toUCAST-INDIVandBDCSTin Figure 9. TheUCAST-INDIVscheme running its MAC-layer rate adap-tation technique adapts the fastest.Medusawith its in-tent of making rate adaptation decisions (of its PHY baserate) slowly, adapts somewhat slower. It takesMedusaabout 0.4 seconds to adapt to the change in channel con-dition for the mobile user. This occurs in both cases —

when the user moves away from the low loss location,and when it returns to the low loss location. This can beattributed to the higher layer reception reports and slowertimescales in which they occur. However, onceMedusaadapts, it provides the user with the same performance astheUCAST-INDIVin this case. TheBDCSTscheme hasno adaptation mechanism and does not adapt when theuser moves.Impact of interference on rate adaptation: We nextstudy the performance of these schemes under targetedinterference from an external 802.11 source, that wasa hidden terminal to theMedusaclients. Figure 10(a)shows the relative performance ofMedusa, UCAST-INDIV, andBDCST, when the video rate was 5 Mbps.The interferer used UDP to download a large file startingat time 2 seconds. The performance impact of this inter-ference is similar to that of mobility.Medusaperformedsimilar toUCAST-INDIVand much superior toBDCST.However, it experienced a slight delay in adapting its ratewhen compared toUCAST-INDIV.

As shown in Figure 10(b), at a video rate of 20 Mbps,a similar effect happens with the hidden terminal inter-ference. However, hidden terminal has a significantlygreater interference impact and at this high video rate, thePSNR of bothMedusaandUCAST-INDIVdrops. Fur-ther, at 20 Mbps and with hidden terminal interference,the performance ofUCAST-INDIVfalls slightly belowMedusa. Examining this performance ofMedusamoreclosely, we see that at time 2.4 seconds, the inflate-deflatealgorithm kicks in to help improve performance. Thetable in Figure 10(c) shows the number of I, P, and Bframes thatMedusahad to discard, inflate, deflate, andtheir channel occupancy time in the three phases (ini-tial no interference, interference starts, and inflate-deflatestarts).

4.3.2 Network coded re-transmissions

We evaluate the benefits of using network coded re-transmissions with varying number of clients in the sys-tem (Figure 11). Panel (a) figure shows the percentageof all packet transmissions in each case that were actu-ally network coded. As can be seen from the plot withincreasing number of clients the number of network cod-ing opportunities increases. Also, we would like to notethat the computation overhead is never more than 1% ofCPU time in any of our experiments. The actual perfor-mance gains from network coding can be seen in Fig-ure 11(b) which indicates the reduction in airtime loadthat occurred due to network coding opportunities.

Finally, we evaluate the benefits of network coded re-transmissions under varying channel conditions. We ex-periment with 5 clients receiving a 5 Mbps video undergood, medium, and bad channel conditions respectively.We report the coding opportunities and the airtime reduc-

0 2 4 6 8

10 12 14 16

1 2 3 4 5 6 7 8 9 10

% C

odin

g op

p.

Number of Clients

(a) Coding opportunities

0 2 4 6 8

10 12 14 16 18

1 2 3 4 5 6 7 8 9 10% N

etw

ork

load

red

uctio

n

Number of Clients

(b) Traffic savings

Figure 11: Coding opportunities and percentage traf-fic reduction as a function of number of clients undermedium channel condition with 5 Mbps video averagedover 20 runs.

Chnl. cond. Good Medium Bad% of coded packets 3.1 7.4 12.6% Airtime loadreduction 5 8 13

Table 3: Coding opportunities and normalized traffic in-jected as a function of channel condition for five clientswith 5 Mbps video averaged over 20 runs.

tion due to the network coded scheme in Table 3. Thetable shows that worsening channel condition leads tohigher benefits from network coding. This is expected,as the number of packet losses increases as the channelcondition becomes bad, this in turn leads to higher num-ber of retransmissions and thus more coding opportuni-ties.

We note that using network coding also leads in im-proving PSNR with increasing number of clients orworsening channel error conditions. We do not presentthe results for sake of brevity.

4.3.3 Component contributionThe Medusa system employs content aware rateadaptation, selective retransmissions and transmission(re)ordering to provide quality enhancements overbroadcast based media delivery. Figure 12 shows therelative contribution of different design components inMedusa, over and above standard WiFi broadcast. In thelow-loss and the high-loss environments various mecha-nisms inMedusa(re-transmissions, rate adaptations, or-dering, rest – from integration of all the components).provides a nearly 9 and 10 dB improvement in PSNRover plainBDCST.

5 Related WorkThere has been a significant amount of research in thearea of video streaming over wireless networks, both invideo and systems community (see [29] for a summary).We comment on the most related pieces in this section.

Dynamic transcoding is a standard technique for en-hancing the quality of the streaming video. It involved

(a) Video at 5 Mbps rate. (b) Video at 20 Mbps rate. (c) Video at 20 Mbps rate.

Figure 10: Adaptation of different schemes with external hidden terminal interference with video at 5 and 20 Mbpsrate. The table shows the number of I, P, and P frames that werediscarded, inflated, deflated, and the channel occu-pancy time forMedusain the three phases.

BDCST

Retx.

Rate

Order

Rest

Channel Condition

Figure 12: Performance breakdown between rate adap-tation and retransmission components ofMedusasystemfor 10 clients averaged over 10 runs under varying chan-nel conditions.

estimating the bandwidth available in the medium andthen change the video rate itself to ensure the best qual-ity video that the channel can support is delivered to thereceivers. Chou et.al. [9, 11, 12] in their seminal workpropose a rate-distortion optimization technique to adjustthe rate of the transmitted video based on channel qual-ity. However, this body of work depends on the wire-less hardware to pick the rate at which the video is tobe transmitted. A second set of prior work dealing withidentifying the optimal video rate as well as the amountof redundancy to be added to the video stream is repre-sented by the [25, 26]. The authors formulate a complexoptimization problem for the same and provide heuris-tic algorithms which show the performance benefits ofthe designed algorithms. Such FEC based mechanismsare orthogonal to the set of techniques used in our work.In Medusawe mostly leverage understanding from suchprior work, and tailor our solutions to the needs of WiFi-based media delivery and specific issues therein.

Authors in [19] use a scalable video codec and opti-mally determine the amount of FEC required. This isa representative of a large body of literature in the area.This approach is, however, complementary to ours, as we

focus on rate adaptation and re-transmission based tech-niques for WiFi broadcasts in video delivery systems.

In general wide-area network settings, the OxygenTVproject [15,16] has considered performing selective end-to-end re-transmissions of packets based on the videoframe type, focusing more on unicast video delivery.They propose the SR-RTP protocol for the such selec-tive retransmissions [16]. In contrast, our work exploresvarious wireless link adaptation mechanisms that lever-age packet content information.

In [31], authors present a measurement study differentapplication-layer video streaming mechanisms in multi-hop wireless context. They do not explore interactionsbetween the value of content to applications, and linkadaptation mechanisms as we do in this work. In [27],authors present mechanisms to improve the quality of thevideo while operating in a lossy wireless environment.However they focus on low bit-rate video streams, whileour solutions are stylized to deliver HD quality video inWiFi environments.

The authors of [28] present an end-to-end video ratecontrol protocol for mobile media streaming on Internetpaths involving wireless links. They implement the con-trol functionalities in the receiver, which is charged withproving feedback to the server. The video server uses thisinformation to change the video codecs used to matchthe available capacity of the end to end path. The pro-posed approach is complementary to ours, as we focuson adapting video delivery on the WiFi link, by makinglink adaptation decisions for WiFi transmitters.

A recent mechanism, SoftCast [17], uses the notion ofcompressed sensing to create equal priority video pack-ets. This allows users to extract information proportionalwith their own channel quality. The core of this work fo-cuses on the complementary aspect of compressed sens-ing. Furthermore, SoftCast also requires changes to thewireless radio hardware (and the PHY layer), while oursystem makes no changes to the current 802.11 stan-dards.

Finally, DirCast [10] also design and implement asystem for WiFi multicast. They advocate the use ofpseudo-broadcasts in their system. However, the maindifference between ourMedusaapproach and DirCastis that we propose a content-dependent PHY rate selec-tion, re-transmissions, and packet order selection. Thisis an issue that is not considered by DirCast. DirCastfocuses on some complementary problems for the multi-cast case only (e.g., intelligent client-AP association de-cisions, FECs, etc.), and is agnostic of value of packetsto applications.

We believe that the main contribution ofMedusais incombining some understanding of packet contents withvarious WiFi link layer functions to improve the qual-ity of media delivery. WiFi link layer decisions, untilnow, have been considered in a mostly content-agnosticmanner.Medusasuggests an interesting design point forcombining application-layer information in making de-cisions at the link layer.

Various other new techniques can be brought to im-prove performance ofMedusaeven further. In the futurewe therefore plan to investigate the use of other com-plementary but related mechanisms, such as applicationlayer FEC for proactive error recovery, and a congestioncontrol mechanism for co-existence with TCP flows.

6 ConclusionsMedia delivery over wireless systems is a growing areaof importance. We present the design and implementa-tion of theMedusasystem which allows efficient deliv-ery of high quality media to one or more WiFi clients.The key contribution of this work is in recognizing thatcertain link layer functions, e.g., re-transmissions, PHYrate selection, packet transmission order, can be imple-mented better by having some knowledge about the valueof packets to applications. In order to be minimally inva-sive to existing systems, we implement this function ina proxy. Our results indicate that our collection of tech-niques can facilitate HD video delivery of 20 Mbps to 25clients while maintaining a good viewing quality.

7 AcknowledgementsWe thank Sanjeev Mehrotra for initial discussions onthe state-of-art in media streaming. We acknowledgeSateesh Addepalli for his comments and suggestions onour evaluation plan that helped improve the quality ofthis paper. We also acknowledge Sriram Subramanianfor co-developing a preliminary version of this systemfrom which we learned a number of important lessons.Finally, we thank our shepherd Srinivasan Seshan andother anonymous reviewers whose feedback helped bringthe paper to its final form.

Sayandeep Sen and Suman Banerjee were supportedin part by the US NSF through awards CNS-0916955,

CNS-0855201, CNS-0751127, CNS-0627589, CNS-0627102, and CNS-0747177.

References[1] Evalvid - a video quality evaluation tool-set. www.tkn.

tu-berlin.de/research/evalvid/.[2] Ffmpeg - digital audio converter.www.ffmpeg.org/.[3] Mpeg-2 hd test patterns.www.w6rz.net/.[4] Mpeg-4, moving picture experts group-4 standard.

www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm.

[5] Mplayer - the movie player.www.mplayerhq.hu.[6] Streambox. www.streambox.com/products/hd/hd\

9200\ main.html.[7] Vlc media player.www.videolan.org/vlc/.[8] B ICKET, J. Bit-rate selection in wireless networks. MIT Master’s

Thesis, 2005.[9] CHAKARESKI, J., AND CHOU, P. A. Radio edge: rate-

distortion optimized proxy-driven streaming from the networkedge.IEEE/ACM Transactions on Networking(2006).

[10] CHANDRA , R., KARANTH , S., MOSCIBRODA, T., NAVDA , V.,PADHYE , J., RAMJEE, R., AND RAVINDRANATH , L. Dircast:A practical and efficient wi-fi multicast system. ICNP 2009.

[11] CHOU, P., AND M IAO , Z. Rate-distortion optimized streamingof packetized media.IEEE Transactions on Multimedia(2006).

[12] CHOU, P., MOHR, A., WANG, A., AND MEHROTRA, S. Fecand pseudo-arq for receiver-driven layered multicast of audio andvideo. Proceeding of Data Compression Conference(2000).

[13] DAVID , S. A guide to data compression methods, 2002.[14] DEMICHELIS, C., AND CHIMENTO, P. Ip packet delay variation

metric for ip performance metrics (ippm). RFC 3393, IETF.[15] FEAMSTER, N. Adaptive delivery of real-time streaming video.

MIT M.Eng. Thesis, 2001.[16] FEAMSTER, N., AND BALAKRISHNAN , H. Packet loss recovery

for streaming video. 12th International Packet Video Workshop,2002.

[17] JAKUBCZAK , S., RABUL , H., AND KATABI , D. Softcast: Onevideo to serve all wireless receivers. MIT-CSAIL-TR-2009-005,2009.

[18] KATTI , S., RAHUL , H., HU, W., KATABI , D., MEDARD, M.,AND CROWCROFT, J. Xors in the air: practical wireless networkcoding. IEEE/ACM Transaction Networking.

[19] MAJUMDAR, A., SACHS, D., KOZINTSEV, I., RAMCHAN -DRAN, K., AND YEUNG, M. Multicast and unicast real-timevideo streaming over wireless lans.IEEE Transactions on Cir-cuits and Systems for Video Technology,(2002).

[20] MARTINEZ-RACH, M., AND ET. AL . Quality assessment met-rics vs. PSNR under packet loss scenarios in MANET wirelessnetworks.

[21] MURTY, R., WOLMAN , A., PADHYE , J.,AND WELSH, M. Anarchitecture for extensible wireless lans.HOTNETS-VII(2008).

[22] ORLOV, Z. Network-driven adaptive video streaming in wirelessenvironments.PIMRC(2008).

[23] ROZNER, E., IYER, A. P., MEHTA, Y., QIU , L., AND JAFRY,M. ER: efficient retransmission scheme for wireless lans.

[24] SCHULZRINNE, H., CASNER, S., FREDERICK, R., AND JA-COBSON, V. RTP: A transport protocol for real-time applications.RFC 3350, IETF.

[25] SEFEROGLU, H., ALTUNBASAK , Y., GURBUZ, O., ANDERCETIN, O. Rate distortion optimized joint arq-fec scheme forreal-time wireless multimedia.

[26] SEFEROGLU, H., GURBUZ, O., ERCETIN, O., AND ALTUN-BASAK , Y. Rate-distortion based real-time wireless videostreaming.Image Communications(2007).

[27] TAN , K., RIBIER, R., AND L IOU, S.-P. Content-sensitive videostreaming over low bitrate and lossy wireless network.

[28] TAN , K., ZHANG, Q.,AND ZHU, W. An end-to-end rate controlprotocol for multimedia streaming in wired-cum-wireless envi-ronments.ISCAS ’03..

[29] WANG, Y., AND ZHU, Q.-F. Error control and concealment forvideo communication: a review.Proceedings of the IEEE(1998).

[30] WONG, S. H. Y., YANG, H., LU, S., AND BHARGHAVAN , V.Robust rate adaptation for 802.11 wireless networks.

[31] X IAOLIN , C., PRASANT, M., SUNG-JU, L., AND SUJATA, B.Performance evaluation of video streaming in multihop wirelessmesh networks.