Paul Rinaldo, W4RI. President, AMRAD
Terry Fox, WB4JFI. Vice President, AMRAD
Eric Scace, K3NA. AMRAD Good-Guy
Jon Bloom, KE3Z. AMRAD Good-Guy
Gordon Beattie, WB2CAM. R.A.T.S.
Dave Borden, K8MMO AMRAD Good-Guy
Version 1.1 October 10, 1982
NOTE: This is a rough draft, subject to change
Introduction
The purpose of this document is to establish a standard
protocol to be used at layer 2 of the ISO open systems
interconnection reference model (OSI-RM) (commonly referred
to as the link level) that will work effectively in the
Amateur Radio enviroment with a minimtm of overhead.
This protocol conforms with the ISO Standard 3309,
4335 (including DAD1&2) and 6256 high-level data link
control (HDLC) and uses terminology found within that
document.
This protocol also follows, in principle, the level 2
protocol used in the CCITT standard X.25. The only
deviations from the letter of this standard are the
extension of the address field and the inclusion of an
additional frame, the unnumbered information (UI) response
frame, which was taken from the HDLC standard.
This protocol is designed to work in either half- or
full-duplex radio enviroments.
This standard has been written to work equally well for
either point-to-point connections or connections thru a
network controller or other larger device.
This standard is not responsible for defining the
operation of any other layer of the ISO OSI-RM.
Definitions
There are two basic types of devices used in packet
networking. One is a device called a data circuit-
terminating equipment (DCE), which is usually a larger
device, such as a Metropolitan Network Controller (MNC), or
some other device that is smart enough to handle the link
connection. The other device is the data terminal equiqment
(DTE) device. The DTE is usually the originator of a
connection, and could be considered the terminal end of the
data link.
2
Frame Structure
All transmissions shall be sent in frames. A frame
shall be formatted as shown in Figure 1. Figure 1A shows
how unsequenced and supervisory frames are constructed,
while Figure 1B describes an information frame.
First
bit sent
--------------------------------------------------------------
| Flag | Address | Control | FCS | Flag |
--------------------------------------------------------------
| 01111110 |112/168 bits | 8 bits | 16 bits | 01111110 |
--------------------------------------------------------------
Figure 1A. U and S Frame Construction
First
bit sent
-------------------------------------------------------------------
| Flag | Address |Control |Information | FCS | Flag |
-------------------------------------------------------------------
|01111110 |112/168 bits| 8 bits |N*8bits long| 16 bits |01111110 |
-------------------------------------------------------------------
Figure 1B. Information Frame Construction
Field Definitions
Flag Field
All frames shall begin and end with a flag, which is
defined as one 0 followed by six 1s and another 0.
A single flag may be used as the closing flag for one frame
and the opening flag of the next frame.
Address Field
The address field in this protocol deviates from the
letter of the present (CCITT yellow book) X.25 standard.
This protocol uses extended addressing, and has both the
source and destination addresses where X.25 specifies only
single-octet address. X.25 also sends either the DCE or DTE
address, depending on who is sending it, and whether a
command or response is sent.
3
Note:
It should be pointed out that the reason this document
recommends sending both the destination and source addresses
is to allow multiple DCE/DTE links to share the same data
channel. There are two possibilities to accomplish this.
One way is to modify the connection establishing procedure
to make sure both ends of the link know who they are
connected to, and no other stations can accidentally foul up
the link. The other way is to include both addresses in
every frame, insuring that neither end of a link would ever
get confused. In the long run, the additional overhead
needed for sending both addresses in all frames seems worth
tolerating in order to simplify link establishment and
control procedures, and to avoid central assignment of brief
addresses.
The encoding of the address field will be discussed
later in the document.
Control Field
The control field consists of one octet. It is
responsible for informing the stations on the link what type
of frame is being sent, and is also where link control
functions are transferred.
The contents of the control field is discussed in a
following section.
Information Field
If an information field exists, it is totally
transparent at the end-to-end points. It is bit stuffed
over the link however, to prevent flags from accidentally
appearing, which would cause an early frame ending, and
errors.
The maximum length of the information field is 256
octets. This will allow 128 actual user-data octets with
room for higher layer overhead. Larger lengths may be used
by bilateral agreement.
Frame Check Sequence
The frame check sequence (FCS) consists of 16 bits
generated in accordance with ISO 3309 (HDLC).
4
Bit Stuffing
Whenever a frame is being transmitted, all fields
except for the flags will be checked to be sure that no more
than 5 contiguous 1 bits exist. Any time that 5 contiguous
1 bits are detected, the transmitter must add a 0 bit after
the fifth 1 bit. This added 0 bit will be detected at the
receive end of the link and automatically deleted.
This bit-stuffing technique is necessary to insure that
a flag sequence doesn't accidentally appear anywhere but at
the beginning and end of frames.
Order of Bit Transmission
All fields of each frame shall be sent starting with
the least significant bit except for the FCS, which shall be
sent starting with the highest order bit first, in
accordance with ISO 3309.
Frame Abort
When a frame must be aborted, at least fifteen
contiguous ones must be sent, with no bit-stuffing zeros
added.
Invalid Frames
Any frame consisting of less than 32 bits, or not
bounded by opening and closing flags, or not consisting of
an integral number of octets should be considered an invalid
frame by the link layer.
5
Non-Repeater (Normal) Address Field Generation
The address field is encoded as shown in Figure 3.
This encoding system places both the destination and the
source Amateur Radio call signs in the address field. The
destination address is the address of the station this frame
is being sent to. The source address is the address of the
actual sender of the frame.
There is an extra octet at the beginning of each
address sub-field that allows room for a secondary-station
ID (SSID) and also reserves three bits for future expansion.
The SSID allows one amateur to put up several packet
stations and have them individually addressable at level 2.
This is necessary or useful for functions such as repeaters,
hosts, multiple terminals, etc.
A1 thru A14 are the fourteen octets that make up the
two address sub-fields in the address field. The
destination address is seven octets long (A1 thru A7) and is
sent first. This will allow it to be compared with the
receiving station's address while the rest of the frame is
being received. The source address is then sent in A8 thru
A14. Both of these address sub-fields are the same format,
so just the destination sub-field encoding will be shown
here.
Destination Sub-Field Encoding
Figure 4 shows how an Amateur Radio call sign is placed
into the destination address sub-field in octets 1 thru 7 of
the address field.
-----------------------------------------------------------------
| A 1 | A 2 | A 3 | A 4 | A 5 | A 6 | A 7 |
-----------------------------------------------------------------
|E0RR|SSID|E[ W ]|E[ B ]|E[ 4 ]|E[ J ]|E[ F ]|E[ I ]|
-----------------------------------------------------------------
|00RR|SSID|01110101|00100001|00010110|01101001|00110001|01001001|
-----------------------------------------------------------------
>>Order of Bit Transmission>>
Figure 4. WB4JFI Encoded into Destination Address Field
6
Where:
1. The first (low-order) bit sent, designated "E", of
each octet is the HDLC address extender bit. This
bit shall be a 0 for all but the last octet in the
address field where it is set to 1.
2. The bits marked "R" are reserved bits, which may
be used in an agreed upon manner in individual
local networks. If they aren't used, they should
be set to 0.
3. "[ A ]" is the ASCII character of the Amateur Radio
call sign to be encoded into the address octets. It
is standard seven bit ASCII that has been bit
shifted left once to accomodate the HDLC extender
bit. A2 is the first character of the call sign.If
the call sign is less than six characters long, it
will be padded at the trailing end with ASCII
spaces (20 hex).
4. The SSID field is a secondary station ID that will
allow amateurs to operate more than one packet
station. The operation of the SSID field is left
vague at this point, and is up to individual
stations how this field is defined. Some suggested
definitions for this field are as follows:
0000 Not allowed under normal operation.
0001-1110 Normal Packet Stations (14 total).
1111 All-Call address (1 total).
7
Level 2 Repeater Address Encoding
When there is a level 2 repeater in operation, the HDLC
address field is extended to include a third address sub-
field, which contains the address of the repeater that
should repeat that frame. The position of the repeater
address is shown in figure 3A.
The repeater address sub-field is encoded similar to
the destination and source address sub-fields with the
exception of the first octet, where an additional flag bit
is added. This flag bit, called the H bit, is set to 0 by
the source station, and the repeater changes it to a 1 by
the repeater when it repeats a frame to indicate the sent
frame has been repeated. This allows a station that might
see both the frame originally sent by the source station and
the repeated frame to distinguish between the two, and
accept only the repeated frame. The encoding of the
repeater address sub-field is shown in figure 4A.
-----------------------------------------------------------------
| A15 | A16 | A17 | A18 | A19 | A20 | A21 |
-----------------------------------------------------------------
|EHRR|SSID|E[ W ]|E[ B ]|E[ 4 ]|E[ J ]|E[ F ]|E[ I ]|
-----------------------------------------------------------------
|0100 0010|01110101|00100001|00010110|01101001|00110001|11001001|
-----------------------------------------------------------------
Figure 4A. Repeater Sub-Address Encoding.
Where:
1. "E" is the HDLC extender bit as mentioned earlier.
2. "H" is the has-been-repeated bit. If H=0, then
the frame has not been repeated,while if H=1, then
the frame has been repeated.
8
Address Field Exceptions
There are two octets that should not appear within the
Amateur call sign address fields shown above. The first is
an all-zero octet, which HDLC defines as a null address and
should be ignored. This means that any frame that contains
a null address octet in any portion of the address field
should be ignored. The null address can optionally be used
during testing since it will be ignored by other packet
stations.
The other address octet exception is an all-one octet.
HDLC defines this octet as an all-call address (similar to
an Amateur Radio QST message). This all-one octet should be
avoided in the address field. The problem of an all-one
octet is virtually eliminated in this protocol, since the
only octet that has the extender bit set to 1 is the last
octet in the total address field. This octet carries the
last ASCII character of an amateur radio call, and therefore
shouldn't ever show up as all ones.
9
Note:
Advantages of the WB4JFI Addressing Scheme
Some of the advantages to using this addressing system
are:
1. Every packet station will have a unique fixed address
that doesn't change every time a new network is
logged into.
2. Relocating to a new area won't cause major
(or minor) problems.
3. Allows for more than 62 or 31 users at a time.
4. No local packet guru is needed to assign addresses
with attendant concerns of backup and transfer
during failure.
5. Direct or network operation requires no change of
address.
6. All the problems with dynamic allocation/de-
allocation are eliminated.
7. Reduces local co-network interference due to users in
overlapping local network rf domains with the same
address fields.
8. With every frame having both the destination and
source addresses in them, it will be a lot easier to
set-up and run multiple connections on the same data
channel without having problems arise as to who is
sending what frames to whom.
10
Control Field Formats
The control field is used to convey commands and
responses regarding the control and status of the data link.
The control field of this protocol uses the X.25 standard
as a starting point, and adds an additional control field from
HDLC to allow the protocol to work effectively during point-
to multi-point operation.
There are three basic formats of the control fields. They
are the Information format (I frames), the numbered
Supervisory format (S frames), and Unnumbered control frames
(U frames). Figure 5 shows the basic format of these
fields. Bit 1 is the first bit transmitted, bit 8 the last.
----------------------------------------------
| Control Field | Control Field Bits |
| Type | 1 | 2 3 4 | 5 | 6 7 8 |
----------------------------------------------
| I Frame | 0 | N(S) |P/F| N(R) |
----------------------------------------------
| S Frame | 1 | 0|S S |P/F| N(R) |
----------------------------------------------
| U Frame | 1 | 1|M M |P/F| M M M |
----------------------------------------------
Figure 5. Control Field Formats
Where:
1. N(S) is the send sequence number (bit 2= low order
bit).
2. N(R) is the receive sequence number (bit 6= low order
bit).
3. S means the supervisory functions bits.
4. M means the unnumbered modifier bits.
5. P/F is the Poll/Final bit.
Control Field Definitions
Information Frame Control Field
I frames have bit 1 of the control field set to 0.
N(S) is the sender's send sequence number (the sequence
number of this frame). N(R) is the sender's receive
sequence number (the sequence number of the next expected
received frame). The poll/final bit (P/F) will be discussed
in a later section.
11
Supervisory Frame Control Field
The S frame has the control field's bit 1 set
high, and bit 2 set low. S frames provide supervisory
link control such as acknowledging or requesting
retransmission of I frames, and link level window
control. Since S frames don't have an information
field, the sender's send variable and the receiver's
receive variable are not incremented.
Unnumbered Frame Control Field
U frames are distinguished by having both bits 1
and 2 of the control field set to 1. U frames are used
to extend the number of link supervisory functions
beyond those allowed as S frames. U frames are
responsible for the setting up and tearing down of the
data link, along with other miscellaneous functions.
Some U frames may contain an information field.
Control Field Parameters
Sequence Numbers and Variables
For the basic (non-extended) control field, every
I frame shall be assigned a sequential number varying
from 0 to 7. This will allow up to seven outstanding I
frames at a time.
Send State Variable V(S)
The send state variable is an internal
variable (never sent) that contains the next sequential
number to be assigned to the next transmitted I frame.
This variable is updated with each successive I frame
sent.
Send Sequence Number N(S)
The send sequence number is found only in I
frames. It is the sequence number of the I frame being
sent. Just prior to the sending of the I frame, N(S)
is updated to equal the send state variable.
Receive State Variable V(R)
The receive state variable is an internal variable
that contains the number of the next expected I frame
to be received. This variable is updated upon the
reception of an error-free I frame whose send sequence
number equals the present receive state variable value.
12
Receive Sequence Number N(R)
Both I and S frames contain N(R), the sequence
number of the next expected received I frame. Prior to
sending an I or S frame, this variable is updated to
equal that of the receive state variable. Transmission
of this updated N(R) implictly acknowledges the proper
reception of all I frames up to and including N(R)-1.
Poll/Final Bit
The poll/final bit can be used with all types of
frames. It is used in a command (poll mode) to request
an immediate reply to a frame. The reply to this poll
is indicated by setting the P/F bit (final mode) in the
appropriate response frame. Only one poll command is
allowed per direction at a time. Implementation of the
P/F bit will be discussed later in this
recommendation.
Control Field Encoding
Information Frames
The information frame control field is encoded as
shown in Figure 6. Information frames are used to
convey user data across the link. These frames are
sequentially numbered to maintain control of their
passage along the link. The I frame control field used
here conforms with both the X.25 and ADCCP standards.
Control Field Bits
---------------------------------
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
---------------------------------
| 0 | N (S) |P/F| N (R) |
---------------------------------
Figure 6. I Frame Control Field
Supervisory Frames
The supervisory frame control fields are encoded
as shown in Figure 7. S frames are used in this
standard only as response frames. These fields conform
with both X.25 and ADCCP (except for SREJ not being
implemented from ADCCP).
1. To indicate that the sender of the RR is now
able to recieve more I frames.
2. To acknowledge properly received I frames up
to, and including N(R)-1.
3. To clear a previously set busy condition
created by an RNR command having been sent.
It should be noted that the status of
the other side of the link can be requested
by setting the poll bit.
Receive Not Ready (RNR) Response
Receive not ready is used to indicate to the
sender of I frames that receiver is temporarily
busy and cannot accept any more I frames. Frames
up to N(R)-1 are acknowledged. Any I frames
numbered N(R) and higher that might have been
caught in between and not acknowledged when the
RNR command was sent are NOT acknowledged.
The RNR condition can be cleared by the
sending of a UA, RR, REJ, SARM, or SABM frame.
The P/F bit can be used within the RNR frame to
interrogate the status of the other side of the
link.
Reject (REJ) Response
The reject frame is used to request
retransmission of I frames starting with N(R).
Any frames that were sent with a sequence number
of N(R)-1 or less are acknowledged. Additional I
frames may be appended to the retransmission of
the N(R) frame if there are any.
14
Only one reject frame condition is allowed in
each direction at a time. The reject condition is
cleared by the proper reception of I frames up to
the I frame that caused the reject condition to be
initiated.
As with the other supervisory responses, the
P/F bit may be used in the REJ frame.
Unnumbered Type Frames
Unnumbered frame control fields are either
commands or responses. This standard follows X.25 as
much as possible. The only deviation from X.25 is in
the addition of the Unnumbered Information (UI) frame
from ADCCP. X.25 is designed to work with in full
duplex systems with only one main device (DCE) and
potentially many users (DTEs).
Amateur radio packet systems differ greatly on
both of these respects. Not only is amateur radio
packet networking done in a half duplex RF enviroment,
but many DCE/DTE links many be sharing the same
channel. Many amateurs have rejected the use of X.25
as a result of these problems. X.25 can easily be
enhanced so that it will perform properly over amateur
radio.
Figure 8 shows the layout of U frames implemented
within this standard.
The SABM command is used to place 2 stations in
the asynchronous balanced mode. This is a balanced
mode of operation known as LAP B where DCEs and DTEs
are treated as equals.
Information fields aren't allowed in SABM
commands. Any outstanding I frames left when the SABM
command is issued will remain unacknowledged.
Disconnect (DISC) Command
The DISC command is used to terminate a link
session between two stations. No information field is
permitted in a DISC command frame. Any outstanding I
frames will remain outstanding.
Disconnected Mode (DM) Response
The disconnected mode response is sent whenever
the DTE or DCE receives a frame other than a SABM while
in a disconnected mode. It is sent to request a set
mode command, or to indicate it cannot accept a
connection at the moment. The DM response cannot have
an information field.
A DCE or DTE in the disconnected mode will respond
to any command other than a SABM with a DM response
with the P/F bit set to 1.
Unnumbered Acknowledge (UA) Response
The UA response frame is sent to acknowledge the
reception and acceptance of a U frame command. A
received command is not actually processed until the UA
response frame is sent. An information field is not
permitted in a UA frame.
Frame Reject (FRMR) Response
The FRMR response frame is sent to report that
for some reason the receiver of a command or information
frame cannot successfully process that frame and that
the error condition is not correctable by sending the
offending frame again. Typically this condition will
appear when a frame without an FCS error has been
received with one of the following conditions:
1. The reception of an invalid or not
implemented command or response frame.
16
2. The reception of an I frame whose information
field exceeds the agreed upon length.
3. The reception of an improper N(R). This
usually happens when the N(R) frame has
already been sent and acknowldeged, or when
N(R) is out of sequence with what was
expected.
4. The reception of a frame with an information
field where one is not allowed, or the
reception of an U or S frame whose length is
incorrect.
When a CMDR or FRMR frame is sent, an information
field is added to the frame that helps to explain where
the problem occurred. This information field is three
octets long and its contents is shown if Figure 9
below.
1. The rejected frame control field carries the
control field of the frame that caused the
reject condition. It is in bits 1-8 of the
information field.
2. V(S) is the current send state variable of the
device reporting the rejection (bit 10 is the
low bit).
3. V(R) is the current receive state variable of
the device reporting rejection (bit 14 is the
low bit).
4. If W is set to 1, the control field received
was invalid or not implemented.
5. If X is set to 1, the frame that caused the
reject condition was considered invalid
because it was a U or S frame that had an
information field that is not allowed. Bit W
must be set to 1 in addition to the X bit.
17
6. If Y is set to 1, the information field of a
received frame exceeded the maximum capacity
of the device reporting the condition.
7. If Z is set to 1, the control field received
and returned in bits 1 to 8 contained an
invalid N(R).
8. Bits 9, and 21 to 24 are set to 0 in both CMDR
and FRMR frames. Bit 13 of a FRMR is set to 0
if the rejected frame was a command, or 1 if
if it was a response.
Unnumbered Information (UI) Frame
The unnumbered information frame is used to pass
information along the link outside the normal
information controls. This allows information fields
to go back and forth on the link bypassing flow
control. Since these frames are NOT acknowledgeable,
if one gets wiped out, there is no way to recover it.
The UI frame is not defined in X.25. It has been
taken from ADCCP to allow uncontrolled information to
flow thru the link without interferring with a next
higher layer.
18
Link Error Recovery
There are several link level errors that are
recoverable without tearing down the connection. These
error situations may occur as a result of malfunctions
within the DTE or DCE, or if transmission errors occur.
Invalid Frame or FCS Error
If an invalid frame is received, or a frame is
received with an FCS error, that frame will be
discarded with no action taken.
Device Busy Condition
When a DTE or DCE becomes temporarily busy, such
as when receive buffers are full, it will send a
receive not ready (RNR) frame. This tells the other
side of the link that the device cannot handle any more
I frames at the moment. This condition is usually
cleared by the sending of a UA, RR, REJ, or SABM
command frame.
Send Sequence Number Error
If the send sequence number , N(S), of an
otherwise error-free received I frame does not match
the receive state variable, V(R), a send sequence error
has occured, and the information field will be
discarded. The receiver will not acknowledge this
frame, or any other I frames until N(S) matches V(R).
The control field of the erroneous I frame(s) will
be accepted so that link supervisory functions can
still be performed, such as checking the P/F bit.
Because of this updating, the retransmitted I frame may
have an updated P bit and N(R).
19
Time-out Error Recovery
When a transmission abnormality wipes out a single
I frame, or the last I frame of a group, there is no
way of telling this immediately, since the receiver
does not necessarily know something was sent until
another frame is sent resulting in an out-of-sequence
error. To cope with this situation better, some form
of time-out delay will be incorporated by the sender
after it sends out a frame. This time-out timer is
started at the time a frame is sent, and stopped by the
reception of an acknowledgement for the sent frame. If
the timer times out before an acknowledgement is
received, any unacknowledged frames are retransmitted.
The delay is an agreed upon amount that will vary with
the type of RF medium and signalling speed used.
Rejection Error
A rejection error condition occurs when an error-
free received frame has one of the following problems:
1. An invalid command or response control field.
2. An invalid frame format.
3. An invalid N(R).
4. An information field that exceeds the maximum
the device can accept.
Once a rejection error occurs, no more I frames
are accepted (with the exception of the P/F bit still
usable) until the error is resolved. The error
condition is reported to the other side of the link by
sending either a CMDR or FRMR response frame.
20
Primary/Secondary versus Balanced Operation
There are two basic classes of link level connections.
The first, known as Link Access Procedure (or LAP) is often
called an unbalanced service where the DCE is considered the
primary (or master) devices and the DTEs are considered
secondary (or slave) devices. The second class of service
is known as LAPB, Link Access Procedure Balanced. In this
service both devices are treated as equals as far as
connection requests and other types of commands. There is
still only one DCE and potentially many DTEs, but both ends
can command the link equally.
Primary/Secondary (LAP) Operation
LAP is the older style of link control, where most of
the intelligence was assumed to be in a large mainframe (the
DCE) and the end users were just using smart terminals (the
DTEs). Since network software can have a lot of overhead,
it made sense at the time to put most of the overhead in the
big computer, and just enough smarts to make the link work
in the terminals.
Balanced (LAPB) Operation
LAPB is a slightly modified version of LAP. It has
been changed to allow the two sides of a link to operate in
a more balanced manner. In the official version of X.25
there is still only one DCE to potentially many DTEs, but
the two can operate more as equals than master and slave.
LAPB is what this document describes for use over Amateur
Radio packet networks. Even when there is a network
controller overseeing the network operation, the balanced
link procedure will enhance operation.
21
Connection Operation
In Amateur network operations, it would be very helpful
if one level 2 protocol would work with the various RF
systems in use. An example of this is the difference in
operation between a simple two-station link, and multiple
stations operating thru a network controller. Obviously,
when a network controller exists, it should be considered
the DCE, while the other stations connecting to it would be
the DTEs. A simple two-station connection is another
matter. To this type of connection the station requesting a
connection should always be considered the DTE, while the
device that is receiving the connection request should
operate as the DCE. This simple rule should eliminate any
ambiguity that might otherwise occur under these conditions.
NOTE There are a couple minor changes from the
official X.25 standard in the protocol recommended here.
These changes are done only as absolutely necessary to work
over the shared RF media. Since X.25 was written to work so
that one DCE talked with many DTEs over a closed network, it
cannot properly cope with a channel where there may be many
DCEs linked to many DTEs. Some amateurs have thrown X.25
out because of this problem. It seems to take just a couple
minor changes in the initial link set-up procedure to make
X.25 work properly over amateur radio. Where these changes
are made, both the original X.25 procedure and the
recommended amateur procedure will be noted.
22
LAPB Procedures
The following describes the procedures used to set-up,
use, and disconnect a balanced link between a DTE and DCE.
These procedures have been taken from X.25 and conform very
closely to that standard, except where it was necessary to
change due to the radio enviroment.
Address Field Operation
All transmitted frames shall have address fields
conforming to above mentioned rules. Except for all-call
frames (those with a single octet of all ones), all frames
will have both the destination device and the source device
addresses in the address field, with the destination address
coming first. This will allow many links to share the same
rf channel. The destination address is always the address
of the station(s) to receive the frame, while the source
address contains the address of the dveice that sent the
frame. The destination address can be a group name or club
call however, if point to multi-point operation is allowed.
This will be discussed further under link operations.
LAPB Connection Establishment
When a device (either a DCE or DTE) wishes to connect
to another device, it will send a SABM command frame to that
device and start a time-out timer (T1). If the other device
is there and able to connect, it will answer with a UA
response frame and at the same time reset both of it's
internal state variables (V(S) and V(R)). The reception of
the UA response frame at the other end will cause the device
requesting the connection to abort the T1 timer and set it's
internal state variables to 0 also.
If the other device doesn't respond before T1 times
out, the device requesting the connection will re-send the
SABM frame, and start T1 running again. This trying to
establish a connection will continue until the requesting
device has tried unsuccessfully a number of times. That
number (N1) is variable, depending on the frequency of
operation, type of transmission (eg. terrestial vs.
satellite), and the signalling speed in use. N1 will be
discussed in another section.
23
Information Transfer
Once a connection has been established as outlined
above, both devices are able to accept I, S, and U frames.
Sending of I Frames
Whenever a station has an I frame to transmit, it
will send the I frame with N(S) of the control field
equal to it's current send state variable V(S). Once
the I frame is sent, the send state variable is
incremented by one.
The station should not transmit any more I frames
if it's send state variable equals the last received
N(R) from the other side of the link plus seven. If it
were to send more I frames, the flow control window
would be exceeded and errors could result.
If a device is in a busy condition, it may still
send I frames as long as the other device is not also
busy.
If a device is in the frame-rejection mode, it
will stop sending I frames.
Receiving I Frames
If a device receives a valid I frame (one with a
correct FCS and whose send sequence number equals the
receiver's receive state variable) and is not in the
busy condition, it will accept the received I frame,
increment it's receive state variable, and act in one
of the following manner:
1. If it has an I frame to send, that I frame
may be sent with the transmitted N(R) equal
to it's receive state variable V(R) (thus
acknowledging the received frame.
Alternately, the device may send an RR frame
with N(R) equal to V(R), and then send the I
frame.
2. If there are no outstanding I frames, the
receiving device will send an RR frame with
N(R) equal to V(R).
If the device is in a busy condition, it may
ignore any received I frames without reporting this
condition other than repeating the indication of the
busy condition.
The reception of I frames that contain zero length
information fields shall be reported to the packet
level but no information field will be transferred.
