Evaluation and Improvement of Multicast Service in b

Transcription

1 Evaluaion and Improvemen of Mulicas Service in b Chrisian Bravo 1 and Agusín González 2 1 Universidad Federico Sana María, Deparmen of Elecronics. Valparaíso, Chile chbravo@elo.ufsm.cl 2 Universidad Federico Sana María, Deparmen of Elecronics. Valparaíso, Chile agusin.gonzalez@elo.ufsm.cl Absrac. Wireless Technologies have allowed a fas growing of he Inerne service in boh public and privae environmens where wireless neworks mosly consis of nodes inerconneced wih a fixed infrasrucure; neverheless, hey do no offer a good performance in all he wide variey of services ha are required for applicaions. Alhough he IEEE MAC proocol is he sandard for wireless LANs, his proocol shows a very poor performance and reliabiliy compared wih he mulicas raffic ransmied in wired neworks, his represens a significan challenge for exising neworks because i requires ransmission over muliple unreliable channels o heerogeneous receivers wih differen connecion bi raes and very limied feedback informaion o he sender. In his paper, we discuss he drawbacks of several proocols proposed in he lieraure ha offer reliable mulicas service. In addiion, his work evaluaes he performance of he wireless neworks under mulicas raffic and presens a proposal for acual IEEE neworks o improve heir efficiency. I uses a reliabiliy conrol based on a polling service along wih conrolled reransmissions; his allows servicing nodes applicaions wih a high efficiency wihou deerioraing fairness in he service. We presen deails of a prooype implemenaion and resuls ha sugges ha our proocol performs beer han oher proposed in erms of reliabiliy as well as daa hroughpu in our measuremen scenarios. 3 Key words: IEEE , Mulicas, Wireless LAN, Reliabiliy. 1 Inroducion The wireless echnology has grown fas as a way o inerconnec compuers. Wireless neworking applicaions coninue o proliferae a an incredible pace as wireless feaures, funcions, securiy, and hroughpu improve. IEEE802.11b [1] [2] is he sandard on which wireless neworking are based oday, and producs ha employ he echnology suppor a broad range of uses for enerprises 3 We hank o he USM Research Projec of he Federico Sana María Universiy for he suppor o develop his work.

2 and home users. An imporan difference beween he wireless and he wired neworks is he greaer daagram loss rae of he firs ones. These neworks operae in a radio band ha was originally reserved inernaionally for non-commercial use of RF elecromagneic fields and is power of ransmission is limied. This condiion, added o he inerference of he radio frequency specrum and he medium access proocol defined in b, causes a grea number of daagram losses. Unlike mos of he daa-link layer proocols used in wired neworks [3], incorporaes acknowledges (ACK s) o decrease he high rae of frames los due o inerferences, decay of signal, and collisions. In his way, i is aemped o reach reliabiliy in unicas ransmissions over wireless links. However, he ACK s and he reransmissions are omied when he daa desinaion is a mulicas address, hus an implosion of ACK s or requess of reransmissions a he Access Poin is avoided. Based on he same reason, he IEEE sandard does no include he opional exension RTS/CTS for mulicas/broadcas ransmissions [1] [3]. The mulicas daagram loss rae causes ha applicaion programs such as radio broadcasing saions, elevision, disribued compuing, cha and whieboard applicaions and all ype of Inerne conferences show a very poor performance compared wih hem on wired neworks [4]. This is explained because hey are normally designed o operae wih low error raes and because hey inerpre he daagram loss as congesion, reacing wih complex mechanisms like changing of coders o decrease he ransmission rae. Obviously, his does no solve he problem ha has is origin in a high Block Error Rae (BER) a he physical level. This paper goal is oriened o evaluae he problem ha appears in a nework wih infrasrucure, operaing in he Basic Service Se (BSS) mode, where he saions are fixed in indoor and oudoor scenarios. Thus, we cenered our ineres on he mulicas performance degradaion of he wireless link ha connecs he AP wih he wireless saions. In addiion o his evaluaion, we propose a proocol o improve he reliabiliy of he mulicas ransmissions unil achieve a performance close o he one observed in wireless unicas ransmissions. The previously proposed soluions use Error Correcion Codes [5] or sugges modificaions o IEEE MAC proocol [6]- [7] which does no solve he problem of he neworks ha were already insalled. We presen relaed work in more deail in he nex secion. 2 Relaed Work Several approaches have been proposed in he mulicas communicaions area o reduce he effecive packe loss rae and, a he same ime, provide a reliable service. Some of hem provide reliable mulicas ransmissions in he end-o-end sense assuming he exisence of underlying rouing proocols. Oher soluions propose o analyze he subjec of he losses recovery using errors correcion echniques like FEC (Forward Error Correcion) [5]. Several mulicas proocols

3 have been developed as an exension for MAC Layer described in he sandard IEEE They ry o improve he performance in he daa ransmission process beween he nodes. Our proposal is in he same direcion, looking for a mechanism based on he IEEE sandard ha improves he performance of he reliable mulicas proocols proposed so far. Following, he proposals of our bes knowledge o dae are briefly described. The proocol proposed in [8] ries o exend he IEEE sandard for mulicas/broadcas ransmissions using messages RTS/CTS (Reques To Send/Clear To Send) in all nework configuraions. Obviously, his proocol presens he CTS s implosion problem in he source node. The proocol proposed in [6], known as Broadcas Suppor Muliple Access (BSMA), is an exension o he previous proocol [8]. Briefly, afer he source node received he CTS of some neighbor, his one sends he daa and wais for a deermined ime for a Negaive Acknowledgmen (NACK). A NACK is sen by he node ha sen he CTS if he daa does no arrive before a imeou occur. If he source node does no receive a NACK hen i assumes ha he ransmission was compleed. In he oher case, i senses he channel o resar he RTS/CTS process. In his approach, he node ha sen he CTS does no consider if he oher cliens received daa successfully or no before sending an ACK or NACK which means ha some cliens could be losing daa. Reference [9] describes anoher proocol known as Broadcas Medium Window (BMW). Where each mulicas/broadcas message is reaed like muliple unicas ones. In summary, he idea is o handle a lis of he receivers and o make all he DCF (Disribued Coordinaion Funcion) conenion, ransmission and error recovery process for each one ineresed in receiving he message. Alhough i is an ineresing opion because i improves reliabiliy, we considered ha in his soluion here is oo much redundancy since reransmissions can be done using mulicas frames. Thus, he error recovery process in a receiving node aids o he ransmission of he same frame o ohers. Oher proposals as [7] and [10] are focused on he IBSS (Independen Basic Service Se) nework configuraions also known as Ad-Hoc Neworks [1], where i is assumed ha all nodes are wihin he same ransmission radio. The presened works have conribued o improve he performance of he IEEE sandard for mulicas/broadcas ransmissions; neverheless, mos of he proposals discussed previously are difficul o inegrae o he already spread sysems based in his sandard. In our work a novel scheme is presened which does no require modificaions o he MAC layer because i works in he applicaion level and uses an inercepor beween IP and MAC layer as i is described in secion 4. 3 Measuremen Scenarios The firs sep in his invesigaion was he reproducion of he problem observed in he FDI-Corfo IP Wireless Diffusion projec [11], where i was possible o deec serious performance problems on he applicaions when he physical medium was unable o reach a ransmission rae similar o hose observed in

4 Mulicas Receiver Mulicas Transmier Access Poin d Mulicas Receiver Fig. 1. Differen Scenarios. Indoor scenario used d < 50 [m]. Oudoor scenario used d > 1 [Km] Video TX Smar Server Mulicas Transmier Wireless Nework Mulicas Receiver Mulicas Receiver Mulicas Receiver Fig. 2. Proposed soluion srucure wired neworks using he RealNeworks echnology. For ha, wo es scenarios were srucured in which he problem had been observed. The firs scenario is an Indoor environmen (WLAN Nework wih a radio less han 50 [m]) and he second one is an Oudoor environmen (WLAN Nework wih a radio over 1 [km]). The second scenario may need special hardware ha allows elevaing he power of he signal o obain long disance ransmissions (amplifying) or differen anennas configuraions. Figure 1 shows he previously described scenarios. A mulicas server and clien applicaion were developed o ransmi mulicas raffic o mulicas clien applicaions. The server applicaion ransmis sreams varying he ransmission rae, he size of he daagrams and he ime beween each daagram (which emulaes ransmission of differen codificaion raes videos). In he oher side, he clien applicaion includes funcions o measure he loss percenage of frames sen by he server. These funcions were used o look for dependencies beween he percenage of losses in receivers, he ransmission rae and he size of frames. Besides, physical layer informaion provided by he driver of he WNIC was colleced, for example, power level of he signals received or he Signal o Noise Raio (SNR) o find he relaion beween wireless link qualiy and losses percenage in receivers. 4 Design of he proposed soluion and Proocol Descripion This secion inroduces he main idea of our soluion and how our proocol works o improve he acual performance of mulicas ransmissions. The idea is o use efficien reransmissions mehods by polling he cliens, wih he objecive o improve he acual performance of mulicas ransmissions in wireless neworks. As programming language, we chose Java because i allows our applicaions o be run on any arbirary Java-capable device wih an inerface wihou any furher changes o he device iself. The JAVA plaform ha we developed consiss of hree main pars: The regiser of cliens, he addresses mapping service and he reransmissions proocol.

5 4.1 The Regiser of Cliens In order for he Smar Server o be able o perform a reransmission proocol based on a polling sysem, a regiser of s is needed. This regiser conains a lis wih informaion of all he cliens conneced o he mulicas ransmission. The informaion required includes he IP address, Por and Life- Time for each clien. This allows us he regular mainenance of he sae informaion and keep an updaed daabase of he number of receivers in he group. For his, he Smar Server sends Mulicas Beacons hrough a mulicas conrol address. These beacons conain he Unicas IP Address and Por of he Smar Server. s are also members of his mulicas conrol group and, afer receiving a beacon, hey sar a random backoff imer o reduce he collision probabiliy of heir responses. When his imer ends, each clien sends a Unicas Subscripion Message o he unicas address of he Smar Server. Afer ha, each will wai for anoher five beacons before sar his imer again. Thus if his message is los, he will rery is subscripion laer. This Unicas Subscripion Message forma is <IP address, Por>. We added he applicaion por because i will be used o receive unicas polls in our proocol. Once he Smar Server receives he informaion, i adds a field of lifeime o each clien pair. If he server already has he pair of he clien, i will only updae he lifeime field; else i adds he new clien o he regiser. If no Subscripion Message is received, he clien is deleed from he lis when is lifeime reaches zero. Thus, he Smar Server keeps an updaed lis of he acive s, and i allows o delee hose ha have lef heir mulicas group. 4.2 The Addresses Mapping Service This service consis in redirecing he mulicas frames by changing he Mulicas Address Desinaion, he Desinaion Por and he Time-To-Live (TTL) fields of he incoming frames. We insalled a mulicas raffic inercepor beween he mulicas ransmier and he wireless nework, and oher one inerceping he raffic beween he wireless nework and he mulicas receivers, as he figure 2 shows. The echnique we use is similar o ha of Secure Shell (SSH) and ohers where i is possible o send he X-Windows raffic hrough he same SSH connecion using a unnel o obain is encrypion. Basically, he original source sends is raffic o a mulicas address A.A.A.A por XXXX wih TTL=0, which means ha he sream will no leave he local hos machine. Our Smar Server joins ha mulicas address and redirecs he daagram wih new parameers such as B.B.B.B por YYYY wih TTL=N (where N depends of he nework size). Therefore, he daagram leaves he local hos wih a mulicas desinaion address known by he s, hey join o ha address and perform he reransmission proocol. Afer ha, hey apply he mapping service again o deliver he sream o he final desinaion wih parameers like his A.A.A.A por XXXX wih TTL=0. This has o be he address o which

6 Sequence Number New or Resen Daa or Poll Mulicas Sream From Sequence Number To Sequence Number Bis Array 1 [Bye] 1 [Bye] 1 [Bye] 1 [Bye] 1 [Bye] 1 [Bye] Fig. 3. Reransmission Proocol Header Fig. 4. Poll and Poll Response Message Forma. Poll Message does no include he bi array field he final desinaions joined in firs place, and by seing he TTL in zero we limi he scope of he raffic o he specific machine which is running he Smar Clien applicaion. 4.3 The Reransmissions Proocol The hird and las module conains he reransmission proocol iself, ha we named as GroupPoll proocol (GP). The Smar Server map he mulicas sream using he mapping service firs and hen is forwarded o he s. Besides, when he mulicas raffic arrives o he Smar Server i adds a header o each frame wih informaion ha includes a sequence number, new-or-resen and a daa-or-poll field. The forma of his header is shown in figure 3. The 1- Bye new-or-resen field can be used by cliens o keep loss saisics of frames and he daa-or-poll field o indicae when he mulicas frame is daa or a poll message. The sequence number field conains an idenificaion number assigned by he Smar Server o be used in he reransmission algorihm. In our esbed, we assume ha he sequence number is assigned o frames in he same order ha hey have lef he original source, bu his could be differen if he proocol is implemened direcly in he AP raher han in he same machine as he original source. Alhough we se 1-Bye for hese fields for simpliciy in he laer performance analysis, we could have used less bis in boh fields. Hence, once a small group of daa frames has been forwarded, he Smar Server selecs one of he cliens included in is Regiser of Cliens o be polled. The poll message is sen by he Smar Server o he unicas address formerly sen by he Smar Clien and is forma is shown in figure 4. The From Sequence Number and To Sequence Number fields indicae a window of daagrams being polled, and he Bis Array 1 associaes one bi for each frame included in he window. For our measures, we se he group size in 8 o use jus one bye, so each bi represens one of he 8 previously sen daagrams. As daa frames arrive o Smar Cliens, heir sequence number is checked. While here are no missing frames, he reransmission proocol header is removed and he frame is passed o he clien applicaion. When a frame is los, hose frames wih sequence number greaer han he los frame are held in a buffer unil he packe is reransmied and successfully received, or he buffer filled up a which poin he los packe 1 This field is added only in he poll response message.

7 : 7777 Video TX Smar Server : 4444 TTL = 15 Wireless Nework : 4444 TTL = : 4444 TTL = : 7777 Fig. 5. GroupPoll (GP) Proocol Nework Diagram. Solid Lines represen mulicas ransmissions and Dashed Lines he polling process. is skipped and all waiing packes (up o he nex los packe in he buffer, if here is one) are sen o he clien applicaion. When he poll message arrives asking for he recepion saus of he las frames group, he ses he Bis Array of he poll message depending if he frames arrived successfully or no. Once his poll response message is received by he Smar Server, i sars he process of resending he missing frames and advancing he sliding window depending of he message received. Thus, a any momen, he sender mainains a lis of sequence numbers i is permied o send. These are frames sen-buno-ack and frames no-ye-sen. I is imporan o noice ha due o he use of his sending window, he Smar Server can keep sending frames while is waiing for arrival of he poll response message wihou blocking immediaely afer send a group of frames. Once all frames in he sending window are sen-bu-no-ack, he server eners in a blocking condiion which could generae he loss of frames if hey arrive during his condiion. To avoid his siuaion, every ime ha a poll message is sen a imer is sared. When a imeou occurs before receiving a reply from he chosen, he whole las group of frames is resen and he lower edge of he window is advanced. As our goal is no o achieve full reliabiliy in all hoss bu a reducion in frame loss for mos of he hoss, we accep he loss of a packe if a reransmission limi is reached. Therefore, he reransmission limis have o be carefully se o decide how many imes a frame should be resen before giving up. In our measures, we fix his limi o one reransmission, his parameer was chosen o achieve he delay/loss radeoff required for video applicaions. A nework diagram of he proocol is shown in figure 5. Figure 6 shows how he proocol works over he ime. To compare our proposal performance, we also developed wo oher proocols ha represen he worse and he bes scenario in erms of reliabiliy. The firs one is called Mulicas-o-Mulicas proocol (M2M) and as is name says, i jus works like a ransparen unnel for he mulicas sream. Thus, his proocol represens he case of a mulicas ransmission over wireless links using he sandard. This can be seen as he worse scenario in erms

8 Server Clien F1 F2 F3 F4 F6 Ack Nack 5 7 Ack Nack 11 F8 Poll 1 : 8 - C1 F9 F5 F7 F10 F12 F13 F14 F15 F16 Poll 9 : 16 - C2 F17 F11 F18 Fig. 6. GroupPoll (GP) Proocol over ime Diagram. Fx is he x, Poll x:y - Cz he Poll sen o Clien z asking for frames in he range [x-y], and Ack x y z Nack u v w he Poll response message saying ha frames x, y and z were successfully received and u, v and w were los. of reliabiliy because of he high frame losses caused by he lack of any reransmission echnique. The second proocol was called Mulicas-o-Unicas proocol (M2U) and is a represenaion of he proocol proposed in [9]. In his proocol, he Smar Server reas each mulicas/broadcas message like muliple unicas messages direced o each. To do his, i uses he Regiser of Cliens o ge he clien unicas addresses and hen i uses he sandard unicas ransmission for each one ineresed in receiving he message. As we said before, alhough i is an ineresing opion because i improves reliabiliy and is he bes scenario in erms of reliabiliy, we considered ha in his soluion here is oo much redundancy which harms hroughpu and delay. As a consequence of his redundancy, his proocol performance drops quickly as he number of cliens or ransmission rae grow even hough he no-scalable behavior of his approach resuls incompaible wih he mulicas concep, we develop i o ge upper bounds for reliabiliy and delay. In figures 7 and 8, nework diagrams are showed for hese proocols. In addiion, figures 9 and 10 show how boh proocols behave over ime. 5 Measuremen Deails and Resuls This secion presens he resuls ha were obained using he scenarios and proocols previously described in secions 3 and 4. In all our measures we used Java-capables machines in he same IP nework and ha were running Debian Linux wih he kernel Boh cliens used b Orinoco Silver Wireless Cards and he nework inerface of he server was conneced hrough a

9 : 4444 TTL = : 4444 TTL = 15 Video TX Smar Server Wireless Nework : 4444 TTL = 15 Fig. 7. Mulicas-o-Mulicas (M2M) Proocol Nework Diagram. Solid Lines represen mulicas ransmissions : : 7777 Video TX Smar Server Wireless Nework : : 7777 Fig. 8. Mulicas-o-Unicas (M2U) Proocol Nework Diagram. Solid Lines represen mulicas ransmissions and Do-Dashed Lines represen unicas ransmissions. Server Clien 1 Clien 2 Server Clien 1 Clien 2 F1 F2 F3 F4 F5 F6 F7 F8 F9 F1 F2 F3 F4 F5 F6 F7 F8 F9 F2 F1 F2 F1 F2 Fig. 9. Mulicas-o-Mulicas (M2M) Proocol over ime Diagram Fig. 10. Mulicas-o-Unicas (M2U) Proocol over ime Diagram crossover cable wih an AP-1000 Orinoco Access Poin. To emulae he oudoor scenario we used an aenuaor ha covers he AP ransmiing anenna. Thus, we were able o obain he same values of SNR ha hose observed in he real oudoor scenario. I is imporan o noice ha in he oudoor scenario is possible for nodes on opposie ends of he WLAN coverage area o be unable o hear each oher. Under hese condiions, he well known hidden and exposed erminal problems are quie likely o occur. To solve his, we forced o all wireless devices o use he RTS/CTS proocol when hey ransmi frames

10 unicas wihou considering he size of he frames. To perform our measures, we generaed mulicas frames wih a 972 [Byes] size in he server applicaion layer simulaing a video ransmission. The firs 4 [Byes] of each frame sen by he original source were used o add a sequence number and conrol informaion o auomae he measures. Figures 11 (righ) and 11 (lef) show he percenage of packe loss calculaed over a oal of frames ha were sen over he measuremen ime using a specific rae. We run his experimen several imes varying he ransmission raes and daa were compiled unil obain averages values wih an inervals of confidence of 5% for a confidence level of 95%. Also, i is imporan o noice ha, like in he case of he measuremens made wih he RealNeworks echnology, he same measuremen was made using a Fas-Eherne wired nework insead of a wireless nework, he losses remain close o 0% using he same wo cliens. This is an imporan poin because i means ha our proocol passed a saniy check ha allows us o discard losses ha could have exis because our implemenaion of he proocol. Besides, our nework scenarios consider ha he cliens disance o he ransmier is one hop (wihou inermediae nodes) so losses due o buffers sauraion during he inermedia rouing of frames can be discarded. Le us sar by examining he loss percenage of he indoor scenario. In figure 11 (righ) curves of he wo cliens are presened. The M2U proocol losses remains below 0.05%, while he M2M proocol shows ha all resuls are less han 0.2%. Our proposal measures appear in he upper curves, neverheless i is possible o appreciae ha he loss percenage do no exceed he 0.6%. All curves show a small growh as he ransmission rae increases because more frames are sen in a less ime, and in presence of fading or channel inerference i causes greaer losses. Alhough in our proposal losses are over he oher proocols resuls in his scenario hey are sill negligible, for insance, in erms of video qualiy. Furhermore, one reason of his loss is he overhead added by he unicas polling process which could be useless when he channel is almos ideal. I could be avoided if he server had wireless channel informaion o decide when he condiions are good enough o sop his process and jus direcly deliver frames in sandard mulicas fashion. This issue will be developed as par of our fuure work. In he oher hand, we have he oudoor scenario. Curves in figure 11 (lef) shows ha M2U has a poor performance because i has o perform independen ransmissions for each clien. In addiion, when he wireless channel qualiy is poor, he M2U proocol have o perform several error recovery which makes i highly inefficien. The M2M proocol average losses is around 12% while our proposal average losses remains nearly he 6% which raduces in a much beer video qualiy. Thus, our proposal reaches a beer hroughpu as he channel condiions become worse. 6 Performance Analysis In he following, we analyze he heoreical performance of our proposal. In figure 12, a ransmission scheme for all proocols is shown. As our proocol

11 POLL 0.5 PC1 M2M PC1 M2U PC1 GP PC2 M2M PC2 M2U PC2 GP Loss Percenage v/s Rae [Kbps] PC1 M2M PC1 M2U PC1 GP PC2 M2M PC2 M2U PC2 GP Loss Percenage v/s Rae [Kbps] Loss Percenage Loss Percenage Rae [Kbps] Rae [Kbps] Fig. 11. Resuls obained in he indoor (lef) and oudoor (righ) scenarios for he ransmission proocols implemened using ransmission raes beween 250 and 2000 [kbps] wih frames of 1000 [Byes] UNICAST (M2U) MULTICAST (M2M) Bes Scenario Worse Scenario Bes Scenario Clien 1 Worse Scenario 8 frames sen 8 frames sen Firs frame sen Clien 2 Clien 1 Firs frame sen c 8 frames sen Clien 2 8 frames sen Clien 1 Clien 2 Bes Scenario 8 frames sen Poll Process GROUPPOLL Worse Scenario POLL ACK 8 frames sen Poll Process Firs frame ReTx 8 firs frames resen POLL ACK :DIFS and BACKOFF :Unicas ACK :GroupPoll Header ACK :GroupPoll ACK :SIFS :Packe Loss Deecion :GroupPoll Poll :RTS/CTS Handshaking Fig. 12. Bes and Worse Performance Scenarios for he M2M, M2U and GroupPoll proocols. Do-Dashed Lines represens variable ime where several ransmissions ook place. works based on a group of eigh mulicas frames, we se his comparison over ha ground. We omi some frame ransmissions in he figure for space reasons, bu hey were considered in his analysis. Besides, we assume ha here are only wo cliens presen in he nework. Wih he purpose of sudy hese effecs in deail, we poin ou differences in proocols considering boh, he bes and worse scenarios depending of he success of he ransmission of frames. Hence, we assume ha in he bes scenario here is no frame loss while in he worse scenario, a successful ransmission always akes place in he las aemp before he frame is dropped. Based in he figure 12 we define he ime equaions for all proocols. These equaions are shown below.

12 M2M Bes Scenario Time=(DIFS+BACKOFF+FRAME)* 8 s (1) M2M Worse Scenario Time=(DIFS+BACKOFF+FRAME)* 8 s (2) M2U Bes Scenario Time=(((DIFS+BACKOFF+RTS+SIFS+CTS (3) +SIFS+FRAME+SIFS+ACK)* 2 Cliens)* 8 s) M2U Worse Scenario Time=((((DIFS+BACKOFF+RTS+SIFS+CTS (4) +SIFS+FRAME+SIFS+ACK)* 4 Reries)* 2 Cliens)* 8 s) In [4], Reries represens he LongReryLimi consan of he IEEE802.11b sandard. We use his value because we se our RTSThreshold limi in 0 using he RTS/CTS for all unicas ransmission. Thus, every frame size is greaer han his hreshold which ses his limi in 4. GroupPoll Bes Scenario Time=((DIFS+BACKOFF+GPFRAME) (5) *8 s)+(difs+backoff+rts+sifs+cts+sifs +POLLFRAME+SIFS+ACK)+(DIFS+BACKOFF+RTS +SIFS+CTS+SIFS+POLLACK+SIFS+ACK) GroupPoll Worse Scenario Time=((DIFS+BACKOFF+GPFRAME) (6) *8 s)+(difs+backoff+rts+sifs+cts+sifs +POLLFRAME+SIFS+ACK)+(DIFS+BACKOFF+RTS +SIFS+CTS+SIFS+POLLACK+SIFS+ACK)+((DIFS +BACKOFF+GPFRAME)* 8 s) Here, in [5] and [6], GPFRAME represens a frame wih a GroupPoll Header, POLLFRAME and POLLACK he Poll and Poll Response messages respecively. As ransmission ime for each frame depends on he ransmission rae used, in figure 13 we presen curves obained from his equaions for all daa raes used in he IEEE802.11b sandard. We also assume he values showed in able 1 for his analysis. These resuls allow us o examine he impac in laency added by our proocol and he radeoff beween reliabiliy and delay when we compare our proposal wih oher proocols. In figure 13 can be appreciaed ha M2U proocols presen a larger delay in boh scenarios and his increases quickly as he number of cliens grows. I is also clear ha our proocol remains very close o he M2M delay in he bes scenario (no reransmissions are needed), bu when he channel qualiy ges worse i reaches almos he double (reransmissions are always needed). In consequence, our proocol leads us o achieve a beer hroughpu over a wireless channel wih poor qualiy when mulicas raffic is sen. We also showed ha in he worse scenario he laency of our proocol would be consrained o nearly he double of a normal mulicas ransmission bu reducing almos by a half is losses. In his way, our radeoff is beer qualiy adding conrolled laency o improve he overall efficiency in mulicas ransmission.

13 Table 1. Size and Time values used in he IEEE802.11b Parameer Name RTS 20 CTS 14 ACK 14 MAC Header 34 IP Header 20 UDP Header 8 Layer Packe 972 GroupPoll Header 3 Poll 2 Poll Response 3 Parameer Name Size [Byes] Time [µs] DIFS 50 SIFS 10 Average Backoff Time 310 PHY Preamble and Header Duraion 192 Noe : see [10]; Noe : Long preamble, 24 [Byes] sen wih a 1 Mbps rae Delay [sec] v/s Rae [Mbps] M2M Bes Scenario M2M Worse Scenario M2U Bes Scenario M2U Worse Scenario GroupPoll Bes Scenario GroupPoll Worse Scenario 0.5 Delay [sec] Rae [Mbps] Fig. 13. Bes and Worse Time Performance Scenarios for he M2M, M2U and Group- Poll proocols. 7 Conclusions and Fuure Work In his paper, we presened a proposal for acual IEEE neworks o improve heir reliabiliy for mulicas daa. A novel feaure of his proposal is ha is reliabiliy conrol based on a polling service along wih conrolled rerans-

14 missions; besides, i does no require modificaions o he MAC layer because i works in he applicaion level and use inercepors o forward he mulicas sream. We recognize ha he Smar Server could be seen as a single poin of failure in our implemenaion, bu our proposal considers he use of one Smar Server for each AP in he nework. Thus, a commercial implemenaion could include he Smar Server proocol in he AP, inheriing in ha case, he robusness of a nework wih infrasrucure. Our resuls show ha our proocol performs beer han oher proposed in erms of reliabiliy as well as daa hroughpu in our measuremen scenarios. Furher work in his area will concenrae in improving our proocol adding feaures ha will allow us o obain delay and jier measures. References 1. IEEE Sandard , Par 11: Wireless LAN media access conrol (MAC) and physical layer (PHY) specificaions, IEEE Sandard b, Par 11: Wireless LAN Medium Access Conrol (MAC) and Physical Layer (PHY) specificaions: Higher-Speed Physical Layer Exension in he 2.4 GHz Band, Larry Peerson and Bruce Davie, Compuer Neworks a Sysems Approach, 2nd ed. Morgan Kaufmann Publishers, Daniel Grobe Sanchs and Igor Kozinesev and Minerava Yeung and Douglas Jones, Hybrid ARQ for robus video sreaming over wireless LANs, in Proceedings of he Inernaional Conference on Informaion Technology: Coding and Compuing, (ITCC 01), E. Ayanoglu, S. Paul, T. F. LaPora, K. K. Sabnani, and R. D. Gilin, AIRMAIL: A link-layer proocol for wireless neworks, ACM Wireless Neworks, vol. 1, no. 1, pp , K. Tang and M. Gerla, Random Access MAC for Efficien Broadcas Suppor in Ad Hoc Neworks, in Proc. IEEE WCNC 2000, pp , Sep M. Sun, L. Huang, A. Arora, and T. Lai, Reliable MAC Layer Mulicas in IEEE Wireless Neworks, in ICPP 02: Proceedings of he 2002 Inernaional Conference on Parallel Processing (ICPP 02), (Washingon, DC, USA), p. 527, IEEE Compuer Sociey, K. Tang and M. Gerla, MAC Layer Broadcas Suppor in Wireless Neworks, in Proc. IEEE MILCOM 2000, pp , Oc K. Tang and M. Gerla, MAC Reliable Broadcas in Ad Hoc Neworks, in Proc. IEEE MILCOM 2001, pp , Oc M. Kappes, An -Layer Approach for Muli-Hop Communicaion in IEEE Ad-Hoc Neworks, ech. rep., Avaya Labs Research-Technical Repor ALR , Ocober Proyeco FDI-Corfo Difusión Inalámbrica IP. Wireless IP Diffusion FDI-Corfo Projec, hp://inalambrico.reuna.cl.