CPSC 689: Discrete Algorithms for Mobile and Wireless Systems Spring 2009 Prof. Jennifer Welch

CPSC 689: Discrete Algorithms for Mobile and Wireless Systems

Spring 2009

Prof. Jennifer Welch

Discrete Algs for Mobile Wireless Sys 2

Lecture 3 Topics:

MAC Protocols part 2 Sources:

Schiller, Ch 1-3 Balakrishnan, Ch 11 Vaidya, Ch 1-2, 4-5 MIT 6.885 Fall 2008 slides


Reservation-Based Strategy Used in MACA and MACAW. For unicast transmission only. Assumes data to be sent can be fairly long. Introduces control messages, which are short, so less likely to

collide. Each data transmission is preceded by a control message

handshake to reserve the channel for a period of time.

Messages: RTS (Request To Send), CTS (Clear to Send), Data Sender A sends RTS.

Contains name of sender A and receiver B, and length of data to be sent (amount of time the data transmission will take).

Receiver B responds with CTS. Contains same info.

If sender A gets CTS, sends the actual data.


Reservation-Based Strategy (cont’d)

RTS / CTS / Data protocol can be interrupted: If sender A hears another CTS with a planned transmission interval

that would overlap its proposed interval, then A doesn’t transmit. Because some receiver C in A’s range has already OK’d another

transmission, say from D. So A’s transmission might collide at C with D’s transmission, ruining

D’s transmission.

A C Drequests tosend to C

clears Cto send

A waits tonot spoilD's msgat C


Reservation-Based Strategy (cont’d)

RTS / CTS / Data protocol can be interrupted: If receiver B hears another RTS, intended for another receiver C,

with a planned transmission interval that overlaps the one proposed by A, then B doesn’t respond with the CTS.

Because the two transmissions might collide at B.

Reservation approach does not use carrier-sensing---just explicit messages.

A B Drequests tosend to C

requests tosend to B

doesn'tsend CTS

C


Hidden Terminal Problem

RTS / CTS / Data protocol solves the hidden terminal problem, assuming conditions don't change after the reservation. A requests to send to B with RTS B sends CTS, which is heard by A and C C will not send to B during A's transmission

A B C


Exposed Terminal Problem Handles exposed terminal problem somewhat:

Suppose that B sets up transmission to A first. Sender C sends RTS to D. D hasn’t heard the RTS from B to A (not in range), so D can respond

to C with CTS. Then C can transmit to D, knowing that D shouldn’t be receiving any

other transmission. However:

D sends the CTS to C But it seems likely that C won’t hear it, because of interference from

B’s transmission. ?

A B C D


Acks and Reservations If the data transmission is followed by link-layer

Acks, then we must be sure that Acks succeed also, not just the Data packets. Because if Ack is lost, Data must be retransmitted.

So, expand the proposed reserved transmission time to include enough time for the Ack too.

Essentially, an RTS / CTS / Data / Ack protocol. Since this involves communication in both directions

(sender to receiver and receiver to sender), we should treat the link symmetrically.

Simplest version: Let each sender or receiver defer if it hears either an overlapping RTS or CTS.


Evaluation

RTS / CTS / Data and RTS / CTS / Data / Ack protocols reduce likelihood of collision: Now collisions can occur only during the

handshake. Probability of collision is lower, since control

messages are short. Ex: Suppose A and C send RTS at the

same time for the same receiver B. B might not receive either. B might receive one, respond with CTS. B might receive both, could respond with CTS to one of

them.


Evaluation

Overhead: High, if data packets are short or collisions are

infrequent. May be acceptable if data packets are long and

collisions frequent. Assumes symmetrical transmission/reception

conditions. Good only for unicast. RTS / CTS strategy sometimes called “Virtual

Carrier Sensing”, since it provides an implicit way to tell if the channel is busy.


Use of Time in Reservation Protocol

The descriptions are in terms of “time”, so it sounds like the nodes should be using (approximately) synchronized clocks.

But it seems that this could be implemented with un-synchronized local clocks.

The reservation period is short, and everyone could keep track of proposed intervals in a relative way, in terms of their own clocks.

Details?


Reducing Collision Probability p-persistence:

At each “valid” transmission opportunity (when sensing mechanisms don’t detect any activity on the channel), allow a node to transmit a packet only with probability p.

How to choose p? Too small: Wasted slots, hurts throughput. Too large: High chance of collision. Ideal would be p = 1/n, where n is the number of nodes that would like

to transmit. However, the devices don’t know n. E.g., could estimate it as some multiple of the number of known

neighbors. Again, slots must be synchronized; with clock skew, the slots must

be correspondingly larger.


p-Persistence p-persistence is memoryless:

Probability a node transmits in a slot doesn’t depend on time since it last attempted to transmit.

An arbitrary number of slots could pass without some particular node being able to transmit.

Unfair! Might consider letting unsuccessful nodes increase their p. Next strategy adds some memory, for better fairness.


Backoff Interval Strategy Ensures that a node attempts to transmit after a bounded

number of valid transmission opportunities (when channel appears to be free).

Node wanting to transmit sets a counter to a number b, and transmits at the bth valid opportunity.

Thus, never lets more than b valid opportunities pass before trying to transmit.

How to choose b? Too large: Wastes slots Too small: High chance of collision Ideal: n, number of contenders, but hard to estimate this. Choose b uniformly at random in an appropriate range [0,bmax]. Randomness avoids synchronized retries and the resulting repeated

collisions.


Backoff Interval Strategy To transmit:

Pick a number in [0,bmax], uniformly at random. Use this to initialize a counter b. Try periodically to sense; each time:

Decrement the counter if the channel appears free. Leave the counter alone if the channel appears busy.

When b = 0, transmit the data.

Can do this without synchronized clocks.


Responding to Packet Loss Assume we are using the backoff interval

strategy above, plus link-level Acks to tell if transmission succeeds.

If a node A transmits and no Ack arrives, A must retransmit.

The failure is evidence that there is too much contention, so instead of using the same bmax to choose b, increase bmax.

When transmission succeeds, reset bmax to a small number bmin.


Responding to Packet Loss How to increase bmax? Common strategy: Binary exponential backoff (BEB).

Double bmax. Used in Ethernet, works well there (theoretical results prove

it’s optimal). In wireless setting, may be too pessimistic, since failure

could be caused by noise as well as contention.

Strategy is somewhat unfair: A device that is unsuccessful keeps increasing its bmax,

which gives it fewer and fewer chances. Tends to allow devices who are transmitting successfully to

keep transmitting successfully, and to lock out unsuccessful devices.


Combining Backoff with RTS/CTS

Use backoff to tell a node when to start an entire RTS / CTS / Data dialog, not just when to transmit actual data.

Use backoff only for initial entry to the dialog, i.e., for sending the RTS; thereafter, just keep going as before.

Of course, look out for collisions. If dialog is interrupted, increase bmax and start

the entire dialog again.


Eliminating collisions? In many wireless networks, no one starts out knowing what

devices are participating. In an ad hoc network, we can reduce collisions to short

intervals---time to exchange RTS/CTS control packets. In a cellular network, a base station can schedule data

transmission. But there is still a very small probability that a device will be

blocked from announcing its presence to the base station. It seems that, no matter what we do, there remains some

possibility of collisions; all we can do is reduce the probability.

Q: Prove a theorem?


Comparison Carrier-Sense Multiple Access (CSMA) strategies, with Collision

Avoidance (backoff), can work well when contention level is low. Little overhead, low likelihood of colliding.

Reservation-based protocols work well when contention level is high.

But they work only for unicast.

Neither is completely adequate for ad hoc networks---still an active area of research.

Can be combined, as in 802.11.


Specific MAC Protocols

802.11 MACA / MACAW


802.11 Overview IEEE standard for wireless MAC layer. For both cellular systems and ad hoc local networks. Centralized Point Coordination Function (PCF)

Needs an AP (Access Point = base station) to coordinate. Both asynchronous and time-bounded service. Time-bounded service is good for supporting voice/video. AP uses a centralized polling protocol, polling all the devices it is

servicing to see if they have something to send. Distributed Coordination Function (DCF)

Works for both cellular and ad hoc settings. Just asynchronous service (no time bound guarantees). Uses CSMA/CA (with backoff), plus RTS/CTS reservations. RTS/CTS often turned off, because of overhead.


802.11 Time Synchronization

Cellular systems: Access Point transmits Beacon Frames

periodically, containing the value of the AP’s clock at the time of transmission; receiving stations reset their clocks accordingly.

Beacon Frames should be sent at particular “target beacon transmission times”.

Doesn't always succeed, because of congestion-induced delays.

AP does its best.


802.11 Time Synchronization

Ad hoc systems: All devices try to send beacons at target times. Most of the time, one of the broadcasts wins over

the others (because of characteristics of the broadcast medium).

Everyone sets their clocks according to the received beacon.

Sometimes no beacon will succeed at some target time. Then beacon for that time is lost; algorithm recovers at

the next target time.


802.11 Time Synchronization Ad hoc solution is not completely satisfactory:

Can lead to discrepancies in large network, even between nearby neighbors.

Still a research topic.

Basic 802.11 contention management doesn’t require time synchronization.

Balakrishnan’s notes assume slots, but that is for performance: recall that collisions are less likely when transmissions occur on synchronized slot boundaries (throughput is twice as great).


802.11 Protocol Physical carrier sensing:

Compares level of energy on the channel with usual noise level.

No “busy-tones”, just basic carrier sensing. Link-layer Acks:

Uses absence of Acks as a way of detecting collisions. Reservations (optional)

RTS / CTS / Data / Ack Reduces collisions due to hidden terminals, by reducing

window of vulnerability to short RTS/CTS handshake interval. Overhead:

Reservations consume channel resources. Often turned off because of overhead. But may be worth it, if data is very large.


802.11 CSMA/CA Main strategy used in 802.11 DCF. Slots (but need not be synchronized). Slot size = large enough to complete message transmission (e.g.,

sum of carrier-sensing delay, propagation delay, transmit/receive delay,…).

Each node maintains CW, the contention window size (like b earlier), initially CWmin (bmin).

To transmit: Pick a random number in [0,CW], to initialize a local “delay” timer. Sense at the beginning of each slot, decrementing the delay timer

each time the channel appears idle. When delay = 0, transmit data.

If transmission seems to fail, double CW and try again (but just a bounded number of times, not forever).


802.11 CSMA/CA How does the sender decide that the transmission has

failed? For unicast, uses link-layer Acks.

If no Ack received in a reasonable time,… For broadcast ??? Old method: just guess based on physical carrier

sensing. If channel is busy too many times while counting down delay

timer,… Not reliable. No good solution yet.


802.11 CSMA/CA

To handle hidden or exposed terminals: For unicast, can replace transmission of

data with entire RTS/CTS/Data/Ack exchange.

For broadcast ??? Can rely on characteristics of the medium:

If the carrier-sense range is >> the reception range, then no hidden terminals will occur.


802.11 Pseudocodesucceeded := falseCWmax := CWminwhile not succeeded do

CW := choose uniform[0,…CWmax]while CW ≠ 0 do

while channel busy do no-opCW := CW -1

transmitif successful then succeeded := trueelse CWmax := 2 CWmax

Notes: Do the main loop bounded number of times.transmit is Data/Ack or RTS/CTS/Data/Acksuccessful test based on Acks, or physical carrier sensing


802.11 for ad hoc networks Not completely satisfactory. Success test not adequate.

RTS/CTS strategy good only for unicast. Broadcast? Who should respond?

Not clear whether the backoff strategy is optimal. Time synchronization strategy messy, not clear

how well it works. Needs work!


MACAW Overview

[Bharghavan, Demers, Shenker, Zhang, 1994] MAC protocol for a single channel wireless LAN

developed at Xerox PARC Based on earlier MACA strategy:

RTS / CTS / Data Binary exponential backoff

Elaborates on the reservation strategy Modifies the backoff strategy


MACAW Reservation Strategy

In original RTS / CTS / Data / Ack strategy, nodes defer when they hear RTS or CTS with overlapping interval.

Add a Data Sending (DS) packet from sender to receiver. RTS / CTS / DS / Data / Ack DS means CTS has arrived and data transmission is about to occur.

Helps with exposed terminals: If C hears RTS from B to A, then C should defer to avoid:

Having its data transmission collide (at B) with B’s receipt of an Ack from A.

Having the CTS from D collide (at C) with B’s data transmission. But these are important only if B actually receives the CTS

from A. DS message confirms this; C defers only if it hears DS (or

CTS).


Exposed Terminal Scenario

B sends RTS for A, heard by C also

A sends CTS for B B sends data for A A sends ACK for B

A B C D

C should not interfere with B's receipt of CTS and ACK from A

So C defers for a long time

But what if A does not send to B?


Exposed Terminal Scenario

B sends RTS for A, heard by C also

A sends CTS for B B sends (short) DS, heard

by C B sends data for A A sends ACK for B

A B C D

If C does not get DS from A in a timely fashion after getting RTS from A, then it assumes transmission didn’t happen, so it need not defer


MACAW Backoff Strategy More gradual adjustments:

Backoff multiplies counter by 1.5 instead of 2 (recognizing that not all failures are due to collisions).

Counter decremented by 1 after success, rather than getting reset to bmin (recognizing the contention is most likely ongoing).

Noted that backoff strategies use too little information---suggest sharing and remembering congestion information.

Authors say that their solutions are good for the unicast case, but recognize that they still don’t have good solutions for the broadcast case.


Remaining Research on MAC Layers

Practical: Better strategies for handling local broadcast,

rather than unicast. Better ways to estimate contention, better backoff

protocols. Managing the overall network for good

throughput (capacity).


Remaining Research on MAC Layer Theoretical:

Physical layer models: Capturing signal propagation, noise, device failure, mobility.

Better backoff protocols, realistic analysis. Prove inherent limitations. Sort out dependence on time synchronization. MAC layer guarantees: What are good abstract models for

what the MAC layer should guarantee to higher layers? High-probability successful local message delivery,

conditioned on some factors about the environment, like amount of contention?

Also export other information, e.g., about amount of contention, or about occurrence of collisions?

Documents

CPSC 689: Discrete Algorithms for Mobile and Wireless Systems Spring 2009 Prof. Jennifer Welch