Reliable Delivery of Popular Information Services in WIDE
Sinan Isik, Mehmet Yunus Donmez and Cem Ersoy
Department of Computer Engineering, Bogazici University,
Istanbul, Turkiye
{isiks, donmezme, ersoy}@boun.edu.tr
Abstract – Wireless Information Delivery Environment (WIDE) is a distributed data
dissemination system, which uses IEEE 802.11b technology. WIDE aims to deliver popular
information services to registered mobile clients in WLAN hot spots. Data delivery is based on
broadcasting and multicasting. System specific reliability mechanisms are needed because of
unreliable medium and transport protocol. Reliability in WIDE is assured with a combination of
Forward Error Correction (FEC), data carousel and ARQ techniques. This paper presents the
proposed system architecture with the details of reliable data delivery mechanisms. Performance
evaluation results of the proposed reliability mechanisms using the implemented prototype are
also included in this paper.
Index Terms – wireless data delivery, reliability, FEC, data carousel
1. Introduction
The dominant use of IEEE 802.11b WLANs is to provide Internet access for mobile users
as distributed hot spots. However, WIDE (Wireless Information Delivery Environment) [1] is a
system which is intended to offer data services other than Internet access to its users. WIDE aims
to deliver popular information services, which appeals general interest such as entertainment,
shopping and education in distributed hot spots.
WIDE hot spots can be found in locations where there is the appropriate user density, but
users have to walk through the service area in order to actually access the service, and then take
their service away for later consumption. As users walk through the coverage area of the system,
the most recent version of the subscribed information services will be automatically downloaded
to their mobile terminals without any user intervention.
WIDE system is designed considering moderate-sized and low-mobility environments.
Some specific deployment scenarios may be listed as follows: A WIDE system may deliver
course notes, web pages and announcements to students in a campus environment, detailed
information to visitors about the objects on the stands in an exhibition center, or product and
price information to clients in a shopping-mall.
Since the system offers popular information services, it should perform in an acceptable
level in terms of reception time for individual clients when there are many users demanding the
same service. Hence, the design should be based on data broadcasting, or, more precisely, on
data multicasting to provide scalability and efficient use of the wireless channel. However, TCP
does not support broadcasting and multicasting. Hence, we are restricted to design data delivery
mechanism to use UDP as transport protocol. Since UDP is an unreliable protocol and the
wireless medium is known to be erroneous, WIDE needs a system specific reliability
mechanism.
In this paper, we concentrate on the reliability mechanisms in WIDE system. Automatic
Retransmission Request (ARQ) techniques are generally used in unicast environments. ARQ
2
might result in a reduced throughput, and especially in a multicast environment, it might be
highly inefficient because of uncorrelated losses at different groups of receivers. In these cases,
Forward Error Correction (FEC) techniques, possibly combined with ARQ may be useful [2].
Here the sender prevents losses by transmitting some amount of redundant information, which
allows the reconstruction of missing data at the receiver without further interactions. Besides
reducing the time needed to recover the missing packets, such an approach generally simplifies
both the sender and the receiver since it might render a feedback channel unnecessary; also the
technique is attractive for multicast applications since different loss patterns can be recovered
from using the same set of transmitted data.
Data carousel or broadcast disk [3] is another approach to eliminate the need for
retransmission and to allow receivers to access data asynchronously, ensuring full reliability. In a
data carousel approach, the source repeatedly loops through transmission of all data packets.
Receivers may join the stream at any time and listen until they receive all distinct packets
comprising the transmission. Clearly, the reception overhead at a receiver, measured in terms of
unnecessary receptions, can be extremely high using this approach. WIDE system employs a
reliability mechanism, which is a mixture of data carousel, FEC and ARQ techniques.
In Section 2, we give a brief overview of the WIDE system architecture and the data
delivery mechanism. The details of the reliability mechanism are presented in Section 3. Section
4 presents the performance results evaluated on implemented WIDE prototype. Section 5
concludes the paper, suggesting some future works.
2. Wireless Information Delivery Environment
WIDE is a system, which is designed for delivering popular information services in
moderate-sized environments. There are components having specific tasks in WIDE design
which form the WIDE network. The network is composed of both wired and wireless mediums.
Two main system components, called WIDE cluster controller (WICC) and WIDE servers (WIS)
are located in the wired part of the system and they communicate through WIDE LAN. The
building blocks of the WIDE system and their connectivity are shown in Figure 1.
SA
HUB
WIC
WIC
WIAP
WIS
WIAP
SA
WIC
WIAP
WIDE LAN
WICC
WIS
SA
SA
WIS
WIC
WIC
WIAP
WIAP
WIC
WIS
Figure 1. Building blocks of WIDE
3
WIDE servers are responsible for preparing and delivering information services to
clients. The information services, which are available for delivery to clients, are assumed to be
stored on each WIS. The delivery management information such as service identifier, class,
version, name and location on the local disk is recorded in a database called WIDE Server
Database (SDB).
WIDE cluster controller keeps and manages system administration database called WIDE
Cluster Controller Database (CCDB). Information about servers, user profiles, services offered
by the system and authentication of clients are stored in this database.
The IEEE 802.11b WAPs, namely WIDE access points (WIAPs) are located at the endpoints of the wired network to provide wireless connectivity of WIDE clients (WIC) to the
servers of the system. A client is a battery operated handheld or laptop PC with necessary
equipments that provide wireless connectivity.
There can be one or more WIAPs connected to a server, but a WIAP can only be
connected to one server. The geographical area covered by WIAPs that are connected to a server
is called the service area (SA) of that server.
2.1. Data Delivery Cycles of WIDE
Client-server communication is divided into periodic time frames, which are also divided
into sub frames. Each sub frame is a time period, which is dedicated to a certain communication
task. This frame structure is formed to organize the message and data transfers. Since there is
only one physical channel, namely the wireless medium, such an organization is needed to
decrease the number of collisions and to provide efficient use of the channel. Periodic time
frames are called Communication Cycles (CCs). Figure 2 illustrates the structure of the CC.
Time
RQP
DP
CS N
CS 1
AUP
RPP
IBP
CS 2
Figure 2. Communication Cycle
The sub frames, which are named as index broadcast period (IBP), reception preparation
period (RPP), data period (DP), authentication period (AUP) and request period (RQP),
sequentially follow each other in this order in a CC. DP is also divided into sub frames, called
communication slots (CS).
A client, who enters to the service area of a server, discovers the existence of it by
listening to the broadcast messages initiated by that server. The client should authenticate itself
to the system in order to receive service from that server. For this purpose, the client has to wait
for the AUP to send its authentication request to the server. The server sends the response to
authentication request in AUP of a following CC.
The requests of authenticated clients for subscription to information services or requests
for unsubscriptions are transmitted to the server on RQP. In addition, retransmission request for
4
the information services, whose packets are missed, and polling request for updates of
information services on the user profile are also transmitted to the server on RQP. The server
sends the corresponding response messages to the client on the same RQP.
A scheduler running in the server decides data to transmit during each CC and prepares
the index. The scheduling of an information service in a server requires at least one client in the
service area of that server who previously subscribed or has just subscribed to that service. If the
client has just subscribed to that information service or a retransmission is requested for that
service from the server due to incomplete reception, then that service is queued for delivery. In
addition, if the client has made an authentication or polling request and if there is a version of
that information service that is newer than the one recorded in the user profile of that client, then
that service is queued for delivery. At the time of delivery, the service appears on the index.
When a client is within the service area of that server, it listens to the index sent on IBP
to see which information services are offered by the server during that CC. This index message
also informs the clients about the multicast group of transmission, the version and the size of the
information service to be transmitted. Each multicast group is coupled with a CS in DP. The
client examines the index and determines whether there are any available items of interest by
looking up the user profile in the mobile terminal. If items of interest are available, the client
joins to the announced multicast group and prepares the buffers for receiving an information
service in the RPP. Services are delivered to clients in the form of packets of fixed size. Data
packets of each item announced for that CC are delivered in the corresponding CS. The client
receives data packets of the interested service by listening to the joined multicast group.
3. Reliable Data Delivery in WIDE
Wireless data delivery systems require reliability mechanisms to ensure that all the
intended recipients of an information service receive the service intact. The reliability
mechanism in WIDE is designed to employ a mixed type of carousel, erasure code and ARQ
techniques. Pure carousel technique provides full reliability for data delivery by delivering the
data multiple times. However, this increases the number of unnecessary receptions caused by
duplicate packets on the client side. Also, carousel mechanisms cause to increase the average
reception time of an information service in unreliable mediums. Hence, the number of carousel
cycles for each information service is kept limited. In addition, erasure code mechanisms [4] are
employed to decrease the reception time.
The reliability mechanism in WIDE starts with the preparation of the requested
information services for delivery. The preparation phase consists of three steps, namely
packetization, encoding and security steps. In the packetization step, the data to be transformed
are sequentially buffered in memory in the form of equally sized blocks of data. The size of these
blocks is a configuration parameter of the system. In our studies, we set the value of this
parameter to 1400 bytes because the maximum throughput of UDP on wireless medium is
achieved when the UDP packet size is 1472 bytes including headers and throughput rapidly
drops after this value [5]. The number of data blocks, n, is determined by the size of the
information service.
The encoding step is related with the reliability mechanism. In the encoding step, data
packets are processed by the FEC module, which outputs n+k packets. The k packets correspond
to redundancy of the FEC algorithm applied in WIDE. The value of k is determined by the
redundancy parameter of the system, which is set as a predetermined percentage of the number
of whole packets. Figure 3 illustrates general operation of FEC schema. After the encoding
5
process, a packet number is given to each packet in sequential order. Security operations are
performed on the encoded packets and then the scheduler is informed that the information
service is ready for delivery (RFD).
Figure 3. FEC schema [4]
The scheduler collects the RFD messages of each ready information service. These RFD
messages are classified and queued according to some specific criteria to be able to inform
Communication Cycle Manager whenever it is consulted. The current scheduler in WIDE
operates in an FCFS manner.
In the data delivery step, another reliability mechanism of WIDE, namely data carousel,
is employed. Data carousel is controlled by the CC Manager. At the beginning of each CC, the
CC Manager consults the scheduler for any RFDs to be assigned to empty communication slots.
Depending on the size of the assigned slot, the complete delivery of information services may
take one or more CCs. The CC Manager keeps track of necessary data and makes necessary
calculations for a complete delivery of an information service. Information services are delivered
on the assigned CSs repeatedly, which is called a carousel cycle. The number of carousel cycles,
nCAR, is a system parameter, and its default value is two. The details of the CC Manager will be
given in Section 3.2.
A client can reconstruct an encoded information service by receiving of any n packets out
of n+k transmitted packets. The packet numbers are used to keep track of the received packets.
When enough number of packets is received for the FEC decoding process, packets are decoded
to form the actual data packets in sequential order. If the received number of packets is not
enough to reconstruct the actual data, the missing packets can be captured in the next carousel
cycle, if exists. If there are still missing packets to be captured, then an ARQ request is prepared
by the client to request the server to reschedule that information service.
Since the packets to be requested may vary from client to client, the number of ARQ
requests made for individual packets creates congestion on the server side. This is a phenomenon
called feedback implosion [6]. The ARQ mechanism in WIDE is used to make requests for the
delivery of whole packets of an information service, not for individual packets, which decreases
the risk of feedback implosion.
3.1. FEC Mechanism in WIDE
The FEC mechanism in WIDE uses the FEC schema proposed by Luigi Rizzo [7] based
on the Galois Field Theory. It is noted that the algorithm most efficiently operates when the
6
number of packets including the redundancy is smaller than 28, i.e. n+k ≤ 256. There is another
version of this FEC schema for higher number of packets, which is based on GF(216) instead of
GF(28). However, in the GF(216) polynomial space, the degrees of polynomials are at most 15. In
this case, operation complexity is higher, since matrix sizes increase with the maximum
polynomial degree, and operations mostly involve matrix multiplications and inversions. For the
cases where the number of packets including redundancy is above 256, packets are divided into
blocks of sizes smaller than 256.
FEC schema assumes a constant rate of redundancy packets per block. This rate is a
percentage of the number of packets in each block. As this percentage increases to 100, the
behavior of this schema converges to data carousel. On the other hand, as this percentage
decreases to zero, the schema will be less tolerant to errors.
The aim of FEC schema in WIDE is to keep the number of blocks as small as possible.
As the number of blocks increases, the size of the blocks decreases and the number of redundant
packets per block decreases. As a result, this makes blocks less tolerant to packet losses.
The number of blocks is minimized by either keeping the size of blocks except the last
one as big as possible to leave some small portion of packets to the last block, or keeping the
block sizes as equal as possible. In the former case, the loss tolerance of the bigger blocks is
higher but the last block has a poor loss tolerance. In the latter case each block has almost equal
tolerance for any packet loss. Therefore, the FEC schema in WIDE is designed to keep the block
sizes as equal as possible. The number of packets to be encoded in each block is determined
using the algorithm in Figure 4.
NumberOfBlocks = 1;
AvailableBlockSize = Floor(256*(1-Redundancy/100));
BlockSize = Ceil(TotalNumberOfPackets/NumberOfBlocks);
While BlockSize > AvailableBlockSize
NumberOfBlocks = NumberOfBlocks + 1;
BlockSize = Ceil(TotalNumberOfPackets/NumberOfBlocks);
Figure 4. FEC block size algorithm
The information service packets are grouped into blocks of size determined by
BlockSize in Figure 4. The result of application of FEC schema to each block is a new block of
size BlockSize*(1+ Redundancy/100). These blocks are sequentially buffered to form the
encoded information service to be transmitted.
3.2. Communication Cycle Manager
The delivery of an information service may not be completed in one CC because of the
limitations on the data period. These limitations are on the number of communication slots and
total number of packets that can be delivered in a DP, which are client-server communication
system design parameters in WIDE. The total number of packets is divided among the
information services that are scheduled for delivery in that CC according to the partitioning
algorithm. This algorithm decides the number of packets to be delivered for each information
service considering the total remaining packets of it. In the first delivery, the number of
remaining packets are nCAR * size in packets. If the number of packets scheduled to be
transmitted for an information service is smaller than the total number of packets of it, the
7
delivery of that service cannot be completed in that CC. The CC Manager keeps delivery status
records necessary for the complete delivery of an information service. After each delivery,
number of remaining packets for each service is updated in the corresponding record. The
manager controls the carousel cycles of each information service by making necessary
calculations on the total number of remaining packets. Tasks of the manager are: communicating
with the scheduler to decide the information services and calculation of the number of packets of
the information services scheduled to be delivered in that CC; multiplexing the scheduled
information services to CSs; preparation of the index message for that CC and execution of CC.
CC Manager communicates with the scheduler at the beginning of each CC and receives
required number of RFDs to utilize the empty CSs whose data delivery have finished in a
previous CC. Using these inputs, the manager forms a list of RFDs that represents the
information services scheduled to be delivered in that CC. This list is processed by the
partitioning algorithm, which outputs the numbers of packets to be sent in that CC corresponding
to each RFD. Then multiplexer assigns a distinct CS to each RFD. Partitioning and multiplexing
outputs, together with the RFD list are used to create the index message for that CC. After this
point the manager executes the CC by delivering the appropriate packets informing clients about
the start and end points of the periods.
3.2.1. Partitioning Algorithm
The aim of this algorithm is to determine the number of packets to be delivered in that
CC for each information service which is listed in RFD. There are two parameters used in this
algorithm. These parameters are nPACK and nCS, which corresponds to the maximum total
number of packets that can be delivered in a DP and the number of communication slots in a CC
respectively. Partitioning Algorithm works over sizes of sets. It gets the size of the whole set and
outputs the sizes of the partition sets whose sum gives at most the size of the whole set. Figure 6
gives the partitioning algorithm used in WIDE.
TotalPackets = 0;
For all RFD in RFD list
TotalPackets = TotalPackets + RFD->NumberOfPackets;
If TotalPackets <= nPACK
For all RFD in RFD list
RFD->NumberOfScheduledPackets = RFD->NumberOfPackets;
Else
Sort RFD list wrt NumberOfPackets;
RFDCount = 0;
For all RFD in RFD list
SlotSize = Floor(nPACK/(RFDList length - RFDCount));
If RFD->NumberOfPackets < SlotSize
RFD->NumberOfScheduledPackets = RFD->NumberOfPackets;
Else
RFD->NumberOfScheduledPackets = SlotSize;
nPACK = nPACK - RFD->NumberOfScheduledPackets;
RFDCount = RFDCount + 1;
Figure 6. Partitioning algorithm in CC Manager
8
Algorithm starts with summing up the number of remaining packets of each information
service for delivery in the RFD list. If the sum is less than nPACK, then the result of the
algorithm is an array containing the numbers of packets. Otherwise, it gets nPACK as the whole
set size. If there are less than nCS information services, nPACK is divided into this many
partitions. If there are more than nCS information services, only nCS many of them are delivered.
The partitioning algorithm uses some criteria while partitioning nPACK into parts. A
familiar approach is partitioning nPACK equally between information services. Another
approach is partitioning nPACK according to the value of a criterion, i.e. the more an information
item has number of packets, the more space is partitioned for it or the higher priority class an
information item belongs to, the more space is partitioned for it.
3.2.2. Multiplexer
The aim of the multiplexer is to assign a distinct empty CS to each information service in
the RFD list in that CC. Every CS is coupled with a DCH. Hence, the multiplexer assigns a DCH
to each service in RFD list. Each CS has a fixed sequence number for delivery in a DP, which
can be defined as DCH identification number. The multiplexer returns a list of DCH identifiers
whose contents correspond to the delivery order of the information services in RFD list.
This assignment is done according to some multiplexing criteria. A simple way is to
assign empty slots to new RFD items in a FCFS manner. In this mechanism, first information
services, whose delivery have started in a previous CC, are assigned to lower sequence numbered
slots according to their arrival order to CC Manager. Then information services, whose delivery
will start in that CC, are assigned to remaining empty slots according to their arrival order.
Another multiplexing criterion is to have priority classes. The information services of higher
priority classes are assigned to be delivered in smaller sequence numbered CSs. The multiplexer
in WIDE employs the FCFS as the assignment mechanism.
4. Performance Evaluation of Reliability Mechanisms on a WIDE Prototype
A “proof of concept” prototype of the proposed system is implemented and deployed as
part of the Mobile Applications and Services Testbed (MAST) [8] of Bogazici University. The
prototype provided a testbed for the evaluation of the performance of the proposed data delivery
mechanisms and for further studies. Performance tests in this paper are not large-scale tests. We
mainly concentrate on finding the effects of reliability mechanisms on the on the system
performance. The behavior of the FEC schema is analyzed in terms of processing times
measured for varying file sizes. In addition, the effect of carousel and FEC mechanisms on file
reception is investigated in existence of background traffic.
The server and cluster controller prototypes run on desktop computers which have a
Windows 2000 Family operating system on them. The client application is executed on a laptop
computer with a Pentium III processor operating at 500 MHz and 192 MB RAM with Windows
2000 Professional Edition operating system. The server and the controller applications are
executed on the same desktop computer with a Pentium IV processor operating at 1800 Mhz and
1 GB RAM with Windows 2000 Advanced Server Edition operating system. The wireless
connectivity between the server and the client is provided with a Cisco AiroNet 350 Series WAP
connected to the server computer via an Ethernet adapter and a 3Com AirConnect WLAN
PCMCIA card installed on the client.
9
4.1. Performance of FEC Schema
In this section, the performance of the FEC operations on the client is analyzed. For this
analysis, the client is placed indoor, to five meters apart from the WAP, in the line of sight.
nCAR parameter value was set to 1. The Server-WAP connection type was the direct cable
connection. No background traffic is employed on the adapter connecting the server to the WAP.
Each information service is requested from the server in a way that only one file was delivered in
a CC and the processing times of FEC for these files are measured after every file reception. The
experiments were repeated 15 times for each file size. Figure 7.a presents the behavior of the
FEC algorithm employed in WIDE. Each value on the graph represents the average values.
80
Processing Time (ms)x
70
60
50
40
30
20
10
0
100
200
300
400
500 600 700
File Size (KB)
800
900 1000
(a) Performance of FEC for different file sizes
File Size
100
200
300
400
500
600
700
800
900
1000
Packets
74
147
220
293
366
439
512
586
659
732
Block Size
74
147
220
147
183
220
171
196
220
183
Blocks
1
1
1
2
2
2
3
3
3
4
(b) FEC information
Figure 7. FEC schema on client for different file sizes
Figure 7.b gives the information about the number and the size of FEC blocks for each
file size used in the experiments. Table shows that the increase on the number of FEC blocks
results with a decrease on the number of packets in each FEC block. Although the number of
FEC blocks increases, the decrease in FEC block size decreases the total processing time. The
processing time for the files having the same FEC block size are observed to be nearly the same
except the case when the number of FEC blocks is equal to one. The observed behavior in Figure
7.b is a result of these facts.
4.2. Effect of Background Traffic on Reliability
In this section, the effect of background traffic on the performance of file reception is
analyzed. For this purpose, the client is placed indoor, to five meters apart from the WAP, in the
line of sight. nCAR parameter value was set to 1 to be able to detect the number of cycles elapsed
for the completion of the reception. The Server-WAP connection was established via a 10 Mbps
HUB. Background traffic is created by transferring data from another desktop computer
connected to the HUB to a wireless capable laptop computer associated to the WAP.
Under this traffic condition, file reception statistics of subscribed information services are
recorded with and without employing the FEC mechanism. The table in Figure 8 summarizes the
statistics obtained in these experiments. Each value in the table represents the average of 15
values. The third, fourth and the fifth columns represent the number of trials in which the
information services were received in one, two or three cycles respectively. The sixth column
10
represents the average number of duplicate packets of the trials where reception of the
information services was completed in more than one cycle. Similarly, the seventh column
represents the average number of packet losses of the trials where reception of the information
service was completed in more than one cycle. We can observe that the background traffic on the
radio significantly affects the performance of information reception. The completion of reception
may finish in more than one cycle, which increases the reception time. As the size of information
service to be delivered increases, the average number of packet losses increases. The reason may
be the congestion on the WAP caused by the traffic, which is created by both WIDE system
communication and the background traffic.
Without FEC
With FEC
One Two Three
File Size
Duplicates Loss Redundancy Loss
Packets
Cycle Cycles Cycles
(KB)
100
74
11
4
0
42.75
3.5
0
2.22
200
147
5
10
0
104.7
6.1
0
7
300
220
6
9
0
139.44
7
0
6
400
293
2
13
0
196.31
10.77
12.07
4.53
500
366
0
15
0
291.73
11.27
14.33
7.6
600
439
1
14
0
341.43
20.07
15.93
11.4
700
512
2
12
1
337.08
19
28.07
9.53
800
586
0
14
1
527.53
21.07
31.67
9.2
900
659
0
10
5
667
33.13
39.73
6.07
1000
732
0
10
5
794.33
34.33
45.6
13.27
Figure 8. The statistics of information reception in case of background traffic on the radio
In the second part, the FEC mechanism is employed with 10 per cent redundancy. We
observed that all of the receptions completed in the cycle following the subscription. The eighth
column in the table gives the average number of redundant packets received and discarded until
the completion of reception. The last column gives the average number of packet losses. We can
observe that when there is background traffic on the radio, employing FEC decreases the number
of cycles for reception. Consequently, it decreases the average reception time and hence
increases the performance of information reception.
It can be observed from the table that without FEC mechanism, the increase in the
average number of the packet losses results with an increase in the number of cycles for the
completion of the file reception. By comparing with and without FEC cases, it can also be
observed that the increase in the number of cycles also results with an increase in the number of
packet losses. This means that packet losses and number of retransmissions trigger each other in
a cyclic way. The cyclic behavior repeats in the cases where the packet losses in a cycle coincide
with the packets that could not be received in previous cycles. The high values of average loss in
without FEC case are outcomes of this condition.
Another advantage of employing FEC can be observed by comparing the duplicates
column with the redundancy column. It can be stated that employing FEC not only reduces the
reception time, but also reduces the number of unnecessary receptions in a considerable way.
11
5. Conclusion
The design of an information delivery system, namely WIDE, and the mechanisms
required for reliable data dissemination are presented in this paper. The system uses the WLAN
hot spot concept to disseminate high-bandwidth data in distributed manner. IEEE 802.11b
technology is used as the underlying infrastructure for the proposed system. Current system
architecture is constructed for a moderate-size network with the assumption of walkthrough
scenarios. The reliability mechanism in WIDE is a mixture of data carousel, FEC and ARQ
techniques. Proposed reliability mechanisms are tested on a “proof of concept” prototype and
some preliminary results on the performance, perceived by the client, are reported.
The results of the tests show that even though pure carousel technique is known to
provide full reliability, even a single packet loss may dramatically increase the reception time
together with the number of unnecessary receptions caused by duplicate packets on the client
side. This proves that carousel technique should be supported by another reliability mechanism.
FEC mechanism employed in WIDE is shown to decrease the average reception time and
number of unnecessary receptions by transmitting some amount of redundant information.
Acknowledgements
This work is partially supported by the State Planning Organization of Turkey under the
grant number 98K120890, and by the Bogazici University Research Projects under the grant
number 02A105D.
References
1.
2.
3.
4.
5.
6.
7.
8.
Donmez, M. Y., S. Isik and C. Ersoy, “WIDE: Wireless Information Delivery Environment in Distributed Hot
Spots”, Proceedings of Wireless On-Demand Network Systems 2004, LNCS 2928, pp. 315-328.
Rizzo L. and L. Vicisano, “RMDP: an FEC-based Reliable Multicast Protocol for Wireless Environments”,
Mobile Computing and Communications Review, Vol. 2, No. 2, pp. 1-10, April 1998.
Acharya S., R. Alonso, M. Franklin and S. Zdonik, “Broadcast Disks: Data Management for Asymmetric
Communication Environments”, Proceedings of the ACM SIGMOD Conference, San Jose, CA, pp. 199-210,
May 1995.
Rizzo, L., “Effective Erasure Codes for Reliable Computer Communication Protocols”, ACM Computer
Communication Review, Vol. 27, No. 2, pp. 24-36, April 1997.
Vasan, A. and A. U. Shankar. An Empirical Characterization of Instantaneous Throughput in 802.11b WLANs,
http://www.cs.umd.edu/~shankar/Papers/802-11b-profile-1.pdf, 2003.
Nonnenmacher J. and E.W. Biersack, “Optimal Multicast Feedback”, Proceedings of IEEE INFOCOM, San
Francisco, CA, USA, Vol. 3, pp. 964-971, March 1998.
Rizzo L., FEC Code, http://info.iet.unipi.it/~luigi/vdm98/vdm980702.tgz, July 1998.
Mobile Applications Testbed (MAST), Netlab, Bogazici University, http://netlab.boun.edu.tr/mast.html.