Fred R. Goldstein k1io
25 October 1988
Preface
This is a draft description of a potential protocol for providing
the Data Link Layer service to packet radio networks in the Amateur
Radio Service. This draft presumes a familiarity with the AX.25
protocol adopted by the American Radio Relay League. Actual
implementation is not suggested at this time.
Intended audience: Amateur packet radio operators. This draft is
leading towards an "ARFC".
The A802 Metropolitan Area Network Protocol for Amateur Packet Radio
I. Introduction
Amateur Packet Radio has been practically synonymous with the AX.25
protocol since the early 1980s. While AX.25 has allowed packet
operation to become quite popular, it has not proven to be fully
sufficient for the task. Instead, it has created a minor industry
in Terminal Node Controllers, which have isolated their users, and
their computers, from the protocols themselves.
A totally different protocol can take the place of AX.25, especially
when used with more sophisticated upper layers such as TCP/IP. A
candidate for such a protocol can be loosely based upon Local Area
Networks which operate over shared cable; A802 takes such an
approach.
I.1. AX.25 is itself a misnomer
AX.25 takes its name from Recommendation X.25 of the CCITT, the
international consultative body that makes standards for telephone
networks. X.25 itself is a definition for a standard interface into
packet switched networks. It defines, in detail, two different
layers of software. Layer 2 (or Level 2, in X.25's original
terminology) is the Data Link layer, responsible for ensuring error-
free transmission between adjacent entities. Layer 3 is the Network
layer (originally the Packet layer) which operates across the
boundaries of the network, establishing virtual circuits
(connections) between users. (Layer 1, the Physical Link layer,
simply transfers bits across a data connector, like the widely used
RS-232 interface. Modem standards fall within the bounds of Layer
1, but are not part of X.25. Packet radio standards for Layer 1 are
only partially covered within this document.)
X.25's Data Link layer uses a protocol called LAP-B (Link Access
Protocol - Balanced). This has been adapted, with much change, into
AX.25. While X.25's network layer has been implemented in some
connection-oriented networks, it is not part of AX.25. So the name
AX.25 is really a misnomer; it is simply a much modified LAP-B.
Like LAP-B, AX.25 is a member of the HDLC (High Level Data Link
Control) family of protocols. HDLC frames (which is the correct
term for packets at Layer 2) begin and end with a flag character,
and allow data transparency by a bit insertion (stuffing) procedure.
The last two bytes of the frame are the checksum, or cyclic
redundancy check (CRC). Bit stuffing (and removal, on receive) is
easily accomplished with specialized hardware, but next to
impossible using standard personal computer modem interfaces. Hence
the need for a TNC with its HDLC chip.
While X.25 is widely used, it really has little in common with
packet radio. For one thing, X.25 networks run over point to point
wire lines. And LAP-B doesn't worry about addressing (there are
only two stations on the wire, one at each end); lengthy address
strings were added to create AX.25.
II. The data link, the LAN and the MAN
Packet radio operators know that their networks are not derived from
X.25 wireline networks, as packet networks are often called Local
Area Networks (LANs). This is not strictly accurate, since a LAN
operates only within a building or campus, but packet radio MANs
(metropolitan area networks) are still a lot more like LANs than
like X.25 links. LAN protocols don't exactly follow the same
layered model as X.25 or LAP-B, either: They don't strictly map
into the traditional Layer 1 and Layer 2.
The most widely used LAN standards are defined by IEEE committee
802, and include 802.3 (based on Ethernet), 802.4 (token bus) and
802.5 (token ring). Since token-passing has not been successfully
demonstrated on packet radio, 802.3 comes closest to modeling radio.
Indeed, the name "Ethernet" was coined by its inventors who noted
that the coaxial cable was a broadcast medium not entirely unlike
radio. Alas, it is also quite different from radio: Not only does
it run much faster, but it is virtually lossless.
II.1 LAN layers
The lowest layer in a LAN, roughly within the physical link layer,
is called the Physical Medium Dependent (PMD) layer. This, of
course, differs greately between the different types of 802 LANs.
The PMD layer is concerned with how bits are transmitted. The next
layer up is the Medium Access Control (MAC) layer; this is where the
stations on the LAN address each other, and determine when they can
transmit. Finally, the Logical Link Control (LLC) layer provides
the same types of services as a Data Link layer. There are two LLCs
defined in IEEE 802.2; LLC1 provides a datagram service (like UI
frames), while LLC2 provides a virtual circuit service (like I
frames). LLC2 procedures (the types of frames and how they
interact) are very close to LAP-B.
II.2 The A802 protocols
The LAN protocols found in IEEE 802 provide a model for packet
radio. For the sake of discussion, these are herein called "A802";
the IEEE 802 protocols are merely an inspiration, but provide a
model, just as X.25's Layer 2 provided a model for AX.25.
A802 starts with a different premise than AX.25. It does not use
HDLC, so there is no bit stuffing, and ordinary PC asynchronous
communications hardware can be used. It also pays a bit less
attention to terseness -- LAP-B headers cram a lot into a few bytes,
but lack flexibility.
As a further note, A802 can be run in either asynchronous or
synchronous mode -- a low-end implementation can be sent using a
standard asynchronous modem port, and monitored without special
hardware. However, net throughput will be higher if synchronous
transmission is used, and the two modes are not compatible. Thus
any given transmission channel must be either synchronous or
asynchronous or some stations will not be able to contact others.
II.3 The A802 frame structure
An A802 frame takes the following format:
Frame {
Sync_characters Literal "^V"s Mandatory
MAC_header Structure Mandatory
LLC_header Structure Mandatory
Data String Optional
Frame_checksum 2 bytes Mandatory
}
The sync_character is not part of the A802 frame itself, but is
always transmitted at least twice before every frame. It has
the literal decimal value of 22, or control-V; its purpose is to
allow the receiving modem to establish synchronization. In
synchronous mode, it establishes both byte and frame
synchronization; in asynchronous mode, it only establishes frame
sychronization. Note that HDLC protocols such as AX.25 can send any
number of flag characters between frames; IEEE 802.3 precedes each
frame with a stream of alternating 1 and 0 bits for synchronization.
The A802 "header" consists of two separate sub-layers. The MAC
sublayer provides addressing functions, while the LLC sublayer
provides both connection-oriented and connectionless options.
AX.25's basic functions are still provided, including support for
digipeating.
II.4 The MAC layer
The Medium Access Control layer allows stations to address frames to
one another. It is possible for a connection-oriented protocol to
have a very small address field; instead of putting a full address
(typically here, a call sign) in each frame, a data link control
indicator (DLCI) refers to a previously-created connection. This
has been done in the pioneering VADGC (Vancouver) packet radio
protocols, and is done in both LAP-D (the ISDN follow-on to LAP-B)
and X.25's Network Layer, which are connection-oriented. Like
AX.25, however, A802 puts the source and destination addresses in
every frame, allowing them to be handled as datagrams. A802 also
supports digipeating.
The fundamental components of a MAC header are the sender's and
receiver's addresses. For example, Ethernet (and its follow-on IEEE
802.3) have a 48-bit address, so 96 bits of the MAC header are taken
up by addressing. But digipeating makes life more complicated!
Digipeating is more precisely referred to as source routed MAC
relay: Source routed because the path is specified by the source of
the packet, and MAC relay because the frame is simply relayed by the
intermediate stations without looking at layers above MAC. (Source
routing is supported in IEEE 802.5, the token ring LAN.)
The MAC header can be described as
MAC_header {
Hop_pointer Integer (Mandatory)
Destination_address Structure (Mandatory)
Intermediate_address_1..7 Structure (Optional)
Source_address Structure (Mandatory)
Protocol_discriminator Alpha (Mandatory)
}
II.4.1 Addresses
Each address field typically contains a call sign. In a simple two-
station connection, the sender of the packet puts its call sign in
the Source_address field and puts the other station's call in the
Destination_address field. Secondary station IDs can be appended to
the callsigns, as can portable identifiers, as the address is not
constrained to 8 bytes (unlike AX.25 Version 2.0).
II.4.2 Source routing
Digipeating is accomodated via the Intermediate_addresses and the
hop_pointer. The hop_pointer indicates which of the addresses
(destination or intermediate) the frame is being directed to. In a
two-station (no digipeater) packet, the Hop_pointer always has a
value of 1. If there is one digipeater, then it begins with a value
of 2; this means that the receiver recognizes the packet as its own
when its own address is in the Intermediate_address_1 position.
Likewise, if there are two digipeaters, the first digipeater
increments the hop_pointer to 3 so that the second digipeater
recognizes its address in the intermediate_address_2 position. And
the last digipeater sets the hop_pointer to 1, the position of the
destination address.
A multicast or broadcast frame is sent with the hop_pointer set to
0. Thus the hop_pointer can have any value from 0 to 8.
The hop_pointer is designed to reduce the processing load on
receivers; they only have to listen to see if the pointed-to address
is their own, and if it is not, then the frame can be ignore. The
most common value will be 1; when this occurs, receiving stations
may ignore subsequent addresses. (Conversely, when a frame has a
hop_pointer value of 8, then every digipeater that hears it must
wait until Intermediate_address_8 is sent. This is, of course, a
degenerate case, as it is highly unlikely that a chain of 8
digipeaters will work!
For identification purposes, the sender (as contrasted with the
originator) of each transmitted frame is identified by determining
the previous hop in the source routing chain.
II.4.3 The protocol discriminator
One final field in the MAC header is the protocol discriminator.
This allows the upper layers to know what type of protocol the A802
frame is carrying in its data field. It should be noted that in the
current Open Systems Interconnection Reference Model, protocol
discriminators are taboo -- different protocols at the same node
should be distinguished by different addresses. But AX.25 uses a
protocol discriminator, Ethernet (pre-802) uses a protocol
discriminator, and most TCP/IP users have grown to expect a protocol
discriminator. So A802 has one too. (This does not rule out using
distinctive addresses, if one chooses to do so.)
The protocol discriminator is a single upper-case letter (A-Z).
Tentatively values are as follows:
Letter Protocol type
I IP (as in TCP/IP)
R ARP (Address Resolution Protocol)
X X.25 Packet layer or OSI CONS (ISO 8208)
O OSI Internet Protocol (ISO 8473)
T Plain text
Other values will be assigned as required.
II.4.4. Parsing the MAC header
Since some of the header fields are of variable length, they must be
separated from one another. There are several techniques that could
be used for this. LAP-B uses only fixed-length fields, while AX.25
uses fixed-length addresses with a bit set to indicate whether or
not each has already been digipeated and another set to indicate
which address is the last. Some protocols (notably those used in
Open Systems Interconnection, the OSI program of the International
Organization for Standardization) use a tag-length-value technique,
which is very flexible but frequently takes at least 3 octets to do
anything.
A802 is a bit more like natural language -- it relies on taking each
byte's values in context. Individual fields can only have certain
values, so they end when a separator character, or one which cannot
be part of that field, occurs. In A802, the MAC header is encoded
using printable ASCII characters.
The first octet of the MAC header is always a numeral, in the range
0-9 (although value 9 is presently reserved). This hop_pointer is
followed by the destination_address. This can contain the
characters A-Z, 0-9, plus the hyphen "-" and slash "/". The
secondary station ID field, an AX.25 artifact whose value can be 0
through 15, can further be encoded using one ASCII character
representing a hexadecimal digit, in the ranges 0-9 plus a-f,
immediately following the call sign. Or a hyphen can be used,
noting that K1IO-10 and K1IOa are two different addresses, though
both represent the same ss_id. (Should these be equated? This
requires further study.) Terse format (K1IO3) is recommended.
Intermediate_address fields are optional, inserted only as required.
Each one begins with the ASCII character "v", and then encodes call
sign the same way as the destination_address.
The source_address field, using the same encoding technique, is
preceded by the ASCII character "<" (less than, or left-pointing
angle bracket). This character is equivalent to the Morse code
"DE".
II.4.5 Examples of MAC header addressing
A packet addressed to K1IO from 4X/WB2ZJQ1 without a digipeater:
1K1IO<4X/WB2ZJQ1
A packet addressed to FG0/K1IO/FS7-3 (K1IO operating portable on St.
Martin using an FG0 authorization and the informal suffix FS7, SSID
3) from KA9Q8 via digipeaters WB2ZJQ and NP4XYZ would be initiated:
2FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
This would be picked up by WB2ZJQ would would transmit:
3FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
and it would finally be transmitted to FG0/K1IO/FS7-3 from NP4XYZ:
1FG0/K1IO/FS7-3vWB2ZJQvNP4XYZ<KA9Q8
It is possible to identify the sender (not originator, but the
digipeater) of each packet, by following the process backwards!
This is not particulaly human-friendly, but unambiguous to a
computer. Note that the protocol discriminator is not shown above;
it is the byte immediately preceding the LLC separator ":" (colon).
II.5 The Logical Link Control header
Logical Link Control provides the rest of the protocol's functions.
A connection-oriented LLC (like IEEE 802's LLC2) provides an error-
corrected, sequenced stream of frames -- a virtual circuit. AX.25's
virtual circuit mode does the same thing; this is the usual way X.25
networks use LAP-B. A connectionless LLC (like IEEE 802's LLC1)
does not try to make up for losses in the physical medium, but it is
simpler and often adequate. This corresponds to UI frames in AX.25.
Two LLCs are defined in A802. LLC-U is essentially similar to LLC1,
providing an unsequenced datagram delivery service. LLC-C provides
a connection-oriented (sequenced) service similar to that provided
by LLC2. It does not, however, follow LLC2's specific procedures.
The A802 LLC header also helps provide the frame integrity. It
includes a frame length field and a header checksum. Since A802
does not follow the HDLC flag-delimiting technique or reserve any
characters for "end of packet", it needs a way to indicate the end
of a frame: The frame length field indicates how many bytes of data
are in the frame, so the receiver simply counts bytes to determine
the end of the frame. The header checksum decreases the chance
that an error in the address or frame length causes the rest of the
frame to be incorrectly framed, with the chance that an incorrect
frame checksum is accepted.
The LLC header takes this structure:
LLC_header {
Separator Lit. ":" Mandatory
Control Alphabetic Mandatory
Receive_sequence Alphabetic Optional
Transmit_sequence Alphabetic Optional
Length Integer Mandatory
Header_Checksum Integer Mandatory
}
Note that the Control, Receive_sequence and Transmit_sequence fields
will be described in Section III, below. All header fields up to
and including Transmit_sequence are encoded in printable ASCII
character; the remaining portion of the LLC header, and the rest of
the frame, may have any arbitrary value.
II.5.1 Length
A802 is a byte-count protocol. The length field is not encoded in
ASCII; it is a two-byte integer, with the high order byte followed
by the low order byte. This allows large frames, though many or
most frames will have a zero value in the high-order byte. The
length field counts the number of bytes in the data field, following
(not including) the header checksum.
Some frames do not contain a data field. In such a case the length
field remains, with a value of 0.
II.5.2 Header Checksum
The header checksum field is only intended to detect some number of
header errors. It is a simple, one-byte value computed by adding up
the binary value of every previous byte in the header plus the total
number of bytes in the header (not including the checksum). If the
checksum does not match when computed by the receiver, then the
frame is discarded. The receiver also does not have confidence in
the length field, and may lose frame synchronization (see below).
II.5.3 The data field
The whole point of this protocol is to exchange data; the header
simply facilitates it. The data field in A802 begins six bytes
after the separator (":") in I frames, four bytes after the
separator in U frames, and five bytes after the separator in S, G
and R frames. The maximum length of the data field is subject to
negotiations by the two parties, and should be restrained in order
not to "hog" a channel, but in a high-speed network can be as long
as 8191 bytes. (This value is for further study.) On a 1200 bps
half-duplex channel, however, a maximum of 256 bytes is recommended.
There are no constraints on the contents of the data field, except
that it must be an integral number of octets long. Segmentation of
packets to accomodate different maximum data field lengths is for
further study.
II.5.4 The frame checksum
At the end of every frame, following the data field (and not
included within the length field) is the frame checksum. This is
computed on the entire frame, beginning with the hop pointer and
ending with the last byte before the frame checksum.
The frame checksum uses the 16-bit CRC-CCITT cyclic redundancy
checksum, identical with the one in AX.25. While computationally
rather intensive, it will detect essentially all errors of fewer
than sixteen bits and most longer errors. (Since A802 is intended
for use in the absence of dedicated "TNC" hardware, which would
normally implement CRC in hardware, use of a different checksum is
for further study.)
III. LLC procedures
III.1 LLC-U operation: Connectionless
The A802 connectionless mode of operation has a very simple LLC
sublayer. The Control field has a value of "U", corresponding to
Unnumbered Information (UI) frames in AX.25. All such frames stand
alone. They do not have a receive_sequence or transmit_sequence.
Thus the LLC-U header begins with the separator ":", followed
immediately by the Length field and Checksum. If the frame checksum
(as well as the header checksum) is valid, then the data is passed
to the next layer up. If the checksum is invalid, then the data is
not passed.
III.2 LLC-C operation: Connection oriented
A connection-oriented Logical Link Control provides sequenced,
error-corrected packets. This isn't so simple: If a packet isn't
acknowledged, it must be retransmitted by the sender. And since it
might take some time for this to occur, the sender may wish to send
more than one packet at a time. This is called a window, and is a
feature of both AX.25, LAP-B and many higher layer protocols.
A802's LLC-C defines three phases of data communications:
Connection establishment, data exchange, and connection release.
Connection establishment uses a three-way handshake (unlike AX.25's
two-way handshake). Connection release uses a two-way handshake
(more like AX.25). Each step can be described as a change in the
connection state. These stages are initiated by values in the
Control field.
III.2.1 Connection establishment
A802's connection establishment begins with the connection in a null
state. The station which initiates the connection sends a frame
with the Control field set to "A" ("ask for connection"). That
station moves into the connection initiated state. The recipient
station, if it chooses to accept the request, immediately responds
with the Control field set to "B" ("begin to connect"). Neither A
nor B frames may contain data. (A802 does not support "fast
connect". You want fast, you use U frames!) The recipient, who
sent the "B", is now in the connection pending state.
If the receiver does not want to accept a connection request, then
it responds not with a "B" but with a No Contact frame (Control
value of "N"). The receiver stays in the null state.
After receiving a "B" frame, the initiator sends a Connect frame
(Control value of "C"). This step allows the recipient of the
connect request to know that its "B" frame was received. Upon
sending the C frame, the initiator moves into connected state; the
receiver moves into connected state when it receives the C frame.
As you can see, connection establishment is as simple as A-B-C! But
of course, there are complications, mainly a number of necessary
timers. When the initiator moves into the connection initiated
state, it starts Timer A to await a response. If Timer A expires
without any response, then the connection is assumed to have failed.
It may re-initiate with another A frame.
Once the recipient sends a B frame, it starts Timer B. If it does
not receive a C frame before Timer B expires, then it retransmits
the B frame once and restarts Timer B. If no C frame is received,
then it assumes that the connection is lost and returns to the null
state. If the C frame was lost, the originator will not know it
until another B frame is received. It may have begun transmitting I
frames in the meantime, but I frames must be acknowledged, and the
receipt of a second B frame implies that the I frames have been
rejected. Similarly, I frames received before a C frame are
discarded by the receiver as being out of sequence.
III.2.2 Data exchange
Once a connected state is achieved, data exchange may begin. A802's
connected mode makes use of sliding windows, not unlike AX.25. But
in keeping with A802's alphabetic nature, it adopts a modulus of 26;
letters are used to indicate the send and receive variables.
The receive_sequence is encoded using lower-case ASCII letters; the
transmit_sequence is encoded in upper case. During information
exchange, the receive_sequence is transmitted in I, S and G frames;
it has the downcased version of the next letter (a-z, wrapping z to
a) after the last correctly-received frame's transmit_sequence. The
transmit sequence (A-Z, wrapped) identifies each unique sequenced
frame.
Thus the first station to transmit information after connection
establishment sends the I frame with sequence variables "IaA",
inviting the other side to send its own frame A. If side X has
received five frames frpm side Y and not transmitted any, then sends
one frame, it sends "IeA". If X has a second frame to transmit
right away, that frame is sequenced "IeB". Then, if Y sends its
sixth frame, it sends IcF, which acknowledges X's frame B.
In theory this allows up to (modulus - 1) 25 frames to be
outstanding at once. This window size value k is typically much
lower; in some half-duplex packet radio environments, it may need to
be as low as 1, whence every frame must be acknowledged before
another can be sent. Windows belong to the transmitting side only
and need not be symmetrical; a station simply doesn't transmit more
than k frames ahead of the last acknowledged frame.
Every I frame must be acknowledged within the duration of the
sender's timer I. If there is a relatively constant flow of data in
both directions, then each side's I frames acknowledge the other
side's. If, however, the recipient does not have data to send, then
it still needs to acknowledge the received data before the sender's
timer I expires. This is accomplished by sending a G (Go) frame
with the appropriate receive sequence_value (the transmit_sequence
value one after that of the last received I frame). Timer G
determines how long the recipient waits before sending this G frame.
If a frame is not acknowledged within timer I, then the station
retransmits the frame. If a station retransmits the same frame
r times without being acknowledged, then it assumes that the
connection has been lost. It then transmits a D frame.
III.2.3 Flow control
Sometimes one side of a connection is incapable of handling any
additional I frames. This may occur because of congestion further
down the network, or because its receiver has filled (or anticipates
imminently running out of) its buffers. When a station expects to
be unable to handle additional traffic, it sends an S (Stop) frame.
This contains a receive sequence value but not a transmit sequence.
The sender of the S frame is now in a stopped state. Any I frame
data received at this time is expected be discarded. (U frames may
be accepted or rejected at the recipient's option.) Upon receipt of
an S frame, the sender enters halted state.
A station in halted state may not send further I frames, but may
itself acknowledge receipt of I frames via S frames. A station in
stopped state may, however, send I frames.
Once the station is again able to receive traffic, it sends a G
frame, moving from stopped to connected state. Its receive_sequence
value should be the next one after that of the last I frame and
match the one in the S frame which it cancels; however, at the
receiver, value of the G frame takes precedence in case of mismatch.
(This allows the receiver to accept additional I frames after
sending an S frame, at its discression. S and G frames correspond
loosely to RNR and RR frames in AX.25 and LAP-B.)
III.2.4 Out of sequence packets
If a valid frame is received whose transmit sequence is not exactly
one more (modulo 26 from the A-Z sequence) than the last correctly
received frame, then it is out of sequence. A802 is intended to
operate only over simple point to point links, or over static
digipeater chains, so sequence should always be preserved. Thus out
of order packets imply that intervening packets have been lost. The
recipient of an out of sequence frame should send an R frame with
the receive_sequence value one greater than the correctly received
frame's transmit_sequence.
III.2.5 Connection release
When either side of a connection wishes to release the connection,
it sends a D (Disconnect request) frame. This contains a
receive_sequence value one ahead of the last correctly received
frame's transmit_sequence. It goes into the disconnect pending
state. The recipient of a D frame immediately acknowledges it with
an E (End) frame, which has no associated sequence variables. At
this point both stations go into the disconnected mode.
If the sender of the D frame does not receive an E frame within the
time specified by timer A, then it should retransmit the D frame up
to r times.
III.3 Header checksum errors
For every received frame, the header checksum should be computed and
compared to the received value. If it is incorrect, then the frame
is simply discarded.
Since the number of bytes in the frame is part of the header
checksum, the receiver must resynchronize. This is accomplished by
waiting for two successive bytes with the decimal value of 22
(control-V) followed immediately by an ASCII representation of a
numeric value, which could represent the first byte of a frame.
This may or may not mark the beginning of a new frame. The receiver
must then see if the potential new frame has a valid header
checksum. Other heuristic means of determining frame breaks are for
further study. Frame synchronization can typically be re-attained
from the beginning of a new transmission, as noted from the Data
Carrier Detect signal or squelch signal.
III.4 Frame checksum errors
If the frame checksum of any frame but an I frame is correct but the
frame checksum is incorrect, then the receiver discards the frame.
If the header checksum of an I frame is correct but the frame
checksum is incorrect, then the receiver can have a fair degree of
confidence that the frame in question comes from the sender
identified in the MAC header, even if the data itself is valid. If
the recipient of this corrupted data field has data to transmit,
then it sends an I frame with the receive sequence value of the next
anticipated frame following the last received valid frame. For
example, if frame M was received correctly and a corrupt frame N was
then received, the receiver's next outgoing I frame should have a
receive sequence of "n". The transmitter then resumes from its
frame N.
If the recipient of the corrupted data does not have data to
transmit, it should, without further waiting, send an R (Reject)
frame with its receive_sequence value one after the last valid
received frame's transmit_sequence value. (This will typically be
the transmit sequence of the corrupt frame, but that may not be the
case if other frames were lost.)
III.5 Channel Access Procedures
Packet radio does not exactly resemble any wireline medium.
Different packet radio configurations, in turn, have different
physical characteristics which impact procedures.
The purpose of the channel access procedures is to guarantee that a
shared channel does not reach a state where additional demand causes
net throughput to decrease precipitously, a condition known as
congestion collapse. This has been a significant problem in AX.25
networks. It is essentially impossible, however, in properly
operated Ethernet networks.
III.5.1 CSMA operation
If it were not for the "hidden transmitter" problem, packet radio
half-duplex operation would resemble carrier sense multiple access
operation. CSMA operation can, however, be achieved when half-
duplex packet stations operate through a repeater (a two-frequency
repeater, not a digipeater). The repeater regenerates everyone's
transmitted bits so that everyone else can hear them; this prevents
any station from transmitting on top of another station unless they
both start transmitting at almost exactly the same time.
In CSMA operation, an A802 station with data to transmit first waits
until the channel is free. It then waits for a random period of
time t in the range m < t < s, where s is the slot time. Slot time
is represented by TXdelay + Df: The sum of the transmitter keyup
delay (TXdelay in some packet radio TNC operation) added to a
constant Df. (Ideally, in a system where TXdelay is not long, Df
represents the duration of a minimum-length frame; initially here,
it should be at least equal to TXdelay, so that slot time is at
least twice TXdelay. This value requries further study.) The
minimum wait, m, is equal to TXdelay.
On retransmissions, however, slot time increase exponentially:
TXdelay + (Df*(2^t)), where t is the retransmission number
beginning with 0 (for the first transmission) and ending with r.
Thus each retransmission delay will take, on average, almost twice
as long as the previous delay. But this is only the outer bound of
a random function.
III.5.2 CSMA/CD operation
IEEE 802.3 and Ethernet use a contention technique called carrier
sense multiple access / collision detection, or CSMA/CD. This is
based on the concept that every transmitting station is
simultaneously listening, so it knows if its signal was "clobbered"
-- it compares the received signal to the transmitted one.
(Ethernet, keeping it simple, uses a current source into a fixed 50
ohm load. If the voltage goes above the transmitter's own output
voltage -- i.e., it detects 6 v when it transmits at 3 v -- then it
knows a collision has occurred. This obviously does not work when
an antenna is used.)
Stations must listen before they transmit. However, it is possible
that two stations choose to transmit at almost exactly the same
time. This causes a collision. Since the station is listening,
though, it does not complete sending the packet. It stops
transmitting and waits a random interval within (2^n * slot_time),
where n is the retransmission count.
This leads to a conclusion that, given sufficient received signal
strengths (i.e., low bit error rate exclusive of collision), LLC-U
operation is appropriate for CSMA/CD operation, while LLC-C
operation is most desirable for CSMA operation. If CSMA operation
is used, then a collision-caused error can only be recovered by an
end-to-end layer, either operating across a digipeater chain or at a
higher layer.
From a practical perspective, CSMA/CD operation requires all
stations to operate using full-duplex radios, listening to a
repeater output even as they transmit to the input. Hence very
little amateur packet radio operation is true CSMA/CD.
III.5.3 Single-frequency operation
With a single frequency and no repeater, even true CSMA is not
possible. Stations must still listen before transmitting, but the
sender might not hear a third station that blocks its transmission
from reaching the receiver. This is the "hidden transmitter"
problem. Single-frequency operation thus has a lower maximum
channel throughput than true CSMA operation, though higher than
Aloha operation, in which stations transmit without listening.
The same procedures as used in CSMA operation should be used in
single-frequency operation. However, it may be necessary to use
longer initial slot times. This is for further study.