Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding CAN/CSA Z243.101-89 (R2018): HDLC Frame Structure Standard for Data Communication
A Comprehensive Guide to the Requirements and Implementation of the High-Level Data Link Control Frame Structure Standard
CAN/CSA Z243.101-89 (R2018), titled Data Communication – High-Level Data Link Control (HDLC) Procedures – Frame Structure, is the Canadian adoption of the international standard ISO 3309:1984. It defines the frame structure used in HDLC, a bit-oriented data link layer protocol that ensures reliable data transfer over synchronous or asynchronous communication links. This article provides a detailed examination of the standard’s scope, technical requirements, implementation considerations, and compliance notes for engineers and system architects.
1. Scope
The standard specifies the frame structure for HDLC-based communications. It applies to both point-to-point and multipoint configurations operating in balanced (BA) or unbalanced (UA, UB) modes. The scope includes:
- Definition of the flag sequence used for frame delimitation.
- Structure and encoding of the address and control fields.
- Format of the information field (if present).
- Calculation and placement of the Frame Check Sequence (FCS) for error detection.
- Bit stuffing rules to ensure transparency of the flag pattern within payload data.
CAN/CSA Z243.101-89 (R2018) is applicable to all HDLC implementations, including those in X.25, Frame Relay, ISDN LAPD, and other link layer protocols that inherit the HDLC frame format.
2. Technical Requirements
The HDLC frame consists of a fixed sequence of fields. Each frame starts and ends with a unique 8-bit flag. The standard mandates strict bit ordering, field sizes, and coding rules to maintain interoperability across heterogeneous systems.
2.1 Frame Structure Overview
The general frame format is:
| Flag (8 bits) | Address (8/16 bits) | Control (8/16 bits) | Information (variable) | FCS (16/32 bits) | Flag (8 bits) |Table 1 summarizes the fields defined by the standard.
| Field | Length (bits) | Description |
|---|---|---|
| Flag | 8 | Unique pattern 01111110; marks start and end of frame. |
| Address | 8, 16, or extended | Identifies the secondary station or multiple stations; extended formats use a continuation bit. |
| Control | 8 or 16 | Carries frame type (I, S, U) and sequence numbers; 16-bit format for extended sequencing. |
| Information | Variable (multiple of 8) | Contains higher-layer data; not present in supervisory (S) and some unnumbered (U) frames. |
| FCS | 16 or 32 | Cyclic Redundancy Check (CRC) covering address, control, and information fields. |
2.2 Flag Sequence and Transparency
The flag pattern 01111110 is unique and must not appear anywhere else within a frame. To achieve transparency, the standard requires the transmitter to insert a 0 after any sequence of five consecutive 1s (bit stuffing). The receiver un-stuffs by removing any 0 that follows five 1s. This ensures payload data never mimics the flag.
2.3 Address and Control Field Encoding
The address field can be extended using a continuation bit (first bit set to 0 indicates addressee, 1 indicates more bytes). The control field distinguishes three frame types:
- I (Information) – Carries sequence numbers (N(S), N(R)) for acknowledged data transfer.
- S (Supervisory) – Used for flow control and error recovery (RR, RNR, REJ, SREJ).
- U (Unnumbered) – For link setup, disconnect, testing, and other commands/responses.
2.4 Frame Check Sequence (FCS)
The FCS is a 16-bit or 32-bit CRC calculated using the polynomial defined in ISO 3309 (for 16-bit: CCITT CRC-16). It protects all bits between the opening flag and the FCS itself, excluding any stuffed bits. The generator polynomial for the 16-bit variant is G(x) = x16 + x12 + x5 + 1.
Implementation Tip: When implementing FCS generation, process the address, control, and information fields bit-by-bit through a Linear Feedback Shift Register (LFSR) or use a precomputed lookup table for byte-wise speeds. Ensure that bit stuffing is applied after FCS computation to avoid corrupting the CRC.
3. Implementation Highlights
Adopting CAN/CSA Z243.101-89 (R2018) requires careful attention to bit ordering, transparency rules, and frame handling.
3.1 Bit Ordering and Byte Transmission
All bytes in the HDLC frame are transmitted least significant bit (LSb) first. This applies to the address, control, information, and FCS fields. The flag, however, is transmitted as a fixed bit pattern.
Common Pitfall: Some implementations reverse the bit order of the FCS or treat the address field as most significant bit (MSb) first. This violates the standard and will lead to frame rejection. Always confirm that LSb-first is used for all octets except the flag.
3.2 Abort Sequence and Interframe Fill
The standard defines an abort sequence of 7 or more consecutive 1s (no bit stuff) to terminate a frame prematurely. Interframe fill is accomplished by transmitting continuous flags (01111110) or idle line marks (1s). The receiver must treat flags as frame delimiters and ignore any sequence of 1s between frames.
3.3 Handling Extended Address and Control
When extended addressing is used, the first bit of each address octet acts as the extension indicator (0 = next octet follows, 1 = final octet). Similarly, the control field can be extended to 16 bits for large sequence number windows (modulus 128 vs. modulus 8). Implementations must check the initial bits to correctly parse the field boundaries.
Compliance Note: Systems that fully implement CAN/CSA Z243.101-89 (R2018) will interoperate seamlessly with any other HDLC-compliant equipment. The standard’s stability (reaffirmed in 2018) ensures long-term compatibility in legacy and modern networks.
4. Compliance and Reaffirmation Notes
CAN/CSA Z243.101-89 (R2018) was reaffirmed by the Canadian Standards Association (CSA Group) in 2018 without technical changes. It is identical to ISO 3309:1984. Compliance with the standard is typically verified through conformance testing that checks:
- Correct flag pattern and transparency (bit stuffing/unstuffing).
- Proper FCS generation and detection.
- Accurate address and control field interpretation for all frame types.
- Handling of abort and fill sequences.
Organizations deploying HDLC-based systems (e.g., in SCADA, telecommunication, or industrial automation) should reference this standard to ensure reliable link-layer communication. While newer protocols such as PPP have evolved, HDLC remains foundational for many deterministic serial links.
Non-Compliance Risk: Deviations from the standard, such as incorrect bit ordering or FCS polynomial mismatches, can cause undetected errors, frame loss, or link failures. Always validate your HDLC implementation against the specifications in CAN/CSA Z243.101-89 (R2018).
5. Frequently Asked Questions
Q: Is CAN/CSA Z243.101-89 (R2018) equivalent to ISO 3309?
A: Yes, the standard is technically identical to ISO 3309:1984. It includes the same frame structure, bit ordering, and transparency mechanisms. Reaffirmation in 2018 confirms its continued validity without modifications.
A: Yes, the standard is technically identical to ISO 3309:1984. It includes the same frame structure, bit ordering, and transparency mechanisms. Reaffirmation in 2018 confirms its continued validity without modifications.
Q: Can this standard be used for HDLC over synchronous and asynchronous links?
A: Yes. While originally designed for synchronous links, the frame structure applies to any bit-serial transmission. For asynchronous links, the flag and bit stuffing must still be respected; additional start/stop bits are added at the physical layer, not defined by Z243.101.
A: Yes. While originally designed for synchronous links, the frame structure applies to any bit-serial transmission. For asynchronous links, the flag and bit stuffing must still be respected; additional start/stop bits are added at the physical layer, not defined by Z243.101.
Q: What is the difference between 8-bit and 16-bit control fields?
A: The 8-bit control field uses a modulus of 8 for sequence numbers (3 bits each for N(S) and N(R)), while the 16-bit field uses a modulus of 128 (7 bits each). The choice depends on the required window size and is negotiated during link initialization using the Set Normal Response Mode (SNRM) command.
A: The 8-bit control field uses a modulus of 8 for sequence numbers (3 bits each for N(S) and N(R)), while the 16-bit field uses a modulus of 128 (7 bits each). The choice depends on the required window size and is negotiated during link initialization using the Set Normal Response Mode (SNRM) command.
Q: Does the FCS include the flag or stuffed bits?
A: No. The FCS calculation starts with the first bit after the opening flag and ends with the last bit before the FCS field. Bit-stuffed zeros inserted by the transmitter are excluded from the FCS coverage, but they are present in the transmission. The receiver un-stuffs before verifying the FCS.
A: No. The FCS calculation starts with the first bit after the opening flag and ends with the last bit before the FCS field. Bit-stuffed zeros inserted by the transmitter are excluded from the FCS coverage, but they are present in the transmission. The receiver un-stuffs before verifying the FCS.