AX.25 LAYER 2 PROTOCOL SPECIFICATION This protocol conforms with the ISO Recommendations 3309, 4335 (including DAD 1&2) and 6256 high-level data link control (HDLC) and uses some terminology found in these documents. This protocol also conforms with ANSI X3.66, describing ADCCP, balanced mode. This protocol is written to work equally well in either half- or full-duplex amateur radio enviroments. This protocol has been written to work equally well for either point-to-point connections, or connections made thru a larger device, such as a metropolitan network controller (MNC). This protocol does allow the establishment of more than one layer 2 (link layer) connection per device, if the device is so capable. This protocol also follows in principle the CCITT X.25 recommendation, with the exception of an extended address field and the addition of the Unnumbered Information (UI) frame. Most layer 2 protocols assume that one large device (generally called a DCE, or data circuit-terminating equipment) is connected to several smaller devices (usually called a DTE, or data terminating equipment). AX.25 assumes that both ends of the link are balanced, thereby eliminating the two different classes of device. Frame_Structure Level 2 packet-radio transmissions are sent in small blocks, called frames. These frames are made up of smaller parts, called fields. Fig. 1 shows how the three types of frames are made up. Fig. 1 shows the frames in the same bit order that most packet articles show them. Unfortunately, this method has led to some confusion, since the least-significant bit (LSB) is to the left rather than to the right, as most people would ordinarily assume. I am pointing this out early in this paper to prevent mass confusion as I progress. Later on, I will switch to a hopefully more understandable way of showing the frame ans its components. Field_Definitions The frame is made up of several parts, called fields. Each of these fields is made up of an integral number of octets (or bytes), and serves a specific function. Flag_Field Since amateur packet radio is a bit-oriented protocol, the only way to tell when one frame is over and another is starting for sure is to delimit each frame with a certain bit sequence both at the beginning and the end. This is the job of the flag field. A flag consists of a zero followed by six ones followed by another zero, or 01111110 (7E hex). Due to the bit stuffing mentioned above, the only time this sequence is allowed is at the beginning and end of a legitimate frame. Address_Field The address field is used to identify both where the frame came from and what the destination of it is. In the CCITT recommendation X.25, this field is only one octet long. This permits at most 256 users per level 2 channel, and since some bits of this field were used for other purposes, the real number of users were about thirty per level 2 channel. Both the HDLC and ADCCP recommendations allowed the address field to be extended, so we decided to extend the address field per their recommendations in the amateur version of X.25 to include the callsigns of both the destination and source amateur radio stations. The method used to extend the address field will be described shortly. Control_Field The control field is used to identify the type of frame and control several attributes of the level 2 connection. It is one octet in length, and its encoding will be discussed in a following section. PID-Field The Protocol Identifier (PID) field is used only in information frames, and identifies what kind of layer 3 protocol, if any, is in use. Its encoding is as follows: M L S S B B xx00xxxx Reserved at the moment. xx01yyyy AX.25 layer 3 implemented. xx10yyyy AX.25 layer 3 implemented. 11110000 No layer 3 implemented. 11111111 Escape character. Next byte contains more PID information. Where: 1. An x indicates a "don't care" bit. 2. A y indicates all combinations used. Information_Field The information field is used to convey the actual user data from one end of the link to the other. I fields are allowed in only three tyes of frames, the I frame, the UI frame, and the FRMR frame. The I field can be up to 256 octets long, and should be an even multiple of octets long. Any information in the I field should be passed along the link totally transparently, except for any zero-bit insertion necessary to prevent flags from accidentally appearing in the I field. Frame_Check_Sequence The frame-check sequence is a sixteen-bit number calculated by both the sender and receiver of a frame. It is used to make sure that the frame was not corrupted by the medium used to get the frame from the sender to the receiver. It is calculated in accordance with ISO 3309 (HDLC) recommendations. Bit_Stuffing In order to assure that the flag sequence mentioned above doesn't accidentially appear anywhere else in a frame, as the frame is being sent it should be monitored, and if more than five contiguous ones are detected, a zero bit should be added between the fifth and sixth ones, eliminating the possibility of a flag appearing in the frame other than where it belongs. The receiver of five ones, a zero, and more ones should automatically eliminate the inserted zero before passing the data on. Bit_Order_of_Transmission With the exception of the FCS field, all other fields in an AX.25 frame should be sent starting with the least-significant bit. In accordance with HDLC practices, the FCS should be sent most-significant bit first. Frame_Abort If a frame must be prematurely aborted, at least fifteen contiguous ones should be sent with no bit stuffing added. Invalid_Frames Any frame consisting of less than 136 bits, or not bounded by opening and closing flags, or not octet aligned (an integral number of octets) should be considered an invalid frame by the link layer. Address_Field_Encoding The address field of all frames should be encoded with both the destination and source amateur callsigns of the frame. If a level 2 amateur "repeater" is to be used, its callsign should also be in the address field. AX.25 follows the HDLC recommended method of extending the address field in order to fit all this information into the address field. Basically, the way the HDLC address field is extended beyond one octet is to reserve the least-significant bit of each octet for what is called an "extender bit". This bit is set to zero if the next octet contains more address field information, and is set to one if this is the last octet. To make room for this extender bit, the amateur radio call sign information is shifted one bit to the left. The actual encoding techniques for both non-repeater and repeater operation follows. Non-Repeater_Address-Field_Encoding If a level 2 repeater is not being used, the address field is encoded as shown in Fig. 2. The destination address is the call sign of the amateur radio station that the frame is addressed to, while the source address contains the amateur call sign who sent the frame. These call signs are the call signs of the two ends of a level 2 AX.25 link only, not of any other station, such as the destination of a packet going thru an intermediary link. Those addresses should be in a higher layer, not layer 2. A1 thru A14 are the fourteen octets that make up the two address sub-fields of the address field. The destination sub-address is seven octets long (A1 thru A7), and is sent first. This will allow the receivers of the frame time to check the destination address sub-field and see if the frame is for them while the rest of the frame is being received. The source address sub-field is then sent in octets A8 thru A14. Both of these sub-fields are encoded in the same manner, except for the last octet having the HDLC address extender bit set. Since they are basically the same, only the destination sub-address will be outlined. There is an extra octet at the end of each address sub-field that allows room for a Secondary-Station Identifier (SSID) and three additional bits for future expansion. The SSID field allows an Amateur Radio operator to have more than one packet radio station. This is useful when an amateur wants to put up a repeater in addition to his regular station for example. Appendix A shows a typical AX.25 frame in the non-repeater mode. Destination Sub-Field Encoding Fig. 3 shows how an amateur call sign is placed in the destination address sub-field, occupying octets A1 thru A7. | Octet | ASCII |Bin.Data|Hex Data| ----------------------------------- | A1 | W |10101110| AE | | A2 | B |10000100| 84 | | A3 | 4 |01101000| 68 | | A4 | J |10010100| 94 | | A5 | F |10001100| 8C | | A6 | I |10010010| 92 | | A7 | SSID |0RRSSID0| | ----------------------------------- Bit Position--> 76543210 Fig. 3. Destination Field Encoding Where: 1. The top octet (A1) is the first octet sent (sort of like popping it off the top of the stack), with bit 0 of each octet being the first bit sent, and bit 7 being the last bit sent. 2. The first (low order or bit 0) bit of each octet is the HDLC extender bit, which is set to zero on all but the last octet in the address field, where it is set to one. 3. The bits marked "R" are reserved bits. They may be used in an agreed upon manner in individual networks. If they aren't implemented, they should be set to one. 4. The characters of the callsign should be standard seven-bit ASCII (upper case only) before being shifted left to make room for the extender bit. If the callsign is less than six characters long, it should be padded at the trailing end with ASCII spaces between the end of the callsign and the SSID octet. 5. The SSID portion of the last octet has been intentionally left vague at this point, and is left up to the individual station to assign. The only recommended restriction is to reserve the all-one condition (1111) for an all-call SSID in case one wants to reach an amateur but doesn't know what SSID that amateur operates under. Level_2_Repeater_Address-Field_Encoding If a frame is to go thru a level 2 amateur packet repeater, there is an additional address sub-field added to the end of the address field. This additional sub-field contains the call sign of the repeater to be used. This will allow more than one repeater to share the same rf channel, which has been a problem with the older protocols. If this field exists, the last octet of the source sub-field has its extender bit set to zero, indicating that more address-field data follows. The repeater address sub-field is encoded in the same manner as the destination and source address subfields, except for one bit in the last octet, called the "H" bit. The H bit is used to indicate whether a frame has been repeated or not. This is necessary to prevent someone from potentially receiving two identical frames, the one going to the repeater, and the one coming back from the repeater. Fig. 4 shows how the repeater address sub-field is encoded. Appendix B is an example of a complete frame on its way back from a repeater. ----------------------------------- | Octet | ASCII |Bin.Data|Hex Data| |---------------------------------| | A15 | W |10101110| AE | | A16 | B |10000100| 84 | | A17 | 4 |01101000| 68 | | A18 | J |10010100| 94 | | A19 | F |10001100| 8C | | A20 | I |10010010| 92 | | A21 | SSID |HRRSSID1| | ----------------------------------- Bit Order --> 76543210 Fig 4. Repeater Address Encoding Where: 1. The top octet is the first octet sent, with bit 0 being sent first, bit 7 sent last of each octet. 2. As with the source and destination address sub-fields discussed above bit 0 of each octet is the HDLC address extender bit, which is set to zero on all but the last address octet (A21) where it is set to one. 3. The "R" bits are reserved just like in the source and destination sub-fields. 4. The "H" bit is the has-been-repeated bit. It is set to zero on a non-repeated frame, and set to one by the repeater when the frame has been repeated. It should be noted that some of the advantages of this addressing scheme are mentioned in Appendix C. Control_Field_Formats The control field is responsible for identifying what type of frame is being sent, and is also used to convey commands and responses from one end of the link to the other to maintain proper control over the link. The control fields used in AX.25 use the CCITT X.25 control fields for balanced operation, with an additional control field taken from ADCCP to allow connectionless and round-table operation. There are three general types of AX.25 frames. They are the Information frame (I frame), the Supervisory frame (S frame), and the Unnumbered frame (U frame). Fig. 5 shows the basic format of the control field associated with these types of frames. ---------------------------------------- |Control Field | Control Field Bits | | Type | 7 6 5 | 4 | 3 2 1 0 | ---------------------------------------- | I Frame | N(R) |P/F| N(S) | 0 | ---------------------------------------- | S Frame | N(R) |P/F| S S| 0| 1 | ---------------------------------------- | U Frame | M M M |P/F| M M| 1| 1 | ---------------------------------------- Fig. 5. Control Field Formats Where: 1. Bit 0 is the first bit sent, bit 7 is the last bit sent of the control field. 2. N(S) is the send sequence number (bit 2 is the LSB). 3. N(R) is the receive sequence number (bit 6 is the LSB). 4. The "S" bits are the supervisory function bits, and their encoding is discussed below. 5. The "M" bits are the unnumbered frame modifier bits and their encoding is discussed below. 6. The P/F bit is the Poll/Final bit. Its function is described in more detail shortly. Control_Field_Definitions Information Frame Control Field All I frames have bit 0 of the control field set to zero. N(S) is the sender's send sequence number (the send sequence number of this frame). N(R) is the sender's receive sequence number (the sequence number of the next expected received frame. These numbers are described in the section regarding flow control. Supervisory Frame Control Field Supervisory frames are denoted by having bit 0 of the control field set to one, and bit 1 of the control field set to zero. 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 for S frames. Unnumbered Frame Control Field Unnumbered frames are distinguished by having both bits 0 and 1 set to one. U frames are responsible for maintaining control over the link beyond what is accomplished with S frames. They are also responsible for the establishment and tearing down of the link. U frames also allow for the transmission and reception of information outside of the normal flow control. Some U frames may contain information fields. Control_Field_Parameters Sequence_Numbers_and_Variables Every AX.25 I frame shall be assigned a sequential number from 0 to 7. This will allow up to seven outstanding I frames per level 2 connection at a time. Send_State_Variable_V(S) The send state variable is an internal variable that is never sent. It contains the next sequential number to be assigned to the next transmitted I frame. This variable is updated upon the transmission of each I frame. Send_Sequence_Number_N(S) The send sequence number is found in the control field of all I frames. It contains the sequence number of the I frame being sent. Just prior to the transmission of the I frame, N(S) is updated to equal the send state state variable. Receive_State_Variable_V(R) The receive state variable is an internal variable that contains the sequence number of the next expected received I frame. This variable is updated upon the reception of an error-free I frame whose send sequence number equals the present received state variable value. Received_Sequence_Number_N(R) The received sequence number is in both I and S frames. Prior to sending an I or S frame, this variable is updated to equal that of the received state variable, thus implictly acknowledging the proper reception of all I frames up to and including N(R)-1. Poll/Final_(P/F)_Bit The P/F bit may be used in 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 response (final) bit in the appropriate frame. Only one outstanding poll condition per direction is allowed at a time. Control_Field_Encoding Information_Frame_Control_Field The information frame control field is encoded as shown in Fig. 6. These frames are sequentially numbered to maintain control of their passage over the link level connection. Control Field Bits ------------------------- | 7 6 5 | 4 | 3 2 1 | 0 | ------------------------- | N(R) |P/F| N(S) | 0 | ------------------------- Fig. 6. I Frame Control Field Supervisory_Frame_Control_Field The supervisory frame control fields are encoded as shown in Fig. 7. In AX.25, S frames are used only as responses to other frames. ------------------------------------------------ | Control Field Bits | 7 6 5 | 4 | 3 2 | 1 0 | |----------------------------------------------| | Receive Ready RR | N(R) |P/F| 0 0 | 0 1 | |Receive Not Ready RNR | N(R) |P/F| 0 1 | 0 1 | | Reject REJ | N(R) |P/F| 1 0 | 0 1 | ------------------------------------------------ Fig. 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, 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. 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 environment, 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. Fig. 8 shows the layout of U frames implemented within this standard. ------------------------------------------------ | Control Field |Type| Control Field Bits | | | | 7 6 5 4 3 2 1 0 | |----------------------------------------------| |Set Asynchronous |Cmd| 0 0 1 | P | 1 1 | 1 1 | |Balanced Mode-SABM| | | | | | |----------------------------------------------| | Disconnect-DISC |Cmd| 0 1 0 | P | 0 0 | 1 1 | |----------------------------------------------| | Disconnected Mode|Res| 0 0 0 |P/F| 1 1 | 1 1 | | DM | | | | | | |----------------------------------------------| | Unnumbered |Res| 0 1 1 | F | 0 0 | 1 1 | | Acknowledge-UA | | | | | | |----------------------------------------------| | Frame Reject-FRMR|Res| 1 0 0 | F | 0 1 | 1 1 | |----------------------------------------------| | Unnumbered |Eit| 0 0 0 |P/F| 0 0 | 1 1 | | Information-UI |her| | | | | ------------------------------------------------ Fig. 8. U Frame Control Fields 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. 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 Fig. 9 below. -------------------------------------------------- | Information Field Bits | | 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | | 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| |------------------------------------------------| | 0 0 0 0|Z|Y|X|W| V(R)|C| V(S)|0| Rejected Frame| | | | | | | | | | | Control Field | -------------------------------------------------- Fig. 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. 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 8, and 20 to 23 are set to 0. Bit 12 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 interfering with a next higher layer. 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). Reject_(REJ)_Error_Recovery REJ is used to request a retransmission of I frames following the detection of a sequence error. Only one outstanding reject condition is allowed at a time. This condition is cleared when the requested I frame has been received. A device receiving the REJ command will clear the error by sending over the I frame indicated in N(R) of of the REJ command frame. 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 signaling 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 a FRMR response frame. 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. Connection_Operation In amateur radio 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. 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 environment. Address_Field_Operation All transmitted frames shall have address fields conforming to above mentioned rules. All frames should 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 device 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 Nconnection to abort the T1 timer and set its 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 signaling speed n use. N1 will be discussed in another section. 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 Nth 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 ast 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. If a busy condition exists, the station receiving the busy condition indication should poll the sender of the busy indication periodically until the busy condition disappears. The reception of I frames that contain zero length information fields shall be reported to the next level but no information field will be transferred. When an I frame is received with a correct FCS, but it's send sequence number does not match the current receiver's receive state variable, the frame should be discarded and a REJ frame should be sent with a receive sequence number equal to one higher (modulo 8) than the last correctly received I frame . Any out-of-sequence received I frames should be handled in this manner. The received state variable and poll bit in such a discarded frame should be checked before throwing it away, and take any action needed depending on the condition of them. Receiving_Acknowledgement Whenever an I or S frame is correctly received, even in a busy condition, the N(R) of the received frame should be checked to see if it includes an acknowldegment of outstanding sent I frames. The T1 timer should be reset if the received frame actually acknowledges previously unacknowledged frames. If the T1 timer is reset, and there are still some frames that have been sent that are not acknowledged, T1 should be started again. If the T1 timer runs out before an acknowledgement is received, the device should proceed to the retransmission procedure. Receiving_Reject Upon receiving a REJ frame, the transmitting station will set its send state variable to the same value are the REJ frames received sequence number in the control field. The device will then retransmit any I frame(s) outstanding at the next available opportunity conforming to the following: 1. If the device is not transmitting at the time, and the channel is open, the device may commence to retransmit the I frame(s) immediately. 2. If the device is operating on a full duplex channel transmittiong a U or S frame when it receives a REJ frame, it may finish finding the U or S frame and then retransmit the I frame(s). 3. If the device is operating in a full duplex channel transmitting another I frame when it receives a REJ frame, it may abort the I frame it was sending and start retransmission of the requested I frames immediately. 4. The device may send just the one I frame outstanding, or it may send more than one if any more I frames followed the first one not acknowledged, provided the total to be sent does not exceed the flow control window (7 frames). If the device receives a REJ frame with the poll bit set, it should respond with either an RR or RNR frame with the final bit set before retransmitting the outstanding I frame(s). Receiving_an_RNR_Frame Whenever a device receives an RNR frame, it may transmit or retransmit the I frame whose send sequence number equals that of the received sequence number indicated in the RNR control field. If timer T1 runs out after the RNR was received, the waiting acknowledgement procedure listed below should be performed. The poll bit may be used in conjunction with S frames to test for a change in the condition of the busied out station. No I frames other than the one mentioned above may be sent out before the busy condition is cleared. Sending_a_Busy_Indication Whenever a device enters a busy condition, it will indicate this by sending an RNR response at the next opportunity. While the device is in the busy condition, it may receive and process S frames, and if a received S frame has the P bit set to one, the device should send a RNR frame with the F bit set to one at the next possible opportunity. To clear the busy condition, the device should send either a RR or REJ frame with the received sequence number equal to the current receive state variable, depending on whether the last received I frame was properly received or not. Waiting_Acknowledgement The device should maintain an internal retransmission count variable which is set to zero whenever another I frame is acknowledged (either thru the reception of a UA or RNR frame, or when a received I or S frame has an N(R) higher than the last received N(R), showing the acknowledgement of additional I frames). Any time the timer T1 runs out, the device will re-enter the timer recovery condition, the retransmission count variable will be incremented by one, and another internal variable (X) will be set to the current send state variable value. The device will then restart the T1 timer, set its receive state variable to the last receive sequence number, and retransmit the corresponding I or S frame with the P bit set to one. The timer recovery condition is cleared when the device receives a valid S frame with the F bit set to one. If the device receives an S frame with the F bit set to one and N(R) within the range from the current send state variable to X mentioned above inclusive while in the timer recovery condition, this condition will be cleared, and the send state variable will be set to the N(R) received. If the device receives an S frame with the F bit set to zero but otherwise the same condition as the last paragraph, the timer recovery condition will NOT be cleared. The received N(R) may be used however to update the send state variable. The device may keep the last I frame transmitted (even if it was acknowledged) to be retransmitted with the P bit set to one if timer T1 expires at a later time. Once the retransmission count variable reaches N2, the device should proceed to the resetting procedures outlined below. Link_Disconnection When in the information-transfer phase, either device may initiate a link disconnection by sending a DISC frame. It should then start its T1 timer, and wait for a response. If the proper response doesn't come before T1 times out, it should send the DISC frame again and restart T1. If this happens N2 times, the device should enter the disconnected state. When a DISC frame is received, the receiver should return a UA response frame, and enter the disconnected state. Disconnected_State After having sent a DISC frame and received a UA, or receiving a DISC and having sent a UA, the device will enter the disconnected state. In the disconnected state, the device may initiate a link set-up as outlined in connection establishment above. It may also respond to the reception of a SABM and establish a connection, or it may ignore the SABM and send a DM instead. Any station receiving a DISC command while in the disconnected state should send back a DM response frame. Any device receiving a command frame other than a SABM or UI frame with the P bit set to one should respond with a DM frame with the F bit set to one. The offending frame should also be ignored. When the device enters the disconnected state after an error condition or if it has recovered from an internal error condition by coming up in the disconnected state, it should indicate this by sending a DM response rather than a DISC frame. It should start the T1 timer when the DM is sent, and if T1 times out before getting a SABM or DISC frame back, it should send another DM frame, and restart T1. After retransmitting the DM frame N2 times, the device will remain in the disconnected state, and no other action will be taken. Resetting_Procedure The resetting procedure is used to initialize both directions of flow after a nonecoverable error has occured. This resetting procedure is only used when in the information transfer phase of an AX.25 link. A device shall request a reset by sending an SABM frame. Upon receiving an SABM frame from a station previously connected to, the receiver of an SABM frame should send a UA frame back at the earliest opportunity. Both devices should then set their send and receive state variables to zero. Any busy condition that previously existed will also be cleared. It is possible to initiate a disconnect procedure instead of resetting the link. One device may ask the other to reset the link by sending a DM response frame. After the DM frame is sent, the sending device will then enter the disconnected state. One device may ask the other to initiate a link reset by transmitting a FRMR response frame. After sending the FRMR frame, the sending device will enter the frame reject state. This condition is cleared when the device that sent the FRMR frame receives an SABM or DISC command, or a DM response frame. Any other command received while the device is in the frame reject state will cause another FRMR to be sent out with the same information field as originally sent. The device that sent the FRMR frame should start the T1 timer when the FRMR is sent. If above mentioned frames are not received before the timer runs out, the FRMR frame should be retransmitted, and the T1 timer restarted as described in the waiting acknowledgement section above. If the FRMR is sent N2 times without success, the link should be reset. Rejection_Conditions A device should initiate the link-reset procedure when a frame is received with the correct FCS and address field during the information transfer phase with one or more of the following conditions: 1. The frame is not known as a command or response to the device. 2. The information field is invalid (as an example is longer than 256 octets) A device will initiate a reset procedure whenever it receives a DM or FRMR response frame during the information transfer phase. A device may initiate a reset procedure also whenever it receives a UA response frame or if it receives an unsolicited response frame with the F bit set to one. Collision_Recovery Collisions_in_a_Half-Duplex_Enviroment Collisions of frames of any type in a half-duplex enviroment are essentially taken care of by the retry nature of the T1 timer and retransmission count variable. No other special action needs to be taken. Collisions_in_a_Full-Duplex_Enviroment Collisions in a full-duplex enviroment are not really frame collisions, but have more to do with the devices being pulled in two different directions at the same time. Collisions_of_Unnumbered_Commands If the sent and received U command frames are the same, both devices should send a UA response at the earliest opportunity, and both devices should enter the indicates state. If the sent and received U commands are different, both devices should enter the disconnected state, and transmit a DM frame at the earliest opportunity. Collision_of_a_DM_with_a_SABM_or_DISC When an unsolicited DM response frame is sent, a collision between it and a SABM or DISC may occur. In order to prevent this DM from being misinterpreted, all unsolicited DM frames should be transmitted with the F bit set to zero. All SABM and DISC frames should be sent with the P bit set to one, so there isn't any confusion when a DM frame is received. Connectionless_Operation In Amateur Radio circles, there is a type of operation that isn't really feasable using level 2 connections. This operation is the roundtable, where several amateurs may be engaged in one conversation. The only way to accomplish this in a connected mode would be to have everyone crossconnected with each other. This would require a seperate frame to be sent to each member of the roundtable every time someone says something. Obviously, this mode is not practical. The way most amateur packet radio enthusiasts have ended up implementing the roundtable operation is outside the AX.25 connection, but still using the AX.25 frame structure. AX.25 does allow a special frame for this operation, called the Unnumbered Information (UI) frame. It is recommended that when this type of operation is in use, the destination address have a code word installed in it to prevent the users of that particular roundtable from seeing all frames going thru the shared RF medium. An example of this is if a group of amateurs are in a roundtable discussion about packet radio, they could put PACKET in the destination address, so they would only receive frames from others in the same discussion. An added advantage of the use of AX.25 in this manner is that the source of each frame is in the source address sub-field, so re could be written to automatically display who is making what comments. Admittedly, this is a kludge to the level 2 AX.25 protocol. This type of operation really belongs at the next layer (layer 3, packet level) of operation but until layer 3 is implemented, this appears to be an acceptable substitute. Keep in mind that this mode is connectionless, so all transmitted frames should be of good quality, as there will be no requests for retransmissions of bad frames. Collisions will also occur, with the potential of losing the frames that collided. List_of_System_Defined_Parameters Timers It is recommended that there are two timers used to maintain the integrity of the AX.25 layer 2 connection. The first timer, T1, is used to make sure a device doesn't wait forever for a response to a frame it sends. This timer cannot be expressed in absolute time, since the time required to send frames varies greatly with the baud rate used at level 1. T1 should be at least twice the time it would take to send a maximum length frame to the other end of the link, and get the proper response frame back from the other end of the link. This would allow time for the other end of the link to do some processing before responding. The second timer, T2, is used whenever T1 isn't running to make sure that a supervisory frame is sent periodically to maintain link integrity. It also will vary dramatically depending on layer 1 constraints, and is subject for further study. Maximum_Number_of_Retrys_(N2) The maximum number of retrys is used in conjunction with the T1 timer. It will vary depending on the layer 1 in use, but will generally be sixteen. Maximum_Number_of_Octets_in_an_I_Field_(N1) The maximum number of octets allowed in the I field will be 256. There should also be an even multiple number of octets. Maximum_Number_of_I_Frames_Outstanding_(k) The maximum number of outstanding I frames at a time is seven. A smaller number may be used at any time, provided it is agreed upon ahead of time. 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| PID | Info. | FCS | Flag | ------------------------------------------------------------------------ | 01111110 |112/168 Bits| 8 Bits | 8 Bits| N*8 Bits| 16 Bits| 01111110 | ------------------------------------------------------------------------ Figure 1B. Information Frame Construction First Octet Sent -------------------------------------------------- | Address Field of Frame | |------------------------------------------------| | Destination Address | Source Address | |------------------------------------------------| |A1 A2 A3 A4 A5 A6 A7 | A8 A9 A10 A11 A12 A13 A14| -------------------------------------------------- Figure 2A. Non-Repeater Address Field Encoding First Octet Sent ---------------------------------------------------------------------------- | Address Field of Frame | |--------------------------------------------------------------------------- | Destination Address| Source Address | Repeater Address | |--------------------------------------------------------------------------| |A1 A2 A3 A4 A5 A6 A7|A8 A9 A10 A11 A12 A13 A14|A15 A16 A17 A18 A19 A20 A21| ---------------------------------------------------------------------------- Figure 2B. Repeater Address Field Encoding Appendix A. Non-Repeater Frame Example ----------------------------------- | Octet | ASCII |Bin.Data|Hex Data| ----------------------------------- | Flag | |01111110| 7E | | A1 | K |10010110| 96 | | A2 | 8 |01110000| 70 | | A3 | M |10011010| 9A | | A4 | M |10011010| 9A | | A5 | O |10011110| 9E | | A6 | space |01000000| 40 | | A7 | SSID |01100000| 60 | | A8 | W |10101110| AE | | A9 | B |10000100| 84 | | A10 | 4 |01101000| 68 | | A11 | J |10010100| 94 | | A12 | F |10001100| 8C | | A13 | I |10010010| 92 | | A14 | SSID |01100001| 61 | |Control| SABM |00111111| 3F | | PID | none |11110000| F0 | | FCS | part 1|XXXXXXXX| HH | | FCS | part 2|XXXXXXXX| HH | | Flag | |01111110| 7E | ----------------------------------- The frame shown is an SABM frame, not going thru a level 2 repeater, from WB4JFI (SSID=0) to K8MMO (SSID=0), with no level 3 protocol. Appendix B. Repeater Type Operation | Octet | ASCII |Bin.Data|Hex Data| |---------------------------------| | Flag | |01111110| 7E | | A1 | K |10010110| 96 | | A2 | 8 |01110000| 70 | | A3 | M |10011010| 9A | | A4 | M |10011010| 9A | | A5 | O |10011110| 9E | | A6 | space |01000000| 40 | | A7 | SSID |01100000| 60 | | A8 | W |10101110| AE | | A9 | B |10000100| 84 | | A10 | 4 |01101000| 68 | | A11 | J |10010100| 94 | | A12 | F |10001100| 8C | | A13 | I |10010010| 92 | | A14 | SSID |01100000| 60 | | A15 | W |10101110| AE | | A16 | B |10000100| 84 | | A17 | 4 |01101000| 68 | | A18 | J |10010100| 94 | | A19 | F |10001100| 8C | | A20 | I |10010010| 92 | | A21 | SSID |11100011| E3 | |Control| SABM |00111111| 3F | | PID | none |11110000| F0 | | FCS | part 1|XXXXXXXX| HH | | FCS | part 2|XXXXXXXX| HH | | Flag | |01111110| 7E | ----------------------------------- The above frame is the same as in Appendix A, but with the addition of a repeater address subfield (WB4JFI, SSID=1). The H bit is set, indicating this is from the output of the repeater. Appendix C. 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. 9. In round-table operation, every frame sent will have the source address imbedded in it, allowing automatic printing of the source of the frame. Appendix D. Layer 2 AX.25 State Table ----------------------------------------------------------------------------------------------------------------------------------- | State |I with|I with-|RR with|RR with-|REJ with|REJ with-|RNR with|RNR with-| SABM | DISC | UA | DM | FRMR | | | Poll |out P | Final |out F | Final |out F | Final |out F |either|either| either| either | either | |---------------------------------------------------------------------------------------------------------------------------------| |S1 Disconnected | DM | | DM | | DM | | DM | |UA,S5 | DM | |SABM,S2 | | |---------------------------------------------------------------------------------------------------------------------------------| |S2 Link Setup | | | | | | | | | UA |DM,S1 | S5 | S1 | | |---------------------------------------------------------------------------------------------------------------------------------| |S3 Frame Reject | FRMR | | FRMR | | FRMR | | FRMR | |UA,S5 |UA,S1 | |SABM,S2 | SABM,S2| |---------------------------------------------------------------------------------------------------------------------------------| |S4 Disconnect Rqst | | | | | | | | | DM | UA | S1 | S1 | | |---------------------------------------------------------------------------------------------------------------------------------| |S5 Information Xfr | RR | I | I | I | I | I | S9 | S9 | UA |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| |---------------------------------------------------------------------------------------------------------------------------------| |S6 REJ Frame Sent | RR,S5| I,S5 | I | I | I | I | S15 | S15 |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| |---------------------------------------------------------------------------------------------------------------------------------| |S7 Waiting Acknow. | RR | I | I,S5 | I | I,S5 | I | S9 | S12 |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| |---------------------------------------------------------------------------------------------------------------------------------| |S8 Device Busy | RNR | RNR | I | I | I | I | S10 | S10 | UA |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| |---------------------------------------------------------------------------------------------------------------------------------| |S9 Remote Device | RR | RR | I,S5 | I,S5 | I,S5 | I,S5 | | |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S10 Both Devices | RNR | RNR | I,S8 | I,S8 | I,S8 | I,S8 | | |UA,S8 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S11 Waiting Acknow.| RNR | RNR | I,S8 | I | I,S8 | I | S10 | S13 |UA,S8 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | and Device Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S12 Waiting Acknow.| RR | RR | I,S5 | I,S7 | I,S5 | I,S7 | | |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | and Remote Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S13 Waiting Acknow.| RNR | RNR | I,S8 | I,S11 | I,S8 | I,S11 | | |UA,S8 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | Both Devices Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S14 REJ Sent and | RNR | RNR | I | I | I | I | S16 | S16 |UA,S8 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | and Device Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S15 REJ Sent and |RR,S9 | RR,S9 | I,S6 | I,S6 | I,S6 | I,S6 | | |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | Remote Busy | | | | | | | | | | | | | | |---------------------------------------------------------------------------------------------------------------------------------| |S16 REJ Sent and | RNR | RNR | I,S14 | I,S14 | I,S14 | I,S14 | | |UA,S5 |UA,S1 |SABM,S2|SABM,S2 | SABM,S2| | Both Devices Busy | | | | | | | | | | | | | | ----------------------------------------------------------------------------------------------------------------------------------- Ritorna a Software Radioamatoriale by IW3FQG