free network design, part 2: medium access protocols

July 1, 2001

Free Network Design, Part 2: Medium Access Protocols

Paul Campbell (Nombrist Beor)

My Thoughts on building a 100% free network that is scalable to millions of users and resistant to attack by unlawful governments.

In the previous part, the various regulations of the FCC were covered. Following this, the question of whether such a network is feasible or not was answered. Essentially, the answer is “yes”. The requirements are not too tough and the available bandwidth over short distances is not too shabby.

The trouble is that this is not true for long distance links where the only available way to construct the network (other than overlaying commercial ones, doing things illegally, or putting up with some very large lag times) is through fortuitous terrain or living with the bandwidth limitations of tropospheric scatter.

Either way, this splits the problem into two separate areas. On the one hand, the network routing system will have to be designed to deal with almost constantly changing condi-tions. It will have to be adaptable to potentially incompatible networks, similar to the way in which IP packets were adapted to all other existing networks until for all intents and purposes, the “internet” became almost the only available network. This problem (and the problem of dealing with “long distance” links) will be covered in part 4.

The second area is knowing that the radio spectrum is out there, just how can it be used. The current de facto solution is IEEE 802.11, but there are severe problems with this standard because it and most other “state of the art” protocols rely on a fundamental assumption which is incorrect. Because this assumption is untrue, these types of designs suffer from horrible bandwidth sharing problems when the “hidden terminal” situation exists, even though they were specifically designed to eliminate the “hidden terminal” problem!

In this part, the “MAC” or “medium access protocol” is laid out. The goal here is to pro-vide some sort of basic communication mechanism that allows a radio to communicate with other neighbors within an acceptable probability of error. The previous most popu-

1

lar method, statistical multiplexing, looks at first glance to be inefficient relative to other techniques. It works really well in multichannel scenarios (where multiple users transmit simultaneously). The other two techniques (contention protocols and conflict free protocols) essentially create a method of allocating bandwidth on an as-needed basis. With a single channel for communication, contention protocols come very close to within the theoretical efficiency of conflict free protocols. In fact in this case, they are superior in terms of simplicity and because they can trivially handle dynamically chang-ing bandwidth requirements.

In a multichannel scenario, the problem is that it is more difficult to coordinate commu-nications on a packet-by-packet basis since several channels may actually be allocated and used simultaneously. In this case, contention protocols lose their edge over the other two techniques. Contention protocols in fact only work well when a single channel is used for control transmissions and the rest are used for data.

At this point, something interesting happens. The bottleneck is the control channel. A data channel can only be allocated using a contention protocol at the rate that it can be negotiated in the control channel. Since single channel protocols can only achieve about 30-50% bandwidth usage at best for their control traffic, this means that only 30-50% of the data channels can be allocated at best unless the bandwidth of the control channel is significantly wider than the data channels (difficult to do with the FCC’s restrictions on signalling types).

Collision free and statistical multiplexing systems can allocate virtually any amount of the data channels (subject to the limitations of their control overhead which can be arbi-trarily small). At this point, these two protocols degenerate into essentially the same thing.

As already discussed in part 1, multichannel and especially multichannel systems with multiuser receiving capability are superior to single channel systems within the con-straints of the FCC. Straight-out multiuser receivers appear to be computationally very difficult in the general case (random signature patterns). However, using a pattern that is specifically designed to create signal separation solves that problem. In the process, it creates a multichannel system. Then it is a relatively simple matter to map radios onto the multichannel system and the simplest (and arguably most efficient) system is a sta-tistical multiplexing one. The mapping process is carried out using a contention protocol in a single channel, so don’t eliminate any concern for that type of communication just yet.

Although the details have been completely left out, this is the design of the proposed MAC. It divides the spectrum up into several barely overlapping channels (called hop-ping patterns). One channel operates using a contention protocol. This channel is only used for the purpose of allocating the rest of the channels (one per radio) and synchro-nizing the entire system. The rest of the channels are used only for “data” communica-tion (higher level protocols are considered “data” and are “carried” by the underlying MAC).

Once this basic communication system is established, it provides a firm foundation to create the higher level protocols. It establishes communication from one radio to the next. It is up to the higher level protocols to handle the pesky details of flow control,

2 Free Network Design, Part 2: Medium Access Protocols

bandwidth (latency) allocation, and multihop communication. Without the MAC, these protocols are very difficult to construct.

SIGNAL TO NOISE RATIO Any real communication system is going to have errors occasionally. It is usually possi-ble to measure the average error rate (how often an error does happen). As the signal-to-noise ratio goes up (the signal is getting clearer), the error rate goes down. The way to get around errors is simply to have a set maximum error rate. Then if a bad packet is detected, throw it out and retransmit it. Another method is to add a slight amount of redundancy into the transmission so that if one or two bits are bad, the redundant infor-mation corrects these occasional “blips”.

Shannon’s theoretical formula for channel capacity is based on the second idea. A small amount of redundancy is needed to fix 2 or 3 bad bits in a packet. The chance of an error in that type of packet is even smaller. If the data was a continuous stream and not indi-vidual bits, then the errors would be down to fractions of a bit, which would need only a tiny fraction of redundancy. If this pattern were taken to the extreme, then the theoreti-cal capacity of a channel can be calculated if the bandwidth and signal-to-noise ratio are known (and the noise is assumed to be totally random).

Real systems can only get to within 2 or 3 dB of Shannon’s theoretical capacity. Multi-level coding and “turbo codes” invented within the last 10 years are getting very close to Shannon’s theoretical capacity limit, but most of them require a lot of computing horse-power. So in reality, the goal is to choose a signal format, choose an acceptable error rate (assuming retransmitting is going to be used; otherwise, live with occasional fail-ures), and then the required signal-to-noise ratio and bit rate pop out of those decisions. Usually, about 5-10 dB is pretty easy to deal with. By really stretching the limits, NASA gets by on only 2-3 dB from some of their deep space probes. Going in the other direc-tion, “FM radio quality” broadcasts usually need 20-30 dB or more to eliminate all noise. High data rates (such as 56 kbps in a 3 KHz bandwidth such as a telephone modem) also require 30 dB or more.

If multipath is a problem (it makes the signal fade in and out), the easiest way to avoid them is to specify an SNR so high that the signal is always received with the minimum required SNR even during peak fades.

Finally, “multiuser” interference is not true “thermal noise” so the simple calculation of the received power divided by all the interfering signals and thermal noise doesn’t work in reality. So some extra safety margin has to be added to avoid multiuser interference.

REQUIRED SNR To sum up all the above requirements, the various design choices will set the required minimum SNR. Any signal that is larger than the minimum SNR will be received with a known probability.

Below that level, there is a wide range of things that could happen. The signal may or may not be received correctly. An interfering signal could be received instead of the intended one. The signal might be detected but not actually received. Or it might not even be detectable.

Free Network Design, Part 2: Medium Access Protocols 3

The “global noise” assumption will work perfectly well for transmitters that are far enough away that their signals can’t really even be clearly detected. The trouble starts with all the radios that are close enough to detect to some degree. So the first require-ment is to organize all the potential transmitters in some way to gaurantee the minimum SNR at least part of the time.

Deciding who transmits, who receives, how, and when, is a difficult problem with tradio transmission. On the internet, the problem is pretty simple because there are usually only 2 systems involved. At least with multiple user systems such as Ethernet they are all on the same wire and can hear each other clearly and detect when interference occurs. This means that the difficult radio problem (what happens when SNR is lower than the required level?) is very easy to solve.

COLLISION SENSING A large portion of the internet used to be attached using Ethernet. In this system, all of the computers are strung together effectively on a single wire. Any node can transmit a packet at any time and it is received by all the others. If 2 nodes transmit simulta-neously, both packets are lost (nobody can receive either one), but more importantly, both nodes will also simultaneously know that a “collision” occurred. Once the collision is detected, both nodes rescheduling their transmissions to avoid future collisions. Using this system, collisions cause all nodes to spread their transmissions out over time and share the available bandwidth equally.

In radio transceivers, there is a limitation called “dynamic range”. More will be said about it in the final second, but the fundamental problem is that because of dynamic range requirements, it is simply not possible for a transmitter to receive simultaneously. Without this capability, collision sensing is not possible and Ethernet-style networks are not possible.

HIDDEN TERMINALS Worse yet, even if two perfectly innocent transmitters attempt to transmit to transmit to the same receiver at the same time, either one, or neither of the packets may be received. And it is almost as difficult for the receiver to tell when 2 transmitters attempted to com-municate simultaneously as it is to transmit and receive simultaneously. The concept of “collisions” in packet radio just doesn’t work at all.

As if it weren’t bad enough if the playing field was more “level”, it’s not. It is easily possible for 3 radios to be in a straight line, let’s say A, B, and C. Let’s also assume that A and C are out of range of each other, but both can communicate easily with B.

As before, if A and C transmit simultaneously, either one or neither might be received by B. But A & C are not able to detect this fact except via B. If A is sending a long MPEG to B, it is impossible for C to know it without some signal from B and if C does attempt a transmission, it may just garble one of A’s packets. In this case, A & B are still totally unaware that C was actually trying to communicate. In this case, C is known as a “hidden terminal” from A’s point of view.

Compared to collision sensing, the hidden terminal problem causes a real problem. The design of the solution for collision avoidance also affects how the available bandwidth is shared equally. In fact, the geometry of the radios and their packet loads both contrib-ute to the problem of sharing bandwidth. Essentially, certain configurations are just less


“fair” than others and hidden terminals are usually denied fair access to bandwidth as the A-B-C scenario shows.

FAIRNESS Even in the internet, the original routing and TCP protocols suffered from severe fair-ness problems. Both TCP and routing protocols have advanced over time and are getting better. In this case, almost all internet connections are discrete wires. There is no such thing as a “hidden terminal” causing inherent fairness problems. That is a wireless-only problem.

Instead, the algorithms that are designed to control flow rates operate only at the ends of a connection. Depending on how the router and the sending end reacts to congestion, it can tend to overreact and either increase or decrease congestion. Research on conges-tion control and fairness that works with wireless networks has come out of the internet work.

First off, there are several ideas about what “fairness” means vs. throughput. For instance, several algorithms for wireless networks have been designed that provide fair access for each radio. If the typical situation of one radio per user exists, then this appears on the surface to make sense. However, some radios are acting as routers for communication between 2 users that are not in direct contact with each other. Any com-munication through the routing radio will be penalized for it’s activity. Worse yet, the per-radio fairness works as long as all communications are between independent users. If for instance, one radio is acting as a gateway to the regular internet or phone system, or one radio is a big server for a popular database (such as a search engine), all connec-tions to/from it will be limited to the allowed flow rate for a sngle radio.

A different definition is to look at fairness in terms of destinations or sources. This elim-inates some of the fairness problems related to per-radio service as long as the data flows are asymmetrical. For instance, if fairness is based on a per-destination configura-tion, then a server that is a source of a lot of data will be able to broadcast as much data as necessary provided that it can fairly send that data to each destination. This does not work for gateways which may have flows going in both directions, such as users on the other side of the gateway accessing a server in the wireless network.

A better definition of “fairness” should be in terms of flows of data. If the flow of data from each application is considered, then some sneaky applications will open mulitple flows and use them all simultaneously, saturating the network. Instead, a “flow” should be considered all packets that have the same source and destination. This definition works well for unicasting but it fails to capture the concept of “fairness” with multicast-ing. Currently, there are no good solutions in terms of multicasting because the source-destination flow-fairness model does not capture the effects and advantages of merging flows for routing.

Finally, the exact relationship between two different flows contending for the same bandwidth has to be considered. The usual definition has been that flow rates should be as equal as possible subject to the limitations imposed by link capacities. This is called “max-min” fairness. One of the big problems with it is that it is very difficult to identify exactly how the allocation should look. Another more recent definition of fairness is that flow rates are allocated to maximize proportional bandwidth allocation subject to


Understanding the Time-Frequency Continuum

the costs of doing so. This economic model results in “proportional” fairness. Finally, fairness can be set up to maximize the response time of any communication. This is called “minimum delay” fairness. Internet protocols are supposed to be designed to pro-vide max-min fairness. In reality, TCP generally produces a close approximation to pro-portional fairness. So far, only the ABR (available bit rate) service in ATM (asynchronous transfer mode) networks provides true max-min fairness.

Of the three fairness models proposed so far, minimum delay makes sense primarily for real time communication such as voice-only networks. Proportional fairness makes sense for pretty much everyone else. In all cases, it is easy to modify the fairness model and add weights where a flow with a weight of “2” receives twice as much bandwidth allocation as a flow with a weight of “1”.

SUMMARY This quick summary illustrates why a free packet radio system is fundamentally differ-ent from the internet or any sort of LAN. It also illustrates another problem. The internet protocols are often called a protocol “stack”. The actual physical packet transmission/receiving are at the bottom of the stack, followed by packet scheduling, routing, and flow control. Each “layer” in the stack is treated independently from the others. With a radio system, this convenient idea that each layer can be treated separately gets tossed out the window. Each “layer” in a radio system has to be designed with all of the other layers in mind because they all interact. Routing, flow control (bandwidth allocation), and scheduling are all tightly intertwined.

The best that can be done then is to start with material from the first part of this docu-ment along with a quick overview of spread spectrum since the best channels available require it, and then expand outwards towards the network routing protocols.


The title of this section sounds very, very intimidating. It would be really easy here to dive deeply into integral calculus and start talking about orthogonal basis sets, convolu-tion, and such. Tempting as it is, I will assume that most people reading this document haven’t had the joy of suffering through a 4 year mathematics degree called electrical engineering, especially the more esoteric parts like doing Fourier integrals to derive the little table of transformations.

This section does have a point. The point is to explain spread spectrum. Since the most valuable spectrum real estate based on the calculations from the first part of this docu-ment has to be spread spectrum, it is important to understand it. So just bear with me. Reality is just a couple pages away.

Suffice to say that we live in a world of time. Things happen in time. Real signals are measured at a particular time. But, lots of signals are cyclical and the individual mea-surements are not as interesting as the pattern of the cycles. Enter the world of Fourier. The rate that a signal repeats is it’s frequency, in cycles per second, or just Hertz.



It is also possible to add 2 signals together and get a third signal. If both of those two signals are cyclical, then the resulting pattern will also have a cycle. One of the really neat properties is if one of the frequency of one signal is an exact muliple of the other one (2X, 3X, or more the first signal’s frequency), then when they are added, the com-bined signal has a frequency equal to the signal with the lowest frequency.

Or looking at things the other way around, a signal could be torn apart into it’s individ-ual component signals. One very neat set of signals to work with are sine waves. It turns out that sine waves can be added together to reconstruct any other signal. All that is missing is the multiplier on each one. Sine waves that are not needed get a “0”. And the pattern of multipliers is unique; if 3 sine waves add to give a particular signal, you can’t do it any other way, even with a supply of sine waves at an infinite number of frequen-cies.

The fundamental set of wave forms used in this way is called a “basis set”. Sine waves are also not the only possible wave form that can be used this way. There is a type of square-wave looking wave forms called Hadamard waves that do exactly the same thing. Instead of “frequency”, people using Hadamard waves call it “sequency”.

The conversion process to go from “time” to “frequency” and back is called a Fourier transform. A real Fourier transform can use any basis set, but most people think of sine waves when they use the word Fourier simply because the mathematics are easier (although other basis sets like Hadamard are easier for computers to deal with since it ends up being a series of digital signals).

Sine waves and Hadmard waves a treated as if they stretch out infinitely in time. The basis set can also use waves that have a finite length in time. One popular group of wave forms are called “wavelets”. Digital versions are “Walsh” and “Haar” waveforms (con-sisting of just +1 and -1 signal levels). The analog ones are very complicated looking waves.

The “infinite time” problem is important because real signals don’t actually last forever. “Finite” signals always cause an infinite number of sine waves to appear. Usually, the first few sine waves match the signal shape and the rest of them are just there to progres-sively cancel out ripples. The ripples only exist because of the “infinite time” assump-tion in sine wave basis sets.

There are a couple consequences to consider here. First, as a signal changes faster in time, it requires more high frequency sine waves to match it. Faster signals inherently require more “bandwidth” in terms of frequency.

Second, if two signals are multiplied together, the result will be a “convolution” in fre-quency. At least for sine waves, the effect is pretty easy to understand from this relation:

So multiplying 2 sine waves of different frequencies together results in 2 new sine waves, one with the difference of their frequencies (A-B) and the other with their sums

Asin Bsin⋅ 12--- A B–( )cos 1

2--- A B+( )cos–=


An Unjaded Look at “Spread Spectrum”

(A+B). The consequence is that when one signal has a very high frequency (the carrier or fundamental frequency), then when it is multiplied with another signal (the data sig-nal), then the data signal is spread out along either side of the high (carrier) frequency.

Without going through the exercise, if the signal is multiplied again by the same high frequency signal, the result is a copy of the original low frequency (data) signal and a much higher frequency copy that can easily be filtered out any removed. There are some tricky phase shifting things going on (since sines are turning into cosines), but part 3 will get into that in more detail.


These are some of the claims about spread spectrum:

• Practically unlimited bandwidth.• Minimal or no interference from other users.• Immunity from eavesdropping.• Almost unlimited spectrum sharing.• Multipath resistant.• Low power.

Of these points, the first one is obviously false. The idea there is that if your signals have lower signal power than the thermal noise in everyone’s receivers, then you could potentially use all the spectrum you want without anyone else even being aware of your presence. Nice try but so far the FCC won’t budge on the absolute power limits in the general requirements section. If they ever set power limits based on spectrum usage, it will be another story.

The second point is partly true. Traditional narrowband systems confine their transmis-sions to a set channel or frequency. Spread spectrum systems spread their signal around an entire band in a semi-random way. Instead of having a definite line where there is clearly either interference or not, the line gets fuzzy because spread spectrum systems cause random (and controlled) amounts of interference to other users in the same chan-nels.

The third point relies on the idea that Bubba Six-Pack’s nine million channel scanner is not designed to detect and receive spread spectrum signals. If spectrum spreading is done to an extreme level, it is easy to make the signal very difficult to detect acciden-tally. But even if you simply suspect that the signal is there, it is trivial for the FCC and military equipment to find, detect, and decode spread spectrum transmissions that are not specifically designed to evade detection.

The fourth point is tied in with the second. The idea is that since everything is more or less randomized, two spread spectrum systems will look essentially like noise to each other so they can more or less co-exist while contributing only small amounts of noise to each other. This last one is definitely very untrue. About once a month, the 2.4 GHz



cordless phone in my house gets jammed by someone else in the same area with a simi-lar phone even though we probably have very different spreading patterns.

TIME HOPPING A very easy way to achieve spectrum “spreading” is called time hopping. The idea is that the transmitter uses very strong pulses of signal to send data. The pulses are short enough that they will cover the entire band when they are broadcast.

The easiest system to construct is this: the pattern of when the pulses are transmitted is determined by a random number generator. Say for instance that pulses are transmitted once every second for 1 millisecond. Just pick a number from 0 to 999. When that milli-second on a timer happens, transmit a pulse if the data bit is a one and don’t transmit if it is a zero.

The receiver needs some kind of synchronization system (all spread spectrum systems need this) and an identical random number generator. One way to synchronize is start receiving for a little while and see if the received signal is anything but jibberish. If it is jibberish, then stop the receiver’s timer for 1 millisecond and try again. Keep pausing until the receiver and transmitter clocks are aligned. This type of synchronization is called a “sliding correlator”. It is slow but very simple.

CHIRP Chirp systems rely on “chirp” signals. A “chirp” is a type of signal used in radar where the transmitter sends a pulse that starts out with a frequency at the bottom of the band. The signal rises at a steady rate, then cuts off when it hits the top of the band. The signal is spread out completely across the band in time. A receiver just has to look for “chirps”. The transmitter is actually very easy to build but the receiver is complicated, especially if the chirps are very short for high data rates.

FREQUENCY HOPPING In this case, the transmitter is more conventional. The only radical difference is that the transmitter constantly changes channels according to a random number generator. Fre-quency hopping systems are called “slow hop” if one or more bits is sent in a channel before jumping to the next one (or even a whole packet), or “fast hop” if individual bits are chopped up and sent on multiple channels.

DIRECT SEQUENCE This is potentially the most difficult spread spectrum system to understand. Essentially, the data signal is multiplied together with a “pseudo-random noise” generator. The gen-erator is usually just a random bit generator, just like the random number generator used for time and frequency hopping. The generator’s output looks like noise and multiplying the data signal with it does a convolution so that the output signal looks like noise, too.

The receiver just synchronizes an identical copy of the pseudo-random noise generator and multiplies the received signal with it. The signal gets converted back into a data sig-nal that a conventional receiver can handle.

PSEUDO-RANDOM NOISE Except for chirp systems, each of the spread spectrum systems relies on a random num-ber generator to produce a “spreading” pattern. Most books on spread spectrum then go on for several pages on what “good” codes should look like.



One key point is that the spreading code increases the bandwidth that a signal appears to cover by a certain amount called the spreading gain. This is most obvious with direct sequence systems. A signal may actually be 1 MHz but after multiplying each real bit with 10 random ones, it makes the signal appear to be 10 MHz of random noise.

Pseudo-random number sequences have a repeat rate. It is possible to design several dif-ferent sequences that have the same repeat rate but use different sequences. For instance, all 24 GPS satellites use the same length code but each satellite’s code is dif-ferent. These codes correspond approximately to the idea of a channel in conventional radios.

In reality, the channels are not totally separated. There is a certain amount of overlap between 2 different random number sequences. In the best case, the difference is

where L is the length of the sequence. Even with 1000 bit codes (and only using 0.1% of the band), the cross correlation is -13.5 dB. This means that using pseudo-random numbers to provide separate channels on 1000 bit codes only reduces the interfering signals by about a factor of 20. This is a substantial number but real spread spectrum systems rarely get over 10-50 bits (IEEE 802.11 is 11 bits) so the “min-imal interference” and “unlimited spectrum sharing” ideas don’t work in practice. It helps but it doesn’t eliminate the problem.

MULTIPATH AND SPREAD SPECTRUM

One of the ideas about spread spectrum is that because it potentially uses many different frequencies, it should be resistant to or totally eliminate the effects of multipath because only parts of the bandwidth are affected at any one time. Unfortunately, multipath is influenced by wavelength. In order to get any kind of substantial relief, a significantly large spread of wavelengths would be necessary. Even in the 915 MHz band (where wavelengths are a ways apart), the wavelength difference across the entire band is a mere 2.8%.

LOW POWER Sometimes people see the “spreading gain” term and forget that the signal strength has not changed at all. A little sugar coating on the transmitted signal has been done, but that’s about all. The real signal power is not lowered or increased at all except relative to the amount of the signal that a narrowband receiver would pick up.

DIRECT SEQUENCE VS. FREQUENCY HOPPING

Even among spread spectrum “wizards”, the wars over direct sequence and frequency hopping methods of spectrum spreading sound suspicously like a certain beer commer-cial’s “tastes great” vs. “less filling”. One of the fundamental problems is a little annoy-ing problem called “near-far”.

Remember the little bit about multiuser vs. single user receivers? Now, combine that with the fact that cross-correlation (how much channel isolation actually exists) and you’ve got a recipe for disaster. Direct sequence systems simply don’t have any real capability of using multiple channels. The problem of being able to actually filter out interfering signals on different codes is called the “near-far” problem.

With frequency hopping systems, the “near-far” problem is already much better because usually the cross-correlation is better since there is a choice of several channels. But there is another way. All the transmitters can use the same hopping pattern. But if they

2( ) L( )⁄


Scheduling Transmissions

are timed so that each one is on a different channel (corresponding to a different number in the entire pseudo-random sequence), they won’t interfere and the system can effec-tively use the entire spectrum.

Direct sequence radios could theoretically do the same multichannel trick by offsetting the same random code. The synchronization requirements are very difficult and radios have to calculate distances between radios and how the signals will interact in “space” since one “bit” even in IEEE 802.11 is only 30 meters (about 100 feet) of distance in terms of space.

The downside of frequency hopping is that for some strange reason, the FCC decided to saddle it with a really obnoxious channel allocation rule that permanently limits fre-quency hopping to have less raw bandwidth than direct sequence (about 10-20% as much). The difference is made up somewhat with higher SNR, but Shannon’s capacity rule says that given a choice between signal strength and bandwidth, bandwidth rules every time. Looking at the chart, frequency hopping is penalized with about 1/4 the bandwidth per link of the direct sequence systems.

So when comparing the two systems, frequency hopping is limited to 1/4 of the band-width on each link compared to a direct sequence system. On a total available “system bandwidth” point of view, frequency hopping wins not only because of the calculations on the chart, but also because it is not currently feasible to make multichannel direct sequence systems that have comparable performance to their direct sequence counter-parts. Different spreading codes can still be used with direct sequence, but they do not enjoy true full isolation of different channels like a frequency hopper. If a single channel scheduling system is used instead of a multichannel one, then direct sequence systems will provide more “system” bandwidth. The question is whether a highly efficient multi-channel scheduling system can fully utilize the extra bandwidth compared to the single channel approach.

Scheduling Transmissions

When a packet is transmitted, there are 7 possible outcomes at the receiver:

1. Two transmitters are active simultaneously. Because of capture (the “good” near-far case), the transmitted packet from one transmitter is received but not from the other.

2. Two transmitters are active simultaneously. Because of interference, both packets are lost. It is usually possible for the receiver to detect that something was sent (with the appropriate extra hardware such as carrier sensing) but not to receive any packet.

3. The receiver was actually transmitting and since dynamic range makes it impossible to receive while transmitting, the packet was not received or detected.

4. The receiver was actually on another channel/code and didn’t hear the packet at all.5. The receiver is turned off (intentionally or not), crashes, etc...the receiver has failed.6. The receiver was working, but noise prevented reception.7. The packet is received successfully.


Statistical multiplexing

With only 2 radios or by maintaining a central base station or setting up round-robins, etc., only the last 3 scenarios can occur. Otherwise with more than 2 radios, the entire range of 7 scenarios can occur when a packet is transmitted. The only way to avoid these problems is through some sort of communication scheduling. There are basically 3 approaches to the problem: statistical multiplexing, contention protocols, and “conflict free” scheduling. These approaches run the extremes in terms of what kind of coordina-tion occurs between radios, from essentially no coordination to full coordination.

Statistical multiplexing

This technique is one of the simplest because it requires very little effort for each trans-mitter to schedule a transmission. Each radio has a random pattern of transmissions. The transmission pattern is designed so that on average, some percentage of those transmis-sions will happen when all other radios are silent. If the radios were fully scheduled (the other extreme of coordination), then all transmissions would happen without interfer-ence.

This idea has resurfaced every few years. Quite often the authors seem to think that the idea is original. The first version of it that I have found was published by Cohen, Heller, and Viterbi (yes, the famous one) in 1971. In their case, they didn’t get worked up about packets and frames and things like that. Their system was based essentially on time hop-ping where a burst of signal was sent every so often. If interference happened, it always resulted in a “0” (absence of signal) being mistaken for a “1”.

They calculated that in their system, the maximum theoretical capacity of a statistical multiplexing system is ln(2)/M where M is the number of users. They mixed their trans-mission system with error correcting codes and it was pretty obvious that the trends on their lines with greater amounts of coding were tending towards a capacity of ln(2)/M. This happens for an asynchronous system.

Extending the same idea to whole packets, the idea is to have each user transmit a packet randomly based on a timer and a pseudo-random number sequence and give each user a slightly different sequence. The timer controls how many attempts are made in a span of time...which limits how many users the system can support. This is the more popular approach.

A third approach uses frequency hopping. A “one-coincident” code is a group of codes that work with P channels. P has to be a prime number. There are P-1 codes, and the codes are of length P. Each code is a sequence of numbers. The codes have perfect auto-correlation (shifted versions of the same code coincide only in one place). Also, any 2 codes only coincide in one place, regardless of shifting (timing offsets). This puts an absolute gaurantee on the amount of interference that any one code can receive from other codes.

From graph coloring theory, if each radio is allowed to have at most d neighbors and the codes/channels of those neighbors must not be the same (so that the radio can distin-guish one neighbor from another without interference), the number of channels (codes)


Contention Protocols

necessary is d(d-1)+1. In a frequency hopping statistical multiplexing scheme using one-coincident codes, then, a radio will only receive interference from d neighbors, but d(d-1)+1 codes are needed and d(d-1)+2 channels are needed.

For example, suppose that the maximum number of neighbors is set at 8. Then 8(8-1)+1=57 one-coincident codes are needed, or 58 channels. Since 58 is not prime, the next largest prime must be used (59). A radio will only receive interference to any par-ticular neighbor’s transmission in 8 of the 59 channels that are in use, or double that number of radios are not synchronized (worst case). Error correcting codes need at least twice as many bits there are errors to correct any errors that happen, so 32 error correc-tion bits would be necessary (assuming 1 bit per frequency/channel). At 59 total chan-nels/frequencies, this equates to a transmission rate of (59-32)/59=46%, worst case. If the transmissions can be synchronized (so that only 8 hits are taken at maximum), then the efficiency increases to 43/59=73% of the individual channels used, and effectively all of the channels are being used (maximum transmission density assuming continuous transmission). At these relatively low error rates, a multiuser receiver can easily be con-structed because it only has to receive and decode the traffic on each channel. The error correction code eliminates all interference in a separate step.


In a contention protocol, packets are still sent somewhat randomly. The difference is that the receiver sends some kind of feedback (packet received/not received/no response). The word “contention” shows up because all protocols of this type “test the water”. The transmitters use the receiver feedback in some way to schedule their trans-missions to raise the odds of successfully getting packets through. The feedback must come from the receiver since the transmitter has no way of knowing whether the packet was received successfully.

This is an improvement over statistical multiplexing schemes because they can’t fully utilize the bandwidth because they can’t measure how much is being used. Contention protocols are fundamentally simpler than full scheduling protocols because the distrib-uted database of transmission scheduling isn’t necessary. There are claims that full scheduling systems react slower to changes than statistical multiplexing but most real full scheduling protocols have some contention-related functions that use the “unsched-uled” slots.

Almost all recent contention protocols use the “mini-packet” approach. The basic idea is that the length of a data packet is much larger than the smallest sized packet that can be transmitted. Instead, mini-packets are transmitted. Since the packets are smaller than full data packets, this limits the amount of bandwidth wasted on failed transmissions from interference. Usually, the two main types of mini-packets are called RTS for “request to send” and CTS for “clear to send”. The exchange of mini-packets creates an artificial “collision detection” mechanism that lets conventional “Ethernet” type proto-cols work.



Once a successful exchange has happened, any packets pinned on after that point ride along “for free” with minimal chances of interference. This includes any acknowledge-ment/retransmit requests from the receiver and even packet transmissions from the receiver back to the transmitter. This scheme has been called either “piggy-backing” or “packet trains”.

Some current typical protocols in this group are: FAMA, MACA, and RIMA. The IEEE 802.11 protocol itself is essentially a member of this group of protocols. There are sev-eral variations with each of these protocols.

HIDDEN TERMINALS The basic problem that contention protocols are designed to deal with is hidden termi-nals. In a hidden terminal situation, the transmitters can’t detect each other, but the receiver can detect both transmitters. Since the transmitters can’t detect each other, it is up to the receiver to pass along information about channel conditions.

In a transmitter-based scheme, any radio with a packet to send first sends an “RTS” or “Request to Send”. The RTS does two things. First, it attempts to let the receiver know that a packet is ready for sending. Second, it signals all neighbors near the transmitter to be quiet for the packet that may be about to come.

When a receiver hears a clean RTS and it is allowed to transmit, it responds with a “CTS” or “Clear to Send” packet. This packet alerts any nearby neighbors to the receiver (such as potential hidden terminals) that a data packet is about to be sent. It also lets the transmitter know that the RTS was received cleanly.

Following receipt of the CTS, the transmitter then begins transmitting the actual packet. At this point, assuming issues like timing and carrier sense are done correctly, all poten-tial interfering transmitters around the receiver (including hidden terminals) are aware of the data packet transmission and suspend any attempts to transmit until after the data packet has been completed.

RTS/CTS systems can completely eliminate the hidden terminal problem because the receivers handle any transmission conflicts. The trouble is with fairness. Usually, both problems occur with one another. This is a situation with a group of radios all within range of each other and a “loner” hidden terminal out on an edge. Within the group of close radios, they can all hear the RTS followed by a CTS and the following data packet. Those radios stay silent to avoid causing interference.

The radio on the edge meanwhile keeps trying over and over again to transmit using an RTS. Almost every time it tries, the transmission fails (the radios nearest it can’t trans-mit within interfering with an ongoing communication if they can hear it at all). This gives the radio on the edge the impression that traffic is very heavy, so it purposely throttles back on communication (and attempts to do so), making the problem even worse.

Two different suggestions have been made to cure this problem. The first suggestion is to pass around traffic estimates intentionally so that all radios get a fair and accurate assessment of the real network load. The second suggestion is that the backoff method is flawed and that instead, the initial contention system should be modified.



RECEIVER BASED SYSTEMS

Transmitter based systems require the dual packet RTS/CTS combination. A recent innovation relies on a single packet. Since interference problems occur at the receiver, the receiver is always involved in eliminating interference. As a result, if receivers take the initiative to send a signal packet, one of the required control packets is eliminated. In this case, receivers transmit “RTR” or “Ready to Receive”.

There are additional variations on the same idea such as “Ready to Multicast”, “Ready to Broadcast”, “Ready to Send and Receive”, etc. The whole idea is to extend the amount of traffic covered by the RTS/CTS or RTR system to reduce the amount of potential interference that can occur.

BUSY TONES Aside from using outright packets, it is also possible to use “busy tones”. In this case, transmitters don’t modulate their carrier. They simply transmit a single tone. Receivers can detect tones very easily (the hardware is not very complex). Tones are also additive so it gives an indication of “at least one transmitter” or “no transmitters” sensed. Also, carrier (tone) detection requires a much lower SNR level than detecting data.

As one possible example, if a receiver transmits a busy tone while it detects an incom-ing packet, the busy tone effectively conveys a “don’t transmit” signal, preventing colli-sions. The bandwidth required to transmit a tone is much smaller than that required for whole packets.

In this case, the radio would be constructed with a device called a “diplexer”. This device has 2 separate frequency bands that are isolated from each other. Each band can be used seperately. For instance, one band could be used to transmit while the other is being used to receive. Diplexers are only effective if the relative distance of the bands from each other is quite large. In the case of ISM bands, the filtering requirements are almost impossible to meet. Thus, busy tones would be effective in say the 49 MHz band but not at 915 MHz or 2.45 GHz.

USING SILENCE Radios are inherently broadcast systems. If a routing protocol is designed which can take advantage of multicasting (transmitting the same packet to multiple receivers simultaneously), wireless systems have the potential to be much more efficient. The trouble is that the basic RTS/CTS falls down. Each intended receiver must provide a separate CTS to avoid hidden terminal problems. In this case, the simple case is that the transmitter essentially creates multiple CTS “slots” from the RTS. In a multichannel system, the separate data channels can hold the CTS packets, avoiding the problem.

There is another solution that has been published in FPRP. All of the receivers could potentially transmit a CTS simultaneously. If this is done, it will only be known that at least one receiver allowed the transmission but it doesn’t indicate whether or not inter-ference occurred at one of the receivers. Instead, use “silence” as an acknowledgement. If a receiver knows that there is a problem (a interference), then the receiver broadcasts a “Don’t send” signal instead of a CTS. If the transmitter doesn’t detect any “Don’t send” packets or garbled packets from multiple receivers, then it is safe to send a broad-cast packet. The only downside is that the ability to detect lost packets (from noise) is lost in the process.



POWER CONTROL IEEE 802.11 uses fixed power levels for transmitting. This means that each radio will effectively block all transmissions over the same geographic area (if the Earth is flat). This is inefficient because if the receiver is relatively close by, the transmitter could cut it’s power and allow other transmissions to continue without blocking the entire area off from any other communications.

Theoretical calculations have shown that using power control will at least double the available throughput. So far, variations on this theme have popped up now and then.DRA (published 1996) is typical. In DRA, each station maintains a list of all recently detected stations and the power limitations set by those stations (with expira-tion times). The RTS packet includes the power used to transmit and the allowed maxi-mum power. The CTS packet includes the allowable interference level, the recommended power for the transmitter to use, and the power level used to transmit the CTS packet.

The latest version to be published is called “PCMA” (Power Controlled Multiple Access). It adds a slight twist with the addition of a busy tone channel. In all cases, the transmitter monitors communications to track the maximum allowed transmission power. When it transmits, it uses the minimum transmission power necessary to reach the receiver subject to the maximum power limit constraint. In the RTS packet, it includes the transmit power level actually used. All radios receiving the RTS packet can estimate the distance (gain) to the receiver so that they can determine the required mini-mum and maximum allowed transmission levels.

The receiver responds back with a CTS packet that includes the maximum tolerable interference level (minimum SIR), and appropriate power limits. It also includes the power level chosen for the CTS packet. All listening radios once again make measure-ments.

The transmitter embeds the same information again in the header of the data packet. In this way, all nearby radios have good power level and path loss estimates. In order to avoid multipath and multiuser-type problems, the power controlled algorithms make sure that only very conservative estimates.

PCMA improves the situation beyond this basic scheme. In addition to all of the above control messages, PCMA requires a more sophisticated radio. During reception of the data packet, the receiver broadcasts tone pulses on a separate channel. The power level of the tone pulses is set to prevent any transmitter from interfering. Potential transmit-ters listen to the side channel to measure the signal strength of tone pulses on the side channel. Those measurements are used to control broadcast power used in the initial RTS to avoid collisions with data packets.

DIRECTIONAL ANTENNAS Directional antennas work with the power control concept. In this case, a radio uses a directional antenna to avoid interferring with neighbors nearby by focussing the signal strength directly towards the intended receiver. Unfortunately with contention proto-cols, there is a basic problem with this concept. The RTS/CTS packets are used to avoid hidden terminal problems. With directional antennas, the hidden terminal problem creeps back in again.



For instance, hidden terminal problems only exist at the receiver. If the receiver broad-casts an omnidirectional signal (CTS or RTR), this eliminates hidden terminals and allows the transmitter to broadcast directionally. However, it is not possible for trans-mitters near the receiver to broadcast. There never was an issue around the transmitter.

This has not been suggested before but a combination strategy can be used. The receiver can broadcast the first CTS/RTR omnidirectionally to alert any potential transmitters of the ongoing communication. Then it can broadcast a second CTS/RTR directionally towards the transmitter. Any potential interferers hearing the second CTS/RTR are then aware that they are in the path of the data packet and need to remain silent. The direc-tional signals will be transmitted at reduced power (the gain over an omnidirectional signal).

MULTIPLE CHANNELS This is an area in contention protocols that hasn’t really been covered very much. Of the work that has been done, there are two distinct approaches. In the first approach, each receiver is assigned it’s own channel. Periodically, the radio invites transmitters with a RTR packet (transmitted in the same channel). Then it does contention resolution before receiving all the outstanding packets. Each transmitter switches between it’s own chan-nel and that of others. It can only linger on other channels for a short period of time...long enough to capture any activity such as the RTR before returning to support contact in it’s own channel. This protocol is known as CARMA-MC.

There are two downsides to CARMA-MC. First, it requires coordination among the radios to set up and maintain separate channels for each radio. Second, without a com-mon meeting point to coordinate communication, the probabilities of being able to ini-tiate a communication are somewhat low. One argument in favor of CARMA-MC is that since each station essentially acts like a base station, it is trivial to implement col-lisiion resolution among the potential transmitters. This is actually done in CARMA-MC.

The second approach is to use a single universal “requests” channel for the mini-packets and leave the remaining channels for handling data. Protocols in this category are MACA-CT, HRMA, CHAT, the RICH family, CATS, and CHMA. All of these proto-cols are frequency-hopping based.

In MACA-CT, there is a single, common hopping sequence. Each hop has 2 slots in it. A transmitter that wishes to send first sends an RTS to the receiver in the first slot. If the receiver hears the RTS correctly, it responds with a CTS in the second slot. Then all other radios have hopped on to the next pair of slots. In the following channel, after receiving a CTS, the transmitter begins sending data and stays on that channel hop with the receiver, while the other transmitters and receivers go on to the next channel. The transmitter sends the entire data packet and then the receiver sends an ACK in the same reserved channel. Then both radios return to the common hopping sequence.

CHMA takes one step further. Each hop lasts for exactly one mini-packet. Transmitters send an RTS in that slot when they attempt to transmit. Receivers responding to the transmitters use the next hop to send a CTS. Then both transmitter and receiver stay on the same hop to exchange data and possibly an ACK packet. Aside from being able to



hop twice as fast (which shortens the allowed length of the data packets), CHMA also gaurantees that RTS/data packet collisions won’t happen unlike MACA-CT.

HRMA is one of the more interesting protocols because it answers questions about han-dling synchronization. HRMA is intended for an ISM-band frequency hopping system. One channel is designated as the synchronization channel. When radios occupy the syn-chronization channel, they contend to be “leader” and control the hopping pattern tim-ing. The rest of the time, they follow a hopping sequence where each “hop” has room for 3 slots worth of mini-packets in it.

In the first slot, the radios tune again to the synchronization channel for synchroniza-tion. During the remaining two slots, they make RTS/CTS exchanges. Furthermore, the transmitter and receiver stay in the SAME hop, not continuing on to the next one. This sets up a pattern where essentially, the radios all at least receive on the synchronization channel every third slot. Once every complete cycle of the hopping pattern, they occupy the synchronization channel for a full three slots in a row. This means that regardless of how far radios in the network may drift or if they start up unsynchronized, they will eventually synchronize at least once every full cycle of hops. Normally, they are syn-chronizing every third mini-slot. Once per cycle, they also cover the remaining parts of the timing pattern.

The fact that the transmitter and receiver stay in the last hop is important. It means that unlike MACA-CT and CHMA, data and CTS packets are sent with no possibility of col-liding with an RTS packet. This enhances the probability of a successful RTS/CTS exchange.

Under the RICH protocols, instead of transmitters sending RTS packets, receivers send RTR (ready to receive) packets. The RTS packets are eliminated. RTR packets are sent during a one-hop window (like CHMA), and the receiver remains in the channel (along with the named transmitter). It does require the receivers to “guess” how often to poll the transmitters for data but this is not a difficult problem to solve in practice. Variations of RICH allow for more extended packet transfers such as simultaneously requesting permission to send to one radio while receiving from another.

CHAT takes CHMA one step further. A one-hop window is used once again. CTS’s are sent in the reserved slot along with data. This avoids RTS/CTS and data collisions. In addition, CHAT also sends an “extended” RTS once it has sent the normal one. The extended RTS allows CHAT to include a list of multiple receivers...which means it can multicast or broadcast. Each receiver simply responds with a CTS in the appropriate allocated time “slot” based on receiving the extended RTS (called SRTS in CHAT).

Finally, CATS is based on the idea that essentially, radios are reserving “links” and they simply need coordination to arrange for a “link”. In CATS, there is one scheduling chan-nel, one broadcast channel, and several data channels. The protocol is very complicated (there are 5 separate mini-slots plus a data slot). Instead of staggering packets over a rotating “virtual scheduling channel” like the other protocols, the details of how to form separate channels are not considered. The 5 mini-slots are used in a very complicated way to allow radios to make and hold broadcast, multicast, and uni-cast reservations. One innovation in the protocol is that in several places, an “idle” mini-slot is an acknowledgement while either noise or a “NAK” packet indicates denial. This means



that the assumption is always successful unless a radio transmits otherwise. Most prot-cols assume that only a correctly received packet indicates success.

In terms of capacity, the single-channel contention systems are easy to calculate. Assuming a slotted system and that each “slot” in the main channel (even a rotating one like HRMA) corresponds to a separate data channel, the total maximum capacity of the system is C(N-1) where C is the capacity of a single channel and N is the number of channels. This assumes the contention channel and the data channels are equal in size. The real capacity is limited by the contention protocol’s ability to have successful trans-missions. Based on recent attempts achieving 90% in a single-channel case, the total system bandwidth should be 90% of the maximum case.

In the one channel per transmitter systems (such as CARMA-MC), the same contention protocol limits apply. The only advantage in this case is that the amount of contention is divided up among the number of channels, reducing the impact of contention. It is replaced by the need for a channel “owner” to be present simultaneously with a poten-tial transmitter (a probability problem). This problem is similar to that of the “persis-tence” of contention protocols.

On top of the basic persistence problem, one channel per transmitter systems must either vary the number of channels allocated to each transmitter to deal with variable numbers of available transmitters in an area or else take another hit on system bandwidth. This makes the single-channel contention systems a clear winner in terms of system band-width.

SLOTTING AND CARRIER SENSING

Even with mini-packets and scheduling, It is also necessary to create situations where a transmission can’t be halfway over when another transmitter accidentally transmits out of turn. This wastes bandwidth because on or both of the transmissions will be lost. To avoid this, radios either need a carrier sensor or slotting.

With slotting, radios divide time up into “slots”. All radios must be synchronized in time so that their slots are all coordinated. How well they can synchronize controls how thick the “walls” on the slots need to be and how small slots can be. Transmissions must occur within the boundaries of the slots. Since transmissions are only allowed in a slot, there is no possibility of causing partial interference. All interference is either full or non-existant.

In carrier sensing, the receiver has extra hardware. The extra hardware can detect whether or not any nearby transmitter is transmitting, although the packet itself may not be received. The carrier sensing circuit acts like an “in-use” or “vacant” signal, telling the transmitter when any transmissions are completed.

Frequency hopping and time hopping systems have built-in requirements for good time synchronization. This makes it inherently easy for them to implement slotting. With direct sequence systems, carrier sensing is almost exclusively assumed since it is rela-tively easy to implement with the extra hardware. Either method works equally well.


Contention Algorithms


The previous sections deal with the basic problem (how to get information through while avoiding interference with data packets). From monitoring the signalling informa-tion, each radio can make estimates on how much traffic is actually being transmitted. Then if each radio chooses how often it attempts to transmit when the band is clear, the total number of radios attempting transmission simultaneously decreases. This increases the odds of avoiding collisions which increases throughput since a transmitter can only send a packet after an RTS/CTS signalling attempt. This type of mechanism is called “persistence” with Ethernet type protocols.

Simultaneously, persistence solves a second problem. If traffic can be correctly mea-sured, then persistence systems allow all potential transmitters an equal shot at being able to transmit. This allows fairness to be solved.

UNDERSTANDING CONTENTION PROBLEMS

One of the basic problems with wireless radio systems (Ad Hoc systems) is that there are geometry constraints. These constraints make fairness inherently difficult to achieve. It causes “standard” flow control algorithms that are perfectly acceptable in wired networks to be completey unfair in wireless ones.

Let’s start with a simple example. Nodes A, B, C, D, E, and F are all in a straight line. Each node can communicate with it’s two nearest neighbors (line of sight), but no far-ther. So B can communicate with A & C but not with D, E, or F.

Let’s assume all links are active. Now draw a flow contention graph with all the “active flows” (all links in this case). Flows (links) are nodes in this graph. If a flow can cause a collision with another flow, then draw a link between the flows. For instance, the flow between A and B conflicts with the flow between B and C since if A & C communicate simultaneously, they will cause a collision at node B. It will also cause a conflict with the flow between C & D since any of C’s transmissions will cause a collision at B. The resulting contention graph looks like the following:

Alternatively, any two nodes that are within a distance of 2 hops to each other contend with each other since a neighbor’s neighbor counts as a potential hidden terminal. Each edge (link) in the graph represents a neighbor or a neighbor’s neighbor. So the edge from AB to BC represents B, which is a neighbor of A. The edge AB to CD represents

AB(1)

BC(2)

CD(3)DE(4)

EF(5)

FIGURE 1. Flow Contention graph.



C, which is a neighbor of A’s only neighbor. But this interpretation is more confusing than just identifying potential collisions as nodes.

It should also be obvious from the flow contention graph that in this node configuration, the maximum system capacity is 200% of a single channel. Simply pick flow 1 and then either flow 4 or 5 can be active simultaneously (but not both). Although 200% is the maximum throughput, it is also very unfair (by any definition) since flows 2 and 3 will not be allowed any bandwidth whatsoever.

Now, go through the graph and identify all the maximal cliques. A maximal clique is a group of connected nodes. The nodes in the clique have the property that only one flow can transmit at a time. For instance, flows 1, 2, and 3 (using the numbers since it is more convenient) represent a maximal clique. If node 4 is added, then flow 1 and flow 4 could transmit simultaneously without causing a conflict since they are not neighbors in the flow contention graph. The same is true if node 5 is added.

The maximal cliques represent a special situation. By definition, only one flow can be active in a clique at a time. A clique represents a “distinct contention region”. In order to be able to make a successful transmission, a flow must be the only one active in each contention region that it is a member of. Drawing a graph to represent the contention regions, we get the following:

Each distinct contention region (K, L, M) represents a “channel resource”. The flows (1, 2, 3, 4, 5) are competing for those resources. A flow can only be successfully received if it simultaneously obtains rights to each of the channel resources that it is associated with.

Notice that this simple example is inherently unfair. Flows 1 and 5 only need to get rights to a single channel resource. Flows 2 and 4 need two channel resources, which flow 3 needs all three of them. It is not the fault of the protocol (which we have not defined). It is simply the physical geometry of the situation penalizes some flows over others.

This example shows the extremely ugly nature of hidden terminals since every single flow experiences hidden terminal problems. It is the job of the contention protocol to resolve resource contention problems and support some kind of “fair” allocation of bandwidth.

FIGURE 2. Resource Contention Graph

1 2 3 4 5

K (123) L (234) M (345)



PUBLISHED BACKOFF/PERSISTENCE STRATEGIES

Most current protocols have a fixed persistence algorithm and a variable backoff algo-rithm. Essentially, they all attempt to access the network during perceived silence peri-ods simultaneously. Following a collision, the protocols spread their access attempts out over more time (backoff).

The idea is that following a successful packet transmission or an idle period, the channel conditions are unknown. By attempting transmission with some fixed probability, the channel conditions can be established (idle or collision).

Each collision that occurs indicates that the channel is apparently more crowded than first suspected. So after a collision, the protocol automatically backs off, decreasing the probability of transmission attempts. Equivalently, it can simply increase the delay between transmission attempts.

This protocol sounds simple enough in theory. It is the classic Binary Exponential Back-off (BEB) protocol. However, there are some problems with it.

THE BACKOFF TRAP Backoff protocols also contain a pitfall. One or more radios may have suffered a colli-sion. This causes them to go into a backoff state. Meanwhile, another radio may receive a packet (or generate one) and be ready to transmit. Seeing the channel clear, it begins transmitting. The newly activated radio is completely unaware that the other radios are in a backoff state. If the other radios are still in “backoff”, the newly joining radio may continue to transmit packets for a long period of time.

Even more insidious, if the backoff timers are reset back to a minimum value each time, then the first radio to have a successful transmission after a collision automatically has a better probability of accessing the channel than the one that is still in backoff.

The naive backoff strategy essentially causes “short term” unfairness. Some radios have more access to the channel than others because not every radio has the same backoff timer.

THE COPYING TRAP The “obvious” solution to the backoff problem is for each radio to advertise it’s backoff timer in the RTS/CTS packets. Any radio that receives an RTS or CTS that is higher than it’s own can simply copy the higher value. This somewhat alleviates the different backoff timer problem.

Now the problem becomes more insidious. The short term fairness problem still exists. It is simply reduced to a slightly lower level of trouble. Now some radios will pick up the new backoff values from when they receive RTS/CTS packets correctly. But not every radio sees the same RTS/CTS exchange so not every radio is aware of exactly what happened.

Worse yet, the backoff timer problem can spread from areas where contention is high to areas where it is relatively low. This causes throughput in areas with low congestion to mimic the congestion of the higher throughput area.

For example, all of a radio’s neighbors are in the same congestion level as that radio. Backoff copying works here. Some of the flows of a radio’s neighbor’s neighbors (those



radios which are 2 hops away) are also in the same congestion. The congestion packets are the ones that are being sent to the radio’s neighbors. The rest of the flows (those directed out into other parts of the network) are not in the same congestion level. Their ccongestion conditions are dictated by the relative congestion conditions 3 hops away.

BEB Binary Exponential Backoff (BEB) is the method chosen in IEEE 802.11. Originally, this is also the exact same technique used for flow control in TCP. In the original scheme based off Ethernet (which uses a similar scheme), a backoff counter is set to 1. Each time a transmitter attempts to transmit, it picks a random number between 0 and the counter. It waits for that amount of time (the length of an RTS packet) and then attempts to transmit. Since the counter is set to “1”, it transmits immediately on the first attempt. If a collision occurs, then the counter (the backoff counter) is doubled. The transmitter picks a random wait time (0-2), and then tries again. The counter continues to double until the packet is successfully transmitted. When a successful packet trans-mission occurs, the counter is reset back to 1.

In IEEE 802.11, a counter is set to a base value of 31. The potential transmitter picks a random number between 0 and the base value. It waits for that random amount of time and attempts to transmit. If a collision occurs, then it doubles the counter and tries again. After a successful transmission, it resets the counter to 31. The maximum value for the counter is 1023 in IEEE 802.11.

The BEB system has very poor short-term fairness. It suffers directly from the backoff pitfall. The same kinds of effects have been seen (and eliminated) in TCP.

MILD WITH COPY Taking more hints from the TCP flow control algorithm, MACAW suggests multiplica-tive increase/linear decrease with backoff copying. MACAW maintains separate back-off counters for each flow. It doubles the backoff counter for the flow for each loss assigned to the station (the multiplicative part). It decreases the backoff counter by 1 for each successful transmission.

In addition, MACAW also attempts to “share” estimates of contention using copying. It suffers from all the problems that copying algorithms cause in terms of artificially low-ered throughput. It still doesn’t eliminate the erratic behavior of backoff timers since packets can join congestion at any time. But, it does reduce the problem significantly by using longer term metrics (via MILD).

COMBINED PERSISTENCE AND BACKOFF

Contention-based Balanced Medium Access (CB-Fair) tries to combine persistence and backoff. The degree of the receiver is estimated. “Degree” is the total number of neigh-bors that the receiver has. The transmitter contends with a probability equal to the ratio of the degree of the receiver to the maximum degree of all neighbors of the transmitter. The backoff counter is doubled with each failed transmission and halved for each suc-cess. Backoff copying similar to MACAW is used.

It turns out that multiplicative increase and decrease also leads to short term unfairness similar to BEB. This is also true with flow control algorithms. Further, the persistence algorithm artificially increases the persistence of highly contending flows (as measured by node degree), leading to more instability and higher backoff counters.



DFS DFS is from researchers at Microsoft and Texas A & M. Thus even though it clearly still has serious problems, it will probably end up being adopted just because if something comes from the holy temple of Microsoft, it must be good! DFS Attempts to combine backoff and persistence

There are several pages of discussion of virtual clocks. However, by their own admis-sion, the backoff counter is set equal to a multiple of the size of the packet. Then it is slightly randomized (±10%). The backoff counter is used for initial transmissions just like with BEB in IEEE 802.11. After each collision, the backoff counter is doubled.

In an attempt to avoid the problems of BEB, backoff counters are also “time com-pressed”. Essentially, the actual value used is the real value scaled exponentially by a function such as square roots or logarithms. The idea is to try to reduce the effects of very large backoff values.

The authors admit immediately that their protocol has short term unfairness problems. They also run simulations with low throughputs to hide the short term unfairness prob-lems. In most simulations packet sizes are fixed so the fairness problems that may occur with variable packet sizes are suppressed. They then try to demonstrate that although DFS still has short term fairness problems, they believe that the combination of backoff randomization and time compression reduces short term fairness problems.

RT-MAC This protocol has 2 unique features. First, the protocol pre-calculates a random backoff value (not the backoff counter) and puts this in the packet header. Other stations hearing the backoff value are supposed to avoid picking the same value. This has the effect of reducing the possibility of collisions when the station actually contends for the channel.

The second feature is that the initial backoff counter value is not fixed. It is estimated to be approximately 8 times the number of stations heard over the last few seconds. This has the tendency of increasing the initial contention window when there are many sta-tions contending for access.

Neither feature eliminates the basic fairness problems of BEB. They merely reduce the possibility of contention. The contention side is at least on the right track.

MILD PERSISTENCE The authors construct a graph of contention-related problems and then map a contention algorithm onto a solution from the graph. It turns out that:

1. Most of the above approaches tie their contention controls into the backoff algo-rithm. This works but there are severe stability problems. It is easier to control con-tention.

2. Contention should be done on a per-flow basis, not a per-node basis. The reason is because fairness is a flow-related problem, not a node-related one (at least with mod-ern interpretations of fairness).

3. Backoff/persistence should not be simply reset after each transmission. This is the whole reason that short term unfairness occurs. This is nothing more than the erratic BEB algorithm which has been shown to be such a problem in flow control.

4. Each flow participates in several “contention neighborhoods”. This occurs because of hidden terminals.The copying algorithms tend to unfairly penalize flows that are


Contention Resolution

operating in low contention neighborhoods that have neighbors in the high conten-tion neighborhoods. In reality, it is just that a neighbor is located in a bridge.

5. Without collision resolution, all flows must use exactly the same backoff algorithm or short term unfairness will become a problem.

The algorithm they chose is called Proportional Fair Contention Resolution (PFCR). It works as follows. First, there is a transmission probability x. When a station has a packet to send, it picks a random number from 0 to 1. If the random number is greater than x, then it waits for one “slot” (RTS/CTS packet interval). α is added to x before attempting transmission again.

If the station decides to try attempting transmission (probability less than x), then it con-tends for channel access. If either the channel is busy or a collision occurs, then it does a backoff. In this case, it chooses a random backoff time between 0 and B where B is a fixed, system-wide constant. The transmission probability is reduced by βx, so x=x(1-β)+α. Then it attempts transmission again after the backoff.

If it wins the contention, then the data packet is sent and α is added to x. Of the 3 con-stants, B is assumed to be relatively unimportant (it is set to 32 in PFCR). β controls the penalty for collisions. Large β values also cause instability in short term fairness. α causes the algorithm to probe the network for higher transmission probabilities. Small values reduce efficiency when network loads are low. There is a tradeoff between higher throughput (larger α, smaller β) and better fairness (smaller α, larger β). The authors picked an α of 0.1 and a β of 0.5. They stated that after varying the parameters, fairness and throughput did not vary much over a range of 0.01-0.15 for α and 0.3-0.7 for β.

PFCR was tested against IEEE 802.11, MACAW, and CB-Fair. In the simulations done by the authors of PFCR, it achieved a fairness within a few percentage points of perfect fairness (defined as proportional fairness).


If collisions can actually be detected at the receiver, then another piece of information is available to the receiver. In this case, the receiver is definitely aware that more than one transmitter has attempted transmission but the receiver can’t detect which one it was.

The hardware to actually do this is quite simple. The receiver needs to be capable of car-rier sensing. Then if the receiver detects carrier but no packet, either a collision has occurred or the packet was garbled due to noise. If the carrier sensing system is tuned correctly, the probability of noise vs. collisions can be very small.

In contention resolution protocols, the receivers transmit the collision results back to the transmitters. The transmitters break up into groups either randomly or according to some rule. The groups of transmitters schedule themselves in turns. When it becomes a particular group’s turn, the transmitters in the group attempt to transmit test packets again. If a collision happens, then that group splits again until every transmitter has been



identified. Then with all transmitters having been identified, they can all transmit their individual packets free of interference from other transmitters.

In effect, collision resolution is similar to the contention algorithms that have already been discussed. Let’s assume that the collision resolution is the basic “tree algorithm”. In this case, following a collision, each transmitter in the colliding group randomly flips a coin. The “heads” group trys to retransmit immediately. The “tails” group sets the backoff timer to “1”. If a collision occurs again, then the “heads” group splits again. The “tails” group doubles the backoff timer (wait 2 more slots). On success or idle, all the backoff timers are decreased by 1.

This algorithm, as described, is called the “Standard Tree Algorithm” because the group splitting function is similar to doing a binary tree search through all the transmitters. It is also sometimes called a “stack algorithm” because there is a simple way to visualize it as a “stack”. “Tails” groups are being “pushed” onto a stack. As successes/idles occur, the groups are “popped” back off the stack and tested. It is not necessary to actually push/pop values on a stack. It is only necessary for each transmitter to keep track of how “deep” it is in the stack to broadcast at the right time. Effectively, incrementing a back-off timer on each collision and decrementing it on each success/idle slot is measuring the “stack depth”.

PROVIDING CORRECT FEEDBACK

One slight change that has to be made for wireless systems is that basic collision resolu-tion requires every transmitter to be aware of all transmission attempts in a contention region. Thus, the receivers must signal both successful transmissions (CTS) and unsuc-cessful ones so that hidden terminals continue to make backoff timer adjustments.

Collision resolution has one fatal flaw. A legitimate collision can occur but because of the “capture” or near-far effect, one of the transmitters is heard and the other is not heard. Most protocols ignore this problem. Some of them (2CA) are very robust against capture anyways.

From a throughput point of view, capture is “good” because more packets get through which makes the total bandwidth utilization go up. From a fairness point of view, cap-ture is devastating. It creates a situation where because of the terrain and geometry of the transmitters, certain ones are fundamentally at a disadvantage. The captured trans-mitter/receiver combinations are not even aware that a collision is actually occurring. IEEE 802.11 is particularly bad about causing these problems.

Although very few protocols make a provision for it, capture can only be resolved by the transmitters, which is directly opposite the usual interference problem which can only be detected at the receivers. Somehow after a receiver has sent feedback (such as a CTS packet), any transmitters which have detected a clear case of capture have to trans-mit their own feedback (collision occurred). The receiver will then have to transmit a second round of feedback at some point combining both types of interference informa-tion.

FEEDBACK TYPES There are 3 types of feedback. With the backoff/contention systems considered so far, the feedback has been either “success” (CTS signal) or a “nothing” (idle or collision). With collision resolution, the additional piece of information is that the “nothing” signal



is split into “collision” or “idle”. The exact bandwidth available under each scenario has not been proven exactly. However, the best known collision resolution algorithms have a capacity of 0.4877.

A third type of feedback that works well with collision resolution algorithms is “colli-sion” and “no collision”. It is not possible in this case to tell the difference between “idle” slots and “success” slots. The basic tree algorithm described above really only requires “collision/no collision” since it produces identical responses to both successful transmissions and to idle slos. In this case, the best known algorithms with only the suc-cess/nothing signal format have a capacity of 0.367.

Algorithms that respond to “success/nothing” type feedback are also known as “acknowledgement” protocols. The best known of these algorithms also achieves a channel capacity of 0.367.

TYPES OF SPLITTING There are some algorithm variations with respect to how the groups are split up. In a non-deterministic binary system, the usual order is simple. Each transmitter flips a ran-dom coin. “Heads” candidates are in the first group and try retransmitting immediately. “Tails” candidates are in the second group and try after the “heads” group has finished.

In a deterministic system, the groups are more coordinated. The usual schemes are “address” based and “time” based. In an address-based system, the transmitters are split up by address. Say for instance that the transmitters are numbered 0-9. Then the first group is defined to be any transmitters who are numbered 0-4. The second group is numbered 5-9. In a “time” based system, it is assumed that a high resolution feedback is available that tells which transmitters transmitted less than some average starting trans-mission time and which ones transmitted after the average starting transmission time.

Realistically, non-deterministic systems are almost identical to “address” based deter-ministic ones. Each transmitter is calculating it’s own “random” address every time it goes through a collision resolution step. As the number of potential transmitters increases, the deterministic “addressing” based system will converge to the non-deter-ministic one.

REFINEMENTS TO COLLISION RESOLUTION

The first big refinement to the basic tree algorithm is “level skipping”. The simple mod-ification increases the basic algorithm capacity from 0.346 to 0.375. When a conflict is followed by an idle slot, this indicates that all of the transmitters in the conflicting slot chose “tails”. The next slot will always be another conflict and no useful information is obtained by testing that condition. Instead, the protocol should skip “levels” by ignoring the conflict and automatically going to process the next slot.

The algorithm continues on the pattern, interpreting every succeeding idle slot as a con-flict-idle-idle-idle-...conflict situation and automatically “level skipping”. This also leads to a potential deadlock. If an idle slot is incorrectly interpreted as a “conflict”, it will automatically split the “active” group (which is empty) into two. The result of the next attempt will also be idle, leading to a deadlock situation. To avoid deadlock, “level skipping” should only be attempted a predetermined number of times in a row.



The original protocols always assumed that the groups would be split into 2 (binary splits). It turns out that the optimal split for the standard tree algorithm using gated or free channel access (see below) is 3. For the level skipping algorithm with free access, the optimal split is 3. In this particular case, level skipping is only applied if all d-1 slots were empty where d is the number of groups in the split.

Another refinement led to the best protocols developed so far. If the first group (“heads”) after a conflict also results in a conflict, we have no information at all about the transmitters in the second (“tails”) subset. If the initial group (before splitting) con-tained about the “correct” number of transmitters, the “tails” subgroup can’t since it only contains about “half” that many.

Instead, it is more efficient to drop this group and combine it with some other untested traffic to obtain the “correct” amount of packets in the whole group. It is called the “FCFS 0.487” algorithm. In this algorithm, the “tree” concept is pretty much elimi-nated. Instead, the packets are marked by their arrival times. If conflicts with arrival times occur, the disputes are resolved by adding random numbers onto the arrival times. This can distort the FCFS property of the algorithm, but it is distorted only by the reso-lution limit.

The splitting algorithm is very different. Assume that at slot k, all packets older than some time T(k) have been transmitted. All the packets that arrived between T(k) and T(k)+a(k) attempt to transmit in slot k. If there is a collision, then the packets are broken up into two groups. The left half consists of the packets from T(k) to T(k)+b(k), where b(k) is chosen between 0 and a(k). The right half consists of all messages from T(k)+b(k) to T(k)+a(k). Usually, b(k) is set to half of a(k).

The left half broadcasts first. If a collision happens again, then the group is split (by arrival times) again into 2 groups. Now, this is where things change slightly. Only these 2 subgroups are remembered. All messages from T(k)+b(k) to current time are lumped together as a single group that attempts transmission in the next upcoming collision res-olution. If the transmission is successful then the right half is tested.

The throughput of the basic FCFS 0.487 protocol with binary splitting on arrival times achieves a channel capacity of 0.4871. If the splitting process is adjusted to operate “optimally” (and this is not a straightforward calculation), the capacity increases slightly to 0.4877. In any case, window channel access must be used to keep the size of the third group to the “right” amount.

The three-cell algorithm is a simplified version of the FCFS 0.487 algorithm. In this case, the “tails” groups in the interval from T(k)+b(k) to T(k)+a(k) are all collected together instead of being dropped. They are split again, forcing all transmissions in the current collision resolution stage to be resolved before ended the collision resolution and starting with fresh traffic. This simplification only reduces the capacity by 1.6% compared to the 0.487 algorithm.

Another simplification to the three-cell algorithm is the “two cell” algorithm. This ver-sion drops the “level skipping” rule but still does the simplified “tree pruning” rule of the three-cell algorithm. It has the same capacity as the standard tree algorithm (0.347)



but is is very robust against feedback errors. It can tolerate up to 20% feedback errors with virtually no performance losses.

ACCESS WINDOWS A “side” benefit of the original collision resolution protocols is that they solve the fair-ness problems of hidden terminals by requiring contending packets to operate in first come, first serve (FIFO) order. It is not quite “true” FIFO (although there are versions that do this) because all of the packets that are contending may get scheduled out of order. However, each group of contending packets does get FIFO-type access.

Another piece of information for use in bandwidth scheduling also becomes available. If the length of time (number of mini-slots) necessary to resolve all of the collisions is long, that leaves time for a larger number of packets to be ready to be scheduled again in the very next collision resolution step. This additional piece of information (the length of time required to eliminate all collisions) provides details about the level of traffic. In order to reduce the number of collisions, transmitters can throttle back on their packets. These types of algorithms are called “access windows”.

The “obvious” algorithm that requires all packets arriving in the current contention res-olution stage to be resolved in the next resolution stage tends to create the correlated contention resolution cycle. This type of algorithm is called “gated access”. The name refers to packet traffic. The “flood gates” open wide right as the current contention reso-lution stage ends, then close shut before the next one begins.

Taking this example to the other extreme, a packet could just as easily be allowed to transmit at any time. This creates a so-called “free access” system. The packet will just end up joining the currently active collision resolution group. Under this scenario, we have come full circle back to the contention/backoff systems. In a free access system, the FIFO-like conditions vanish. The system simply degrades back into a situation where short term fairness suffers due to more recent packets having lower backoff tim-ers than the packets still waiting to get access.

Obviously, the gated access method avoids the short term fairness problem of free access. The one remaining problem is to smooth out the surges created by the gated access method. The goal is to limit the number of packets to the “right” amount. In this algorithm, there is a maximum window of time over which packets for the next collision resolution period are allowed to enter the collision resolution queue. The maximum window size must be as large as the expected maximum collision resolution period so that the window doesn’t get “left behind” in time.

At light loads, smaller windows will be necessary or a bunch of empty, wasted collision resolution intervals will be generated. So the minimum window size is the minimum of either the size of the last collision resolution interval or the maximum expected size of a collision resolution interval.

Alternatively, the window size can remain fixed. In this case, the radios delay the start of the next collision resolution interval long enough for a “full” window to be formed. In this case, the “length” of a collision resolution interval can never be smaller than the window size. Both algorithms have the same throughput, but the fixed window size



algorithm (called the “simplified window algorithm”) has higher packet delay because of the idle periods.

Finally, the last type of window algorithms can be defined, “limited sensing”. In this case, a true window access system is in place. Any new receivers that were not tracking the ongoing windows and collision resolutions before just delay until the start of the next collision resolution period and jump on it. In effect, they moved their packets to the very next scheduling window after the current one. The packet that got preferential treatment gets an unfair advantage in terms of delay.

MULTIPLE MINI-SLOTS Using any type of splitting pattern (binary splits, ternary splits, etc.) and using whole data packets (not mini-slots), the channel capacity is 0.4877 or 0.367, depending on the type of feedback available. But with mini-slots, there is no reason not to use multiple mini-slots for each full (data) slot. Using this idea, 3 mini-slots is enough to gaurantee that all data slots will be used. This pushes the channel capacity to 100%, less the over-head of the 3 mini-slots and any necessary synchronization.

This simple innovation is the hallmark of “DQRAP”. Unfortunately, the authors of DQRAP have one problem that they have not solved. Their protocol requires ternary feedback for each of the mini-slots. They assume the case of a single base station, so no multiple-receiver coordination is necessary. This eliminates DQRAP from the running for “Ad Hoc” networks.

The requirement for using multiple mini-slots is that somehow, receivers must coordi-nate which data slot each intended transmitter actually gets. After all, if there are 3 suc-cesses, the transmitters can’t all win the data slot. The receivers and transmitters must coordinate and keep track of a distributed queue of transmitted data slots as well as any necessary contention timing requirements.

There are two protocols that are designed to work in ad hoc networks. Variations of “TS XXX” are designed with a goal of maintaining distributed signalling to maintain a glo-bal awareness of contention period boundaries so that the access windows work cor-rectly. Essentially in these protocols, following a successful RTS/CTS exchange, all remaining transmitters broadcast a pilot tone to indicate that the current contention reso-lution cycle is still in progress. A longer idle period indicates completion.

MRW-RAA or TC-RAA (variations on a theme) dispenses with that complication. These protocols which have been extensively simulated have the same basic core sys-tem. It is essentially the two-cell algorithm. Each user has a counter value, called Ri, which has values of either 1 or 2. Time is slotted. When the counter is equal to 1, the user transmits in the slot. All radios monitor the channel to see if any transmissions that occurred were a failure or success. Since the system does not discuss mini-slots, it prob-ably means that full data packets are transmitted, followed by ACK/NAK.

The rules for updating Ri are as follows:

1. If the transmission in the slot was successful or the channel was idle and Ri=2, then Ri=1 (transmission successful; deferring stations move in).

2. If there was a collision and Ri=2, then Ri=2 (defer to allow the collision to be resolved).



3. If the transmission was successful and Ri=1 and capture did not occur, then Ri=1 (keep transmitting).

4. If a collision occurred (or capture) and Ri=1, then flip a coin. On heads, Ri=1. On tails, Ri=2. (This is the usual splitting rule for collision resolution.)

ACHIEVING FIFO WITHOUT BASE STATIONS

Two methods have appeared to accomplish this. In CARMA-MC, each radio is assigned a separate channel. Each transmitter with a packet to send randomly tunes to the channel corresponding to the intended receiver. It waits on the channel for an RTR. If it doesn’t see an RTR within a required amount of time, it gives up and returns to it’s own channel to send an RTR of it’s own. Idle stations (and transmitters that have timed out) transmit an RTR and then wait for a response from any potential transmitters. In CARMA-MC, each receiver then acts like a base station and runs a collision resolution algorithm for all transmitters attempting to contact the receiver. FIFO-type requirements are handled by the receiver.

In another proposed single-channel protocol, the beginning and end of a collision-reso-lution group is detected by signals generated from the transmitters. Transmitters com-pete for collision resolution. When a success happens (a CTS is signalled), all the remaining transmitters transmit carrier in the next available mini-slot. Any transmitters waiting for the current collision resolution to end can detect that it is still ongoing when they hear transmitted carriers following a successful CTS. The transmitters that are active in the current collision resolution are already aware that it is ongoing. If the mini-slot following a CTS is quiet, then contention resolution in the current contention region has ended.

The original protocol did not consider hidden terminals. If the receivers reciprocated the contention signal, this solves the hidden terminal problem. Also, the original protocol had a timeout system in case a long period of dead air-time occurred. The rest of the protocol was mostly occupied with maintaining a good access window algorithm for FIFO-like packet scheduling.

RECEIVER BUSY VS. COLLISIONS

The last important detail with regard to collision resolution algorithms is detecting whether a receiver is busy or idle. With a multiple channel, mini-slot type system, there are actually 4 possible outcomes (ignoring capture):

1. The transmission exchange (RTS/CTS) is successful.2. A mini-slot went idle.3. A collision actually occurred.4. The receiver is busy receiving or transmitting a packet in another channel outside the

contention channel.

If #4 occurs, a “collision” has indeed occurred. However, the whole point of collision resolution is that transmitters are supposed to be contending for access continuously. The transmitter could be unaware of the receiver’s status. Thus, the transmitter will go ahead and attempt to contend until the receiver’s data transfer ends. In the mean time, the current collision resolution time continues for an excessively long period since the transmitter is unaware of the difference in status. This will affect window algorithms and cause other transmission groups to delay while waiting for the “stuck” transmitter.


IEEE 802.11 Details

In CARMA-MC, this does not occur because the receiver transmits and explicit signal to begin collision resolution (an RTR). In a single contention channel system, any suc-cessful transmission puts the transmitter at a distinct disadvantage. An idle transmitter can detect “busy” receivers merely by monitoring the CTS traffic. It will require the time to transmit a full data packet before the transmitter can safely verify the status of all potential receivers. The delay can be reduced somewhat if the receiver and the trans-mitter both send an “RTR” in a couple extra mini-slots following completion of a data packet transfer.

SUMMARY Collision resolution introduces new problems. For collision resolution algorithms to work correctly, information must be distributed correctly among transmitters despite the obvious geometric problems that the wireless environment creates.

Correct collision resolution solves a major problem for “traditional” contention proto-cols. All transmitters (within a limited degree) get fair and equal access to the channel in more or less FCFS (first come, first serve) order. This “fixes” the basic unfairness prob-lem of collision avoidance protocols created by the radio geometry.

Correct collision resolution coupled with an appropriate window access algorithm is also unconditionally unstable. One of the basic problems with collision avoidance algo-rithms is that they always have a point of instability that is avoided here.

Because collision resolution algorithms are unconditionally stable, they can operate at near channel maximum capacity regardless of the system load. Collision avoidance pro-tocols by definition avoid conflicts during heavy loads, reducing throughput right when in reality it needs to be increased.

Delay under collision resolution is minimized. In fact, often it is highly predictable. This leads to the possibility of implementing variable delay/bandwidth service. For example, delay is not important for bulk data transfers such as mail and file copying. Those sys-tems require maximizing bandwidth. However, interactive systems such as games and voice communication usually have little value in extra bandwidth but are very sensitive to even slight delays.

Finally, collision resolution combined with mini-slots can push the capacity of a multi-channel wireless system effectively to 100% use of all data slots (all channel losses are in the mini-slots).

IEEE 802.11 Details

IEEE 802.11 specifies 3 types of wireless systems: infrared, frequency hopping, and direct sequence. The infrared system is not designed to work over long distances so it won’t be covered here. The frequency hopping and direct sequence systems are more important, and concentrating on the 2.4 GHz spectrum which was previously identified as the key area anyways.


Conflict Free Scheduling

DIRECT SEQUENCE SYSTEMS

For direct sequence, IEEE 802.11 divides the spectrum up into 3 separate “channels”. The reason for doing this is that with 3 “channels”, a cellular radio type system can be set up with base stations organized in a hexagonal grid and no two adjacent base stations will have the same channel.

Second, all radios use exactly the same “hopping code”. The original specification used a 11 bit code that has special correlation properties (it is a “Barker” sequence). This sequence has the special property that even small pieces of the code will not correlate with any other piece. This special property is only achievable with a maximum code length of 11.

In the newer specification, the original hopping code is joined by a new “high speed” code. In this code, each radio transmits about the same length code, except that the codes are picked from a set of 8 Hadamard sequences or inverses of those 8 sequences for a total of 16 patterns. These codes look more or less random and duplicate the “spec-tral shape” of the original Barker code, but by transmitting one of the 16 sequences, 4 bits can be transmitted simultaneously instead of the original single bit. In reality, this comes at a cost of much reduced signal range but IEEE 802.11 was never designed to work over long distances except on narrow beam antennas operating in point-to-point coverage.

FREQUENCY HOPPING SYSTEMS


Statistical multiplexing used essentially no coordination over when a transmitter can transmit except for some sort of rudimentary randomization to lower the probability of interference. Contention protocols took the next step by using feedback between trans-mitters and receivers to coordinate their current transmissions. The next step would be a conflict free scheduling system which plans out all or nearly all transmissions in advance. There will always be some sort of unscheduled transmissions or else it will not be possible for radios to handle changes in the network structure. This is only necessary to handle new radios joining and leaving the network. In general, a conflict free sched-uling network should be designed to minimize unscheduled transmissions to only changes in link status.

With one exception, contention protocols have been designed that can work up to around 90% throughput as compared to the theoretical maximum throughput of 69% for statistical multiplexing systems. By definition, full scheduling systems should always operate at 100%. In this case, there are 2 major difficulties. First, in almost any reason-able scheduling scenario, it is simply impossible to find the optimum schedule. The problem very easily becomes NP-complete.

The second problem is the problem of dynamic response. By definition, contention pro-tocols are dealing directly with resolve scheduling conflicts among packets waiting to be sent. A conflict free scheduling system has to react very quickly to give the same



kind of response to waiting packets. At the minimum, some kind of “2 phase locking protocol” similar to that used in database systems would be necessary.

Finally, even if all communications links responded exactly according to a schedule that is created and adapted on the fly, upsets are going to happen. For instance, a failed packet transmission will delay a few packets, causing a temporary surge in bandwidth requirements on a single link. In ATM systems (full-scheduling wired networks), smoothing filters (leaky buckets) are used to cover the bumps and temporary surges that occur.

That being said, any kind of conflict free scheduling system is going to have difficult problems adapting quickly to changing packet loads. Fairness will rear it’s ugly had and must be resolved by some kind of distributed scheduling system. Optimal scheduling is simply not possible.

All conflict free scheduling systems proposed to date are essentially of two designs. The first design seeks to run through a distributed algorithm to determine an appropriate schedule for all radios. It is assumed that scheduling is done in such a way that radios are using the existing schedule to determine a new one to use in the near future.

The second design adapts on the fly. The schedule is adapted to make room for each radio to have some kind of communication in the schedule. A basic, minimal network is formed. Radios then fill in any available gaps in the schedule with more communica-tions.

In either case, the current measured traffic loads have not to date been used for schedul-ing purposes. So-called “traffic sensitive” scheduling algorithms make the assumption that radios with more neighbors will have more traffic and allocate those radios with more time.

It appears that the research problem is simple. As will be shown shortly, the flow control algorithms and the routing algorithms must be wedded. Flow control is needed to avoid congestion. As long as flow control and routing are treated as separate problems, the only way to reduce congestion is to throttle back on packet transmissions.

Statistical multiplexing methods (in their pure form) have no way to adapt at all to traf-fic loads. Contention protocols adapt to traffic loads via their persistence algorithms. Ultimately, a combined flow control/routing/scheduling algorithm will probably use full scheduling. However, conflict free scheduling algorithms were previously created with-out the knowledge of recent advances in the design of flow control and multipath rout-ing.

CHANNEL ACCESS SCHEDULING

The one glaring exception is the family of protocols published by Lichun Bao. Concep-tually, it weds the best features of the best contention resolution protocols with the 100% scheduling feature of the conflict free schemes, while avoiding the NP-hard trap with a simple statistical method.

Bao’s technique is very simple. Contention resolution algorithms rely on a communica-tion method (the handshaking signals) and randomization to resolve and avoid conflicts.



In a sense, Bao’s technique does the same thing by randomization. The trick is to simply use mathematical algorithms called by various names such as hashing or message digests.

The idea is that a function with several inputs produces a result that is based on those inputs. The output of the function is statistically random (no real pattern to it), except that it is still not a true random function. Given the same set of inputs, it produces the exact same outputs.

Since the function provides random outputs, then simply feed it the simple information that each radio has available to it. Each radio should be aware of all of it’s one-hop and two-hop neighbors (since that is where conflicts are going to occur), as well as some mutually known information such as a slot number. Each radio calculates a hash for itself plus all of it’s neighbors, such as:

The ⊕ symbol means the concatenation in this case. Combining the slot number with the radio address gaurantees that each radio will hash to a different value on every sin-gle slot. This gaurantees that statistically, each radio will have a unique hash value for every unique slot number, which gaurantees statistical randomness.

Now, sort the radios based on their hash values. If there are ties, use a simple tie-breaker function that every radio can easily determine such as the radio with the highest address wins when the slot number is even and the one with the lower address wins when the slot number is odd.

Third, the radio with the lowest hash value (in a single channel system) wins the right to transmit. In a multi-channel scenario, the first n (where n is the number of channels) radios win the right to transmit.

Bao does not cover exactly how radios achieve slot synchronization but “joining” the network is discussed. Every so many slots, a short block of slots are left empty (no data traffic). In those slots, new radios can transmit (using a contention protocol) to attempt to join the network.

Since the hash values are statistically uniform, adjusting the “shape” of the probability distribution allows the relative frequencies such as % slots to be adjusted on each radio. In one version, Bao added a “priority”. The hash is multiplied by that priority to give some radios statistically better values.

One of the most interesting variations is a version using unidirectional links. It is easily possible (and possibly common) in radios to have situations where radio A can transmit to radio B, but radio B can’t necessarily transmit to radio A. This situation is called a unidirectional link. Only statistical multiplexing and conflict free protocols can handle it since the RTS/CTS exchange messages of conflict resolution assume that all links are bidirectional.

hash radio address⟨ ⟩ slot number⟨ ⟩⊕( )


MAC Comparison

It is possible to have communication in those two cases because it is not necessary for neighbors to have direct bidirectional communication. It is still necessary for neighbors to have a communication path in both directions in order to synchronize, but that path can be achieved through other neighbors.

As a result, one variation of Bao’s protocol separates links into both directions and treats “downstream” and “upstream” separately. “Downstream” (receiver) neighbors are the first to detect the existence of the link. They propagate this information to other neigh-bors for a limited distance (number of hops). Links are “activated” only when the mes-sage makes it back around to the “upstream” side of the link. This allows unidirectional links to be used.

It is clear from this high level description that Bao’s protocol achieves 100% utilization of resources, less a controlled amount for maintenance of the neighbor database, the amount lost due to packet losses/conflicts (not even considered by Bao), and losses that occur from radios not transmitting when transmission rights are available. The protocol is so simple that it is trivial to modify to achieve other desirable features.

MAC Comparison

Out of the MAC’s proposed so far, the contention-based types appear to give the based throughput. As a minimum, the statistical multiplexing types have a theoretical maxi-mum of ln(2)/N throughput per user, or approximately 0.69, where N is the number of users. If the protocol is synchronous, this increases to 1/N. In either case, each user gets full access to the channel. In reality, some portion of this bandwidth is lost to error cor-rection stripping out the user interference.

The “single contention channel” multichannel types are the best of the multichannel MAC’s. At best, if a collision resolution algorithm could be implemented correctly, the total number of packets scheduled will be approximately 40% of the contention channel bandwidth, based on the idea that collision resolution is only being used to resolve con-flicts and assign channels. Assuming all channels are equal (it is always possible for the contention channel to be “larger” in some way than the data channels), then 40% of the usable system bandwidth is unavailable, giving a system throughput of approximately 0.4/N. So far in practice, only contention-based algorithms have been suggested, reduc-ing throughput to less than approximately 0.35/N. If the contention channel is enlarged in some way so that channels are assigned and collisions resolved at about 3 times the rate of the data channels, then it is possible for contention/collision resolution protocols to increase throughput to near 100%.

There are several people who claim that contention-based MAC’s asymptotically achieve “100% utilization”. This claim is made by assuming that once transmission rights are obtained, the radio keeps its rights and continues to transmit several more packets. This mechanism bypasses contention so if it is being used for some other pur-pose such as enforcing fairness (fair scheduling is not done since there’s no way to account for competing flows and/or radios), the extra packets destroy this function. This issue has not been addressed in those cases.


Flow Control

In the single channel cases, only a single user is allowed to transmit at one time, but the full bandwidth is available. This allows only a single communication in a distinct con-tention region to be active at one time. Bandwidth for contention will be extremely low, but the downside is that with a reasonably wide bandwidth signal, multipath will become a severe problem (lack of coherence). Also, the FCC specifically prohibits this bandwidth usage in the unlicensed case except with severe power limitations. The only way to make this work is to use a single spread spectrum code for all users and take the bandwidth loss induced by spectrum spreading (effectively spreading reduces usable bandwidth). This is exactly the scheme that is implemented in IEEE 802.11 using direct sequence spread spectrum.

True conflict-free systems so far had severe problems with a lack of good scheduling. Bao’s system eliminates that problem. The problem with all conflict free systems (including Bao’s) is flexibly rescheduling bandwidth. Bao’s system appears to be most likely to eliminate this protoblem.

With this in mind, the highest throughput protocol will be one based on statistical multi-plexing, multichannel contention resolution with a single contention channel that is larger than the data channels, or a collision free scheme with rapid adaptability to changing transmission requirements. All 3 protocols should be able to eventually jointly solve the fairness and bandwidth efficiency problem, but the collision free and statistical multiplexing techniques appear to have a slight upper hand at the moment purely because there doesn’t appear to be a good contention protocol with assymetrical channel use/allocation. Single channel contention schemes lose out simply because of the FCC mandate on spectrum usage.

In the following section where a MAC is proposed, the contention schemes were con-sidered first because of their wide spread publicity and apparent asymptotic channel usage. Further analysis showed that they were actually worse than statistical multiplex-ing in terms of system bandwidth utilization since they can only allocate less than 40% of the data channels. Statistical multiplexing appeared to be the clear winner until Bao’s asymptotic randomization technique to using collision free protocols appeared, which appears to be the clear winner at this point, with some modifications to enhance Bao’s original scheme.

Flow Control

At this point, a slight detour is necessary. The various types of MAC’s which handle scheduling of packet transmissions have already been covered. However, this is not the full story. The MAC also influences flow control since it controls the priority and per-mission structure for access to transmit and receive packets. Thus, a MAC should not be developed independently of considering flow control.

A flow is a stream of packets being communicated. This seemingly simple statement has a lot of problems. For instance, does it mean that every radio should have equal access to transmit? This Orwell-style system appears to be basically fair. However, most users will be attempting to pass information to and from a few servers on the network. If


Flow Control

every radio has equal access, then the servers are artificially limited because they have only the same rights as an ordinary user.

Should a stream of packets from a port on one radio to a port on another radio constitute a flow? Superficially, this makes sense. However, it won’t be long before users figure out that they can trivially get unfair access to the network merely by starting multiple communications (such as multiple file downloads) since each communication consti-tutes a “flow”.

The most logical and easiest “flow” to use is all packets that have the same source and destination. This works in the existing internet context. Multiple connections (such as web browsers) do not violate the fundamental concept of fairness. It does become unfair when multiple users share the same radio. In the current communication context, this does not appear to be as large of an issue as it once was since in most cases each user will be equipped with a separate radio.

The “source-destination=flow” concept also does not work when considering “multi-casting”, which is where the same stream is broadcast to multiple receivers. Does a mul-ticast count as one single stream, or multiple streams (one for each receiver or transmitter)? In this case, internet broadcast systems (radio and video-on-demand serv-ers) will have grossly unfair access or experience unfair limitations simply because they use multicasting. This problem does not yet have a satisfactory answer. These types of problems are difficult in part because they are philosophical in nature.

Finally, should all flows have equal access? First off, it is fundamentally impossible to provide true equal access (see the section in contention protocols). Even with a wired network, congestion happens. Some flows by their nature are going to receive less band-width than others just due to network congestion.

Equal access may also be undesirable for other reasons. For instance, a bulk data trans-fer such as email or file transfers is not very sensitive to delay. In this case, it is raw bandwidth that matters most. Interactive access such as chat systems or especially voice communications are very sensitive to delay. At the same time, interactive systems usu-ally have a relatively fixed bandwidth requirement (although they can scale their quality to increase and decrease bandwidth).

It turns out that there is a sort of fundamental axiom of networks that the higher the bandwidth used by applications, the more delay there will be in the system. The only way to avoid delay is to run the system somewhat below full utilization of all available bandwidth.

One way to increase bandwidth to a flow is to give it priority over other flows. This simultaneously decreases delay. However, when the network is structured so that the network is not run by the same people, who decides which flows get priority over oth-ers? It is easy to decide in networks such as cellular phones where users can pay for higher privileges. It is not easy when all users are essentially “equal” and applications are not dictated by the system.

Considering the case of voice communications vs. bulk data transfers for a moment, it is clear that bulk data transfers require maximum throughput, almost without regard for


Flow Control

delay. The current internet provides this kind of access. Voice communications can ben-efit by being able to control delay, but the quality can be adjusted to account for lack of bandwidth.

The one area is where flows can vary their relative privileges compared to one another. So long as a flow voluntarily (or involuntarily) behaves itself by using less than equal bandwidth to the network, it should be possible to trade bandwidth for delay in a fair way. The scheduling “resources” to handle the low delay, lower bandwidth connection should remain the same since the user is simply requesting lower delay in exchange for lower available bandwidth.

One very difficult problem with schedulers (other than one of making priorities work) is isolation of flows. The idea is that it should be possible for each flow to pass through the network with the same access and priority as all of the other flows receive regardless of any problems and misbehaviors in the other flows.

For instance, take the simple First Come, First Serve (FCFS) scheduler that is used almost universally in internet routers. This scheduler queues packets up in the order they are received. The faster a transmitter can get packets into the scheduler, the faster it manages to get packets transmitted. Flows which are “slow and steady” suffer delays and bursty packet reception purely because other “bursty” flows flood the buffer in a router with several packets in a row. Good schedulers won’t allow this to happen since every flow should be treated essentially equally.

THE MEANING OF “FLOWS” Conceptually, what constitutes a “flow” is hard to pin down, as already described. For the purposes of allocating resources and scheduling packets however, the only packets that matter are the ones that are already in the network, waiting for transmission. For this reason, only “active” flows need to be considered. “Active” flows are ones where packets are waiting in buffers. Some applications transmit a continuous stream of pack-ets and keep the buffers filled up. Others actually transmit packets in bursts. A “flow” in terms of a bursty application is just a single burst. In between, the buffer for the flow empties out and becomes inconsequential.

THE FLUID MODEL PACKET SCHEDULER

The theoretical “perfect” model for flow control is called the Generalized Processor Sharing (GPS) algorithm.The fluid model is relatively easy to understand. At any given time, there are flows passing through the radio. Some of those flows have packets backed up (queued) at the radio. The flows have various priorities. The system transmits each of the queues of packets simultaneously in proportion to their priorities.

This model makes obvious sense but it has 2 slight problems. First off, the rate that the queues are served is directly proportional to their priorities. Unfortunately, only one packet can be scheduled for transmission at a time, so reality flies in the face of the fluid model because it requires all flows to be transmitted simultaneously. Second, data is transmitted in whole packets or at least in terms of individual bits, not exact fractional amounts. These two limitations mean that the “perfectly fair” model can’t be directly achieved. Instead, all packet scheduling systems use some sort of approximation.


Flow Control

PACKET FAIR QUEUEING Packet schedulers that take flows into account usually emulate the fluid model inter-nally and attempt to transmit packets in the order necessary to approximate the fluid model. The idea is to transmit packets in the order that they would finish transmitting in the fluid model. The problem is that it is essentially impossible to calculate the actual finish times. Fortunately, it is not necessary to actually calculate the finish times. It is only necessary to keep the finish times in the right order. Then transmit packets in the order of those finish times. Internally, the approximation algorithms algorithms main-tain a system virtual time, V(t). Virtual time represents the amount of service that the flows should have received by time t. It represents the progress of the fluid model. The different algorithms vary in how they actually calculate the system virtual time.

For each flow, two more functions are calculated. S(t) is called the virtual start time. S(t) represents the normalized amount of service that the flow should have received by time t. The goal of all fair queueing algorithms is to minimize the discrepancies between each flow’s S(t) and the system virtual time, V(t).

For each flow, a virtual finish time, F(t) is also maintained. Finish times represent the normalized virtual time that a flow will reach when a packet is transmitted.

The virtual start and virtual finish times are calculated for each flow each time that a packet is received or transmitted for a flow. The virtual start time for the flow equals the virtual finish time when a packet finishes transmission. When a packet is received, the virtual start time equals either the previous largest finish time or the system virtual time, whichever is larger. The virtual finish time can then be recalculated as the virtual start time plus the length of time necessary to transmit the packet divided by the rate allo-cated to the packet (the priority).

The difference between various fair queueing algorithms is how they actually calculate the system virtual time. In Self Clocked Fair Queueing (SCFQ), the system virtual time is equal to the virtual finish time of the packet currently being transmitted. The algo-rithm becomes quite trivial, but the bounds on delay are much larger than the fluid model. As the buffer grows, the degree of fairness degrades significantly. The problem is that SCFQ only calculates transmission times based on current packets. Future pack-ets will cause the fluid server to slow down the transmission rate, which SCFQ doesn’t account for.

The most common algorithm is called PGPS (Packet-by-packet Generalized Packet Server) or WFQ (Weighted Fair Queueing) which avoids the problem with SCFQ. Another queueing algorithm is called Frame Based Fair Queueing (FBFQ). This algo-rithm can also be constructed to provide exactly the same delay bounds as WFQ, but it can be calculated directly from the packet system so it is faster than WFQ.

In the WFQ algorithm, the system virtual time is equal to 0 when no packets are back-logged. While packets are backlogged, it increases at a rate equal to the sum of the rates of all active flows (flows which have packets queued). This means that it is necessary to keep track of virtual time continuously. When new packets arrive for flows, it causes all the virtual start and finish times to be incorrect. They have to be recalculated every time a packet arrives. This makes WFQ computationally difficult to actually implement in the “direct” form.


Flow Control

All of the algorithms so far pick the packet to transmit that has the smallest virtual fin-ish time. This is called the SFF, or Smallest virtual Finish time First policy. To improve on these systems, the scheduler schedules the next packet to transmit among the elgible packets. A packet is elgible to transmit only if the virtual start time of the packet in the flow is no greater than the current virtual time. The policy is called “Smallest Elgible Finish time First”, or SEFF. The reason for this extra rule is that a packet can’t begin transmission in the real world if it hasn’t already begun transmission in the fluid model (calculated by virtual time). This makes the next two the most accurate scheduling algo-rithms available.

WF2Q is identical to WFQ except for the SEFF rule instead of the SFF rule. This gaurantees that WF2Q doesn’t ever vary from the results provided by the fluid server by more than a fraction of a packet.

The last scheduler is called WF2Q+. WF2Q is the most accurate scheduler (it has been proven to be the optimal scheduler). WF2Q+ improves on WF2Q by providing all of the important properties on WF2Q but the virtual time function can be calculated based on the packets in the buffer without resorting to a separate fluid model. The virtual time function is calculated as follows:

V(t) must be calculated recursively (which makes it the slowest algorithm). The final term essentially means the minimum start time of all of the flows.

ADDITIONAL PROBLEMS Radio links are fundamentally unfair in other ways. The contention problem (the fact that packets can block each other) defines one type of unfairness. Two other problems also surface. First, not all radio links have uniformly equal error rates. Some links are inherently more prone to errors than others. This means that some packets will suffer more errors than others, leading to a type of unfairness.

The second problem only creeps in while using collision free systems. Under collision resolution/contention protocols, scheduling decisions are made on a packet-by-packet basis through the collision resolution protocols. Under statistical multiplexing, schedul-ing decisions are made by a scheduling protocol. Under collision free algorithms, sched-uling decisions have to be made on a per-flow basis rather than a per-packet basis. For this reason, dead space (holes) can occur because flows don’t have packets to send. Also, flows may experience some delay due to waiting in queue until the synchroniza-tion opportunity arrives in which new flows can announce their presence. These types of MAC-induced problems create some additional unfairness.

TRAFFIC SHAPERS Aside from the problem of scheduling, there are also shapers. These are used to handle the problem of limited storage buffers. A radio only has a minimum storage space to hold packets that are waiting for transmission. Once the buffer space is used up, the only way to deal with more is to start dumping the excess packets. Either packets in the buffer or incoming packets need to be dumped. This means that the selection of packets to discard should be done once again according to fairness. Flows with the same priority should get equal buffer space.

V t r+( ) max V t( ) r min Si t( )( ),+( )=


Hash Functions

In addition, if it is possible for flows to request lower delays (higher priority in the scheduler) while simultaneously being restricted to lower bandwidth, this is a situation where both the shaper (which will reject the excess packets) and the scheduler have to work together. This function is necessary even if all flows are assigned a fixed amount of bandwidth. If momentary fluctuations in the network load happen, they can cause surges of packets, causing a flow to exceed a downstream buffer even if the upstream radios did not have a problem.

The “ideal shaper” is called a leaky bucket. A “token generator” generates credits at a fixed rate. The credits go into a credit bucket. The bucket can only hold a fixed number of credits. Arriving packets must have a credit available in order to be processed. Excess packets are thrown away. A leaky gaurantees that packets in a flow can only be received at a maximum rate (set by the size of the bucket). It also gaurantees that packets can’t exceed a certain average rate (determined by the token generator), regardless of surges in the flow.

The combination of the shaper and the scheduler determines the delay-bandwidth prod-uct that is available to a flow. The shaper defines a maximum bandwidth (set by the token generator) and delay (set by the credit bucket). The scheduler has a single adjust-able parameter (the priority) which controls both bandwidth and delay. By using the shaper to control available bandwidth and the scheduler to control delay, this allows flows to alter their bandwidth and delays in a fair way since the network load for a flow is the same as long as the delay-bandwidth product is identical.

Hash Functions

Hash functions are a necessary part of statistically randomizing transmissions in order to provide statistical fairness to all flows. Essentially what a hashing function does is to take some input and generate a statistically uniform output (the hash) based on the sup-plied inputs.

“Perfect” hashes are hashes where every input combination is assigned to a unique out-put combination where there are no duplicates (different combinations hash to different values). The easiest way to calculate a perfect hash is simply to list all of the possible inputs in a table and assign the rows to equal hash values (row 1=1, row 2=2, etc.).

In this case, collisions will probably be a fact of life because the hash will be based on a counter (to prevent statistically “bad” patterns from occurring), the source address, and the destination address. Since addresses will probably be around 32 bits or more, and the counter will be at least a few bits as well, input combinations will be on the order of 70 bits. Only a few (less than 100) slots will be available for transmission and the hash only has to differentiate users in a single slot (probably less than a dozen), leaving the necessary length of the hash to be around 20 bits or less. This means that collisions will occur, so perfect hashing is not possible.

Some hashes that are commonly available now such as MD4, MD5, and SHA, are “cryptographically secure” hashes. In this case, the idea is that it is extremely difficult to determine what the input to the hash function was with only the output (hash value)


Hash Functions

available. These functions are used for example in digital signatures. Using encryption on the whole document to “prove” that the user transmitting it knows how to encrypt/decrypt the document (thus proving that signer knows the encryption/decryption key) is computationally slow and wastes a lot of bandwidth. A hash can “represent” the whole document and a user can just encrypt/decrypt the hash, providing a digital signature. Since it is extremely difficult to determine the input combinations in a cryptographically secure hash, someone else can’t forge/alter a digitally signed document easily.

In this particular case, cryptographically secure hashes aren’t necessary, they require quite a bit of calculations to use, and they usually produce very large hashes relative to the size of the input available in this case (since larger hashes==fewer chances to forge). All that is necessary is that the output is sufficient randomized (must be statistically uni-formly random). The easiest way to do this is with a random number generator where the “seed” for the random number generator is the input to the hash and the output is the hash value. The danger of this approach is that conventional random number generators are not very good as hashes because they have a tendency to show “bad” patterns.

In this case however, it is known that some of the addresses will be clustered and that each seed value will be very close to previous values (from the effect of a frame counter, etc.). The goal is just to spread out those values. For this purpose, “good” choices parameters of the previously mentioned “bad” random number generators will be ade-quate.

The particular hash function in question is a so-called “universal” hash function. The equation for it is:

The “mod” or “modular arithmetic” operator means to divide and take the remainder, so 9 mod 4 means divide 9 by 4, taking the remainder. Since 9/4=1 with a remainder of 1, the result is 1.

The parameters c, d, and p come from the particular random number generator being used. x is the input to the hash equation (the number to be hashed). The number m con-trols the output, trimming the output values to end up in the range of 0 to m-1. It turns out that it is also hard to do the modulus operations very quickly except in the special case where m is a power of 2 (such as m=256 or 65536). If c and d are chosen poorly, they will cause loops or poor randomness. There is a lot of development that has been done regarding picking “good” values for c, d, and p.

Alternatively, another proposed hash function is the shift-add-xor function. It was opti-mized for strings, but can work here. Addresses are nothing more than a kind of text string, with text-string like properties (addresses will probably form small clusters). So it would be valid to use this generator as well:

This function is designed specifically to use 32 bit hash values. The usual modulus trick is used at the end to trim the hash down to size. The idea here is to “chain” the hash function along a string. Starting with an initial hash value of 0, each character value is

hash cx d+( )modp( )modm=

hash h h 5«( ) h 2»( ) value+ +( )⊕=


Proposed MAC

fed into the equation along with the previously calculated hash value. h is the previously calculated hash value. The symbol << means to left shift the result (<< 5 means left shift the value 5 bits) and >> means right shifting. The symbol ⊕ means the exclusive-or operation in this case. The equation combines the previous hash value with the new input character, generating a hash as it progresses. The modular arithmetic hash calcula-tor can be converted to work similarly with some mathematical manipulation.

Proposed MAC

The proposed MAC is based on a conflict free scheme. Bao’s conflict free scheme has the advantage that it can fully utilize all available channels, although it does require a small amount of resources be devoted to various types of synchronization. The precise nature of that synchronization and also handling power control is not done.

Conflict free schemes have one basic problem: they are “NP-complete”. That is, actu-ally calculating the appropriate schedule for transmission is computationally infeasible. One simple algorithm is the “greedy one”. Simply take each flow/radio in turn and determine the schedule for that one. Do them in order, ignoring the “problems” that will be created down the road.

In general, greedy algorithms are far from perfect. However, they come to within a short ways from being “perfect”. The order of which radios or flows are scheduled first is important. One of the greatest new achievements to come out of theoretical computer science in years is the idea of “derandomization”. A standard “random” algorithm that is pretty close to optimal (such as a greedy scheduler) requires a source of random num-bers. The question is: how random do those numbers have to be?

If a source is “random enough”, then the algorithm will work as it is supposed to. If “random enough” is acceptable, then the challenge is to design a “random number gen-erator” that supplies “random enough” numbers. And since the generator is now actu-ally a simple algorithm, each radio can run it independently of the others...so communication for scheduling purposes is minimized.

FLOWS Bao’s collision free protocol family makes it possible for all radios to have equal access to the radio channel. However, this doesn’t help flow control. The various MAC’s that address flow control all attempt to give equal access to flows. In the case of the pro-posed MAC, it is trivial to leap-frog that technology very easily. Simply use “flows” instead of “radios” or “nodes” in Bao’s formulations. Now individual flows are given statistically equal access (within the limitations of the radio medium). An individual radio is given higher transmit privileges when it carries more flows.

Making this one slight modification (schedule flows, not radios) makes Bao’s algorithm apply to flows. The scheduling problem is now over 50% solved. The remaining prob-lems are all in terms of synchronization...how to actually boot the network and deal with changing conditions. These issues were left out of Bao’s work, except for passing men-tion of a nonscalable technique.


Proposed MAC

SYNCHRONIZATION REQUIREMENTS

In order for the conflict free schemes to work (regardless of which version it is), syn-chronization is an absolute necessity. Usually, it is assumed that the entire network is synchronized globally, but the details of achieving this are not mentioned. Global syn-chronization has an Achille’s heel: it is necessary to spread the “synchronization” mes-sage throughout the network. So as the size of the network grows, the communication requirements just to maintain synchronization grow until they consume the network. Global synchronization is simply not scalable.

Global synchronization is actually not necessary. In fact, it is only necessary to be syn-chronized with one-hop and two-hop neighbors since synchronization is only necessary to eliminate interference between them. So a protocol that only works as far as synchro-nizing and maintaining synchronization between 1-hop and 2-hop neighbors is all that is necessary. The network may not be truly “globally” synchronized, but there is enough synchronization between neighbors that it is synchronized enough to work properly.

A second requirement with synchronization is the network should be self-synchroniz-ing. Since the radios are designed to be scattered over a large area and perform essen-tially without external dependence on a source of synchronization such as a GPS receiver or a central cellular network, they must be able to synchronize and maintain synchronization autonomously.

Going along with self-synchronization is fault localization. There are two basic ways of synchronizing. In one case, when a change in the network happens such as a radio being turned on or off or physically moving so that links are altered, this triggers a “fault” in synchronization. One method of handling this is that a “resynchronize” message goes out across the network and all of the radios go into a “resynchronization” mode while suspending normal conflict-free communications. This type of algorithm is extremely simple to design.

The problem with a global “resynchronize” message is that once again, it lacks scalabil-ity. Instead, the “fault” should only affect the small area of the network where synchro-nization has been lost. The rest of the network should be able to operate normally. So the second necessary principle is “faul localization”: keeping the synchronization prob-lem only within those radios that are being affected.

There are several kinds of “faults” that can happen. Some examples are when a radio is turned on or off, or when a radio moves far enough away or close enough that a link is either broken or created. When a radio is first switched on, it will not be synchronized. Worse yet, it may actually be in range of two separate isolated parts of the network (par-titions) and forms a bridge between them. Synchronization may actually be different in each of the networks. This violates the “synchronize with 1-hop and 2-hop neighbors” rule, but in an insidious way: previously synchronized radios are now actually violating the synchronization rules.

SYNCHRONIZATION ALGORITHMS

Most of the current synchronization algorithms have very similar structures. They oper-ate in the following way:

1. Time is divided into “rounds”.


Proposed MAC

2. During the round, radios broadcast messages to each other. The messages indicate what the current logical time is at each radio and measurements of time that radios have received from their neighbors.

3. At the end of a “round” (which is somewhat difficult to determine since “time” may be different at each radio), each radio runs the synchronization algorithm.

4. The synchronization algorithm takes inputs from the messages which are measure-ments of logical time at each of the neighbors.

5. After combining these results, the radio estimates some kind of “average” between the time measurements.

6. The radio resets it’s own logical clock to match the “average” calculated from the messages.

7. The process repeats itself. Radios make measurements of time during the next round, and then reset their logical clocks at the end of the next round.

The content of the messages, the way in which the measurements are made and the way in which the “average” is calculated depends on the particular algorithm. “Logical” time is essentially an average or agreed common time. It may be slightly different at each radio, but the averaging calculation is designed so that logical time at all neighbors con-verges to the same value over time.

HARDWARE CLOCKS Each radio is assumed to have an on-board quartz crystal clock. Quartz clocks normally have an accuracy of about 100 parts-per-million (ppm), or an accuracy of approximately ±100 seconds out of every million seconds. Even if all clocks are synchronized initially, the longer they run without periodic resynchronization, the further they will drift apart, since every clock is only somewhere in that ±100 ppm range. So even if clocks were ini-tially synchronized perfectly at the factory or during startup, they must still be periodi-cally resynchronized.

If the accuracy is ρ and the time from the last synchronization is t, then the most that two clocks can drift apart is 2ρt. The 2 is in the equation because one clock may be run-ning faster (+100 ppm) while the other one is running much slower (-100 ppm) than the average.

ACCURACY REQUIREMENTS

As already mentioned, the accuracy of the on-board clock is ρ. The on-board clock is used to determine the logical clock. The logical clock is just the value of the on board clock plus an adjustment factor, which is calculating by the averaging function.

The conflict free algorithm requires synchronization to within d seconds. If a radio is off by more than d seconds, then the conflict free algorithm will not work (interference can occur). So the synchronization algorithm is responsible for keeping logical clocks accu-rate to within d seconds.

Since the local logical time is not always quite the same at every single radio, enough time needs to be allowed for at the end of a round that all radios have reset their logical clocks before beginning a new round. Otherwise, the averaging function may get con-fused because radios are operating in different rounds. Thus, all clocks have to be syn-chronized to within β seconds. β is equal to (1+ρ)d.


Proposed MAC

In this case, the maximum deviation between any two clocks is:

Λ is the maximum error that can occur when reading a remote clock (dependent on the communication system). rmax is the maximum length of a round in real time which accounts for hardware clock drift, or (1+ρ)P+d. P is the clock time duration of a round (which is the calculated value), or at least (2+3ρ)d.

SYNCHRONIZATION CHANNEL MAC

In order to send synchronization messages, there must be a protocol. Since radios may not necessarily be synchronized, the conflict free scheme can’t be used simultaneously for synchronization unless they cease data communication periodically. If all radios cease communication during synchronization, then the scalability and fault localization problems show up again. So a separate channel needs to be used.

The protocol on this separate channel needs to be as simple as possible. Knowing that fairly good rates can be achieved with statistical multiplexing schemes, this appears ini-tially to be a good idea. However, the truly “good” statistical multiplexing schemes also require radios to do some sort of synchronization to use good “channels”. So this leaves some sort of contention scheme as the alternative.

Radios probably won’t be able to detect interference either (since it is a single channel protocol), so alternatively, they must rely on RTS/CTS. The problem with RTS/CTS message exchanges is that first of all, broadcast messages are a problem. If the radio waits for positive feedback, it becomes a problem since the neighbors are not aware of WHEN to reply with a CTS and because multiple simultaneous transmissions cause interference. Second, the goal is to make the synchronization messages extremely short. If they are shorter than a standard data packet, then the advantage gained by the RTS/CTS packets (interference elimination during data packet transmission) is lost compared to the extra overhead. Instead, an RTR followed by a response packet will be used. The RTR will be capable of specifying multiple receivers. Each receiver broadcasts in the order specified by the RTR packet.

MAC PROTOCOL The MAC protocol used is essentially “RIMA-BP” with one small modification. The extra data necessary for time estimation is transmitted in the RTR packet, eliminating the need for extra transmissions. The packet format for the RTR (Ready-To-Receive) packet is fairly simple. It simply contains the following information:

• The address of the sending radio.• The current logical time.• The number of intended receivers.• The list of intended receivers.• A flag indicating whether the radio considers itself synchronized.

When a radio needs to check the time at another radio, it first waits for twice the maxi-mum channel propagation time (time delay) and listens for activity. If there is no activ-ity, then it goes ahead and sends an RTR. If activity occurs, then it goes into a collision resolution protocol, such as the 2-cell algorithm.

4Λ 4ρrmax 2ρβ+ +


Proposed MAC

Each receiver then responds with a response packet. The packets are sent in fixed time windows, in the order of the list that was given in the RTR packet. Each response packet contains the following information:

• The address of the sending radio.• The current logical time.• The logical time when the RTR packet was received.• A flag indicating whether the radio considers itself synchronized.• The number of 1-hop neighbors. If this number is equal to 0, then the number of one

hop neighbors is equal to the maximum allowed to be transmitted in a single packet. If it is equal to the maximum, then the list is incomplete. In subsequent polls, the radio will pass on the rest of the list. In this way, radios can tolerate more neighbors than the fixed size packets allow for.

• A list of the addresses of the 1-hop neighbors, logical time estimates for them, and a synchronization flag.

Relying on an intermediate radio unfortunately doubles the error probability for 2-hop neighbors but there is no way for a radio to directly communicate with 2-hop neighbors by definition.

The first responder to the RTR packet has to wait for a small amount of extra time to allow time for any possible collisions to be detected, equal to 4 times the maximum length of time it takes for a signal to propagate. During that time, if the radio that sent the RTR detects any other transmissions, then it responds with an NTR which instructs the receivers to ignore the original RTR. Fortunately, the propagation time is much smaller than the length of time required to send a packet.

Using this simple protocol, a radio can poll all of it’s neighbors fairly quickly to deter-mine the time at those neighbors and at the 2-hop neighbors. The response packets are sent clearly with no interference with high probability.

The one real constraint on the synchronization channel is the FCC. The FCC has decreed a maximum per-channel utilization of 0.4 seconds out of every 30 second period. This sets a maximum per-radio utilization of 1.33%. The synchronization proto-col must live within this boundary. This means that radios can’t simply arbitrarily trans-mit at any time. The total volume of traffic must be constrained so that it does not exceed 1.33%. Normally, this is not an issue because all the FCC limitation does is require fairly long rounds and spread the traffic out so that the capacity of the synchro-nization channel is very large in terms of the number of radios that can be supported.

Power control is actually done at a higher level and is dictated at that higher level. The synchronization protocol is simply allocated a power level to use.

REMOTE CLOCK ESTIMATION

Once a radio sends out an RTR and gets a response, it has collected several pieces of data. It knows the local logical time at the remote radio when the RTR was received. It knows when the remote response was sent. It also knows when the RTR was sent and the response was received. Based on information from the remote radio, the elapsed time can be calculated. The remaining difference in local time is the round trip propaga-tion time. Assuming approximately 1/2 of this value is the propagation time in one


Proposed MAC

direction, the radio can simply add this time to the time when the RTR was sent. Then after subtracting the remote time when the RTR was received, the radio can arrive at an estimate of the time difference between the remote and local logical clocks.

INITIALIZATION XXX

ROUNDS XXX

LOGICAL TIME ADJUSTMENT

At the end of a round, a radio computes the new adjustment factor to apply to the on board hardware clock to calculate logical time. First, the time estimates for the 1-hop and 2-hop neighbors are checked as follows:

1. All 1-hop and 2-hop neighbors that are within d seconds of local logical time are considered synchronized.

2. A radio itself is synchronized if all 1-hop neighbors are within d seconds of logical time. These first two rules declare synchronization unconditionally.

3. A radio itself is synchronized if it declared itself synchronized and it remains within d seconds of all 1-hop neighbors that declared themselves synchronized. This rule maintains synchronization whenever possible and expands synchronization when-ever possible independently of all nearby radios that are not synchronized.

4. All 2-hop neighbors that are declared synchronized are considered synchronized.5. All 2-hop neighbors that have not been declared synchronized but are also 2-hop

neighbors only of unsynchronized 1-hop neighbors are considered synchronized, but only for the purposes of calculating the adjustment factor.

The last rule sounds rather strange, but it is an extremely important rule. When a parti-tion of the network is detected, it will most likely be declared “unsynchronized”. If this is the case, it is necessary for the two partitions to drift towards a common synchroniza-tion state. The intervening radios will consider themselves “unsynchronized” (failing rule 3). Similarly, rule 4 does the same for partitions where there are actually 2 interven-ing “unsynchronized” radios.

Now, the adjustment factor is calculated by combining the clock times of all of the radios that have been determined to be synchronized by the 5 rules. For unsynchronized radios, this means that their adjustment factors will be immediately reset to something close to “correct”. After a one-round waiting period, if their logical clocks are reading correctly, they will be considered “synchronized”.

The correction function is as follows. First, determine the largest and smallest remote logical clock differences (based on message exchanges). For an unsynchronized radio, go ahead and calculate the adjustment value as (largest+smallest)/2. For a synchronized radio, it must not be allowed to drift too fast or synchronization will be lost. In this case, substitute the largest adjustment if the largest logical clock difference is larger than that value and do the same with the smallest allowable adjustment value (the adjustment fac-tor is ±Λ). Then calculate the midpoint as usual. The midpoint becomes the adjustment factor to apply to the current adjustment factor. Use this new adjustment factor for the logical clock in the next round.


Fair Conflict Free Protocol


Once synchronization is achieved (the radio declares itself synchronized and maintains that condition for one full clock synchronization round), the actual conflict free protocol can be activated. Until synchronization is achieved, a radio will not be allowed to trans-mit and receive data.

The system bandwidth is split out into several separate channels. Time is also divided into even units. A radio can only transmit a packet that fits within the channel and within the time slot. At least 60 dB of filtering should be used to avoid adjacent channel interference problems. A “guard time” is necessary at the edges of the time slot. The size of the guard band is equal to the maximum propagation time for a packet (maxi-mum transmission distance divided by the speed of light) plus the maximum allowed uncertainty from the synchronization protocol. The synchronization protocol gaurantees that interference can’t happen so long as radios don’t try to transmit during the guard times.

Each radio is equipped with a device called a circulator. This device allows the radio to transmit and receive simultaneously as long as the transmission and reception are on separate channels. Strictly speaking, the circulator isn’t necessary since the activity is on separate channels but it will be necessary for dynamic range reasons (discussed more in the hardware section).

Each radio can simultaneously receive on up to a fixed number of channels simulta-neously. The channels to be monitored are specified by the MAC. These two combina-tions (transmit and receive simultaneously along with multiuser receiving) mean that that effective system bandwidth that can be used is much higher than what is tradition-ally possible.

Each radio is equipped with the ability to detect power levels during receiving and has a variable power transmitter. The transmitter has a minimum and maximum power range. It does have discrete power levels (3 dB) but this won’t matter in practice.

In terms of measurement, it would be nice to assume that power levels are relatively constant. Knowing that they are not actually constant, each radio will be making and transmitting measurements over a period of time to determine both the average and spread (standard deviation) on those measurements. In addition, the idea that losses are the same in both directions will not be used. Furthermore, it won’t be assumed that radios can necessarily even talk to each other directly in both directions.

All transmissions are transmitted with error correction. The transmission exceeds any noise as well as any measured power losses. The error correction attached to the packet gaurantees that errors that do occur (which are measurable) are corrected. The system does not absolutely gaurantee that a packet will be received error-free (by the nature of the system), but it gets it to within a known probability of error (<1% chance of a bad packet).

PROPOSED CONFLICT FREE MAC

Each flow has a specified transmission power level, a source, and a list of destinations (which may be all nearby one-hop neighbors). Each slot is numbered using an 8 bit



number, from 0 to 207. There are 52 channels (the required number in the 915 MHz band). The actual destination is essentially assumed for the flow (described during star-tup). The source and the slot number are marked on every single packet, to avoid prob-lems with synchronization.

Each radio has a list of active flows. The list includes the following information:

• The fractional bandwidth currently used by the flow. (0-1). This is in terms of the maximum bandwidth available, not the total bandwidth.

• A list of destinations.

In addition, each radio has a list of one-hop and two-hop neighbors and their current transmission power levels.

At the beginning of each slot, each radio does the following calculations simulta-neously. First, a priority is calculated for every single active flow:

The flows are sorted in order according to their priorities. The channels are doled out in priority order, with the following rules:

• One flow per channel.• A radio may not transmit in more than one channel at a time.• A radio may not receive more than it’s specified maximum number of flows at one

time.

The priority/scheduling protocol listed above doles out slots to each radio. Each radio then picks a packet to transmit (it may use other flows if a flow does not have a packet ready to send) and sends it in the slot. Channel utilization is nearly 100%. It is only lim-ited by the inherent unfairness (in terms of flow contention), the guard times, and the bandwidth used for synchronization.

FLOW INITIALIZATION The one remaining problem is updating the flows. Every radio has a default flow. This flow initially has a priority of “1” but can itself be updated to be changed. The radio uses this flow for a simple purpose. It is necessary to essentially “bootstrap” the data-base of flows. So new flows are broadcasted using this “extra” flow, which consists of a broadcast to all 1-hop neighbors. Essentially, this protocol is vaguely similar to the internet ICMP protocol.

The final requirement is that updating the database of known flows must be done in such a way that it is done transparently and simultaneously at every single radio. If this is not done, then radios will make different decisions and lose their lock-step nature which is absolutely critical to maintaining the conflict free system.

Priority Hash Source radio address Slot #,( )Bandwidth

------------------------------------------------------------------------------------=


free network design, part 2: medium access protocols

Documents