Binary Synchronous Communications

Binary Synchronous Communication (BSC)
Company type	Communication protocol
Industry	Computer networking
Founded	1967
Founder	IBM
Products	Character-oriented half-duplex link protocol

Binary Synchronous Communication (commonly known as BSC or Bisync) is an IBM character-oriented, half-duplex link protocol that was introduced in 1967 alongside the System/360 series. It succeeded the earlier synchronous transmit-receive (STR) protocol, with the goal of standardizing link management across three different character encoding schemes.

The six-bit Transcode was designed for older legacy systems, while USASCII, supporting 128 characters, and EBCDIC, with 256 characters, were developed with future applications in mind. Transcode was rapidly phased out, whereas Bisync implementations using EBCDIC and USASCII continued to be utilized.

At one time, Bisync was the dominant communications protocol and although its use has diminished, it still remains operational in some environments as of 2013.

Framing

Compared to newer protocols such as HDLC, Digital Data Communications Message Protocol (DDCMP), and Point-to-Point Protocol (PPP), which employ a single frame structure, Bisync’s message framing is considerably more intricate. It defines five separate framing formats.

BSC Link Control Characters
Character	EBCDIC (hex)	USASCII (hex)	Transcode (hex)	Description
SYN	32	16	3A	Synchronous idle
SOH	01	01	00	Start of heading
STX	02	02	0A	Start of text
ETB	26	17	0F	End of transmission block
ETX	03	03	2E	End of text
EOT	37	04	1E	End of transmission
ENQ	2D	05	2D	Enquiry
NAK	3D	15	3D	Negative acknowledgement
DLE	10	10	1F	Data link escape
ITB	1F	1F (US)	1D (US)	Intermediate block check character

The acknowledgements ACK0 and ACK1—representing even and odd acknowledgements respectively—are encoded as two-character sequences beginning with DLE followed by specific codes that vary depending on the encoding used. Similarly, WABT (wait before transmit) is also transmitted using DLE-based sequences.

Each frame format begins with a minimum of two SYN bytes. The distinctive binary pattern of SYN enables receivers to identify frame boundaries and synchronize properly. During lengthy transmissions, SYN bytes are periodically inserted to maintain synchronization; however, receivers disregard these inserted SYN bytes.

Frames conclude with either ETB or ETX control characters followed by a checksum. For USASCII, this checksum is a single-character longitudinal redundancy check (LRC), whereas Transcode and EBCDIC use a two-character cyclic redundancy check (CRC). Optional intermediate checksums can be embedded using ITB characters to improve error detection capabilities. Additionally, USASCII characters incorporate odd parity for further validation.

Pad characters are transmitted following line turn-around signals such as NAK, EOT, ENQ, ACK0, and ACK1 to ensure smooth transition between transmissions. These pad characters are composed either entirely of '1' bits or alternate between '0' and '1' bits. Transmission sessions commence with either a pad or SYN character.

An optional heading containing control information may precede the main data block; this heading is enclosed between SOH and STX characters. The contents of this heading are device-specific rather than defined by the protocol itself.

The actual text data follows this heading, starting with STX and ending with either ETX or ETB.

Within standard data frames, certain control characters—including ETB, ETX, ENQ, ITB, and SYN—are prohibited. This restriction limits the number of unique transmittable characters to 59 for Transcode, 123 for USASCII, or up to 251 for EBCDIC.

To support transparent data framing allowing an unrestricted set of characters—64 for Transcode, 128 for USASCII, or all 256 for EBCDIC—block framing control characters are prefixed with DLE in a process known as character stuffing, which functions similarly to bit stuffing.

Link control

The link control mechanism is similar to STR and is intended to protect against basic transmission errors. It mandates that each transmitted message receive either a positive acknowledgment (ACK0/ACK1) or a negative acknowledgment (NAK), which introduces considerable overhead, particularly when handling small packets. The protocol ensures recovery from corrupted or lost data frames as well as missing acknowledgments by means of retransmission.

Because Bisync frames do not incorporate sequence numbers, the alternating use of ACK0 and ACK1 signals serves to identify lost frames or acknowledgments. Nevertheless, the error detection for ACK0 and ACK1 is relatively weak—consisting of only a two-bit Hamming distance—which can result in duplicated data if an acknowledgment becomes corrupted.

This protocol functions in a half-duplex mode using two wires, where data transmission occurs in one direction per packet. This setup requires a 'turn-around' process that reverses the transmission direction, suppresses line echo, and reestablishes synchronization. Such turn-around introduces round-trip latency and diminishes throughput. In contrast, full-duplex configurations employ four wires, allowing simultaneous data and acknowledgment transmissions on separate pairs, thereby eliminating turn-around delays but increasing installation expenses.

Topology

Bisync communications predominantly utilize point-to-point connections. These links may incorporate contention mechanisms to determine the master station: one device issues an ENQ to request control, while the counterpart responds with ACK0 to grant or NAK/WABT to deny the request. Occasionally, terminals establish connections to multiple hosts through dial-up telephone networks.

Multi-drop capability is fundamental to Bisync, enabling a master computer to poll multiple terminals sequentially over analog bridges on a shared line. The master sends an ENQ addressed to each terminal in turn; the selected device replies with its data or EOT if it has no information to send.

Applications

Bisync was originally created for batch communications between System/360 mainframes and Remote Job Entry (RJE) terminals such as IBM 2780 or 3780, supporting limited data formats like punched card images and print lines. Non-IBM manufacturers, including Mohawk Data Sciences, also implemented Bisync for tape-to-tape transfers, with software developers able to simulate RJE terminal behavior.

IBM offered assembler macros through access methods like BTAM and QTAM (which was eventually superseded by TCAM), while VTAM was introduced on System/370 systems to provide advanced telecommunications capabilities.

Teleprocessing monitors, including IBM's CICS and third-party products such as Remote DUCS and Westi, utilized Bisync line control protocols for communication with remote devices.

At its height, the BITNET academic network linked approximately 3,000 systems using Bisync. The financial messaging network S.W.I.F.T. employed the BSC protocol over leased lines connecting Regional Centers and banks until transitioning to X.25 technology in the mid-1990s.

Certain implementations combined Bisync framing with alternative link control protocols. For instance, Houston Automatic Spooling Priority (HASP) utilized Bisync half-duplex hardware alongside its proprietary protocol to achieve full-duplex multi-stream communication between smaller computers and mainframes in a conversational environment.

Early X.25 networks occasionally encapsulated HDLC LAPB packets within transparent Bisync frames. As of 2012, some vendors continue to encapsulate Bisync transmissions over TCP/IP networks.

Bisync was predominantly replaced during the 1970s by Systems Network Architecture (SNA), which facilitated networking among multiple hosts and applications via telecommunications. Subsequent protocols such as X.25 and the Internet Protocol introduced more sophisticated features that extended beyond basic link control.

Devices

Prominent hardware implementing the Bisync protocol comprises:

IBM 3270 Display Terminal Subsystem control units
IBM 2780 Data Transmission Terminal
IBM 2703 Transmission Control
IBM HASP workstations
IBM 1130 Computing System
IBM 2922 Programmable Terminal

Comparable protocols

Byte-oriented protocols akin to Bisync were also created by other manufacturers, including Digital Data Communications Message Protocol by Digital Equipment Corporation and Poll and Select Protocol from Burroughs Corporation.