Protocol Specification for Level 2 (link level). Proposed by: 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. ------------------------------------------------ | Destination Address| Source Address | ------------------------------------------------ |A1|A2|A3|A4|A5|A6|A7|A8|A9|A10|A11|A12|A13|A14| ------------------------------------------------ Figure 3. Address Field Encoding 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. ------------------------------------------------------------ |Destination Address| Source Address | Repeater Address | ------------------------------------------------------------ |56 bits (7 octets) |56 bits (7 octets) |56 bits (7 octets)| ----------------------------------------------------------- | A1 to A7 | A8 to A14 | A15 to A21 | ------------------------------------------------------------ Figure 3A. Repeater Address Field Encoding 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). 13 --------------------------------------------------------------- | Control Field | Control Field Bits | | Response | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | --------------------------------------------------------------- | Receive Ready RR | 1 0 | 0 0 |P/F| N(R) | | Receive Not Ready RNR | 1 0 | 1 0 |P/F| N(R) | | Reject REJ | 1 0 | 0 1 |P/F| N(R) | --------------------------------------------------------------- Figure 7. S Frame Control Fields Receive Ready (RR) Response Receive Ready is used to do the following: 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. --------------------------------------------------------------- | | | Control Field bits | | Control Field | Type | 1 2 | 3 4 | 5 | 6 7 8 | --------------------------------------------------------------- |Set Asynchronous (SABM) |Command | 1 1 | 1 1 | P | 1 0 0 | |Balanced Mode | | | | | | --------------------------------------------------------------- |Disconnect (DISC) |Command | 1 1 | 0 0 | P | 0 1 0 | --------------------------------------------------------------- |Disconnected Mode (DM) |Response| 1 1 | 1 1 |P/F| 0 0 0 | --------------------------------------------------------------- |Unnumbered Acknowledge (UA) |Response| 1 1 | 0 0 | F | 1 1 0 | --------------------------------------------------------------- |Frame Reject (FRMR) |Response| 1 1 | 1 0 | F | 0 0 1 | --------------------------------------------------------------- |Unnumbered Information (UI) | Either | 1 1 | 0 0 |P/F| 0 0 0 | --------------------------------------------------------------- Figure 8. U Frame Control Fields 15 Set Asynchronous Balanced Mode (SABM) Command 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. --------------------------------------------------- | Information Field Bits | | 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 | | 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 | --------------------------------------------------- | Rejected Frame |0| V(S)|C| V(R)|W|X|Y|Z|0 0 0 0 | | Control Field | | | | | | | | | | --------------------------------------------------- Figure 9. FRMR Frame Information Field Where: 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. 24