CSMA - Carrier Sense Multiple Access

This document describes the parameters and systems in packet radio stations to avoid interfering with each other on a single channel.

Each TNC is equipped with circuitry to recognize that the channel either does or does not have somebody already transmitting. If somebody is transmitting (and the stations are in range of each other) the TNC will wait until the channel is clear before transmitting. CSMA is the term which describes having a transmitter wait until the channel is clear.

But wait, there's more!

In the real world, TNCs and radios don't go on the air instantly after testing to see if the channel is clear. There is a real delay in starting up the transmitter. The switchover period is measured by the installer (that's you) and configured into the TNC using a figure (or a knob) called TXDELAY.

There may be more than one TNC waiting to transmit onto the channel and merely waiting for channel clear may not be enough to avoid clobbering somebody else's transmission. Parameters in the TNC allow the operator to configure the TNC for channel sharing.

PPERSIST and SLOTTIME

The TNC default values for PPERSIST and SLOTTIME are 64 and 10 where the 64 represents a figure used in a chance calculation and 10 represents the number of 10s of milliseconds used in a test period. If the SLOTTIME was 5, then 50mS is the test period. If SLOTTIME is 10, then 100mS is the test period.

When a TNC has a packet ready to go, it performs a carrier sense (look at the frequency) to see if anybody is sending a packet already. If the frequency is clear, the station watches the frequency for a SLOT-TIME period, and if the frequency stays clear for SLOT-TIME, the TNC it does a random number calculation generating a value of 0 through 255. If the result is lower than the PPERSIST setting for that station, the station starts generating a packet and sets its radio to transmit. If the PPERSIST number is lower than the random figure, then the station waits for the channel to be clear and stay clear for SLOT-TIME and then does the random calculation again.

It is desirable to set PPERSIST equal to 256 ÷ number of stations that can be heard by the station I'm sending to, which could mean "all stations minus one." If we presume there are 5 operators on the channel and that the TNCs are set up appropriately then 64 would be the desired PPERSIST value. The channel behavior is described below.

Packet Radio with Two Stations

Here is a scenario to help understand what actually happens between stations.

If you had two packet radio stations and your own private frequency, and one station had traffic to send, as the data was queued up in one TNC to send, the other would then acknowledge. Since there are only two stations, PPERSIST can be set to 255, i.e. I always get to transmit. This is what the timing would look like for two stations, Sergey and Sigmund. Sergey is using an Alinco DR135T which has 300mS of TxDelay. Sigmund is using an Icom ID880 which has 100mS of TxDelay

00:00.000 Sergey hits the <return> key on his computer to send an 80 character message.
00:00.300 300mS later Sergey's radio is on-the-air and the packet starts.
00:01.300 1 second later Sergey's radio is done sending the packet and unkeys.
00:01.300 Sigmund's TNC, having decoded Sergey's packet has generated an automatic acknowledgement.
00:01.400 100mS later Sigmund's radio is on-the-air and the packet starts.
00:01.700 300mS later Sigmund's radio is done sending the acknowledgement and unkeys.

It takes about 2 seconds to do a single exchange between two stations with 80 characters in the packet, or 40 characters per second. If there were 210 characters in the packet, it would take about 3.5 seconds, giving us approximately 70 characters per second. A further optimization would be to send characters in the return packet sent by Sigmund, or to send more than one data packet at a time from Sergey. Both of these optimizations are permitted by AX.25 packet radio protocol.

Beware that this is a simplification. In reality the radios take some time to unkey as well. The ID880, for instance, takes longer to unkey than it does to start transmitting.

Please note that the above is considered great throughput. Most packet radio transactions are much slower than that! See below.

Packet Radio with Five Stations

What if there was more than 1 station with traffic in a local group? If one keyed up when another was transmitting there would be a collision and packet data would be lost. The end result would be great throughput, as above, when one station had something to send, and zero throughput if more than one had something to send.

CSMA is a compromise implemented in the TNCs and node software we use for packet radio and was implemented to solve this problem, but at a cost. CSMA was designed for a flat network, where every station could hear every other station. Coaxial Ethernet wiring, where every station is on the same Ethernet, is one example where CSMA is practical. Packet radio networks are rarely implemented such that CSMA is effective.

Here's how it works:
Since each of the 5 operators knows that there are 4 other stations, they all have their number set to 64. SLOT-TIME is set for a number which works out to how long a station could be moving from receive to transmit, yet not putting out a recognize-able signal that the other TNCs could detect. SLOT-TIME is therefore set to the number for the slowest station on the channel.

See below for a more complete definition of SLOTTIME.

Let's assume that Bob's Icom IC228 at 400mS is the slowest.

If a transmission is made, the station it is connected to will answer with the same rules.

In this scenario we'll assume for simplicity sake that each message is sent in a single packet, i.e. MAXFRAME is set to 1 and all of the messages are short enough that the outgoing packet is only 80 characters long. We'll assume that with a 4:1 chance of keying when no activity, that it takes 4 both times.

00:00.000 Sergey hits return on his computer to send a message. The channel is clear.
00:00.400 400mS later the channel has stayed clear, Sergey's Ppersist calculation results in 85, no transmit yet.
00:00.800 400mS later the channel has stayed clear, Sergey's Ppersist calculation results in 182, no transmit yet.
00:01.200 400mS later the channel has stayed clear, Sergey's Ppersist calculation results in 126, no transmit yet.
00:01.600 400mS later the channel has stayed clear, Sergey's Ppersist calculation results in 61, key the transmitter.
00:01.900 300mS later Sergey's radio is on-the-air and the packet starts.
00:02.900 1 second later Sergey's radio is done sending the packet and unkeys.
00:02.900 Sigmund's TNC, having decoded Sergey's packet has generated an automatic acknowledgement.
00:03.300 400mS later, channel having stayed clear, Sigmund's Ppersist calculation results in 102, no transmit yet.
00:03.700 400mS later, channel having stayed clear, Sigmund's Ppersist calculation results in 66, no transmit yet.
00:04.100 400mS later, channel having stayed clear, Sigmund's Ppersist calculation results in 204, no transmit yet.
00:04.500 400mS later, channel having stayed clear, Sigmund's Ppersist calculation results in 7, Sigmund's radio key's up to send the acknowledgement.
00:04.700 200mS later Sigmund's radio is on-the-air and the packet starts.
00:05.000 300mS later Sigmund's radio is done sending the acknowledgement and unkeys.

That's what a perfect packet transaction in a CSMA domain set up for 5 stations looks like. The rate of transaction is about 80 characters on the channel per 5 seconds, or 14 characters per second (cps). If we have 5 stations actually on-the-air and if we set up so each station generates a new 80 character packet every 30seconds, and we spread them out so each generates a packet every 6 seconds, then based on the numbers we got we usually don't get collisions. This is because each transaction (send + acknowledge) is clear of the channel in about 5 seconds, sometimes shorter, sometimes longer and because the chances are pretty good that a pending sender will hear the other pending senders and jamming won't take place. TNCs, and some TNC emulators, must be configured to have PPERSIST and SLOTTIME delays, like this, in order to permit multiple access to the channel.

The default configuration for TNCs includes values like these, though usually the numbers selected for SLOTTIME are way too short for the radios actually used for packet. Note that those delays are used verbatim, whether or not there are more or less than 5 stations actually using the channel.

It may be an interesting historical note that almost all Amateur Radio packet does channel management to avoid collision using CSMA. CSMA was a method implemented into Amateur radio packet before the capability of doing on-channel repeating of packets was introduced. CSMA is foiled by hidden transmitters.

A more complete definition of SLOTTIME

SLOTTIME is used by packet radio software as the interval that must be let between checking for channel-in-use, used for random calculations, so that the chances of two stations grabbing the channel at once, and colliding, are reduced. Channel access can be divided into three modes:

channel-is-free,
channel-is-in-use,
channel-is-indeterminate.

During the channel-is-in-use period, all stations on the channel are supposed to be able to determine that they cannot transmit, and therefore no interference takes place. During the channel-is-free period, any station could grab the channel and start transmitting. The hard part is that when a station goes from idle to transmitting, there is a gap during which the station is no longer listening, and other stations don't yet know its intentions. This is channel-is-indeterminate.

For a given station, SLOTTIME is set the maximum period of time the channel might be channel-is-indeterminate, from the perspective of that station. PPERSIST is then set to the number of tranmitters that station must share the channel with.

The real problem happens when a given station doesn't know when another station is transmitting, ever. This is classic Hidden Transmitter Syndrome. In that case SLOTTIME, if it is to be applied effectively, must be set to the total length of time that any station could be on the channel.

In most Amateur Radio packet network cases, SLOTTIME is never set effectively. This is mostly because if the hams understood the collision model and HTS, they wouldn't be using a channel where stations are hidden from each other in the first place.

Digipeaters

Warning... I'm not clear on whether this is true or not. It would be really neat if somebody would contact me and tell me that it is or is not. Please email me at my QRZ-listed address.
I believe that Digipeaters do not use PPERSIST for channel access control. By design, since the digipeater is called out by a user station, the digipeater will always try to grab the channel immediately on the drop of carrier sense. In a network where a digipeater is present, it is up to the user stations to compensate for the use of the digipeater in the TNC parameter configuration. Yes, this is nearly impossible and highly unlikely to ever have been performed.

Automated replacement for SLOTTIME

In the 1990s (starting before that date) the software packages supporting TCP/IP over packet radio were capable of dynamically adjusting the persistance values based on actually channel performance. This capability is sometimes called BACKOFF-AND-RETRY. BACKOFF-AND-RETRY automatically tracks how long to wait after sending each message before resending. Every time the wait is exceeded with no answer, it increases the wait by a factor specified by configuration, possibly 1.5x or 2x. Every time an answer arrives in time, it decreases the wait by a little, again by a factor specified in configuration, possibly 9/10ths or 4/5ths. This resulted in a mechanism where each station would operate at a proper delay for the current operating conditions.

The value that each station would settle on changed as other stations had traffic to send, or not, but in an HTS situation, the timing for BACKOFF would actually end up looking like an effective SLOTTIME number, and was usually very slow.

Aloha Protocol/AlohaNet

A research project was performed in the early 70s at the University of Hawaii to create a system of packet stations transmitting onto a busy channel. The network was called AlohaNet. Through research while implementing the system, the designers (see Prof. Norman Abramson) decided that the optimum channel utilization for the maximum amount of throughput combined for all users is achieved when the channel is 20% occupied.

Now go read Networking On Purpose, a document that describes different networking solutions and problems they might have, cost, collisions, complexity, etc..