BSC is a half-duplex protocol. Transmissions
are provided two ways alternately. The protocol supports
point - to - point and multipoint connections, as well
as switched and non-switched channels. BSC is a code
- sensitive protocol, and every character transmitted
across a BSC channel must be decoded at the receiver
to see if it is either a control character or end -
user data. As stated previously, code-dependent protocols
are also called byte or character protocols, and they
are further distinguished by the fact that the control
fields usually reside in variable locations inside the
frame. |
The BSC frame formats and control codes
are shown (below). The control codes have several functions
which depend on the particular line mode at a given
moment. The illustration below does not show all the
possibilities for the format of a BSC frame, but provides
samples of some of the major implementations of the
BSC frame format.
Since BSC is a character-oriented protocol, it has a
problem in delineating user data fields from control
fields. It is possible that a code recognized as BSC
control could be created by user application process.
For instance, assume a user program creates a bit sequence
which is the same as the ETX (end of text) control code.
The receiving station, upon encountering the user data,
would assume that the end of the transmission is signified
by the user - generated ETX. BSC would accept the ETX
as a protocol control character and attempt to perform
an error check on an incomplete BSC frame, which would
result in an error.
Obviously, control codes must be excluded from the text
and header fields. BSC addresses the problem with the
DLE control code. This code is placed in front of the
control code STX, ETX, ETB, ITB, and SOH to identify
these characters as valid line control characters. The
simplest means to achieve code transparency is the use
of DLE. STX or DLE. SOH to signify the beginning of
non-control data (user data) and DLE. ETX, DLE.ETB,
or DLE.ITB to signify the end of user data. The DLE
is not placed in front of user-generated data. Consequently,
if bit patterns resembling any of these control characters
are created in the user text and encountered by the
receiving station, the receiving station assumes they
are valid user data, because the DLE does not precede
them.
The DLE places the line into a transparent text mode,
which allows the transmission of any bit pattern. This
capability is important when BSC is used on different
types of applications. For example, engineering or statistical
departments in a firm often use floating - point notation
due to the need for large magnitudes in numbers or very
precise fractions. Accounting departments use fixed
- point notation to provide for accurate fractions (two
decimal places for cents). BSC accepts these kinds of
numeric representation with the use of DLE. |
The DLE presents a special problem if
it is generated by the end-user application process,
since it could be recognized as a control code. BSC
handles this situation by inserting a DLE next to a
data DLE character. The receiver discards the first
DLE of two successive DLEs and accepts the second DLE
as valid user data.
The headers illustration are optional. If they are included,
the SOH code is placed in front of the header. |
