FS-1052: Appendix B

10. GENERAL.

10.1 Scope. This appendix describes the characteristics, interoperability requirements and performance requirements of the FED-STD-1052 data link protocol (DLP). The DLP supports a data link layer protocol as defined by the International Organization for Standardization (ISO) network reference model. This protocol, when used in conjunction with an appropriate modem, provides a method for transmitting error-free data over an HF radio circuit.

10.2 Applicability. This appendix is a nonmandatory part of FED-STD-1052, however, when the optional data link protocol is used, it shall be implemented in accordance with this appendix.

20. APPLICABLE DOCUMENTS. See section 2.

30. DEFINITIONS. See section 3 and definitions below.

30.1 Terms. When used in this appendix, the following terms have the meanings indicated.

• Byte: A field or number comprised of eight bits; synonymous with the term octet used in other standards.

• Control frame: A frame carrying control information between DLP terminals.

• Data frame: A frame carrying user data.

• Data series: A sequence of data frames sent contiguously in a single transmission. The data frames in a data series may carry discontiguous portions of a message.

• Frame: An indivisible unit conveyed over a data link, which carries either control information or user data in a standardized format.

• Herald: A control frame that announces the intention of sending subsequent data frames.

• Receive terminal: The terminal which receives data frames and sends herald acknowledgments and data acknowledgments. When the link is reversed, this becomes the transmit terminal. Note: this terminal is not necessarily the same as the "Destination" (user).

• Transmit terminal: The terminal sending the herald and data frames. When the link is reversed, this becomes the receive terminal. Note: this terminal is not necessarily the same as the "Source" (user)

30.2 Abbreviations and acronyms. (Not defined in section 3).

• DLP: data link protocol

• MDP: message delivery protocol

• p/o: part of

40. GENERAL REQUIREMENTS.

40.1 Modes. The DLP, defined in this appendix, provides three (one has two forms) modes of operation. These provide a variety of data transfer methods intended to meet the requirements of most data transfer applications over the HF channel. Although the DLP has been optimized for operation with the FED-STD-1052 serial (single-tone) waveform, it has been designed to operate with any arbitrary modem waveform. The modes within this DLP are designed to provide a wide range of performance with varying degrees of implementational complexity.

40.1.1 ARQ mode. The primary mode of operation (mandatory) is the automatic repeat request (ARQ) mode, which provides for error-free point-to-point data transfer. One alternative of this mode uses fixed-length control frames and a minimum of link reversals. The other alternative provides additional functionality and flexibility by employing variable length control frames. Both alternatives employ a control frame acknowledgment scheme.

40.1.2 Broadcast mode. A secondary mode of operation (mandatory) is the Broadcast (non-ARQ) mode. The Broadcast mode allows unidirectional data transfer using fixed-length frames to multiple (as well as to single) receivers. No transmissions from the receiving terminal are desired or required. See par. 50.4.3.2.

40.1.3 Circuit mode. The other secondary mode, the Circuit mode (optional), allows a link to be established and maintained in the absence of traffic. The ARQ variable-length frame protocol is used along with a technique to maintain the data link connection in the absence of user data. See par. 50.4.3.3.

40.2 Implementation. The protocol modes defined in this appendix are nonmandatory modes of FED-STD-1052. However, all terminals (message processors) that provide the DLP shall, as a minimum, fully implement the ARQ mode and the Broadcast mode. The Circuit mode is optional in all terminals.

40.3 Functionality.

40.3.1 Open Systems Interconnection (OSI) compatibility. The DLP provides the functionality required to support a data link service defined in ISO/IEC 8886.3. The DLP defined in this appendix does not provide this service directly.

40.3.2 Physical circuit. Implementations of the DLP shall operate over both simplex and duplex physical circuits. The DLP was developed for the serial (single-tone) waveform described in sec. 5.4, but is usable over other physical circuits as well.

40.3.3 Priority. The DLP provides a means for users to unambiguously resolve the relative priority of messages and transfer higher priority messages before transferring lower priority messages. The DLP allows two users to transfer messages of equal priority in both directions over either simplex or duplex links on an equal basis (see pars. 50.1.6.6 and 50.4.1.4).

40.3.4 Preemption. The DLP provides mechanisms for preemption (in either the forward or reverse direction) of a lower-priority message to transfer a higher-priority message (mandatory), and the resumption of the transfer of the lower-priority message after the complete transfer of the higher-priority message (optional). The protocol provides a means for the receive terminal to specify the resumption point within the preempted message, or to request complete retransmission if the preemption resulted in the disposal of the preempted message (see sec. 50.4.1.5).

40.3.5 Flow control. The FED-STD-1052 message delivery protocol (MDP) provides a method for the receive terminal to control the rate at which the transmit terminal sends the messages. The MDP allows the receive terminal to suspend transfer of messages from the transmit terminal for an indefinite period of time and resume transfer from an arbitrary position in the interrupted message (see pars. 50.1.4.2.1.2 and 50.4.3.1.4).

40.3.6 Channel optimization. The DLP provides a means for optimizing the performance of the protocol under varying channel conditions, through manipulation of transmission parameters such as data rate, frame size, number of data frames in each transmission (series), and the size of the modem interleaver.

40.3.7 Synchronization. The MDP provides a method of ensuring that the terminals are in compatible states prior to attempting the transfer of data, a means for the terminals to be returned to a defined state, and synchronization of the activities of the two terminals (see sec. 50.4.2).

40.3.8 Order of transmission. Data and control fields shall be transmitted least-significant bit (LSB) first in all cases. Control fields that contain multi-byte data, such as addresses, shall be transmitted least-significant byte first. User data bytes shall be sent in the order received from the user (or higher-layer protocol). In this standard, bit and byte sequences are shown with the most significant bit (MSB) to the left and the LSB to the right, unless otherwise noted.

50. DETAILED REQUIREMENTS.

50.1 Protocol frames. The DLP shall be implemented through an exchange of protocol frames, from one message processor to another message processor, over a physical channel. The protocol frames shall include a method for detecting uncorrected bit errors induced by the physical channel.

50.1.1 General frame format. The MDP frame format shall be as shown on figure 12.

50.1.1.1 Frame sync pattern. Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010". Note: As shown here in transmission sequence, the left-most bits are the LSBs. If a transmission contains more than one frame, a two-byte sync sequence shall be inserted between each pair of adjacent frames. This pattern (hexadecimal) shall be "5C5C".

50.1.1.2 Sync Mismatch Bit. The first bit following the last synchronization byte shall be set to a logic 1 to signify the end of the synchronization pattern and the start of the protocol frame.

50.1.1.3 Frame Type bit. In each frame, the bit following the Sync Mismatch Bit shall be the Frame Type indicator bit. This bit shall be set to logic Ø to indicate that the current frame is a data frame, or set to logic 1 to indicate that the current frame is a control frame.

Figure 12. Basic protocol frame format

50.1.1.4 Frame Headers and Data. The Frame Headers and Data field shall immediately follow the Frame Type bit and shall contain either control frame headers or data frame headers and data. The length of the Frame Headers and Data field for control frames is either fixed at 486 bits or variable, depending on the number of header fields contained within the control frame (see par. 50.1.2.1.2). The length of the Frame Headers and Data field (number of data bytes per data frame) shall be specified in the herald announcing the data frame series.

50.1.1.5 CRC error control checksum. A 32-bit CRC following the Frame Headers and Data field shall conclude each protocol frame. After initially setting all 32 bits to one, the CRC shall be calculated using all bits of the frame starting with the Sync Mismatch bit and ending with the last bit of the Frame Headers and Data field. The generator polynomial for the CRC calculation shall be:

x³²+x²⁶+x²³+x²²+x¹⁶+x¹²+x¹¹+x¹⁰+x⁸+x⁷+x⁵+x⁴+x²+x+1.

NOTE: The calculation and transmission of the CRC shall be in accordance with FED-STD-1003A, Sep. 1981, par. 5.1.

50.1.2 Control frame format. Figure 13 defines the format of the DLP control frames. The fields of the control frame are described in the following paragraphs.

50.1.2.1 Control frame header fields. The control frame header fields follow the Frame Header fields (Sync Mismatch Bit and Frame Type) in control frames, and are described below.

50.1.2.1.1 Protocol Version. The Protocol Version field shall contain a 2-bit code representing the version of the DLP implemented on the terminal sending the frame. Implementations based on this DLP version shall set the field to zero (ØØ).

50.1.2.1.2 Control Mode. The Control Mode field shall be used to specify the mode under which the data link will operate after establishment. Three control modes are supported: (a) ARQ mode with two alternatives, one for variable-length control frames and the other for fixed-length control frames, (b) Broadcast mode, and (c) the optional Circuit mode.

a. ARQ. A value of Ø in the Control Mode field shall indicate the ARQ mode with variable-length control frames. In this mode, the control frames may be of variable lengths of up to 520 bits (see sec. 50.2).

b. Broadcast. A value of 1 in the Control Mode field shall indicate the Broadcast mode (see sec. 50.4.3.2). In this mode, the receive terminal(s) shall send no acknowledgment of the control or data frames transmitted. The transmit terminal shall send only 520-bit fixed-length control frames.

c. Circuit. A value of 2 in the Control Mode field shall indicate that the terminal is operating in the Circuit mode with variable-length control frames (see par. 50.4.3.3).

d. A value of 3 in the Control Mode field shall indicate the ARQ mode with fixed- length control frames (520 bits). If, during negotiation, either terminal requests fixed-length control frames, both terminals shall transmit only 520-bit control frames.

Header field name		Field name	Length (bits)	Possible values
Frame Header		Sync Mismatch Bit	1	1 (always 1)
		Frame Type	1	Ø = Data frame 1 = Control frame
Control Frame Header		Protocol Version	2	Set to Ø for this DLP version
		Control Mode	2	Ø = ARQ mode with variable-length control frames 1 = Broadcast mode, no ARQ, fixed-length control frames 2 = Circuit mode, ARQ, variable-length control frames 3 = ARQ mode with fixed-length control frames
		Negotiation Mode	1	Ø = negotiate only when there are changes 1 = negotiate before every data series
		Extended Addressing	1	Ø = 2 byte addressing 1 = 18 byte addressing
		Source Address	16	0000 through FFFF hexadecimal representing two least significant bytes of source terminal address
		Destination Address	16	0000 through FFFF hexadecimal (see above)
Link Management		Link State	2	Ø = Calling 1 = Call acknowledge 2 = Linked up 3 = Dropping link
		Link Timeout	4	Maximum retry time (see text)
Data Transfer		ACK/NAK Type	2	Ø = Null-ACK 1 = Data-ACK 2 = Data-ACK request 3 = Herald-ACK
		ACK Bit-Map/Extended Address	256	Ø = Retransmit associated frame 1 = Error-free frame
		Alternating Data-ACK Frames	1	Changes state for each new data-ACK frame
	H e r a l d	Data Rate Format	1	Ø = Absolute data rate 1 = Relative rate
		Data Rate	3	Code	Absolute format	Relative format
				Ø	75 b/s	÷8
				1	150 b/s	÷4
				2	300 b/s	÷2
				3	600 b/s	No change
				4	1200 b/s	×2
				5	2400 b/s	×4
				6	4800 b/s	×8
				7	No recommendation
		Interleaver Length	1	Ø = Short interleaver 1 = Long interleaver
		Number of Bytes in Data Frames	10	56 through 1023 decimal (see par. 50.1.5.4)
		Number of Frames in Next Series	8	1 through 255 decimal. Ø denotes null-herald (see par. 50.1.5.5)
Message Management		Transmit Message ID	8	Ø through 255 decimal
		Transmit Connection ID	8	Ø through 255 decimal
		Transmit Message Size	24	Message size in bits
		Transmit Message Next Byte Location	21	Position of next byte in message
		Reserved	3	Reserved for future use (set to Ø)
		Transmit Message Priority	8	Ø through 255; Ø is lowest priority message
		Receive Message Next Byte Location	21	Position of next byte required by receive terminal
		Reserved	3	Reserved for future use (set to Ø)
Extended Function		User ID	14	Orderwire flag/Free format user ID
		Function Bits	50	Orderwire data/Reserved
(p/o Frame header)		CRC	32	(see par. 50.1.1.5)

50.1.2.1.3 Negotiation Mode. By default, terminals are required to send a herald to re-negotiate the parameters for data transfer only when those parameters will change for the following data series (see par. 50.4.3.1.1). However, if a terminal receives a control frame with the Negotiation Mode flag set to logic 1, it shall send a herald before every data series subsequently sent on that link until it receives a control frame with the Negotiation Mode flag set to logic Ø.

50.1.2.1.4 Extended Addressing. The Extended Addressing flag shall be used to define the format of the source and destination addresses within the control frame. This flag shall be set to logic Ø when an ACK bit-map is required (i.e., when the ACK/NAK type is data-ACK).

a. When set to logic Ø, the Extended Addressing flag shall indicate that the addresses are restricted to two bytes each, and are contained in the message management header, Source Address field and Destination Address field. In this case, the 256 bits of the ACK Bit-Map/Extended Address field are available for data frame acknowledgments and flow control (see sec. 50.1.4.2).

b. When set to logic 1, the Extended Addressing flag shall indicate that extended source and destination addressing is being used. In this condition, the source and destination addresses can each be up to eighteen bytes long (see par. 50.1.4.2.1.3).

50.1.2.1.5 Source Address. When the Extended Addressing flag (par. 50.1.2.1.4) in the data transfer header is set to logic Ø, the Source Address field shall contain a two-byte message source address. When the Extended Addressing flag is set to logic 1, the Source Address field shall contain the two least-significant bytes of the extended message source address (see par. 50.1.4.2.1.3). Up to 16 most-significant bytes of the extended address will be contained in the ACK Bit-Map/Extended Address field of the data transfer header.

50.1.2.1.6 Destination Address. When the Extended Addressing flag (par. 50.1.2.1.4) in the data transfer header is set to logic Ø, the Destination Address field shall contain a two-byte message destination address. When the Extended Addressing flag is set to logic 1, the Destination Address field shall contain the two least-significant bytes of the extended message destination address (see par. 50.1.4.2.1.3). Up to 16 most-significant bytes of the extended address will be contained in the ACK Bit-Map/Extended Address field of the data transfer header. A destination address of all ones shall indicate a broadcast address.

50.1.3 Link management header fields.

50.1.3.1 Link State. The Link State field shall contain the current linking status of the terminal. Terminals exchange their respective link states as part of the link management protocol. The following states are defined:

a. Calling. A value of Ø in the Link State field shall indicate that the terminal does not currently have a link established and is attempting to initiate a link with another terminal.

b. Call acknowledge. A value of 1 in the Link State field shall indicate that the terminal does not currently have a link established and is acknowledging a call from another terminal signifying that it is willing to establish a link with the calling terminal.

c. Linked up. A value of 2 in the Link State field shall indicate that the terminal has successfully concluded the link establishment protocol and is linked to the other terminal.

d. Dropping link. A value of 3 in the Link State field shall indicate that the terminal is dropping an established link.

50.1.3.2 Link Timeout. The Link Timeout field contains four bits to indicate the time that the terminal sending the control frame will wait for a valid response to the frame before dropping the link. This field shall be computed before the initial transmission of each control frame, taking into consideration the number of retries the terminal is willing to perform and any data-rate reductions that will be used for retries (see par. 50.4.4.3). This computed time shall be rounded up to the next multiple of 30 s, and encoded as the number of 30-second intervals minus one. Thus a timeout of 25 s is encoded as Ø, and 78 s is encoded as 2. All transmissions of a control frame (including retries) shall carry the same link-timeout value.

50.1.4 Data transfer header fields.

50.1.4.1 ACK/NAK Type. This field shall indicate the type of acknowledgment being sent.

a. Null acknowledgment (null-ACK). A value of Ø in this field shall indicate a null acknowledgment. This value shall be sent whenever an acknowledgment is not intended or required by context. This value shall be sent in response to a herald when the receive terminal is not willing to accept the offered data series.

b. Data acknowledgment (data-ACK). A value of 1 indicates that the control frame contains an acknowledgment of a data transfer series. In this case the ACK Bit-Map (see sec. 50.1.4.2.1) is active and contains the ARQ bits.

c. Data acknowledgment request (data-ACK request). A value of 2 shall indicate that the transmit terminal is requesting the retransmission of an expected data-ACK control frame.

d. Herald acknowledgment (herald-ACK). A value of 3 indicates acknowledgment of a herald from the other terminal.

50.1.4.2 ACK Bit-Map/Extended Address.

50.1.4.2.1 ACK Bit-Map field. The ACK Bit-Map field shall be used to specify which frames of the prior data transfer series were received error free and which frames require retransmission. A position-based relationship is employed in the definition of this field. The least-significant bit of this field (first bit sent) is bit number 255. The most-significant bit of this field (last bit sent) is bit number Ø.

50.1.4.2.1.1 ACK Bit-Map. When the ACK/NAK Type field (par. 50.1.4.1) is set to logic 1 (data-ACK), bits 1 through 255 of the ACK Bit-Map/Extended Address field compose an ACK bit-map, with each bit corresponding to the data frame having the same data frame sequence number (par. 50.3.2.1) as that bit (e.g., bit 1 corresponds to data frame 1 and so on).

a. A logic Ø in the ACK Bit-Map field shall indicate that the associated data frame was missed or received with errors and should be retransmitted.

b. A logic 1 in the ACK Bit-Map field shall indicate that the frame was received error free and does not require retransmission. All bits numbered higher than the number of data frames in the previous data transfer series shall be set to logic Ø.

When acknowledging a series of data frames sent at 4800 b/s, each bit in the ACK Bit-Map field shall correspond to two frames of data. Bit 1 of the ACK Bit-Map field corresponds to the first two data frames in the data series, bit 2 to the third and fourth data frames in the series, etc.

50.1.4.2.1.2 Flow Control. Bit Ø of the ACK Bit-Map field shall be used as a flow control flag when the Extended Addressing flag (par. 50.1.2.1.4) is set to logic Ø (addresses restricted and ACK bit-map active). When the Flow Control flag (bit Ø of the ACK Bit-Map field) is set to logic 1, it signifies that "No new frames" type flow control is in effect. The transmit terminal shall retransmit only unacknowledged data frames (no new data frames) until flow control is lifted IAW par. 50.4.3.1.4.

50.1.4.2.1.3 Extended Address. The Extended Address field becomes active when the Extended Addressing flag (par. 50.1.2.1.4) is set to logic 1 indicating that extended source and destination addressing is being used. The source address and the destination address fields of the message management header shall contain the two least-significant bytes of the extended address. Up to sixteen of the most-significant bytes (128 bits) of the addresses shall be contained in the ACK Bit-Map/Extended Address field. The source address shall be placed in the first (least significant) 128 bits of the field and the destination address shall be placed in the last (most significant) 128 bits of the field. If addresses are shorter than eighteen characters, the ASCII NULL character shall be used to stuff or fill the remaining bytes in the most significant bytes position. See Fig. 14 for an extended address example.

50.1.4.3 Alternating Data-ACK Frames bit. This bit shall be set to alternate (toggle) between Ø and 1 to indicate successive different ACK bit-maps. In the first Data-ACK frame for each message (and the first Data-ACK frame after resumption of a message) this bit shall be set to Ø. Each subsequent different ACK bit-map shall cause this bit to alternate between Ø and 1. If an ACK bit-map is retransmitted, the state of the Alternating Data-ACK Frames bit shall not change. This bit shall be active when the ACK/NAK Type field (par. 50.1.4.1) is set to data-ACK (value 1). This Alternating Data-ACK Frames bit shall be set to Ø for all other type control frames.

50.1.5 Herald header fields. The herald header fields are included in the data transfer header, and are used to negotiate parameters of subsequent data series. They are described in the following paragraphs.

50.1.5.1 Data Rate Format. This bit specifies the format of the Data Rate field that follows. A logic Ø in this field indicates that the Data Rate field specifies absolute data rate. A logic 1 indicates that the Data Rate field specifies relative data rate. The transmit terminal shall use the absolute data rate for at least its first transmission on a link.

50.1.5.2 Data Rate. This field shall be used in Herald and Data-ACK frames to specify the data rate of the following data series, and in Herald-ACK or Data-ACK frames with null-heralds, to recommend a data rate for the next data series. If the Herald-ACK frame contains such a recommendation for a data-rate change, the transmit terminal may, if in agreement, immediately transmit a new herald, updated as required in regard to the data rate. If not in agreement, the transmit terminal shall proceed with sending data frames at the previously announced data rate. The code definitions for each of the data-rate formats are listed in table XXVIII and are shown on Fig. 14. In the absence of higher order control information and the ability to detect baud rate from the waveform preamble, a default data rate of 600 b/s is recommended.

Figure 14. Extended addressing example: from ABCD to WXYZ

50.1.5.3 Interleaver Length. This bit is used by the transmit terminal to distinguish between the short interleaver and the long interleaver mode of the FED-STD-1052 serial (single-tone) waveform (see pars. 5.4.3.4 and 5.4.3.5). The announcement convention shall be the same as defined for data rate,and if the Data Rate field makes no recommendation, the Interleaver Length field shall not be changed. For the purpose of this standard, the short interleaver setting specifies the 0.6 second interleaver. When this protocol is used with any other waveform, the interleaver length field has no defined meaning, and shall be set to logic Ø.

50.1.5.4 Number of Bytes in Data Frames. The Number of Bytes in Data Frames field shall contain a binary number ranging from 56 to 1023 (decimal), inclusive, specifying the size, in bytes, of the data frames announced by this control frame. The number of bytes in each data frame shall not be changed if any of the frames in the following series are retransmissions of earlier frames.

50.1.5.5 Number of Frames in Next Series. This field shall be used by the transmit terminal to specify the number of data frames contained in the next data series following this herald. The maximum number of data frames in a series shall be a function of data rate as defined in Table XXIX. For a 4800 b/s data rate, this field shall be the number of data frames divided by 2. When the number of frame repeats plus the number of remaining frames is equal to or greater than 255, set the value to 255 (see par. 50.4.3.1.1. for details). When the data rate changes, the number of frames in the next series shall change by the same proportion. If this field is set to value Ø, the entire herald is a null-herald.

50.1.6 Message management header fields. The message management header fields contain data that identify and specify the user message being transferred.

50.1.6.1 Transmit Message ID. The Transmit Message ID field shall contain an eight-bit message number, ranging from 0 to 255 (decimal), that uniquely identifies each message sent over the data link. This message number shall be incremented for each new message transmitted. When the transfer of a message is interrupted by a preemption or link outage, the same message number shall be used upon resumption of the message transfer as was used prior to the interruption. This allows the receiving terminal to associate the resumed message with the previously received portions of the message.

50.1.6.2 Transmit Connection ID. The Transmit Connection ID field shall be used by terminals that support multiple data link connections to identify the data link connection to which the transmit message is associated. Up to 255 connection identifications are available.

50.1.6.3 Transmit Message Size. This field shall specify the total length of the current message in bits. The range of this field is from 0 to 16,777,215, with the extreme values given special meanings:

a. If the Transmit Message Size field has the value of zero, the remainder of the message management transmit header fields shall be ignored.

b. If the Transmit Message Size field contains the value of 16,777,215 (all binary 1s), the size of the message is unbounded. Use of this code places the DLP into "bit pipe" mode. Subsequent use of any other message size terminates this mode.

50.1.6.4 Transmit Message Next Byte Location. The Transmit Message Next Byte Location field shall be used by the transmit terminal to specify the starting byte location within the complete message of the data series being announced. This field shall be set to zero at the beginning of each new message transmission. Upon resumption of an interrupted or preempted message, the transmit terminal shall use this field to indicate the restart position within the interrupted message. This byte position shall be the first byte of the earliest frame not acknowledged. Note: This field may wrap around through zero in bit pipe mode.

50.1.6.5 Reserved (transmit). The three bits following the 21 bits of the Transmit Message Next Byte Location field are reserved for future use and shall be set to zero for this DLP version.

50.1.6.6 Transmit Message Priority. This field shall be used to specify the priority of the transmit data message. Priorities shall range from 0 though 255 (decimal). A lower numeric value in the priority field shall specify a lower-priority message. Terminals shall use this information to negotiate the transfer of higher-priority traffic in advance of lower-priority traffic.

50.1.6.7 Receive Message Next Byte Location. The Receive Message Next Byte Location value shall be used by the receiving terminal to specify to the transmitting terminal the required starting byte position in the message being offered. This byte position shall be the first byte of the earliest frame not received. Upon resumption of an interrupted or preempted message, this value shall be used to specify the restart position of the interrupted message. For new messages, this field shall be set to zero. The receive terminal shall set this field to the value specified in the Transmit Message Size field (divided by eight to convert to bytes) if it has already received the entire message being offered. The receive terminal shall set this field to a value greater than that specified in the Transmit Message Size field (divided by eight) if it is unwilling to accept the message being offered. For all other cases during the reception of a message, when this field is present in a control frame from a receive terminal, it shall specify;

a. the first byte of the earliest frame not yet received correctly, to continue the message transfer, or

b. a value greater than or equal to the Transmit Message Size field (divided by eight) to abort the message transfer.

50.1.6.8 Reserved (receive). The three bits following the 21 bits of the Receive Message Next Byte Location field are reserved for future use and shall be set to zero for this DLP version.

50.1.7 Extended function header fields. The extended function fields within the control frame are used to allow additional functions to be added to the message processing terminals at a future date. The extended function fields also support an orderwire data link between two linked terminals. All extended functions, including the orderwire mode, are optional.

50.1.7.1 User ID. The User ID field shall contain a manufacturer identification code or the interoperable mode code zero. When the User ID code is set to zero, the Function Bit field may contain the orderwire seven-bit ASCII data characters. The User ID field can also be used to identify closed system terminals. Note: Closed systems are not necessarily interoperable with other users. A User ID code other than zero shall indicate an operating version that is specialized to the designated user(s) and is not necessarily interoperable with other users. The terminal shall ignore all unknown user IDs received. It is recommended that manufacturers register their code with the custodian of this standard for the purposes of interoperability, identification, and non-duplication of codes.

50.1.7.2 Function Bits. If the User ID field is set to zero, the Function Bits field may contain orderwire data from the terminal's local input/output (I/O) channel which should be routed by the receive terminal to the local I/O channel. This allows a low data rate communications channel between the two terminals to run in parallel with other control frame traffic. Orderwire data shall consist of seven-bit ASCII characters packed into the Function Bit field. Unused bits shall be set to Ø (producing ASCII NULL characters). Other uses are reserved.

50.2 Control frame lengths.

50.2.1 Variable-length control frames. Control frames shall be one of four possible lengths depending on the operating mode and the contents of the control frame. The value set for the Control Mode bits of the control frame header indicates whether the control frames will be fixed (520 bits) or variable (80, 360, or 456 bits). The Control Mode field value 1 indicates Broadcast mode with fixed-length control frames and value 3 indicates ARQ mode, also with fixed-length control frames. The Control Mode field value Ø indicates ARQ mode with variable-length control frames, and value 2 indicates Circuit mode, also with variable length-control frames. The allowable frame lengths and the control fields available in each frame are shown on Fig. 15. Shaded areas in the figure indicate control fields that are not present in the control frame for the frame type listed.

a. Type 1 control frames are the shortest frames allowable. These frames contain frame, control frame, and link management headers defining the link operating mode, the link state of the transmit terminal, the ACK type indicator, and whether or not extended addressing is to be used. Type 1 control frames can be used to send null-ACKs, data-ACK requests, and herald-ACKs.

b. Type 2 control frames contain all fields of the type 1 frame plus the full data transfer header with the herald fields. The ACK Bit-Map/Extended Address field and the Alternating Data-ACK Frames indicator are included. The herald fields provide information on the data rate, interleaver length, the number of frames in the next series, and the number of bytes in the data frames. In addition to the uses of the type 1 frames, these type 2 frames can be used for data-ACKs, heralds, and null-heralds.

c. Type 3 control frames add the message management header fields to the type 2 control frames. In addition to the source and destination addresses, these fields contain accounting information about the message to be transmitted -- message and connection identification, message size, location of an interrupted message restart position, message priority, and the receive terminal's desired restart position. The type 3 control frames can be used to implement all operational capabilities of the protocol, with the exception of the extended functions.

d. Type 4 control frames are 520 bits long and contain all control fields. The extended function header fields of User ID and Function Bits are the added capability. The type 4 control frames can be used to implement all operational capabilities of the protocol.

Header field name	Field name	Length (bits)	Type 1	Type 2	Type 3	Type 4
Frame header	Sync Mismatch Bit	1
	Frame Type	1
Control Frame header	Protocol Version	2
	Control Mode	2
	Negotiation Mode	1
	Extended Addressing	1
	Source Address	16
	Destination Address	16
Link Management	Link State	2
	Link Timeout	4
Data Transfer	ACK/NAK Type	2
	ACK Bit-Map/Extended Address	256
	Alternating Data-ACK Frames	1

	H	Data Rate Format	1
	e	Data Rate	3
	r	Interleaver Length	1
	a	Number of Bytes in Data Frames	10
	l d	Number of Frames in Next Series	8

Message Management	Transmit Message ID	8
	Transmit Connection ID	8
	Transmit Message Size	24
	Transmit Message Next Byte Location	21
	Reserved	3
	Transmit Message Priority	8
	Receive Message Next Byte Location	21
	Reserved	3
Extended Functions	User ID	14
	Function Bits	50
p/o Frame header	CRC	32
Total frame size			80	360	456	520
Note: Shaded areas (Herald and below) indicate fields not included in header

.

50.2.2 Fixed-length control frames. All control frames transferred over the HF data link in the ARQ mode with fixed-length control frames or in the Broadcast mode shall be type 4 (520 bits) and shall contain all of the control fields described in the previous paragraph.

50.3 Data frame format. Data frames transferred over the HF data link, shall be formatted in accordance with Figure 16. Data frames may be variable in length as specified in the herald control frame that announces one or more data series.

50.3.1 Reverse channel control frame fields. These fields shall be used by the transmit terminal to recommend the data-ACK control frames data rate and interleaver length to the receive terminal. (See pars. 50.1.5.1, 50.1.5.2, and 50.1.5.3 for descriptions of the Data Rate Format, Data Rate, and Interleaver Length fields, and par. 30.1 for the definitions of "receive terminal" and "transmit terminal").

50.3.2 Data frame header fields. The data frame header fields are described below.

50.3.2.1 Data Frame Sequence Number. The transmit terminal shall sequentially number each data frame within a data transfer series, starting at the value specified in the Number of Frames in Next Series field of the data transfer header or herald, and decrementing to one in the last frame of the series. The transmit terminal shall place this number in the Data Frame Sequence Number field of the data frame. The receive terminal shall use this number to construct the position-based ACK bit-map (sec. 50.1.4.2) for the data acknowledgment reply. When the modem is operating at 4800 b/s, the sequence number remains the same for the first two frames and counts down in pairs of frames after that.

Header field name	Field name	Length (bits)	Possible values
Frame Header	Sync Mismatch Bit	1	1 (always 1)
	Frame Type	1	Ø = Data frame
Reverse Channel Control Frame	Data Rate Format	1	Ø = Absolute data rate 1 = Relative rate
	Data Rate	3	Code	Absolute format	Relative format
			Ø	75 b/s	÷8
			1	150 b/s	÷4
			2	300 b/s	÷2
			3	600 b/s	No change
			4	1200 b/s	×2
			5	2400 b/s	×4
			6	4800 b/s	×8
			7	No recommendation
	Interleaver Length	1	Ø = Short interleaver 1 = Long interleaver
	Reserved	1	Reserved for future use. Set to Ø.
Data Frame Header	Data Frame Sequence Number	8	255 through 1 (counts down); identifies data frame within series.
	Message Byte Offset	21	Position of frame in message (byte Ø is first byte)
	Reserved	3	Reserved for future use. Set to Ø.
Data	Data	Vari- able	User data. Variable size as defined in herald control frame.
P/O Frame header	CRC	32	(see par. 50.1.1.5)

50.3.2.2 Message Byte Offset. This field shall be set by the transmit terminal to the relative start position of the data contained in this data frame. The receive terminal shall use this information to assist in the reassembly of the message. Data frames within a series shall be arranged according to increasing message byte offset.

50.3.2.3 Reserved. Reserved for future use. Set to Ø for this DLP version.

50.3.3 Data field. The Data field shall contain the message data. The length of the Data field shall be as specified in the Number of Bytes in Data Frames field of the data transfer header of the most recent herald.

50.4 Protocol suite. The DLP is comprised of a suite of protocols that operate in concert to provide the reliable data link service functions required by ISO/IEC 8886.3. The protocol suite consists of message management, link establishment, and data transfer protocols. The three protocols are loosely coupled and proceed concurrently through an orderly exchange of control frames as defined in the following paragraphs.

50.4.1 Message management protocol. DLP terminals shall use the message management protocol to coordinate the transfer of data messages, priority preemption of message transfer, and resumption of preempted messages. The message management protocol shall be implemented through an exchange of control frames containing the message management header fields (par. 50.1.6). The message management header fields contain a complete definition of the message to be transferred or resumed. Terminals shall be able to selectively accept or reject messages over the data link based upon the message source, priority, length, or connection number.

50.4.1.1 Message announcement. A terminal shall announce a message to be transferred over the HF data link by transmitting a control frame with a message management header that defines the parameters of the offered message. Within the message management header, the terminal shall specify the source address and the destination address as well as specifying the message identification number, connection identification, total message size, the relative starting point within the message, and the message priority. Terminals that support multiple data connections shall specify the connection number of the offered message in the announcing message management header. All others shall set the Transmit Connection ID field to Ø. Terminals shall specify a starting point of zero for all new messages. Transmit terminals may specify an arbitrary start position for messages restarted after a link interruption (due to preemption or link failure), however the start position specified by the receive terminal shall override the position specified by the transmit terminal. Message announcement control frames shall also contain a herald describing the first data series to be transferred (see par. 50.1.2.1.3).

50.4.1.2 Message acceptance. A terminal operating in one of the ARQ modes shall signify its acceptance of an announced message by sending a control frame containing a herald-ACK in response to the herald frame. If other than a type 1 (48 bits) control frame is sent (e.g., in ARQ mode with fixed-length control frames), the message management header fields should duplicate the corresponding fields in the announcing frame. (See par. 50.4.1.5.2 for the case of a receive terminal with higher-priority traffic, and par. 50.4.1.6 for negotiation of starting byte offset in a resumed message). The receive terminal may request a change in the parameters announced in the herald (see par. 50.4.3.1.1.2). For Immediate mode, see par. 50.4.2.4.

50.4.1.3 Message refusal. To refuse an announced message, a terminal operating in one of the ARQ modes shall return a control frame with the Receive Message Next Byte Location field of the message management header set to a value greater than or equal to the value announced in the Transmit Message Size field (divided by eight) of the announcing message management header. However, see par. 50.4.2.4 for Immediate mode.

50.4.1.4 Priority resolution. Terminals shall resolve data link contention by exchanging message management headers announcing the highest priority traffic available for transfer. The terminal with the highest priority traffic shall be allowed to use the data link first. Thus, a terminal receiving announcement of a lower-priority message shall preempt that incoming message IAW par. 50.4.1.5.2, except that the message management header shall be sent with a null-ACK to refuse the first data series (rather than the data-ACK needed when preempting a message in progress). If both terminals have traffic of equal priority, the terminals may share the data link on an equal basis. In such sharing, the two terminals alternate the transmission of data series. Each data-ACK includes a herald. The terminal receiving the data-ACK/herald responds with a herald-ACK. The terminal receiving this herald-ACK responds by transmitting its data series. The terminal receiving the data series responds with a data-ACK/herald, and the link direction reverses again.

50.4.1.5 Message preemption. The message management protocol allows terminals to preempt lower priority traffic with a new message of higher priority. Preemption shall be supported in both the forward direction (higher-priority traffic in the same direction as the preempted traffic) and the reverse direction (higher-priority traffic in the direction opposite to the preempted traffic).

50.4.1.5.1 Forward preemption. A transmit terminal shall preempt the ongoing transfer of a message with a higher-priority message, by sending a new message management header announcing the new message. This message management header should be sent at the first logical opportunity for a control frame transfer. The receive terminal can refuse the offered message as previously described (par. 50.4.1.3). Upon acceptance of the preempting message, the transmit terminal shall suspend transfer of the preempted message until the higher-priority traffic is transferred. Terminals shall only preempt ongoing-message transfers in the forward direction with messages of higher priority than the preempted message. Nested preemption is allowed, provided that the preemption meets this requirement for relative priority. If a terminal resumes preempted messages, it shall resume them in the reverse order of preemption, i.e., the most recently preempted message shall be resumed first. This ensures that the requirement for relative priority is maintained throughout the preemption and resumption process.

50.4.1.5.2 Reverse preemption. A receive terminal shall preempt the transfer of an incoming message by sending a message management header announcing a higher-priority message at the first available opportunity. The transmit terminal can refuse the offered message as previously described in pars. 50.4.1.3 and 50.4.1.5.1 above. Upon acceptance, the terminals shall reverse the link direction and transfer the higher-priority message until completion. Transfer of the preempted message may then be resumed.

50.4.1.6 Message resumption. A terminal shall resume the transfer of a preempted message after the completion of the higher-priority traffic (or of an interrupted message after link recovery) by sending a message management header announcing the resumption of the preempted message. The message management header shall contain the same message identification data as the original announcement of the message with the exception of the Transmit Message Next Byte Location field. The transmit terminal, upon resumption of the message, shall specify the starting location within the message. This would typically be the first byte of the first frame not acknowledged by the receive terminal prior to the preemption (or link failure). The receive terminal may override this starting position by sending a message management header specifying the desired start position in the Receive Message Next Byte Location field. A value of zero in this field shall compel a message restart instead of a message resumption.

50.4.1.7 Null message management headers. When none of the above conditions apply, no message management header need be sent. If a full-length control frame is sent in this case, the message management header fields shall be set to all Øs by the transmit terminal. The receive terminal shall ignore message management headers with the Transmit Message Size field set to the value of zero.

50.4.2 Link establishment protocol. DLP terminals employ the optional link establishment protocol to coordinate the terminals' status (state) and resolve access contention prior to initiating the transfer of data over the link. The link establishment protocol is implemented through an orderly exchange of control frames containing the link management header fields. During the link establishment phase, the two terminals attempting to link shall exchange terminal addresses and link state information in accordance with the protocol rules. This is to ensure that both terminals are fully aware of the link state of the other terminal and therefore do not attempt to transfer data before the other terminal is ready to accept that data. The link establishment protocol is optional and can be bypassed. When the link establishment protocol is bypassed, the terminal shall set the Link State field in all control frames to the linked up state (value 2). This bypass condition is that of the "Immediate mode", described in par. 50.4.2.4.

50.4.2.1 Link establishment states. The link establishment protocol requires that the two terminals attempting to link, sequence through a set of link states, as defined below, to ensure that both terminals reach the linked up state before either attempts to transfer data traffic.

Note: In the descriptions that follow, the potential transmit terminal and receive terminal are shown in parentheses to emphasize that until "negotiations" are complete (especially forward and reverse priorities), either terminal can become the transmit terminal and the other, of course, will become the receive terminal.

50.4.2.1.1 Idle. The idle state of the link establishment protocol is the resting state of the protocol. The terminal shall reside in this state whenever it has no traffic to send and is not being called by another terminal. The terminal shall return to the idle state if there has been a link failure or a time out. However, as an option, either terminal may automatically attempt to reestablish the link to continue the data transfer, rather than returning directly to the idle state.

50.4.2.1.2 Calling. A terminal shall enter the calling state when it has data traffic for another (receive) terminal or is requested to establish a link with that (receive) terminal by one of the data link users (source) associated with the (transmit) terminal. When in the calling state, the (transmit) terminal shall send type 4 (520 bit) control frames containing the following:

a. the control frame header (par. 50.1.2.1) with the Control Mode (par. 50.1.2.1.2), Negotiation Mode (par. 50.1.2.1.3), Extended Addressing flag (par. 50.1.2.1.4), message Source Address (par. 50.1.2.1.5), and the message Destination Address (par. 50.1.2.1.6) fields set,
b. the link management header (par. 50.1.3) with the Link State (par. 50.1.3.1) and Link Timeout (par. 50.1.3.2 and 50.4.4.3) fields set,
c. the data transfer header (par. 50.1.4) with the ACK Bit-Map/Extended Address (sec. 50.1.4.2) field set,
d. the herald header of the data transfer header (par. 50.1.5) with the Data Rate Format (par. 50.1.5.1), Data Rate (par. 50.1.5.2), and Interleaver Length (par. 50.1.5.3) fields set,
e. the message management header (par. 50.1.6) will announce the (first) message that it wishes to transfer to the destination (pars. 50.1.6.1 through 50.1.6.6, and
f. the extended function header (par. 50.1.7) containing the User ID (par. 50.1.7.1) of the calling (transmit) terminal.

After sending the control frame, the (transmit) terminal shall wait for a response from the called (receive) terminal. Upon reception of a valid control frame from the (receive) terminal containing a link management header acknowledging the link request, the (transmit) terminal shall advance to the linked up state. If the (transmit) terminal does not receive a timely call acknowledgment frame, it shall retry the call. See sec. 50.4.4 for timeout calculations. As an option, a terminal should enter the calling mode when a link, that has been established, is interrupted. If node contention is possible, the (transmit) terminal should wait a random time interval before resending the link establishment header, in order to reduce the probability of collision.

50.4.2.1.3 Call acknowledge. A (receive) terminal shall enter the call acknowledge state upon reception of a valid control frame containing a link management header, indicating that a (transmit) terminal is attempting to establish a link with it. When in the call acknowledge state, the (receive) terminal shall send control frames in response to the (transmit) terminal's control frames. These response control frames indicate the local (receive terminal) link state, link timeout, and the accepted link modes and characteristics. If the (transmit) terminal accepts variable-length control frames, a type 1 (48 bits) control frame may be returned to accept the announced message. Note: Overrides to the Control Mode field and to the Negotiation Mode field may be included in control frames of any size. If a longer control frame (types 2, 3, or 4) is sent, refer to Fig. 15 and the descriptions of the other protocols for contents of the message management and data transfer headers. The extended function header (type 4), if present, shall contain a User ID field (par. 50.1.7.1) set to one of the following:

a. Ø, indicating the interoperable protocol mode (which overrides any other User ID), or

b. identical to the User ID of the calling (transmit) terminal to accept the corresponding specialized mode.

After sending the control frame, the (receive) terminal shall wait for a response from the calling (transmit) terminal. If the acknowledging (receive) terminal does not receive a timely valid reply to its response and it has higher-priority traffic (i.e., it initiated reverse preemption), it shall retransmit the call acknowledge announcing this traffic after the response timeout IAW sec. 50.4.4. If it (receive terminal) does not have higher priority traffic, it shall await a repetition of the call. If it (receive terminal) has not received a repeated call within the link timeout specified in the call frame, it shall return to the idle state.

50.4.2.1.4 Linked up state. The linked up state is the fully operational state of the terminal. The terminal may begin the data transfer protocol once it has reached the linked up state. The terminal shall enter the linked up state upon receipt of a valid control frame indicating that the other terminal is in either the call acknowledge or the linked up state, or upon receipt of a local request for Immediate mode message transfer when it is in the idle state (see par. 50.4.2.4). When in the linked up state, the terminal shall include a link management header in all control frames sent indicating its link state is linked up (see par. 50.1.3.1). The terminal may implement any operational feature of the data transfer and message management protocols when in this state. The terminal shall remain in the linked up state until the link is dropped (or fails) whereupon it shall return to the idle state. As an option, in the case of a link failure, the terminal shall attempt to reestablish the link to continue the data transfer, rather than returning directly to the idle state.

50.4.2.2 Link failure. If the link fails while in progress (detected by link timeout), the protocol will act as if the link was aborted and the terminal shall return to the idle state. As an option, the terminal shall attempt to reestablish the link to continue the message transfer. The terminal should be capable of signaling this sudden change in status to a higher layer controller and to the operator. As a design objective, the successfully received portion of the uncompleted message, which was in progress when the link failed, should be retained at the receive terminal in the same manner as a preempted message. The length of time to hold the uncompleted message should be an operator-selectable parameter.

50.4.2.3 Link termination. The link may be dropped due to a local request, a link timeout, or the absence at both terminals of messages to be sent (when not in Circuit mode). Terminals should send a control frame with the Link State field set to dropping link (value 3) before dropping the link.

50.4.2.4 Immediate mode. An Immediate mode message transfer bypasses link establishment and the initial data transfer negotiation. The first transmission shall begin with a type 4 (520 bit) control frame with the Link State field of the link management header set to linked up (value 2), a message management header announcing a message, and a herald describing the characteristics of the first data series, with the User ID field normally set to Ø. This control frame shall be immediately followed by two sync bytes (par. 50.1.1.1), then the first data series of the announced message, with no change in data rate. Following this first data series, the data transfer protocol shall use either the ARQ mode or the ARQ Circuit mode.

50.4.2.5 State sequence rules. Figure 17 summarizes the state actions and transition rules of the link establishment protocol.

50.4.3 Data transfer protocol. HF data link terminals shall use the following data transfer protocol to deliver data over an established data link connection. The data transfer protocol is implemented through the exchange of control frames and data frames over the data link. The data transfer protocol includes three different transfer modes; (a) ARQ mode, (b) Broadcast mode, and (c) Circuit mode. Each of these modes is defined in the following paragraphs.

50.4.3.1 ARQ mode. The ARQ mode is made up of three phases; (a) the negotiation phase, (b) the data transfer phase, and (c) the data acknowledgment phase. Negotiation may be combined with data acknowledgment (e.g., to reverse the link for high-priority reverse-channel traffic).

.

50.4.3.1.1 Negotiation phase. Terminals shall use the negotiation phase of the data transfer protocol to resolve flow control and the transfer specifications of the data link connection prior to the transfer of data frames over the data link. The negotiation phase starts with the transmission of a control frame containing a data transfer header (a herald) announcing a data series to be transferred and ends with the transmission of an acknowledgment of the herald control frame signifying acceptance of the announced data series.

The negotiation phase is required in the following circumstances:

a. Before the first data frames are sent over a link (except Immediate mode message transfers; see par. 50.4.2.4).
b. Before any change in previously-negotiated values in the herald fields. The exceptions are that no negotiation is required to (1) send a data series to finish a message or to (2) change only the data rate and the number of frames in next series if the following rules are followed:
(1) If the data rate increases by 2ⁿ, the Number of Frames in Next Series field value must increase by the same factor, thus keeping the ratio of the number of frames in next series to data rate constant. If this would result in a Number of Frames in Next Series field value greater than 255, the Number of Frames in Next Series field shall be set to 255, but the ratio of the number of frames in the next series to data rate without this limiting operation shall be stored for future reference.
(2) If the data rate decreases by 2ⁿ, the Number of Frames in Next Series field value must decrease by the same factor (then rounded down to the nearest integer), thus keeping the ratio of the number of frames in next series to data rate constant, except that if the previous Number of Frames in Next Series field value was 255, the new Number of Frames in Next Series field value shall be computed from the new data rate using the previously stored ratio of the number of frames in next series to data rate (see above), constrained as before to be no greater than 255.
c. Before each data series, if the most recent control frame from the terminal that will receive the data frames contained the Negotiation Mode field set to 1.
d. When flow control prevents the transfer of any data frames.

50.4.3.1.1.1 Initiation. A terminal shall initiate the negotiation phase of the protocol by transmitting a control frame containing a herald that announces the data rate, interleaver length, number of frames in the data series, and the number of data bytes per data frame. The receive terminal shall answer the herald with one of three responses:

a. a herald-ACK signifying acceptance of the offered data series,
b. a null-ACK indicating that the receive terminal cannot accept the offered data series, or
c. a herald and message management header of its own, announcing a higher-priority data series in the reverse direction.

The transmit terminal shall retransmit the herald if it does not receive a valid response within the response timeout period (see sec. 50.4.4). Note that a transmit terminal may respond to a herald-ACK by immediately transmitting a new, different herald (e.g., for forward preemption). The receive terminal must, therefore, treat each herald received as if it contained new information and not merely as an identical repetition of a previously-received herald.

50.4.3.1.1.2 Acceptance. A receive terminal shall signify its acceptance of the data series offered in a herald frame by responding with a herald-ACK frame. The herald-ACK frame may be type 1 (48 bits) if not otherwise constrained by the need to negotiate data transfer characteristics or by control mode. The receive terminal may negotiate (override) any of the herald fields, except that the Number of Bytes in Data Frames field may not be changed if any data frames from a previous data series are to be resent in the current data series. Upon receipt of the herald-ACK frame, the transmit terminal will normally transition to the data transfer phase and begin transferring the data frames of the accepted series.

50.4.3.1.1.3 Data refusal. To refuse an offered data series, a DLP terminal shall send a null-ACK frame in response to a herald frame announcing a new data series. If the cause for refusal is a temporary lack of local buffer space, the receive terminal shall set the Flow Control flag (par. 50.1.4.2.1.2) in the null-ACK. In this case, the transmit terminal should periodically retransmit the herald frame in order to determine when the flow control restriction is lifted (see par. 50.4.3.1.4).

50.4.3.1.2 Data transfer phase. Upon transition to the data transfer phase, the transmit terminal shall transmit the data frames announced in the acknowledged herald. The transmit terminal shall transmit the total number of data frames announced in the herald without delay or interruption, except for preemption (see par. 50.4.1.5). All data frames shall be of the same size as was announced in the herald. This implies that the last data frame of a message may need to be padded with fill bits. The receive terminal will use the transmit message size information (par. 50.1.6.3) to determine where the message is to be truncated in order to remove the fill bits from its output data stream.

50.4.3.1.3 Data acknowledgment phase. The data acknowledgment phase shall begin after the last data frame of the data series has been transmitted. The transmit terminal shall stop transmission and wait for the data-ACK frame from the receive terminal. The data-ACK frame shall contain the data-ACK bit-map indicating which data frames were received error free and which frames, if any, require retransmission. The transmit terminal shall prepare a new data series containing all prior frames requiring retransmission and enough new data frames to fill the data series. Unless negotiation is required (see par. 50.4.3.1.1.b - d), the terminals shall return to the data transfer phase upon completion of the data acknowledgment phase. If the transmit terminal fails to receive a data-ACK frame from the receive terminal within the response timeout period (see sec. 50.4.4), it shall transmit a data-ACK request frame to inform the receive terminal that a data-ACK was not received. Receipt of a data-ACK request by a receive terminal shall cause it to resend the last data-ACK frame that it had previously sent. If the ACK sequence number received by the transmit terminal is incorrect, the receive terminal must have missed the entire preceding data series, which should, therefore, be resent by the transmit terminal.

50.4.3.1.4 Flow control. A receive terminal may impose flow control by returning a control frame (null-ACK, data-ACK, or herald-ACK) with the Flow Control flag (bit Ø of the ACK Bit-Map field)(see par. 50.1.4.2.1.2) set to 1. Note: The Flow Control flag is present only when the Extended Addressing flag (par. 50.1.2.1.4) is set to Ø. If the ACK Bit-Map field in a data-ACK control frame, with the Flow Control flag (bit Ø) set to 1, indicates that some data frames would be retransmitted, the transmit terminal shall resend those data frames. In no case shall a transmit terminal send new data frames in response to a control frame containing the Flow Control flag set to 1. A receive terminal shall lift flow control by responding to a frame from the transmit terminal with a control frame containing the Flow Control flag set to Ø. The type of control frame sent to lift flow control shall be an appropriate response to the frame from the transmit terminal (e.g., a herald-ACK for a herald, or a data-ACK for re-sent data frames).

50.4.3.2 Broadcast mode. The Broadcast mode shall be used for one-way transfers of data from a single transmit terminal to one or more receive terminals. Since multiple terminals can receive the data, acknowledgments of the data frames are not allowed. A terminal shall initiate a broadcast transmission by transmitting a type 4 (520 bits) control frame containing appropriate data transfer and message management header fields. The control frame header, Control Mode field (par. 50.1.2.1.2) shall be set to Broadcast mode (value 1), and the link management header, Link State field (par. 50.1.3.1) shall be set to linked up (value 2). The terminal shall immediately follow the control frame with data frames. Receive terminal(s) shall not respond with data-ACK control frames to a Broadcast mode transmission. This process shall be repeated until the entire data series is transmitted. All parameters shall remain fixed for the entire data series. Herald frames between each data series are optional. Although the Broadcast mode is non-ARQ, it is very similar to the ARQ mode with fixed-length control frames, except that no acknowledgments are allowed or accepted.

50.4.3.3 Circuit mode. The Circuit mode shall operate identically to the variable-length control frame ARQ mode, except that terminals shall maintain the link in the absence of user data, until directed to drop the link by the user. Terminals shall maintain the data link connection in the absence of data, by sending null-herald and null-ACK control frames that announce no message. Terminals shall respond to this null-herald by sending a null-ACK control frame along with their own null-herald. Terminals should use the error statistics of the null-herald/null-ACK exchange to maintain a valid estimate of the supportable data rate of the data link. When available, new user data shall be announced according to the requirements of the ARQ data transfer mode. Note that the Circuit mode does not include a fixed-length control frame option.

50.4.4 Timeouts. Timeouts serve two functions in the DLP; they ensure that terminals do not wait indefinitely for responses, and that transmissions from terminals that simultaneously attempt to link with each other have a low probability of colliding at every retransmission and therefore failing to link.

50.4.4.1 Turn-around times. After reception of a valid transmission, a terminal shall initiate the responding rf transmission no sooner than 1 second and no longer than 10 seconds after cessation of the received rf signal.

50.4.4.2 Response timeout. After each valid reception, the terminal shall establish a time at which it will take action if further valid receptions are not forthcoming. These times are different for transmit terminals and receive terminals. A further distinction must be made between acknowledged transmit terminals and prospective transmit terminals. When a receive terminal determines that it has traffic to send that is of equal or higher priority than the current transmit terminal (e.g., when such higher-priority traffic is delivered to it by a local user), it heralds this event following the next legitimate reception from the transmit terminal (see sec. 50.4.3.1). Until this receive terminal receives an acknowledgment of its new status, this terminal is a prospective transmit terminal. A terminal that has received acknowledgment of its transmit terminal status is an acknowledged transmit terminal. (Note that under certain conditions, there may be no acknowledged transmit terminal). During link establishment, terminals in the call acknowledge state act as either receive terminals (if not attempting reverse preemption) or as prospective transmit terminals (if preempting). Timeout values shall be set as follows for the interoperable mode (User ID = Ø)(par. 50.1.7.1):

a. After each legitimate reception, an acknowledged transmit terminal shall set a response timeout equal to the ending time of its responding transmission plus 25.4 s.
b. Following each retransmission (or the initial transmission of a data-ACK request), an acknowledged transmit terminal shall set its response timeout to the starting time of that transmission plus 48.8 s.
c. A prospective transmit terminal shall set its response timeout to 48.8 s after the starting time of its transmission, whether this transmission follows a legitimate reception or was a retransmission following a missed response.
d. A receive terminal shall set its response timeout following each legitimate reception from the transmit terminal to a value equal to the ending time of its transmission in response to the reception plus the estimated ending time of its next reception plus the most recent link timeout value received (Link Timeout field (par. 50.1.3.2) of the link management header) from the transmit terminal during the current link. If expecting a control frame, 25.4 s shall be allowed for the next transmission; otherwise (data series expected), the time allowed for the next transmission shall be the sum of a 10 s turnaround time plus N+1 interleaver times, where N is the number of interleavers of the size required to hold the announced data series.
e. After a call (or immediate mode transmission) a terminal shall set its timeout to be 25.4 s after the end of the first transmission. If no valid reception has occurred prior to this timeout, the terminal shall act IAW par. 50.4.4.4, below. After retransmissions, the timeout shall be set to the starting time of the retransmission plus either 48.8 s, 63.8 s, or 78.8 s. The choice among these three values shall be randomly generated in such a manner that each has approximately equal probability of being selected, with little correlation among the choices either at a single terminal or between pairs of terminals.

Terminals may use timings different from those above only if they have negotiated a non-zero User ID field code which is associated with different timing rules.

50.4.4.3 Link timeout. The link timeout shall be computed as the time from the end of the first transmission of a frame until all retransmissions that would result from no response to that frame have been completed, including the response timeout after the last retransmission, and accounting for any automatic data rate or interleaver changes that would be performed by that station.

50.4.4.4 Action following timeout. The action taken by a terminal when no legitimate response is received shall be as follows:

a. If a transmit terminal (acknowledged or prospective) has received no signal by the time specified by the response timeout, it shall decrement its internal retry countdown and transmit a frame that requests a retransmission from the other terminal. If the missing response is a data-ACK frame, the transmit terminal shall send a frame with the ACK/NAK Type field (par. 50.1.4.1) set to data-ACK request (value 2). If the missing response is a herald-ACK, it shall repeat the herald frame. If the missing response is that associated with a call (or an Immediate mode transmission), the repeated frame shall be the call (or the control frame with the ACK/NAK Type field set to data-ACK request (value 2) and the same herald that was transmitted at the start of the Immediate mode transmission).
b. If a transmit terminal (acknowledged or prospective) receives a transmission with an invalid CRC, including a transmission that begins before but concludes after the response timeout, it shall take the actions specified in the preceding paragraph, except that the transmission shall take place as soon as possible within the constraints imposed by par. 50.4.4.1.
c. Upon expiration of the link timeout, a transmit terminal shall either return to the idle state, discarding any unfinished message with notification to the (local) source of that message, or request re-establishment of the physical-layer link (possibly through an ALE controller) with the intent to resume the message if re-linking is successful.
d. A receive terminal that has not received a valid transmission prior to the expiration of its response timeout shall drop the link IAW par. 50.4.2.2. A receive terminal may respond immediately (within the constraints imposed by par. 50.4.4.1) to signals resulting in an invalid CRC, but the operator must be able to disable this function if provided. If the receive terminal is in the process of reception when the timeout expires, it shall complete the reception but shall drop the link if no valid CRC is obtained.
e. In general, whenever a terminal receives a valid transmission, it shall reset the response timeout as specified in par. 50.4.4.2.

50.4.5 Duplex operation. The formats and protocols for duplex operation shall be identical to those specified for simplex operations except that timeouts and retransmissions for one traffic direction must work around the data series transferred in the other direction. Simultaneous traffic should be supported whenever traffic of any priority exists at both terminals. Note that reverse link preemption is not needed in duplex operation.

50.5 Examples. Figure 18 illustrates typical data transfers over the data link. Each square on the figure represents a control or data frame.

Figure 18. Examples of data transfers over the data link during DLP operation

60. NOTES.

60.1 Implementation guidelines. Although the DLP has been designed to operate with any arbitrary modem waveform, it has been optimized to operate over HF radio channels with the inherent high error rate encountered on these channels. It is expected that the protocol will be most often used with the FED-STD-1052 serial (single-tone) waveform. The following paragraphs provide insight and guidance in implementing the DLP using the FED-STD-1052 serial (single-tone) modem waveform.

60.1.1 Adapting data rate. A simple but effective algorithm for adapting the data rate of the modem during data link operation is as follows:

a. If all of the frames are transferred without error, the data rate should be raised.

b. If fewer than 50% of the frames are transferred without error, the data rate should be lowered.

60.1.2 FED-STD-1052 serial (single-tone) interleaver capacity. Table XXX lists the capacity of the serial (single-tone) modem interleaver buffers as a function of interleaver size and data rate. The length of serial (single-tone) modem transmissions is always a mathematical integer of interleaver intervals. When calculating the transmission time of a block of data of a given length, one must take into consideration that in addition to the total number of interleaver intervals required to transmit the user data presented to the modem, the modem will precede the data transmission with a preamble phase equal to one interleaver interval and will append 176 bits to the user data. Table XXX lists the total capacity of the interleaver buffer for each data rate, the minimum number of interleaver intervals required to transmit the 176 postamble bits, and the number of bits remaining for user data within the minimum number of interleaver intervals after the postamble is accounted for.