An Asymmetric Protocol for Digital Cellullar Communications

S. Paul, E. Ayanoglu, T.F. La Porta K-W.H. Chen, K.K. Sabnani, R.D. Gitlin
AT&:T Bell Laboratories, Holmdel, N J 07733
Abstract
This paper describes the design, validation, implementation and performance of an asymmetric linklayer protocol f o r a wireless link. 'The motivation for designing a new link-layer protocol is to obtain better performance in terms of end-to-erad throughput and latency by correcting errors in an unreliable wireless link in addition to end-to-end correction rather than b y correcting errors only b y end-to-end retransmissions. The protocol described in this paper concentrates on asymmetry, although the concept of adaptive forward error correction is briefly introduced. The protocol also supports mobility, the details of which are beyond the scope of this paper. The asymmetry is needed in the design because the wireless terminals have limited power and smaller processing capability than the base stations. The k e y ideas in the design consist of placing bulk of the intelligence in the base station as opposed to placing it symmetrically, in requiring the wireless terminal to combine several acknowledgments into a single acknowledgment to conserve power, and in designing the base stations to send periodic status messages, while making the acknowledgment from the wireless terminal event driven. The asymmetry in the protocol design results in a onc-third redaction of compiled code and a two-thirds redaction of processing overhead in the wireless terminal. Some performance results are also presented.
by Caceres and Iftode in [CI94]. This leads to lower throughput and higher latency. Therefore, correcting errors on the wireless link in addition to end-to-end correction will result in better performance compared to only end-to-end correction. However, there is evidence in the literature that a retransmision in the link-layer does not always result in better performance owing to its complex interaction with end-to-end retransmission mechanisms [DCY93]. We envision a network architecture which has a wired network as its backbone with base stations on it acting as access points for the wireless terminals (Figure 1). Wireless terminals communicate through the base stations in order to communicate with other hosts. In the context of this architecture, a wireless link refers to a link betweein a wireless terminal and a base station. We do not consider the case of a wireless link between two wireless terminals in this paper.

BACKBONE

Mobile Terminal

Base Station

El
U

1 Introduction
With the increasing popularity of wireless communication, there is a growing need for new protocols to accomodate the specific properties of a wireless link in an efficient way so that a wireless terminal with better performance, lower power, and smaller size can be designed. In addition, because of the effects of fading, interference and mobility, the error rate incurred in a wireless link is often very high. This has two effects. First, in current systems, end-to-end protocols must recover from these errors, often using retransmission timers. These timers are typically set to values on the order of seconds to allow for vaxiable network delays. This causes the recovery time of an error that occurs on a wireless link to be long. Secondly, losses incurred on the wireless link trigger the end-to-end transmitters to decrease the window size and increase the duration of the retransmission timers as observed

Fixed Host

Figure 1: Wireless Network Architecture

A wireless link between a base station (which is wired

to the backbone network) and a wireless terminal (which has no wired connection) is inherently asymmetric in nature. The asymmetry can be attributed to the fact that the wireless terminal has limited power and smaller processing capability than the base station. In order to accomodate this asymmetry, we propose to put as much intelligence as possible in terms of processing in the base stations and make the wireless terminals relativiely dumb. In addition to the asymmetric nature of the link between the base station and the wireless terminal, the medium by itself has certain properties.

8d.2.1
0743-166W95 $04.00 0 1995 IEEE
1053

The bandwidth (Hz) is limited and bps (bits per second) needs are constantly increasing. Therefore, bandwidth is expensive and hence needs to be conserved. Bit error rate is variable, but can be very high at times.

(2

There is a fixed processing delay of at most 100 ms. at each end of a wireless link associated with complex signal processing. This delay defines a window in terms of the number of packets that can be in the pipeline between a transmitter and the corresponding receiver at the two ends of a wireless link. The above mentioned properties of a wireless link lead to conflicting requirements in the design of a protocol. For example, since the bandwidth is expensive, it is necessary to minimize retransmissions. On the other hand, the error rate being high, it is desirable to make redundant transmissions with the assumption that the probability of a packet being delivered correctly is higher if it is transmitted more than once. This trade-off must be taken into consideration while designing a protocol. Keeping the above considerations in mind, we present the design of an asymmetric protocol for a wireless link. The key ideas involved in the design are as follows:

it sends a status message after receiving a block (a set of packets). However, there is a tradeoff between wasting power and increasing latency, which needs investigation. Thus a wireless terminal transmits packets, but does not send an acknowledgment after receiving each packet. It waits for receiving a whole block before sending out a status message.

For a link-layer protocol, such as ours, to be useful in

a mobile wireless environment, as handoffs occur and wireless terminal communicates through a new base station, a link-layer handoff must occur. This requires a synchronization of the link-layer state at the new base station with the link-layer state at the old base station. We have designed techniques to deal with handoffs at the link layer [APLSG95]. Recently, a new point-to-point ARQ protocol has been proposed for the radio channel [NED931 which exploits the sequential delivery of packets in a wireless link. However, it assumes circuit-mode data, while we assume packet-mode data. Also, the protocol in [NED931 is symmetric in the sense that both the base station and the wireles terminal perform the same functions, which is not true in our protocol. This paper is organized as follows. The actual protocol is described in section 2 followed by a formal specification of the protocol in section 3. Validation and implementation of the protocol is described in section 4 while section 5 describes how forward error correction can be added to the basic protocol. In section 6, we present some performance results to justify the claims we make about the key properties of the protocol and also show the asymmetry between the base station and the wireless terminal in terms of size of code and processing time. Finally, we conclude the paper highlighting our contribution and future work.

1. Timers are always at the base station regardless

of whether it is transmitting or receiving. Thus the intelligence in terms of maintaining timers, processing complex status messages and most importantly, making decisions resides in the base st at ion.

2. The base station receiver sends its status to a wireless transmitter periodically, like the SNR protocol [NRSSO]. The justification for using periodic status messages is to reduce the dependence on the error prone medium. In particular, if the wireless channel is bad and the base station does not receive packets, it can still send status messages, because sending of status messages is triggered by the timeout signal of a local timer and not by the event of receiving a packet. Also, if a status message gets lost, there is always a next one for the transmitter. Note that the period of sending status messages can be adjusted so as not to waste much bandwidth for control information while at the same time offsetting the effect of a noisy channel.
3. The wireless receiver does not send its status to the base transmitter periodically because of its power constraint. These status messages are event driven.
4. The wireless receiver combines several status messages into one status message to conserve power. That is, the wireless terminal does not send a status message after receiving each packet. Rather

2 2.1

Protocol for a wireless link Protocol for data transfer from a Wireless Transmitter (WT) to a Base Receiver (BR)

The steps involved in the protocol may be listed as follows:

1. W T transmits new packets continuously until a maximum transmit buffer size is reached (maximum buffer size is computed using a multiple of the round-trip delay), a retransmission request (status message notifying loss/corruption of a packet) is received, or it has no more data to transmit. Retransmission has priority over transmission of a new packet. When W T has no more to transmit, it sets a bit in the packet header of the last packet. This bit is referred to as the e-bit in subsequent sections of the paper. 2. BR transmits status messages periodically to W T . This is similar to periodic state exchange in the

8d.2.2
1054

SNR protocol [NRSSO] except that state is not exchanged and that the status messages in this protocol do not contain informatiion regarding how much buffer space is available in the receiver as in the SNR protocol. The periodicity is maintained using a status timer which expires after a given interval and is restarted after a status message is sent. The period is reduced when BR receives a packet with the e-bit set. In such a case, BR sends its status immediately without waiting for the Status Timer to expire. This allows for fast acknowledgments when small ainounts of data are being sent and quick response is the main concern. Since W T does not send its status periodically and it does not have a timer, a timer is needed at BR to detect loss of packets. The concept of using a timer at the receiver was introduced in NETBLT [CLZ87], although in the context of a transport protocol. Also note that BR sends its status periodically to W T , thereby incorporating redundancy in the error prone medium.

part of the status message) arrives, or it has no more packets to transmit. When BT has no more packets to transmit, it sets the e-bit in the packet header of the last packet. BT starts a timer after transmitting a full block of packets or after transmitting a packet with the e-bit set, ancl sends an explicit status request message (Poll) to W R if it does not hear from WR before the timer expires. Note the presence of timer at BT..
2. W sends a status message after it receives a whole block (fixed number of packets). The status message is a bitmap such that bita indicates whether packet; within the given block has been received or not. Biti = 1 indicates received while biti = 0 indicates not received.

3. W T retransmits the requested packets before transmitting any new packet. If retransmissions do not reach BR, W T will not be able to transmit any new packets after a finite period of time because the transmit buffer space at W T will be exhausted. The transmit buffer size buf at W T is larger than the window to take care of loss of status messages from BR to WT. This improves the performance in terms of throughput and delay. Since buf is larger than the window, W T can transmit new packets longer than usual with the hope that status messages ackinowledging previously transmitted packets will arrive a little later than the expected time owing t o the loss of first few status messages. This prevents idling by the transmitter. In other words, W T anticipates opening of window or freeing of buffer space in near future. Buffer space at W T will be exhiausted if the forward channel (BR to WT) is bad or the reverse channel (WT to BR) is bad or lboth are bad. We argue next that in any case such an anomaly will be reflected at BR in the form of an unchanged status. 2.2

Note that to conserve power, WR, unlike BR (when Base Station is in the receiving mode), does not send status messages periodically (at fixed intervals of time) and frequently (more than once during the round trip time). Moreover, for the same reason. it does not send a status message after it receives each packet. W R waits for either a whole block, or a packet with the e-bit set, to arrive before sending out a status message. This allows the wireless unit to conserve transmission power.

3. BT retransmits the requested packets. Note that BT selectively retransmits only the lost packets in a given block and not the whole block.2 This conserves bandwidth. BT also starts the timer to detect if WR sends a status message acknowledging the receipt of the retransmitted packet within the expected time. If not, BT sends an explicit Poll message to WR. If the status message from W R does not arrive before the timer expires, BT tries again and gives up after a few attempts if W R does not respond.

Formal Specification of the Protocols

Protocol for data transfer from a Base Transmitter (BT) to a Wireless Receiver (WR)

The steps involved in the protocol may be listed as follows:

In order to describe the protocols in a formal way, we represent them in the form of Communicating Extended Finite Stake Machines (CEFSMs). In order for an EFSM to transition from one state to another, it may require certain conditions to be true (which depend on the values of the context variables), or may require certain inputs to arrive (from another communicating machine). In addition to that, these EFSMs may update conte.xt variables or send certain oudputs
2This is different from the SNR protocol in which a whole block is retransmitted. SNR protocol is designed for high-speed networks where bandlwidth is not expensive and hence retransmitting a whole block is not a big issue. However, in wireless links, bandwidth is expensive and hence we minimize all transmissions.

1. BT transmits new packets until the window closes, a request for retransmission (which is a
Throughout this paper the term window is used to represent the number of packets that can be transmitted during a roundtrip delay.

84.2.3
1055

(to other communicating machines) during a transition from one state to another. The condition, input, output and update are represented as follows: 1. A condition is represented by {c}.

Explanation br?setuD-ack * u!enable Ibuffufflag=O] {noD < MaxBufF

nI1
II

2. A message is represented by M where M can be of the form ml!z (send a message z to EFSM or m l ? x (receive a message z from EFSM ml . The message z, in general, can have several parameters. An abbreviation (ml?z + ma?y) will be used to represent either ml?z or m z ? y . Similarly, the abbreviation (ml !z * m z ! y ) will be used to represent m l ! z followed by m a ! y .

mll

[Lt=Lr;nop=Ht-Lt;update T-array; if (buffulflan==l)

3. An update is represented by [U] where U can be thought of as a simple program segment which updates context variables. The update may depend on conditions. Thus, U may have conditional statements as well as assignment statements.

) I
Recv-ret s e q

3.1

Protocol for Wireless Transmitter and Base Receiver

The wireless transmitter W T is a single EFSM (Figure 2). Notations used in Figure 2 are explained in Table 1. W T maintains an array T a r r a y in which each entry is a record with three fields: abit, clock and ebit. An entry T-urray[i].abit is 1 or 0 depending on whether packet i has been acknowledged or not. Similarly, an entry T a r r a y [ i ].clock contains the local clock time when packet i was last (re)transmitted. T-array[i].ebit = 1 or 0 depending on whether packet i indicates an early end of a block or not. W T maintains a context variable nop (number of outstanding packets) which is the difference between the highest numbered packet transmitted (Ht) and the lowest numbered packet acknowledged ( L t ). Maxbuf is a constant representing the maximum size of buffer at W T . We also assume that W T sends an indication when it has no more packets to send. The indication which depends on the implementation may be in the form of a bit or in the form of a special packet. Here we assume that the indication is in the form of a bit which we call ebit. ebit is also set to 1 in a packet if that is the last packet in a window. Otherwise it is 0. The EFSM of the base receiver BR (Figure 4) communicates with the Status Timer (ST), which is also modeled using an EFSM (Figure 3). Notations used in Figure 4 are explained in Table 2. We assume that BR maintains an array R a r r a y such that an entry R a r r a y [ i ] is 1 or 0 depending on whether packet i has been received or not. BR maintains two pointers L, and H,. L , points to the lower end of the window. That is, all packets until L, - 1 have been received and L, is the first packet which has not been received. H , points to the higher end of the window indicating the last packet which has been received. Thus if L , = H, 1, then all packets have been received so far. BR sends its status when ST expires. B R sends stat-ack(L,) if L , = H , 1 (that is, it has received all packets so far). B R sends stat-ret(L,, w, B i t m a p ) if

br?stat-ret( Lr,w,BitmapU) -. [Update T-array,Lt,nop; i=O] local-clock $!array[Lr+i].clock) > rtd) AND (Bitmap[i]==O) AND (i < w)} br !pkt(Lr+i,T-array[Lr+i] .ebit) [UDdate T-arrav:++iJ {(i==w) OK. (T-array[Lr+i] .ebit== 1))

Table 1: Explanation of Notation used in EFSM for WT

there is an entry Rarray[i] = 0 for some i between L, and L, w, where w = H, - L, 1. B R maintains a context variable nochng which represents the number of times the status of B R remains unchanged and is incremented if the status of BR does not change since the last time it is sent. The constant MazNochng indicates the maximum number of times the status of BR is allowed to remain the same before disconnection.

Figure 2: Wireless Transmitter

8d.2.4
1056

Explanation I wt?setuD * I wt?pkt(pno,e=O) /:if (newinfo) then 1 update R-array,Lr,Hr;nochng=O] Recv-pkt-el I wt?pkt(pno,e=l) :c st!stop I [if (new-info) then II Lpdate Ra&ay,Lr,Hr;nochng=O] st?timeout [++nochng] Timeout {Lr==Hr+l} wt!etat-ack(Lr) * Send-ack I- ._~ st,!st,art I1 Send-ret-req {Lr < Hr+l) wt!stat_ret(Lr,w,Bitmap[)* st!start {No packet No-pktrecd
I
~

Notation SetuD Recv-pkt-e0

1
I1
Figure 4: Base Receiver respond to the block number and the packet number respectively, are computed from Ht, using the formula H B t = Ht%BlockSize andpno = Ht mod Blocksize. Window is defined as 2*BlockSize. The wireless receiver W R is a single EFSM (Figure 7). Notations used in Figure 7 are explained in Table 4. W R maintains an array Rarray[[ in which an entry Rlzrray[i][j] is 1 or 0 depending on whether packet j of block; i has been received or not. W R also maintains a variable LB, which keeps track of the last block received. Note that the W R sends a status message (which is: a stat-ack or a stat-ret) under four conditions: 1. when the last packet of a block is received. The variable Lpkt, which occurs in label Spontaneousstat of Figure 7, is set to 1 when the last packet of a block is received. The variable Done in Figure 7 is set to 1 if all packets in block LB, are received. Otherwise it is 0.

Nostat-chne: I inochng==MaxNochnn\ wt!quit Table 2: Explanation of Notation used in EFSM for BR

YY
Active

Figure 3: Status Timer

3.2

Protocol for Base ramsmitter and Wireless Receiver

The base transmitter BT is a single EFSM (Figure 5), which communicates with a timer called the Polling Timer (PT). PT is also modeled as an EFSM (Figure 6). Notations used in Figure 5 are explained in Table 3. BT maintains several context variables: (1) Lt (lower end of the window), (2) Ht (higher end of the window), (3) LBi (block number corresponding to &), (4) HBt (block number corresponding to H t ) and (5) natmpt (the number of attempts to obtain a status message from WR). Tlhe constant MaxNatmpt is the maximum number OS times the BT is allowed to poll the WR for a status before disconnection. BT maintains a table Tb-array[i][j whose each entry is a record consisting OS two fie1 s: abit and ebit. An entry Tb-array[i][j].abit is set to 1 when packet j of block i has been acknowledged. Otherwise it is 0. The entry Tb-array[i][j].ebit is set to 1 if packet j is the last packet of block i and the corresponding block is not full. This feature is useful for short queries as opposed to long file transfers. BT transmits a packet in the form pkt(z,HBd,pno, e ) where x=O for a newly transmitted packet and x = l for a retransmitted packet. HBt and pno, which cor-

2. when a pachet is received with block number greater than the previous block number (that is, a packet belonging to a new block is received.).
The variable NewBlock, which occurs in label Spontaneous-stat of Figure 7, is used to indicate the receipt of a new block.

3. when a packet is received with the ebit set to 1 (that is, end of a block is received).
The variable Gotthis, which occurs in labels Send-ret-reg-el-old and Send-ret-reg-el-old of Figure 7, is siet to 1 if all packets in block LB, up to the one with ebit=l are received. Otherwise it is 0.

4. when it receives a poll message from the BT

8d.2.5
1057

Notation SetuD No-pktrecd

I

I bt?setuD

Explanation * bt!setuD-ack {No packet received} bt!setup-ack

Recv-p k t -e0 Recv-pkt-el Send-ack-e0 Send-ack-el Sendset -req-eO

Notation Setup Explanation wr?setuD-ack * u!enable [buffulflag=O] {nop < Window) u?pkt(e=O) [++Ht;++nop;update T-array] wr!pkt( l,HBt,pno,e=O) [if (noD==BlockSizel Dt!startl u?pkt(e=l) [if (nop < Blocksize) pt!start] br!pkt(i=Ht ,e=l) InoD==Windowl ;!d&able [buffucflag=l] wr?stat-ackj LBr) {LBr > LBt} [LBt=LBr;update T-array1

bt?pkt(flag,bno,pno,e=O)
[update R-array] bt?pkt(flag,bno,pno,e=l) [update R-array] bt!stat-ack( LBr) I Got t his== 11 &!stat-ack(LBr) b t !stat s e t (LBr,BlockSize,Bitmapn) {((Gotthis==O) AND (LBr < bno))} bt!statiet (LBr,BlockSize,Bitmapn) { ((Gotthis==Ol AND (LBr==bno))} bt!statset (LBr,pno,Bitmapn)

Sendset-req-el-old

Transmit-e0

Sendset-req-elaew

Transmit3 1 Window-closed Recv-ack

Spont aneous-st at

Table 4: Explanation of Notation used in EFSM for WR

4
41 .

Validation and Implementation of t h e Protocol

Recvset -req ReTransmit [Update T-array,Lt,nop; i=O] {(LBr > LBt) AND (;\< w) AND'(Bitmap[i]==O)} wr!pkt(O ,LBr,i,Tarray[LBr][i].ebit) [Update T-array;++i] i=w) OR &-array[LBr][i] .ebit==l)) pt !start pt?expire*wr !poll* pt!start [++natmpt] {natmpt=MaxNatmpt} wr!quit

Validation

ReTrans-done Trans-poll Quit

The protocol was specified in textual APSL Augmented Protocol Specification Language) [K92 and a validator tool was used to explore the state space of the protocol in a random manner. The reason for random exploration is to avoid the well-known state space explosion. APSL is based on synchronous interaction between the communicating extended finite state machines and each possible interaction is called

Table 3: Explanation of Notation used in EFSM for BT

-&f

Figure 5: Base Transmitter

8d.2.6
1058

BW Smiation

Mobile Terminal

Figure 8: Schematic representation of UNIX Streams implement ation Figure 6: Polling Timer is required. This is the main design of the admin stream. The adniin stream must first open the tty device and configuire this tty port, dial the remote host via a modem, and when connected, log in to establish a session. [t must then pop the ttcompat and Zdterm STREAMS modules that are normally above the tty driver, and activate our protocol driver and link the tty driver under it, as shown in the above diagram. Following the completion of these administration tasks, user applications can start creating logical channels over the serial link. The upper half of the protocol driver accepts user requests that follow the Data Link Provider Interface (DLPI). The DLPI primitives, DLBIND-RE&, DL-UNBIND-RE&, DL-U NITDATA.REQ , and DL-U NITDATA I N D , are currently supported. An application uses the DLBIND-RE& primitive to associate a service access point (SAF') with the endpoint of its logical channel. Once a SAP is bound, it can now use the DL-UNITD14TAAEQ primitive to send data. The DL-UNITDATAAEQ primitive requires a source SAP, indicating the caller's endpoint of the channel, and a destination SAP, that corresponds to the logical channel on the remote host. The source and destination SAPs are lihe the ports in TCP/IP. To support these functions, the upper half of the protocol driver uses theSTREAMS putq() function to place user requests on a queue. The lower half implements a service procedure that uses the getq() function to take a request from these queues and builds a data message for transmission to the remote host if the window is open. As shown in the diagram below, a user message is encapsulated with a header and a frame check sequence (FCS) to form a data frame (Figure
9).
Data frame format - user data field: variable length - all other fields, 1 byte long

Figure 7: Wireless Receiver a rendezvous. The validator is terminated when each possible rendezvous in the protocol specification is exercised.

4.2

A UNIX STREAMS Implementation of the protocol

The implementation of a link layer protocol requires good resource management facilities from the operating system, for example, efficient buffer allocation, high resolution timing service, and responsive scheduling. To have access to these facilities, our protocol is implemented in the kernel as a STREAMS multiplexing driver. As shown in Figure 8, this multiplexing driver interfaces with user applications from the above, and with the tty serial driver from below. Also shown in the diagram is its ability to supporl multiple logical channels over a physical serial link. One of these channels, called an administrative stream, handles modem dialup and disconnection as well as monitors the link status. Being a STREAMS multiplexing (driver, the implementation can be viewed as consisting of an upper half that handles user interface and multiplexing, and a lower half that implements the protocol over the serial link. Functionally, it consist,s of a transmitter (BT, WT) and a receiver (WR, BR) for full duplex
operations.

Figure 9: Format for Data Frame The header contains the type (0x06 for data), the source and destination SAPs, and the sequence number. The frame check sequence (FCS), CRC-16, is computed over the header and the user data. Having encapsulated the user message, the service procedure

For our protocol to work over the tty STREAMS driver, administration of several STREAMS modules

8d.2.7
1059

then frames the entire message with flags, and saves a copy in case retransmission is needed, it then hands it down to the tty driver for transmission to the remote host. When the lower half on the remote host receives a message from the tty driver, it verifies the frame check sequence, and discards it if it is damaged. After updating the window control parameters, it then uses the destination SAP to locate the logical channel in the upper half that should accept this message and sends it upstream to the user application. In addition to data frame, there are also status ack, status retransmission, and status poll frames which are shown below. In all frames, the first byte is used to identify the type of the frame. As indicated in the diagram, the actual length of a frame is dependent on the type of the frame. We use one byte each for the type, the source and destination SAPS, and the sequence number. So for the most frequent frame, the data frame, the size of the header is four bytes. The size of a status ack frame is four bytes but that of the status retransmission frame is dependent on the size of the bitmap. The size of a status poll frame is only three bytes because sequence number is not needed (Figure 10).

Adding Forward Error Correction to the Basic Protocol

Status Ack: flag 0x03 DSAP SSAP Seq Status Retransmission: flag 0x041 DSAI SSAPI : . , :
no.

FCS flag

1 1
map size

bit map FCS

flag

flag Ox05DSAP SSAP FCS flag

Figure 10: Format for Status Frames Based on our preliminary measurements, a window size of 8 and message size of 128 appear to yield good performance. This means a minimum sequence number space of 16. On the base station, two status timers are used, one for BR to periodically report status to W T , and the other for BT to send status-poll to W R to request a status report. These timers are implemented using kernel functions, timeout and untimeout; and the resolution is 10 ms on SunOS/Sparc 10. This version is implemented on SunOS 4.1.3 as a loadable kernel module. It is currently operational and more testing and fine tuning are in progress. The details of the design and its performance will be described in a forthcoming document.

The cellular channel has a high error rate because of several factors like propagation loss, multipath interference, etc. Thus a simple ARQ (Automatic Repeat Request) procedure for retransmitting lost/corrupted data packets may not be very efficient. Our protocol uses a combination of adaptive Forward Error Correction (FEC) and retransmission mechanism. We propose three levels of forward error correction: bit-levell byte-level and packet-level in [APLSG95]. Bit-level FEC addresses physical level reliability. At the bytelevel, CRC (cyclic redundancy check) is replaced with more powerful Reed-Solomon codes that can perform error correction in addition to error detection. At the packet-level, erasure coding and decoding are performed using diversity codes which are more efficient than Reed-Solomon codes [AIGM93]. The addition of each forward error correction level provides increased protection against burst errors. In this paper, we provide a simple example to illustrate how packet-level forward correction fits in the context of a sliding window protocol such as ours. With FEC, the transmitter sends n data packets and m parity (FEC) packets (W = n + m ) to the receiver before the window closes. The m parity packets are computed in such a way that the receiver can reconstruct all the n data packets as long as it receives any n packets. However, if the receiver loses more than m packets, then it will fail to reconstruct the lost packets and it has to request retransmission from the transmit ter . We give a simple example to show how FEC can be used with sliding window in our basic protocol. Consider a wireless transmitter and a base receiver3. Suppose the window size is W = 8 and m = 2 . The transmitter transmits n = 6 data packets (say d o , d l , d 2 , d3, d4 and d5) followed by m = 2 parity packets (say p 0 and p l computed based on the data packets d o , d l , d 2 , d3, d4 and d5). If the receiver receives any 6 of the 8 packets (say packets do, d 2 , d 3 , d 5 , PO and p l ) , it can reconstruct the lost data packets d l and d4. However, if it receives less than 6 packets, recovery is not possible. For example, suppose the receiver receives only 4 packets do, d l , d4 and p l . In that case, it cannot reconstruct data packets d 2 , d 3 and d 5 and hence sends a retransmission request to the transmitter in the form ( L , = 2 , Bitmap = 0010). L, sets the lower end of the window (leftmost bit of the bitmap corresponds to the status of data packet L,) and hence the Bitmap 0010 corresponds to the status of data packets d2,d3,d4 and d5 respectively from left to right. The transmitter moves Lt (lower end of the window at the transmitter) to 2, retransmits data packets d 2 , d 3 and d 5 , transmits new data packets d6 and d7 and computes 2 parity packets PO and pl based on d 2 , d 3 , d 4 , d 5 , d6 and d7 and transmits them following the data packets. Thus the parity packets are computed based on
31t applies equally well to a base transmitter and a wireless receiver.

8d.2.8
1060

the data packets in the current window. The information about which packets have been used in computing the parity packets is available at the receiver (because it is the receiver which sends the bitmap and L,.) and hence, the receiver can use that information to recover lost data packets from the packets it receives a t any instant of time. We skip the details of how the parity packets are constructed at the transmitter and how the lost data packets are recovered at the receiver in this paper. However, the basic ideas are taken from [AIGIM93].

Performance Results

The objective of this section is to justify the claims we made about the key properties of the protocol, namely, conserving bandwidth by preventing redundant retransmissions and conserving power by combining several status messages into one by the wireless receiver even in the absence of timers. We also substantiate our claim of asymmetry by the size of code and the processing time at the base station and at the wireless terminal. First of all, we justify the claim that the transmitters do not make any redundant retransmissioin. This conserves the expensive cellular bamdwidth. Figure 11 shows 3 separate plots corresponding to different packet error rates. The number of status messages on the horizontal axis is varied by changing the timeout interval of the status timer at the base receiver. The plot shows that the number of packets retransmitted by the wireless transmitter is the same irrespective of the number of retransmission requests the slight variations correspond to different number o packets lost in different runs), and that number is emctly equal to the number of lost packets. That is, if we plot the number of lost packets on the same axes, it would overlap completely with the plot for numbeir of retransmitted packets. Thus, even if the base receiver sends its status messages very frequently, the wireless transmitter prevents duplicate retransmission. The same is true for the base transmitter.

off between sending the status more frequently to obtain a better response time, versus the wastage of expensive bandwidth. In this case, the timeout interval of the status timer at the base receiver is altered to send status messages at different frequency to the wireless transmitter. If the status messages are sent too frequently, bandwidth is wasted. However, the response time improves. If the status messages are sent infrequently, bandwidth is preserved but response time suffers. However, the good news is that there is an optimal choice of the timeout interval for the status timer such that the gain in terms of response time is maximum a t the expense of minimum additional bandwidth. From Figure 12, the optimal choice is to send between 1.5 and 2 status messages per round-trip delay to the wireless transmitter .

Figure 12: Trade-off between Bandwidth and Response Time

As expected] the throughput falls with higher packet error rates as shown in Figure 13. However, the normalized throughput of the protocol does not fall below 0.8 even for a packet error rate of 0.1.

10

2~

30

50

60

so

90

Figure 13: Throughput vs. Packet Error Rate We show the effects of asymmetry in the protocol design by providing some figures based on a BSD socket

Nun& dhnr Ms wih RennnigionR m a a l q

Figure 11: No Redundant Retiransmission The next plot (Figure 12) shows tha,t there is a trade

implementation. Table 5 compares the size of compiled code at the base station and at the wireless ter-

84.2.9

1061

WT BR ST

Size of Object File (Bytes) 40960 65536

Table 5: Comparison of the size of compiled code

is transmitting or receiving. The wireless terminal follows a relatively simpler protocol compared to the base station, mainly because it has limited battery power and smaller processing capability. We showed how the protocol conserves bandwidth by preventing redundant retransmission and how the wireless terminal conserves power by combining several status messages into a single comprehensive status message. The use of adaptive forward error correction with retransmission is particularly suitable for error prone wireless links and we showed how forward error correction can be added to our basic protocol.

References
[AIGM93] E. Ayanoglu, C.-L. I, R. D. Gitlin, and J . E. Mazo, Diversity Coding for Self-Healing and Fault-Tolerant Communication Networks, IEEE Transactions on Communications, Vol. COM-41, pp. 1677-1686, November 1993. [APLSG95] E. Ayanoglu, S. Paul, T.F. La Porta, K.K. Sabnani and R.D. Gitlin, AIRMAIL: A Link-Layer Protocol for Wireless Networks, to appear in Wireless Networks, Vol. 1,No.1. ~871 P.T. Brady, Performance Evaluation of multireject, selective repeat, and other protocol enhancements, IEEE Transactions on Communications, vol. COM-35, no. 6, pp. 659-666, June 1987.

Table 6: Comparison of the processing time for W T and BR minal. It shows that the total size of code at the wireless terminal is two-thirds the size of the code at the base station. Table 6 shows the average processing time for the wireless transmitter and the base receiver for transferring a file of size 204 KBytes at a packet error rate of 0.33 and status timer timeout interval equal to half the round trip delay, It shows that the average processing time for the wireless transmitter is one-third of that of the base receiver. The difference between the two reduces with decrease in error rate. Table 7 shows the average processing time for the base transmitter and the wireless receiver for transferring a file of size 204 KBytes at a packet error rate of 0.01 and poll timer timeout interval equal to twice the round trip delay. It shows that the average processing time for the wireless receiver is two-thirds of that of the base transmitter. The difference between the two increases with increase in error rate.

[CI94]

R. Caceres and L. Iftode, Improving the Performance of Reliable Transport Protocols in Mobile Computing Environments, to appear in JSAC, special issue in Mobile Computing Networks.
D. D. Clark, M. L. Lambert and L. Zhang, NETBLT: A bulk data transfer protocol, Proceedings ACM SIGCOMM 87 Symposium, Vol. 17, No. 5, 1987. A. DeSimone, M.C. Chuah and O.C. Yue, Throughput Performance of TransportLayer Protocols over Wireless LANs, Proceedings of Globecom 93, pp.542-549. D.M. Kristol, APSL Toolkit Handbook, AT&T Bell Laboratories.

[C L 2871

Conclusion

[DCY93]

This paper presents the design, validation, implementation and performance of a novel protocol for a wireless link. The protocol is asymmetric in the sense that the intelligence in terms of making decisions is always at the base station, irrespective of whether it Window Size
L

~921 [NED931

S. Nanda, R. Ejzak and B.T. Doshi, A

Retransmission Scheme for Circuit-Mode Data on Wireless Links, to appear in JSAC, special issue in Mobile Computing Networks.

BT Processing
Time (seconds) 0.23 0.24 0.26 0.36

WR Processing
Time (seconds) 0.14 0.16 0.16 0.23

4 8
16 32

[N RS901

Table 7: Comparison of the processing time for BT and W R

A. N. Netravali, W. D. Roome and K. K. Sabnani, Design and Implementation of a High Speed Transport Protocol, IEEE Transactions on Communications, Vo1.38, Number 11, November 1990.

8d.2.10
1062