Language selection

Search

Patent 1255007 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 1255007
(21) Application Number: 570443
(54) English Title: UNIVERSAL PROTOCOL DATA RECEIVER
(54) French Title: RECEPTEUR DE DONNEES A PROTOCOLE UNIVERSEL
Status: Expired
Bibliographic Data
(52) Canadian Patent Classification (CPC):
  • 354/222
(51) International Patent Classification (IPC):
  • H04L 1/00 (2006.01)
  • H04L 12/56 (2006.01)
(72) Inventors :
  • FRASER, ALEXANDER G. (United States of America)
  • MARSHALL, WILLIAM T. (United States of America)
  • RIDDLE, GUY G. (United States of America)
(73) Owners :
  • AMERICAN TELEPHONE AND TELEGRAPH COMPANY (United States of America)
(71) Applicants :
(74) Agent: KIRBY EADES GALE BAKER
(74) Associate agent:
(45) Issued: 1989-05-30
(22) Filed Date: 1986-02-28
Availability of licence: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
714,834 United States of America 1985-03-22

Abstracts

English Abstract




- 1 -


Abstract:
The present invention relates to a data receiver.
The data receiver is characterized by a first-in, first-out
buffer storge unit, a movable barrier in the storage unit
for dividing the storage unit into two parts and a unit for
limiting access to one of the two parts. The invention is
further related to a method of processing data comprising
the steps of loading the data into a multi-stage register
which includes a movable barrier, testing the data while
the data is behind the movable barrier and then moving the
barrier behind the data when the testing is complete.


Claims

Note: Claims are shown in the official language in which they were submitted.






Claims:
1. A data receiver,
characterized by
a first-in, first-out buffer storage means,
a movable barrier in said storage means for
dividing said storage means into two parts, and
means for limiting access to one of said two
parts.
2. The data receiver according to claim 1
further,
characterized by
means for inserting data into said buffer storage
means behind said barrier as said data is received,
means for checking said data, and
means for moving said barrier behind said data
following the successful operation of said check means.
3. The data receiver according to claim 2
further,
characterized by
means for removing data from said storage means
only ahead of said barrier.
4. A method of processing data,
characterized by
loading said data into a multi-stage register
including a movable barrier,
testing said data while said data is behind said
movable barrier, and
moving said barrier behind said data when said
testing is complete.
5. The method of processing data according to
claim 4 further,
characterized by
removing only that data from said register ahead
of said movable barrier.




Description

Note: Descriptions are shown in the official language in which they were submitted.


~L2~ciint~7
UNIVERSAL PROTOCOL DAT~ RECEIVER

This is a division of copending Canadian Patent
Application Serial No. 502,950 which was filed on February
28, 1986.
Technical Field
_______________
This invention relates to data transmission
systems and, more particularly, to a universal protocol
receiver for such data transmission systems.
Bac~ground of the Invention
lo In the field of data transmission, the wide
variety of data communications terminals, the widely
varying traffic characteristics and the requirements of the
communications network have all contributed to the great
complexity and, by and large, the essential incompatibility
of different data transmission systems. At the same time,
the increasing dependence on data transmission and the need
for interconnecting various terminal and computer equipment
have made a flexible approach to data transmission
essential.
The protocol for data transmission can be divided
into a hierarchy having at least the following lowest
three levels
Level A - This is the physical level and
deals with electrical voltage
and current levels and bit
synchronization.
Level B - This is the data link level and
deals with error detection,
multiplexing and envelope (byte)
level synchronization.
Level C - This i5 the data packet level
and deals with error control,
flow control and packet level
synchronization.
Level A and ~ protocols are relatively easy to
implement and, w~en necessary, to convert between different
standards. Level C protocols, on the other hand, are
complex, difeicult to implement, and even more di~ficult or
even impossible to convert between. Moreover, protocol
definition is a diEeiclllt art, and protocol stan~ards are

~'~?t~ t~
-- 2

bulky, ambiguous and difficult to verify. Finally, a lar~e
amount of equipment is already in place which operates
according to one of the existing and largely incompatible
protocols. These existing protocols include Bisync, SDLC,
HDLC, X.25 (level 3), start/stop and raw byte streams.
The problem, then, is how to design a data
transmission network which can interface with terminal
equipment designed to operate according to a wide variety
of different level C protocols.
Summary of the Invention
In accordance with the illustrative embodiment of
the present invention, a standard data receiver rather than
a standard protocol is providedO The standard receiver has
sufficient flexibility and capability to accept data in a
large number of different protocols and to support the
major features of each.
More specifically, the standard receiver is
capable of operating in block (multiple byte) mode or
character (single byte) mode. It contains a data buffer
and responds to a repertoire of data flow control commands
which implement all of the major features of Bisync, SDLC,
HDLC, TCP, X.25 level 3, start/stop and raw byte streams.
More specificallyt the standard receiver is
divided into two stages separated by a buffer register.
The first stage handles packet acceptance processes and
the other, data flow control commands. The second stage
interfaces with the local user and includes acknowledgement
command processing.
In accordance with one feature of the present
invention, the buffer memory between the receiver stage is
a FIFO (first in, first out) memory with a movable barrier
dividing the buf~er into two parts, only one of which is
accessible to the second stage of the receiver. Stage one
moves the buffer barrier after veri~ying the buffer data,
thus minimi~ing the amount o~ buffer storage required.

~ 9~ ~ ~
-- 3 --

In accordance with another feature of the present
invention, the standard receiver can be realized in
hardware as a VLSI chip or in a standard piece of so~tware.
In accordance with an aspect oE the invention
there is provided a data receiver, characterized by a
first-in, first-out buffer storage means, a movable barrier
in said storage means for dividing said storage means into
two parts, and means for limiting access to one of said
two parts.
In accordance with another aspect of the invention
there is provided a method of processing data, characterized
by loading said data into a multi-stage register including
a movable barrier, testing said data while said data is
behind said movable barrier, and moving said barrier
behind said data when said testing is complete.
Brief Description of the Drawing
.________________________________
The present invention taken in conjunction with
the invention ~isclosed in copending Canadian Patent
Application Serial No. 502,950 which was filed on February
28, 1986 will be described in detail hereinbelow with the
aid of the single figure which is a detailed block diagram
of a data receiver.
Detailed Description
One illustrative type o~ transmission system with
which the present in~ention is use~ul is one in which the
basic data stream consists Oe a sequence of nine-sit bytes
(Level B protocol). The ninth bit indicates whether the
remaining bits are data or control codes. The control
codes are used for enforcing protocols at all levels.
Although the invention will be described in connection with
such a transmission system, other types of transmission
systems could readily take advantage of the present
invention in a manner obvious to those skilled in the art.
In order to permit a single receiver to process
data received in ~11 o~ the possible level C protocol~s, it
i~ nece95ary to utilize standard control codes which ~ave




the same or similar meaning ~or all protocols. Moreover,
a standard block ~ormat is necessary to permit bloek error
processing~ A block of data is a plurality of data bytes
aceompanied by central information. In aeeordance with
one feature of the illustrative embodiment o~ the present
invention, all blocks of data have appended to them a ~our-
byte trailer. The first byte is a beginning-of-trailer
(BOT) control code; the second and third bytes (Ll, L2)
represent the number of data bytes in the block, and the
last byte is a eontrol eode whieh includes a sequenee
number (SEQ + i). The sequenee numbers of sueeessive
bloeks are ineremented by one, modulo eight. That is, the
sequenee numbers take on the values 0 through 7 in
sueeessive blocks and are used for error control. Other
moduli could, of eourse, be selected.
It will be noted that bloeks have no headers, and
all control inEormation is in the trailer. Since header
information must be stored until an entire bloek is
reeeived and cheeked, no purpose is served in putting any
~o control information in a header. In accordane with the
present invention, all control infocmation is placed in a
trailer ~ollowing the variable length bloek of data bytes.
It will be noted that the trailer ~ormat
deseribed above is dependent upon byte error deteetion and
deletion at a lower protoeol level, typieally Level B.
With this assumption, the byte length in the trailer is
suf~ieient to detect block ercor.
The ~ive ~ssible types o~ data stceams whieh
require level C protoeols have been summarized by Table 1,
where the cows represent the various types o~ error
control: none, error deteetion without correction, and
error eorrection by retransmission. The columns in Table
1 cepresent the absenee or prexence o~ ~low control, i.e.,
the ability o~ the reeeiver to interrupt the data stream
3S being sent by the transmitter.

~25;5~




T~BLE 1
PROTOCOL TABLE

_ _
¦ Error ¦ Flow Control ¦ Data
¦Control ¦ No ¦ Yes ¦ Format
¦None ¦ Type 1 ¦ Type 2 ¦ Character ¦

¦Detect ¦ Type 3 ¦ Type 4 ¦ 8lock

¦Correct I ___ ¦ Type 5 ¦ Block l l
l_ I 1. 1 .

It can be seen that there are five different
types of data streams possible. The bottom row has only
one entry (Type 5) since correction by retransmission is
not possible without flow control.
A Type 1 data stream contains no level C control
codes and provides no error control or ~low control.
Such a data stream is useful for very short transactions
and for real time data. Some examples include alarm system
data, voice codes, and input from slow terminals.
A Type 2 data stream requires flow control to
prevent loss oE data due to speed mismatches be~ween the
transmitter and the receiver, but data bytes may be dropped
if transmission errors occur. Output Erom a host machine
to a terminal falls into this category, as well as slow
speed transmission over telephone lines.
Types 3 and 4 data streams are received correctly
or completely ignored, a block at a time. This type of
data stream is used in synchronous systems such as ETHERNET
(Trademark of Xerox Corporation). Type 3 data streams

~LZ~5i~



cannot be interrupted and the end user must supply a
windowing scheme to prevent over~low. Type 4 data streams
do provide flow control to accommodate transmitter/receiver
speed mismatches.
A Type S data stream provides error-free
transmission by the retransmission of lost or mutilated
blocks. This is the standard method of communication
between host machines.
An exemplary set of control codes suitable for
controlling a universal data receiver in accordance with
the present invention is shown in Table 2.


1 5





~ 2~ii 5C~




TABLE 2
CONTROL CODES

Octal
Name Code escription

SEQ 010 Sequence codes for end trailer,
. numbered 0 to 7.
017
ECHO 020 Echo codes for signaling that correct
. data has been passed to host,
027 numb~red 0 to 7.
REJ 030 Rejection codes for signaling a remote
. transmitter of errors in transmission,
037 numbered 0 to 7.
ACK 040 Acknowledgement codes for signaling a
. remote transmitter of successful reception,
047 numbered 0 to 7.
20 BOT 050 seginning of trailer for regular
. blocks of data.
BOTM 051 Be~inning of M~type block trailer.
BOTS 052 Beginning of S-type block trailer.
BOU 053 Start of unnumbered block.
25 EOU 054 End of unnumbered block.
ENQ 055 Transmitter request for flow or error
. status.
CHEC~056 Transmitter request for error status.
INITREQ 057 Reqùest initialization from transmitter.
INIT0 060 Character mode initialization.
INIT1 061 Block mode inltialization.
AINIT 062 Acknowledgement of INIT0 or INIT1.

Hardware implementations of transmitters ~or the
various Type 1 through Type 5 data streams will not be
shown in detail. So~tware implementations of one
embodiment o~ each o~ these transmitters wil- be disclosed

-- 8

for logical compcehensiveness.
In the figure there is shown a detailed block
diagram of a hardware implementation of a universal data
receiver 100 in accordance with the present invention
comprising a first stage 10 and a second stage 11
separated by a first-in, Eirst-out multistage buffer
register 12. Buffer register 12 is divided into two parts
by a movable barrier 13 which, under the control of
control circuits in the first stage 10, can be moved to
any storage position of buffer register 12. Buffer
register 12 is a standard "~irst-in, first-out (FIFO)"
register and the movable barrier can easily be implemented
by range registers in the access circuits. One such
implementation is disclosed in U.S. Patent No. 4,507,760
~hich issued on March 26, 1985 to A.G. Fraser.
The FIFO memory 12 between stages 10 and 11,
including a barrier 13, divides buffer 12 into two parts.
Only the part to the right (towards the head H) of barrier
13 is available to stage 11. Indeed, stage 11 perceives
barrier 13 as the end or tail of the bu~fer, and ~hen the
barrier 13 is at the head H of the bufEer 12, stage 11
perceives bu~fer 12 as empty. ~tage 10 can move barrier
13 around in buf~er 12 an~, in particular, can move
barrier 13 to the tail T of buffe~ 12, thus making the
entire buf~er 12 available to stage 11. Stage 10 can also
move the tail T to the barrier 13, thereby effectively
deleting data stored to the le~t o~ barrier 13. In
opecation in the block mode, the barrier 13 is used to
make blocks unavailable ~o stage 11 until after teailer
verifica~ion, at which time the barcier is moved to the
leet o~ the verified block if the block is valid, or the
tail is moved to the bacriec iE the block is not valid.
EC~30 code~s, generatecl at the end oE each valicl
block, are returned to tlle cemote tcansmittec only after
the corcesponcling clatd bytes ace read out oE buEfer 1~ and
passed on to the host computec. Rejectioll cc>des, genecate-3

~z~

- 9 -

at the end of each invalid block, are substituted for the
invalid block in buffer 12 and sent back to the transmitter
when reached by stage 11. ECHO codes are also returned
when a SEQ code is received in the character mode.
It will be thus seen that stage tO and stage 11
access buffer 12 asynchronously, stage 10 loading buffer 12
as data is received, and stage 11 emptying buffer 12 AS
fast as the host computer can accept data.
In all types of data streams with error control,
invalid data blocks are simply discarded. In Type 5
systems, the transmitter holds the blcck after transmission
until either an ECHO acknowledgement is received or a REJ
is received. If an ECHO code is received, the block with
the next sequence number is transmitted. If a ~EJ code is
received, the bloc~ with the same sequence number is
retransmitted.
The data receiver of the figure is capable of
receiving data in all o~ the Type 1 through Type 5
protocols. In accordance with the present invention, a
single standard protocol definition is avoided by providing
a standard receiver of sufficient flexibility to provide
virtually all of the functions required by the many
different data protocols. Such a standard receiver greatly
simplifies the creation o~ large and complex data networks,
including data links using many different data protocols.
In order to achieve such universal flexibility,
the standard data receiver must be capable of operating in
either of two modes, a block mode or a character mode. To
this end, the first stage of the receiver of the figure is
able to recognize initialiæation commands from a distant
transmitter. Inltialization commands are then used to set
the receiver 100 of the figure to the appropriate mode,
block or character. In ~he character mode, stage 10 passes
data characters and flow control characters on to buf~er


- lo -

register 12 AS they are received. The second stage 11 o~
the receiver of the figure passes the data characters on
to the data utilization circuits connected to output
leads 14, and notifies the local transmitter 15 when a
S flow-control character (an ECHO or a REJ) is removed from
buffer register 12. This notification is thereafter used
to signal the remote transmitter of the proper (or
erroneous) reception of the transmitted data. The receiver
of the figure also responds to requests from the distant
transmit~er (connected to transmission line 16) about the
last flow-control character taken out o buffer
register 12. This information is used to properly restart
the distant transmitter if an acknowledgemen~ code is
lost.
It should be noted that "data" or "bytes" in this
connection is anything other than the control codes of
Table 2. This will include control codes to be used for
implementing protocols a~ other levels.
In the block mode, buffer register 12 contains
complete, validated data blocks rather than single data
characters. ~ complete valid data block consists of a
plurality of data envelopes (which may be zero), followed
by a trailer. As in the character mode, the transmitter 15
is notified when flow control codes are removed from
buffer 12. The receiver 100 of the figure will
also respond to the remote transmitter to provide the
identity of the last bloc~ placed in buffer 12 or the last
block removed from buffer 12. The receiver 100 of the
figure will also notify the remote transmitter if an
incomplete or out-of-sequence block is received.
In the block mode r data is grouped into packets
of data envelopes followed by a trailer of four envelopes.
The first trailer envelope is a control character marking
the "beginning Oe trailer" (BOT). The second and third
3S envelopes o~ the trailer contain a two-byte (Ll and L2)
representation of the length L Oe the packet (i.e., the

:~2~5~



number of data envelopes. which can vary from block to
block), while the last envelope contains the sequence
control code (SEQ) of the packet, along with a sequence
number between O and 7. Thus, eight distinguishable
sequence codes can be received, one for each of the eight
different sequence numbers. This type of error control
serves to check that no part of a packet is lost ~length)
and that no complete packet is lost (sequence number).
In general, the receiver 100 of the figure
passes Type 1 and Type 2 data streams directly throùgh the
receiver 100, since no error control is being used. In
Types 3, 4, and 5, where error control is being used, data
is buffered in buffer 12 until it is verified, using the
trailer information. In Types 3 and 4 streams, the
erroneous data block is simply discarded, while in Type 5
erroneous data blocks are discarded, but retransmi~ted by
the remote transmitter.
Flow control (Types 2, 4, and 5) is implemented
by the sequence number codes. These sequence codes
~0 (together with the associated ECHO and REJ codes), permit
the transmitter to know at all times how much information
is in process at the receiver. In Type 2 data streams,
sequence number codes are interspersed in the data stream
at in~ervals and monitored, together with the ECHO codes,
to prevent overflow of the buffer 12. In Types 4 and 5
data streams, the sequence nu(nber code orms part of the
trailer, and serves the same function~
It will be noted that the choice of a trailer
format that begins with one control code and ends with
another control code minimizes the effect o~ errors
occurring in the trailer itself. Similarly, having the
length precede the sequence number also minimizes the
e~ect of errors, requiring three independent errors for an
erroneous sequer1ce to be accepted as a valid data block.
I the transmitter has only seven blocks outstanding at any
given instant, then no combination o~ errors can lead to
acceptance o an incorrect block. The sequence numbers

~Z~5~

- 12 -

are cyclic, modulo eight in the illustrative embodiment
o~ the error control system.
With the above as background, the description of
the figure ~ill be continued. In the figure, R0
register 20, R1 register 22, and R2 register 24 are all
control code re~isters. R0 register 20 holds control
codes representing replies from the distant receiver for
controlling transmitter 15. R1 register 22 contains the
control codes to be sent from the receiver of the figure to
the remote transmitter, except the block
validation/rejection codes. R2 register 24 contains the
block validàtion/rejection code for each type of data
stream excèpt Type 1 (which does not use validation)O
Separate registers for each of the various codes could also
be supplied if desired.
Each of registers 20, 22, 23 and 24 has an extra
"S" (status) bit which is set when a control code is
entered into the corresponding register (by stage 10 or
stage 11) and which i5 reset by transmitter 15 when the
code is read from the corresponding register. Code
registers 20 through 24 implement all of the protocols
described above. In general, reply register 20 holds reply
codes from a remote receiver, like receiver 100, connected
through the network to transmitter 15. These reply codes
include ACK, ECHO, REJ, AINIT, and INITR~Q codes ~rom the
remote receiver and will be described later in connection
with replies made by receiver 100.
Three local variable registers 25, 26, and 2~ are
provided to temporarily store conditions in receiver 100.
More specifically, sequence number counter 25 counts
successive valid data blocks received by receiver 100 as
they are passed on to the host. This sequence number is
used to check the validity o~ received sequence numbers in
the trailer blocks and is used to ~orm the EC~O, AC~, and
REJ codes ~or signaling the remote transmitter.

- 13 -

Trailer register 26 holds received trailer codes
until the length and sequence numbers are checked ~or
validity. Mode register 27 is a one-bit register which is
set when in the block mode (by an INITl code) and reset
when in the character mode (by an INIT0 code). The initial
or default mode is the character mode. Byte counter 2~
counts received data bytes for comparison with the length
count in the trailer register 26.
In the character mode, the receiver 100 of the
figure operates as follows: The first control code
received is an I~IT0 code which, when received in stage 10,
resets mode register 27 to the character mode (if it is not
already there). At the same time, trailer processing is
disabled (if previously enabled) and R1 register 22 i9
loaded with the AINIT code. Transmitter 15 places the
AINIT code from R1 register 22 in the outgoing digital
stream in the next available byte window~ This return
code, like all of the other return codes, can be
interposed anywhere in the data stream and will be
responded to appropriately at the remote receiver. These
return codes are removed at the remote receiver before the
blocks are reformed. The movable barrier 13 is moved to
the tail T of buffer register 12 to flush (effectively
empty) the buffer 12 and make the entire buffer register
unavaila~le to stage 11.
All of the ~ollowing data bytes are loaded into
buffer register 12 at the tail T, and the barrier B moved
to the end of each new added byte. Stage 11 immediately
begins removing these data bytes and passing them on to the
host machine via line 14.
If the character mode data stream is Type 2,
sequence codes will be interspersed at intervals in the
data stream. When one o~ these sequence codes is received
at stage 10, it is translated to ~C~IO + i), where "i" is
3S the same sequence number at the received SEQ codes and
passed onto buer register 12. When received at stage 11,

~255~3~7


- 14 -

the (ECHO + i) code is placed in R2 register 24.
Transmitter 15 introduces the (ECHO t i) code into its
outgoing data stream in the next available byte window.
The ~CHO returns can then be used by the remote transmitter
to control the interruption and resumption of data
transmission for speed matching. The transmitter uses
sequence numbers cyclically, modulo eight, and blocks
transmission when the next sequence number to be sent
matches the most recently received ECHO sequence number.
Thus, at most, seven data blocks must be buffered at the
receiver 100 in register 12, in order to accommodate data
speed mismatches. The value i is saved in sequence
counter 25.
The remote transmitter is protected against lost
ECHO or ACK codes by a timeout circuit. If a timeout
occurs before the expected EC~O code is received, the
transmitter issues an ENQ code. When received by stage 10,
the ENQ code sets one-bit F register 21 and causes the most
recent (ECHO + i) code to be retransmitted from R2
register 24, followed by an (AC~ + j) code, where j is the
most recent sequence number received by stage 10 and stored
in sequence counter 25. The answer to a CHECK code is a
simple (ACK ~ j) where j is the last sequence number
received.
In the block mode, transmission is started by an
INIT1 code received at stage 10. In response to the I~IT1
code, bufer memory 12 is cleared, mode register 27 is set
to block mode, trailer register 26 is enabled alon~ with
trailer processing, sequence number counter 25 and byte
30 counter 28 are reset to zero, and R1 reqister 22 is loaded
with the AINIT code, to be transmitted in the next
available byte window. The movable barrier 13 is moved to
the head H o buf~er 13 to make the data stored therein
unavailable to stage 11 until after trailer processing
(data block veriication) is completed.
The data byte~, a~ received by stage 10, are
loaded into buf~er register 12, beginning at the

3 25~37

-- 15 --

barrier 13. As each data byte is passed to buffer
register 12, byte counter 28 is incremented by one. At the
end of the data block, a trailer is received, consisting of
a BOT (beginning of trailer) code, two bytes containing the
length o the block (up to 216-1 data bytes,
low order bits first) and terminated by a SEQ code with
the appropriate cyclic sequence number. The three bytes
following the BOT code are placed in trailer register 26
~here the length is compared to the count in byte
counter 28 and the sequence number is compared to the
(count + 1~ (modulo 8) in sequence counter 25. If both
comparisons cause a match, an (ECHO + i) code is placed in
buffer 12 and the barrier 13 is moved just past the ECHO
code. This data block is now available to stage 11 which
therefore begins passing the data bytes to line 14. Byte
counter 28 is reset and sequence counter 25 is incremented
by one, modulo 8, in preparation for reception o the next
data block.
If either of the tests (length and sequence
number) fail, the data behind barrier 13 is discarded
as erroneous by moving the tail T over to the barrier B
location. An (REJ + j) code (where j is the value in
sequence counter 25) is then loaded into the buffer 12 at
the new tail T position and barrier 13 moved over one place
to make the REJ code available to stage 11. When the EC~O
code or ~EJ code reaches the head H of buffer register 12,
it is placed in R2 register 24 by stage 11 to be sent back
to the remote receiver.
If an ECHO or REJ code is lost in transmission to
the remote receiver, a timeout occurs, causing the ENQ code
to be transmitted, as in the character mode. The CHECK
code is used just like the ENQ code in some transmitters,
but only ~or error control, and may have a shorter
timeout. In a Type 5 system, the data block must be
retained at the transmitter until an a~knowled~ement is
received (to permit retransmission i~ an REJ is received~.

'7

- 16 -

The answer to a CHECK code is a simple (ACK ~ j~ where j is
the last sequence number received, stored in sequence
counter 25, to be used as a check at the transmitter on the
retained block sequence number.
It can be seen that the receiver 100 of the
figure is capable of receiving data streams in types 1, 2,
3, 4 and 5 formats and supply all of the protocols
necessary to support transmission of all of these various
data streams. In Type 1 data streams, the INIT0/AINIT
interchange can be omitted if the receiver has a default
character mode setting when initially enabled.
Alternatively, for any mode, the request for service could
include the mode of the transmitter, and the answer could
include the mode of the receiver. If they matched, no
initial handshake would be necessary. If the receiver at
one end of a circuit wishes to know the mode setting o~
transmitter, an INITREQ code can be sent to which the
response is INIT0 or INIT1, depending on the transmitting
mode. The AINIT response confirms reception of INIT0 or
INIT1.
The buffer memory 1~ may well be implemented in
the internal memory of the host computer. This causes no
problems as long as the movable barrier restrictions are
implemented and the transmitter 15 has access to the
control codes loaded into the buffer store.
It is also possible to operate the receiver 100
in a multiplex mode in which several different types of
data streams are multiplexed together. In that event, each
different data stream would occupy one uniquely assigned
time~derived channel. It would, of course, then be
necessary to demultiplex and separate the signals. Each
data stream would then have its own buffer register, but
trailer processing and byte handling circuits could be
time-shared by all of the channels. A buffer register
arrangement suitable for mu1tiplexed operation is disclosed
in 11. 5. Pat~nt ~,499,576.
It will be noted that there are three dif~erent

~Z~5~


kinds of BOT codes in Table 2 (BOT, BOTM and BOTS). All
three of these codes are suitable for beginning a trailer,
but the latter two are used for somewhat diferent trailer
processing. A BOTS beginning of ~railer code is used for a
so-called S-type. The S-type block is used in type 3 and
type 4 data streams that utilize error detection, bu~ no
error correction. If a block has been deleted due to an
error, the sequence numbers of all following blocks will be
in error in Type 3 systems. The BO~S code can be used in
an S-type block in such a system to cause an increment in
the sequence counter 25 for both correct and incorrect
blocks. The BOTM code is used in some systems to support a
higher level framing scheme in which a frame consists of
several ~OTM blocks followed by a regular (BOT) block.
The unsequenced block codes BOU and EOU may be
used to send small amounts of da~a which bypass the flow
control mechanism in order to send expedited data in higher
level protocols.
The reaction of the receiver 100 of the figure to
all of the control codes will now be described for
completeness. When an ENQ control character is received by
stage 10, F register 21 is set to "1" and R1 register 2~ is
loaded with tACK + j) where j is the sequence number in
sequence counter 25. The ENQ code also clears trailer
buffer register 26 and deletes any data behind barrier 13.
When a CHECK control code is received, it behaves
identically to an ENQ code, except that F register 21 is
not set, used to indicate that ENQ control character was
not received.
When an INIT1 control code is received, buffer
memory 12 is cleared and trailer processing is enabled by
settin~ mode register 27. Sequence counter 25 and byte
counter 28 are set to zero, and R1 register 22 is loaded
with ~n ~INI'r code. If an INIT0 code is received, mode


~2~5~3~t~

18 -

register 27 is reset to disable trailer processing and
R1 register 22 is loaded with AINIT.
If a BOT (or BOTS or ~OTM) control code is
received, the BOT code and the following two bytes are
loaded into trailer register 26. I~ a data character
(instead of a SEQ code) immediately follows these three
bytes, trailer register 26 is cleared, thereby ignoring
corrupted trailers.
If an unsequenced message, i.e., messages
proceeded by a SOU code, terminated by an EOU code, and
including exactly two data bytes therebetween, is received,
it is passed immediately to the host without proce~sing in
FIG. 1.
tf a (S~Q + i) code is received while in the
character mode (mode register 27 reset), it is translated
into an (ECHO + i) code and transferred directly to buffer
register 12 and the barrier 13 moved just pass the ECHO
code to permit stage 11 to access to the ECHO code.
If a (SEQ + i) code is received while trailer
processing is enabled (mode register 27 set), i is compared
to (sequence number + 1) (modulo 8) in sequence counter 25
and the length in trailer register 26 is compared to the
byte count in counter 28. If either test fails, the data
behind barrier 13 is discarded by setting the tail T of
register 12 to the position of barrier 13. If the
beginning of trailer code is a BOTS ~hen a test fails,
sequence counter 25 is set to l and (ECHO + i) is placed in
buffer 12. Otherwise, an REJ code, followed by the
sequence number in counter 25, is placed in buffer 12. The
barrier 13 moved to make this code available ta stage 11.
If the tests succeed when a (SEQ + i) code is
received, counter 25 is set ~o i and an (ECHO ~ i) is
shifted into buffer 12. The barrier 13 is then moved to
the tail T to make the entire block o~ data available to
3S stage 11.

~S~

- l9 -

Stage 11 of the receiver handles interfacing with
the host machines. Thus the level A protocols match that
of the host machine. Bytes are passed, one at a tirne, from
buffer 12 to the output line 14 in this level A protocol.
If an (~CHO + j) or (REJ + j) code is retrieved from
buffer 12, the code is transferred to R2 register 24
instead of to line 14. When loaded, the status bit in
register 24 is set to signal transmitter 15 to transmit the
stored code.
The various transmitters which will operate
satisfactorily with the receiver 100 of the figure can be
readily fabricated by anyone skilled in the art. However,
to illustrate the appropriate transmitter logic, software
implementations of the various types of transmitters are
illustrated in Tables 3 through 7. These transmitter
implementations are written in high level pseudo-code for
ease in reading.





~s~

-- 20 --

TABLE 3
TYPE 1 TRANSMITTER
Comment~ ut is an infinite data source
partitioned into eight-bit data
bytes
array input (O, inf.~
i-O
main procedure
for (i-O, ) l
send input (i)
i=i~l

end





~5~


-- 2 1

TABLE 4
TYPE 2 TE~ANSMITTER

Comments: R is the value of the last ECEIO number
received.
S is the value of the next (SEQ)
number to be sent.
rec is an envelope received from the receiver.
__
10 TIMEOUT is a fixed time between the receipt
of the last echo and the transmission o~ an
inquiry for receiver status.
array input (0, inf.)
R=0; S=1; i=0
N = blocksize
main procedure
send INIT0
wait for AINIT
while (true) ~
while (S/R) t
send input (i)
if (imodN )t
send (SEQ+S~
S=~S+1)MOD8

i~ rec = ECHO + j
R=j
i time = TIMEOUT
send (ENQ)
end .




,
' - .

~2;;S;5~

- 22 -

TAsLE 5
TYPE 3 TRANSMITTER

Comments: block is an infinite array o blocks of N
eight-bit data bytes, where N = BLOCKSIZE
L1 is the low-order bits of N
L2 is the high-order bits of N
array block (0, inf.)0 main procedure
send INIT1
wait for AINIT
for (i=0, )l
send block (i)
send BOTS, L1, L2, tSE2 + (i+1)MOD8)

end





~2~

-- 23 --

TABLE 6
TYPE 4 TRANSMITTER

array block (0, inf.)
R=0; S=1; i=0
main procedure
send INIT1
wait for ~INIT
while (true)
while (S~R)~
send block(i~
send BOTS, L1, L2, (5EQ + S)
S=(S+l )MoD8
i = i ~ 1

i rec = ECHO + j
R=j
if time = TIMEOUT
send ENQ

end





~2S5~t7 7

- 24 -

TABLF. 7
TYPE S TRANSMTTTER

Comment: FIRSTREJ is a logical
variable which is true or false
array blocks (0~ inf.)
S=1; R=0; i=0; FIRSTREJ = True
main procedure
send INIT1
wait for AINIT
while (true)
while (S~R~
send block(i)
send BOTS, L1, L2, SEQ + S
i=i~l
s= ( st 1 )MoD8

if rec = ECHO f j l
FIRSTREJ = True
R=j

if rec = REJ ~ j
if (FIRSTREJ)~
i = i - (S ~ j 1)MoDB
R = ]
s=(i+1 )MoD8
FIRSTREJ = False
~,

if rec = ACK ~ j
- ( S




s = ( j f l ) MoD8

3S i~ ~im~ = TIMEOUT ¦
send ENQ

~S~


end
Finally, to make this disclosure
complete, a pseudo-code implementation of the receiver 100
of the figure is shown in Tables 8 and 9, representing
stage 1 and stage 2, respectively.





- 26 -

TABLE 8
UNIVERSAL PROTOCOL RECEIVER
STAGE 1
Comments: H is the location of the head of a
EIFO register PD.
T is the location of the tail of
FIFO register PD.
B is the current location of a movable
barrier within FIFO register PD.
SEQNO is the value of the current sequence
number.
MODE is a two-valued variable equal to
CHAR for the character mode and BLOCK
for the block mode.
LGTH is the count of the data block in .
bytes, as received.
main procedure
MODE = CHAR
2G T=B=FI=O
LGTH = SEQNO = O
While (true)
if inpuc = data ~
PD(~) = input
2 5 T=T+ 1
LGTH=LGTH+l
if MODE=CHAR
B=T

i~ MODE=CHAR and input=SEQ + i~
PD(T) = ECHO ~i
T=T~l
B=T

i~ MODE~BLOCK and input=BOT/BOTM/BOTS,L1,
L2,SEQ~i l


-- 27 --

if i=(SEQNO+1 )MOD8) and L1 ,L2=LGTH
PD ( T ) = ECHO+ i
T=T+ 1
SEQNO= i
LGTH=0
B=T
else t
T=B
if lBOTS) t
SEQNO = L
PD ( T ) = ECHO+ i

else
PD ( T ) = REJ + SEQNO
T=T+ 1
B=T
LGTH=0

if input=ENQ t
T=B
LGTH = 0
send LASTECHO
send ACK + SEQ~O
i f input = CUEC:K t
T=B
LGTH = 0
send ACK + SEQNO
if inpuk = INIT0
T=O
B-O
U-O
3 5 LGTH = 0
SEQNO ~ 0
MC: DE - C~IRR

~-2~j5(~P~

- 28 -

send AINIT
J




if input = INITl
T=0
B=0
H=0
LGTH = 0
SEQNO = 0
MODE = BLOCK
Send AINIT
J




if input = ECHO ~ i
give (ECHO ~ i) to local transmitter
if input = REJ + i
qive tREJ + i) to local transmitter
if input = ACK ~ i
give (ACK ~ i) to local transmitter
if input = AINIT
give AIN~T to local transmitter
end





~ ~r-

- 29 -

TABLE 9
RECEIVER
STAGE 2




main procedure
while (H ~ B) ~
if PD(H) = data
send data to host
if PD(H) = ECHO + j ~
send ECHO + j
LASTECHO = ECHO + j

if PD(H) = REJ + j t
send REJ + j
LASTECHO = ~EJ + j
H ~ H + 1
}




end





Representative Drawing

Sorry, the representative drawing for patent document number 1255007 was not found.

Administrative Status

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Administrative Status , Maintenance Fee  and Payment History  should be consulted.

Administrative Status

Title Date
Forecasted Issue Date 1989-05-30
(22) Filed 1986-02-28
(45) Issued 1989-05-30
Expired 2006-05-30

Abandonment History

There is no abandonment history.

Payment History

Fee Type Anniversary Year Due Date Amount Paid Paid Date
Application Fee $0.00 1988-06-24
Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
AMERICAN TELEPHONE AND TELEGRAPH COMPANY
Past Owners on Record
None
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Drawings 1993-09-30 1 19
Claims 1993-09-30 1 31
Abstract 1993-09-30 1 15
Cover Page 1993-09-30 1 19
Description 1993-09-30 29 895