CA1283455C - Apparatus and method for transmitting digital data over a radio communications channel - Google Patents

Abstract

APPARATUS AND METHOD FOR TRANSMITTING
DIGITAL DATA OVER
A RADIO COMMUNICATIONS CHANNEL

ABSTRACT OF THE DISCLOSURE

a digital radio RF signalling protocol communicates either digitized voice or digital data signals and indicates the type of information being communicated to the receiver. Multiple repeats of control signals are provided for fade protection and to ensure correct receipt even under adverse communications channel conditions. When the destination transceiver received a transmitted digital data burst from the transmitter, the destination transceiver transmits a responsive acknowledge message and may specify in the acknowledge message which portions of the received message were received incorrectly and should be retransmitted by the originating transceiver. The originating transceiver determines the contents of subsequently-transmitted data bursts based upon the information it receives from the destination transceiver by way of the acknowledge message. As deleterious phenomena (e.g., noise and/or fading) degrade communications channel quality, the acknowledge message handshaking causes the originating transceiver to repeat incorrectly received data packets until the destination transceiver finally receives those data packets correctly.

Description

~834~S

APPARATUS AND METHOD FOR TRANSMITTING
DIGITAL DATA OVER
A RADIO COMMUNICATIONS CHANNEL

Cross References to Related AP~lications This application is related to commonly-assigned Canadian Application Serial No. 498,346, filed December 20, 1985 entitled "Cryptographic Digital Signal Transceiver Method and Apparatus"; and to commonly-assigned Canadian Application Serial No. 494,791, filed November 7, 1986 entitled "Method and Apparatus for Transmitting Cryptographically Encoded Digital Voice Data Over A Radio Communications Channel".

FIELD OF THE INVENTION
The present invention relates to digital radio frequency communications systems, and more particularly, to a communications protocol for transmitting and receiving digital signals over a radio frequency communications channel.

BACKGROUND AND SUMMARY OF THE INVENTION
Communicating digital control and message data signals over radio communications channels is already well known in the art. See, for example, the following (by no means exhaustive) list of ~`

~2834SS

prior-issued United States Patents:
4,027,243 to Stackhouse et al (1977) 4,369,443 to Giallanza et al (1983) 4,434,323 to Levine et al (1984) 4,322,576 to Miller (1982) 4,267,592 to Cra~glow (19~1) 3,801,956 to Braun et al (1974) 4,418,425 to Fennel, Jr. et al (1983) Commonly-as~ign~d U.S. Patent No. 4,027,243 to Stackhou~e et al do~crlbe~ dlgltal me~sage generator for a digitally controlled radio transmltter and receiver in a radio communications ~ystem. Provision~ are made in thi~ communications ~y~tem for acquiring bit synchronization as well as word ~ynchronization in each of a steady succe~sion of digital command message~ tran~mitted between radio ~tatlon ~lte~.
Commonly-as~lgned Cdn. patent application ~eri~l no. 494~791 of Szczutkowski et al filed November 7, 19 as de~cribe~ a ormat of control and eAcoded voice digital signals which provides sel-ctlve ~ignalling capability, late entry, and word and cryptographic synehronization recovery --a~ well as fade and noise protection -- in the conte~t of a digltal voice privacy rad~o communications system. Prior art FIGURE 1 shows the preerred t~me sequence of digital ~ignals transmittod and received by the communications system de w ribed in the Szczutkowski patent application. While additional details relating to theso digital ~ignal sequences may be learned from the specif~cation of application of serial no.
~94,791 the sequence shown in FIGURE 1 will now be briefly deYcribed.
The sequence of digital signals shown in FIGURE

~za34~5 l includes a preamble followed by one or more data frame~. The preamble contains data providing bit/frame ~ynchronization, repeater addressing, cryptographic synchronization and selective signall~ng control. Data frames carry their own ~ynchronization data and al~o contain digitized, encrypted voice or other data signals.
The signalllng format ~hown in prior art FIGURE
l repotitively transmits certain lnformation both in the preamble portion and at rogular intervals wlthin the encrypted voico data stream to permit a receiver to initially synchronize with a transmitter despito the usual Raleigh fading whlch may be expected on radio freguencies communica'tions channels and also to permit "late entry" (ln the event that the preamblo i~ "mlJ~ed" or un~ucce~lv-ly decoded) ~nd/or recov-ry of ~ynchronlzation (in the event th~t ~ynchronization initially acguired from the preamble is subsequently lost before the end of a me~age).
In the signalllng protocol shown ln FIGU2E 1, initial frame synchronization, ongoing frame synchronization, repeater addressing, cryptographic ~ynchronization and ~elective ~ignalling signals are all repetitively transmitted in the relatively long preamble portion or fade protection, and are alqo repetitively retransmitted at regular interval~
within the subseguent encrypted voice data stream.
Due to the placement of and repetitions of the variou~ control ields within the ~IGURE l protocol, the protocol provides a very high probability of correct initial synchronization and addressing function6.

34~5 The preamble portion of the FIGUR~ 1 signalling protocol preferably includes: (a) a dotting pattern; (b) a synchronization sequence including a repeated group of synchronization signals; and (c) an initialization vector (IV) and selective ~ignalling (SS) sequence (which includes repeated ~elective ~ignalling, initialization vector and guardband (GB) data ~ignal~).
Each data frame of the EIGURE 1 protocol include~ a ~header~ portion, a message portion, and an end of me~age portlon. The header portion include~ versions of the synchronization ~equence and the IV and SS sequence tran~mitted within the preamble portion. The me~s~ge portion includes dlgital ~ignal~ to be communicated (e.g., encrypted voice data). The tran~mitted me~age terminate~ in an end o me-~age (EOM) word including a synchronization field and a dottlng pattern.
The dotting sequence in the F~GURE 1 preamble portion 1~ preferably an alternating 1,0 pattern of digital oignal~ (e.g., 10101010...) continued for 240 bits (25 milli-econd~ at 9600 baud). Thls dotting pattern allow~ circult~ within the receiver of the communications system to quickly obtain bit ~ynchronization.
The synchronization sequence occurring within the preamble portion after the dotting pattern includes three repeated fields: a 16 bit synchronization word "S" (preferably an 11 bit 8arker code ~uch a8 11100010010 and S bits of "fill"
or dotting), an 8 bit ~outside addre~s" (OA) repeated once in complimented form to complete a second 16 bit field; and a 5 bit synchronization ~LZ834~

number (SN) repeated three times (with the ~econd repeat being in complimented form) plus one final bit of odd parity code 80 as to complete the third 16 bit fi~ld.
The repeated IV and SS sequence following the synchronization seguence includes a 64 bit guardband (GB), a 64 bit initialization vector (IV), and a 16 bit ~elective signalling addre~s (SS). In the prior art FIGURE 1 protocol, the 64 bit guardband GB
provides fade protection (and i~ not used to carry u~eful intelligence), and the 64 bit IY field establishe~ cryptographic synchronization in accordance with the conventional DES (described, for e~ample, in "Federal Information Proce~sing Standard~" publication no. 46, Data Encryption Standard, U.S. Dep-rtment of Commerce, NTIS, 52~5 Port Royal Road, Springfield, Virginia 22161). The 16 bit ~elective ~ignalling ield SS provides group and individu-l selective ~ignalling capability within a radio communication networ~ (i.e., "addres~es" specifying particular ind1vidual or groups of receivers are transmitted in this fleld).
The IV, GB and SS fields are repeated nine times in the FIGURE 1 protocol.
Following the preamble are succes~ive data frames each of which preerably includes a subpreamble ("header") portion and successive bits of dlgital data ~ignals (e.g., encrypted voice data). The header include~ a single repeat of the synchronization word S, the outside address field OA, the initialization vector IV and the selective signalling address SS. Enough information is provided in each header portion ~o as to allow for ~Z834~5 late entry into an ongoing message or conversation and/or 80 a~ to reestablish lost frame or cryptographic synchronization (e g , a~ might occur from temporary 108~ of signal due to fading or multipat~ interference conditlon~ or the like on a typical radio frequency communicatlons channel) A
~ynchronization maintenanco control function in the receiv-r monitorJ the ongoing received data frame header -- and can reestablish bit ~ynchronization, frame aynchronization, cryptographic ~ynchronization and ~elective ~ignallinq control from the header portion alone An end of message (EOM) ~ignal is provided at the end of a me~age tran~ml~ion to alert recelvQrs that tho me~age i~ terminated The FIGURE 1 ~ignalling protocol 1~ hlghly ucc---ul, and permlt~ e~tr-mely reliable communicatlon of digital signal~ over a radio (or other) co~munications channel sub~ect to fading, nol~e and other phenomenon at a suffic~ent data rate and wlth very low error probability ~owever, further improvemonts are poJ~ible For e~ample, although the FIGURE 1 signalling protocol i~ designed to communicate encrypted digitized voice data (although it i8 by no means limited to communicating thi~ type of information), it would be desir~ble to selectively communicate digitized voice data or digital information provided by a purely digital ~ignal source such as a data terminal -- and to provide ~ignalling control signal~ within the communications protocol to ~ignify to the receiver what type of me~sage information is being communicated There exists a ~Z~3~55 great demand for radio tran~ceivers which can convey not only voice information but also digital information produced by a data terminal or computer. While the FIGURE 1 protocol is not limited to communicating voice data (virtually any type of digital data could be conveyed within the message data frames), a transmitted indicator signal lndicating th¢ type of data being transmitted would permlt receivers to treat received digital information in the appropriate manner (e.g., convert the data to nalog audio signals for application to a loud~peaker, or preserve the data in digital form to be displayed on a data terminal or stored in a computer memory).
Further improvement in error-free transmission at high data rat~ i8 al~o pos~ible. An effoctive d-t~ rate of ~600 b-ud on an error free channel i~
de~lred. This effective data rate should degrade to no les~ than 2400 baud on a 1.0% BER channel with no RF fading. The probability of receiving a message of 9600 bits incorrectly on a channel with 1.0% BER
and no fadins should be no greater than 0.0001, and with typical fading on the channel, this probability ~hould increase to no more than 0.01.
The signalling protocol ~hould also demonstrate some form of adaptivity to deleterious phenomenon pre~ent on the communications channel (e.g., noise and/or fading). While numerous repetitions of the same data may be necessary to ensure accurate reception when the communications channel is ~ubject to noise and/or fading, such repetition~ decrease the effective data rate and may not be necessary when communicating signals over an optimal channel ~X8345~;

~5MR496 havinq little or no fading and noise. If the roceiver has trouble receiving a particular data packet, then the transmitter should somehow adapt and repeat the pacXet. Data packets should be repeated more often as the bit error rate of the communications channel increa~es -- without significantly increasing tho "overhead" traffic on tha channel usod for communicatlng control signals rather than u~eful data signals.
Moreover, it would be de~irable for such an adaptive ~ignal format to be compatible with the prior signall~ng format shown $n FIGURE 1 (and thus, with existing communications equipment such as repeators and mobile transc~ivers designed to communicate using that protocol).

BRIEF DESCRIPTION OF T~E DRAWINGS

These and other features of the present invention will be better and more completely understood by studying the following detailed de~cription of presontly preferred embodiments togethar with the appended drawing~, of which FIGURE 1 is a schematlc timing diagram of a prior digital signalling format;
FIGVRE 2 is a schematic diagram of the presently preferred exemplary embodiment of a communications ~ystem 50 of the present invention;
FIGURE 3 i~ a ~chematic block diagram of exemplary communications transceivers shown in FIGURE 2;
FIGURE 4 is a schematic diagram of the presently preferred exemplary embodiment of a data ~Z83455 burst siqnalling format in accordance with the present invention;
FIGURE 5 is a schematic diagram of an exemplary format of the preamble portion of the signalling ormat shown ln EIGURE 4;
FIGURE 5A i J a schematic dlagram of an ex-mplary format of the guardband field ~hown ln FIGURE 5;
FIGURE 6 is a ~chematlc dlagram of an exemplary ~ubpreamble portlon of the ~ignalling format shown ln FIGURE 4;
FIGURE 7 i8 a schematic diagram of an exemplary data packet collection portion of the data burst signalling format ~hown in FI WRE 4;
FI5URE 8 18 a ~chematic diagram o an o~emplary acknowledgm~nt m~-sag~ transmittod by a tran~ceivcr in accordance with the pr-~ent inventlon ln re~pon~e to recelpt of the data bur~t ~hown ln FIGURE 4;
FIGURE 9 1~ a ~chematlc block diagram of exomplary buffers used by the transcelver Jhown in FIGURE 3 to proce~ the slgnals shown ln FIGUR~S 4-8;
FIGURE 10 i~ a schematlc flow chart of an exemplary program control routine XMAIN performed by the tran~ceiver control microproce~sor shown ln FIGURE 3;
FIGURES llA-llB toqether are a schematlc flow chart of an axemplary program control routlne XDOM
performed by the transceiver control microproce~or ~hown in FIGURE 3 when the transceiver i~
originating a digital data message;
EIGURES 12A-12B together ~how exemplary program control steps of a routine SHUFTX called ~y the XDOM
routine shown ln FIGURES llA-llB;

1~834~S

FIGURE 13 is a schematic flow chart of exemplary program control steps of a routine FILLTX
called by the XDOM routine ~hown in FIGURES llA-llB
FIGURES 14A-14B together are a schematic flow chart of exemplary program control steps of a routino XDEM performed by the transceiver control m$croproceo~or ~hown in FIGURE 3 when the tran~celv-r i~ the destination of a digital data me~age FIGURES l~A-15B together are a schematic 10w chart of exQmplary program control steps of a routine INPBFF called by the XDEM routlne shown in FIGURES 14A-14B;
FIGURE 16 is a schematic 10w chart of exemplary program control stops of a serial lnterrupt routine performed in response to 8 serial ~lnterrupt~ recelv~d by the tran~ceiver control m~croproc-~or ~hown in FIGURE 3;
FIGURE 17 is a schematic flow chart of oxemplary program control steps of a routine GETDAT
called by the serial interrupt routine ~hown in FIGURE 16;
FIGURE 18 iJ a schematic flow chart of exemplary program control step~ of a routine TRMMSG
called by the serial interrupt routine shown in FIGURE 19 is a schematic flow chart of exemplary program control steps of a routine OUTDAT
called by the serial interrupt routine shown in FIGURE 16;
FIGURE 20 is a schematic flow chart of exemplary program control steps of a modem interrupt routine performed by the transceiver control ~L~834~i microprocessor shown in FIGURE 3 in response to an interrupt generated by the transmit/receive ~nterace;
FIGURE 20A ~ 8 a flow chart of interrupt routine STRTTX;
FIGURE 20B is a flow chart of interrupt routine RCVENT;
FIGURE 21 1- a ~chematlc flow chart of e~Qmplary program control step~ of a routine usod to proce~ the header portion of a received data burst;
FIGURE 22 is a schematic flow chart of exemplary program control steps a routine RXDATA
usQd to process the data portion of a received data burJt;
FIGURE 23 is a schematic 10w chart of xemplary program control ~teps of a routine RXACK
u~ed to proce~ a received acknowledge message;
FIGURE 24 (~ot forth on the ~ame sheet of drawings a~ FIGURE 9) 1~ a ~chematic flow chirt of xemplary program control ~teps of a routine TXDOT
used to effect transmi~sion of a dotting pattern;
FIGURE 2~ iJ a ~chematic flow chart of exemplary program control ~teps of a routine TXAMBLE
used to effect transmi~sion of a preamble portion;
FIGURE 26 i~ a schematic flow chart of exemplary program control steps of a routine TXHDR, which is u~ed to transmit the header shown in FIGURE
4;
EIGUR~ 27 is a schematic diagram of exemplary program eontrol steps of a routine TXACK, which transmits an acknowledge signal; and FIGURE 28 i8 a schematic flow chart of exemplary program control ~teps o a routine TXDATA, ~,Z83~;5 45~R496 which tranamita data.

BP.I F~F DES~I J~TI ON OF A PRESl~Nll,Y PRE;E7~RD
E~IPLARY ~DI~iENT

Ove~all SY~tem F~CURE 2 18 a schematlc dla~ram of a presently proferrod e~empl ary embodiment o f a digltal radio communicatlon~ ~y~tem 50 in aecordanee with the present invention. Communication~ sy~tem SO
includos a data originating mobilo digital radio eommunleation~ tran~ceiver !hereafter ~DOM~) 52, a repeating radlo communications tr~nsceiver (~repeater~) 54, and a de~tination dig~tal radio eommun~eation~ transceiver (hereafter ~DEM~) 56.
DOM 52 tran~mit~ digital data through repeater 52 (oporatl~g on one or moro predetermined radio fregueney communication~ channels) to DEM 56. Upon receipt of a tran~mitted data bur~t, DEM 56 tran~mit~ to DOM 52 an acknowledge ~ignal which acknowledge~ reeeipt of the data and ~pecifies whether the data has been correctly received.
The DOM 52 originates d~gital data, format~
this digital data into a predetermined signalling format, and modulates a radio freguency carrier eignal with the dlgital data 80 formatted to produce RF ~data bursts.~ The~e radio frequency data bur~t~
are tran~mittod by DOM 52 to repeater 54 via RF
communications link 58 (the communieation~ link is a selected RF communication~ channel in the preferred embodiment). Repeater 54 receives, detects, regenerates and retransmits the data bur~t~ over ~2834~

radio freguency communications link 60 (preferably another ~elected RF communicat$ons channel) to DEM
(de~tlnation mobile) 56. DEM 56 receives the regenerated, retran~mitted RF data bursts and demodulates them to extract the digital data signals they carry.
Each data burst transmitted by DOM 52, repeated by repeater 54 and received by DEM 56 contain~ N
(preferably 16 or 32) data ~packets" each of whlch contaln M (preferably 64 or 128) bit~ of digltal ~gnal information. Each packet in a data burst can be unique, or packets may be duplicates o one another in the preferred embodiment, depending upon ~ev-ral different factors (as will be explained).
Following the transmi~sion of a data burst from DOM 52 (via repeater 54) to DEM 56, the DEM responds in the preferred embodiment by transmittlng an "acknowlodge~ message consisting of a bit map with 1 bit corrc~pond~ng to each packet in the data burst, which ~peci~ies which packet~ in the data burst tran~mitted ~y DOM 52 were correctly received and how many new packets can be accepted by DEM in the no~t transmission. This acknowledge message is recoived by repeater 54 (via RF link 60), detected, regenerated and retransmitted by the repeater, and received (vla link 58) by DOM 52. The received acknowledge mes~age at lea~t partially determine~
which data packets the DOM 52 transmits in the next succes~ive data b~rst.
In tho preferred embodiment, DEM 56 acknowledges every data burst it receives by transmitting an acknowledge message. The transfer of a data burst in the preferred embodiment ~ 283455 includes: (1) a transmission from DOM 52 to DEM 56;
and (2) a re~pon~ive (hand~haking) transmi~sion from the DEM to the DOM.
The first data burst in a message transmitted by DOM 52 includes some special informatlon (e.g., an ~outside address~ and an ~initialization vector") used to lnitialize repeater 54 and DEM 56 and to synchronize the DOM, the repeater and the DEM.
After DOM 52 transmits thlJ inltial lnformation, it transmits a data bur~t contalnlng N data packet~.
After tran~mitting the first data bur~t, DOM 52 walts for recelpt of an acknowledge message transmitted by DEM 56. Based upon the contents of the received acknowledge me~sage, DOM ~2 may rQtransmit another data burst contalning some or all of the data packets already transmitted -- or lt may transmit a new data burst containing N
previously-untransmitted d~ta packets. Thls proce~
continue~ ~ntil the entire digital message to be transmitted has been correctly received and acknowl~dged by DEM.

Radio Transceivers In the preferred embodiment, DOM 52 and DEM 56 are identical, and each have the architecture ~hown in FIGURE 3, a sch~matic block diagram of a preferred digital radio communicatlon~ tran~ceiver (thi R transceiver can act as a DOM or a DEM as controlled by the u~er). The structure and operation of DOM 52 and DEM 56 will now be described in connection with that FIGURE 3.
The transceiver shown in FIGURE 3 includes the 45~R496 u-ual rad$o fre~uency transmitter 70 and radio froguoncy receiver 72 (or any other communication channel tran~mitter and receiver ~uch a~, for ex mple, the transmit line~ and receive lines of a conventional wire line modem). A~ indicated in EIGURE 3, the transceiver may be in communication with one or more repeaters or other tran-ceivers or ba~o ~tatlon(s) over a radlo reguency or other form of communication channel.
The transcelver ~hown in FIGURE 3 can operate ln either a ~clear~ mode or a "private" mode. ~n the ~prlvate~ mode, data to be transmitted io firot encrypted using the Data Encryption Standard (see NTIS FIPS Pub. 46) -- and s3mllarly, receivod data i- decrypted u~ing DES before it is outputtod by the tr-n~celver. In particular, the microproce-cor circultry tak-~ conventlonal input signal~ (e.g., from a microphone or audio ampliier or the like) and converto tho~e to a otroam oS cryptographically eneoded digital ~ignalo input at the modulator of transmitter 70. On the receive oide, a stream of digital ~ignal~ produced at the detoctor output oS
receiver 72 i~ ultimately docoded and convorted into output ignalo beore being paooed on to the usual receiver audio output circuitry (e.g., audio amplifiero, loudspeaker and the like).
The overall arch~tecture of the microprocessor control cyotem ohown in FIGURE 3 is generally conventional. The heart o the syotem is a control microproee-oor 74 (Q.q., an Intel ~031 integrated circu~t chip) which communicate~ with the remainder o the digital circuitry via internal data bus 76 and external data bu~ 78. The usual push-to-talk ~283455 (PTT) switch 80 may be considered as one wire in the control bus 78 if desired. The system may include a conventional codec 82 (e.g., an Intel 2916 integrated chip) and conventional speech coding circuits 84 in the form of a suitably programmed digital signal processor lDSP) (e.g., NEC 7720 integrated circuit chip) for converting audio signals to/from digital/analog form in accordance with known speech digitization and processing algorithms.
In the FIGURE 3 transceiver, a hybrid subband coding technique may be employed in accordance with the invention claimed in Canadian Patent No.
1,249,060, issued January 17, 1989 to Zinser, Jr The Data Encryption Standard is implemented via DES
circuits 86 (e.g., MC 6859 integrated circuit chip) and a conventional DES key memory 88. Suitable conventional ROM circuit 90 (e.g., 4 kilobytes) are also provided to physically embody the program control structure pertinent to the system shown in FIGURE 3.
The transmit/receiver interface circuits 92 are sometimes referred to as "modem" circuits and may also be of conventional design. They preferably include bit restoration circuits of the type described in commonly-assigned U.S. Patent No. 4,382,298 to Evans. Reference may also be had to commonly-assigned U.S. Patent No. 4,027,245 to Stackhouse et al for digital transmit/receive mode interface circuits suitable for use with radio frequency transmitters and receivers such as transmitter 70 and receiver 72 and for a hard-wired Barker code sync word detector.

~2834S~

A conventional Gaus~ian Minimum Shift Key (GMSK) filter 94 (e g , a fourth order lowpa~s Bessel filter with a cutoff froquency o about 7 kilohertz mea~ured at the 3dB points) i8 preferably included to process a stream of digital output signals before they are passed on to the modulator of transmitter 70 as will b- appreciated by those ~killed in th- art The output of rec-iver 72 (e g , from an FM
di~criminator) i~ al~o preferably pas~ed through a conventional llmiter circult 96 to eliminate DC
bia~ effect~ that otherwi~e would be present in the output of the receiver discriminator For example, limiter 96 may utilizQ a simple comparator to compare the instantaneous incoming signal from r-ceiver 12 with a runnlng averag-d value over some previou~ relatively ~hort time interval a~ ~hould al~o b- appreelat-d by thos- ~killed in the art ln addition to tran~mitting and receiving voice information, the transceiver ~hown in F~GURE 3 is l~o capable of tran~mitting and receiving digital data ~ignals produced ~y a data terminal 100 Data terminal 100 i~ pr-ferably a conventional digital data terminal including a key~oard (or other) input device and a display (or other) output device Data terminal 100 i~ connected to a data terminal interface 102 which interfaces the data terminal with bus 76 and transceiver control bu~ 78 An operator u~ing the FIGURE 3 transceiver has a choice He/~he can either ~peak into a microphone to transmit voice and listen to the loud speaker producing audio corresponding to received voice signals; or he/3he can input text (or other digital mo~age~) via the keyboard of data terminal 100 and road received digital text meJ~age~ on the display a~oeiated with the data terminal (or control the data terminal to proce~ the received signals in other way~) The FIGURE 3 transceiver i~ capable of differentiating between digital information produced by nd/or to be routed to d-ta tenminal 100, and audio lnform-tion produced by tho microphone and/or to bo routod to the audio output circuits In addition, the EIGURE 3 tran~ceiver can encrypt dlgltal data or~ginating at the data terminal 100 b~foro transm~tting the data and decrypted received data bofore applying the received data to terminal 100.
The manner in whlch a transceiver similar to th- EIGURE 3 transceiver 1~ usod for transmitting nd receiving voice signal~ is described in detail ln cop-ndlng commonly-a~signed Cdn, patent pplic-tion 494,791 to Szczutkow~ki et al filed November 7, 19~6 ~n accordance wtth the present inv-ntlon, tho EIGURE 3 tran~ceiver uses a ~ignalling protocol which is compatible with that ~hown in FIGURE 1 to tran~mit digital data produced by data terminal lO0 and to recelve digital data t~
be di~played or otherwise handled by the data terminal - ~;2~155 Sicnall~na Protocol FIGURE 4 iB a ~chematic diagram of the overall format of a digital data burst 150 transmitted by DOM 52 in accordance with the presently preferred exemplary embodiment of the present invention.
Bur~t 150 include~ three portion~: ta) a header portion 152; (b) a data packet collection porticn lS4; and (c) an ond of me~age (EOM) portlon 156.
~ eader portion 152 lncludes Jignals used for bit, frame and cryptograph~c synchronizat~on, ~olective addre~sing and the like (as will be explained in detail ~hortly). Data packet coll-ction 154 includes "packet~" of digital signals ropros-nting the message belng conveyed. End of mo~ag- portion 156 include~ siqnals indicating the end of data burst 150.
~ eader portlon 152 in the preferred ombodimont includ~s eithor a proamble 158, or a subpreamble 160. Sinco data burst 150 has a predefined length, many data bursts 150 may be needed to transmit a ~inqle message of dlgital data ~me~sages can have any length), each data bur~t containing only a portion of the message. Repeater 54 and DEM 56 must bo initia~ized and synchronized with DOM 52 before the mes~age is transmitted -- and preamble 158 contains signals needed to establish bit ~ynchronization, frame synchronization and cryptographic synchronization between DOM 52, repeater 54 and DEM 56 (as well as to ~electi~ely address individual or groups of DEMs and to perform other functions as well).

~283455 To increase effective bit rate, preamble 158 is tran~mitted only at the beginning of a message transmi~sion (e.q., at the beginning of the first-transmitted data burst 150 containing the first portion of the mes~age), although it may also be transmitted in one or more later data bursts if needed (e.g., to indicate a change in data format occurring in the middle of a message transmi~sion).
The ~ubpr-amble 160 contains ~ome of the ~ame lnitialization information contalned within preamble 158, but i~ much shorter than the preamble (~o that effective data rate can be maximized). Subpreamble 160 i~ transmitted at the beginning of each data bur~t 150 ~uboequent to the initial bur~t in the proferred embodiment.
FICURE 5 i~ a schematic diagram of preamble portion 158, which include~ the following signal~:
(a) a dotting sequence 162; (b) a ~ynchronization ~equenco 164; and (c) an IV/SS sequence 166. In the pr-~erred mbodiment, the synchronlzation sequence 164 and the IV/SS soquence 166 are each repeated multiplo timo~ in proamble 158 to assure proper recognition and provide fade protection.
Dotting ~equence 162 (96 bits of "totting"
pattern, e.g., 101010...) allow~ repeater 54 and DEM
56 to efficiently ostablish bit synchronization with DOM 52.
Synchronization sequence 164 includes a synchronization word S, an "outside addre~s`' word OA, and a synchronization number word SN.
In the preferred embodiment, synchronization word S is a 16 bit long digital word used to e~tablish synchronization, and in particular, is an 12834~;5 11 bit Barker code such as 11100010010 preceded by 5 blts of fill or "dotting" (e.g., 10101).
Outside address word OA is 8 bits long in the preferred embodiment -- and is repoated in complemented form immediately after being transmitted in original form, for a total length o~
16 bits. In the preferred embodiment, this outside addre~J word OA lndicate~ whether the mes~age being transmitted contains digital data or digitized voice. That is, in the presently preferred embodlment, tho digital value contained within out~ide address word OA 1~ set to "5~AAH~ if the me~saqe contains digitized voice, and is set to ~AAS5~" ~f the mesRage contains digital data.
Synchronization word SN contains the number of the repetition of tho "group" (of synchronization word S and out~ide addre~s word OA) the ~ynchronization word SN i~ associated with. This qroup is ropeated 12 time~ in synchronization ~equence 164 (with ~ynchronization word SN
indicating tho numbor of oach repotition) in the pr~forred ombodiment. Synchronlzation word SN
provides fade protection and also helps DEM 56 to determino if it has received preamble 158 correctly.
IV/SS sequenco 166 in the preferred embodiment includes: (a) a guardband field qb; (b) an initialization vector (IV); and (c) a selective signalling word SS. The IV contains decryption informat~on, and word SS continue selective addre~ing signals. In one implementation, the guardband field contain~ only dottinq or other filler and i~ used to provide fade protection during tranomission of the IV/SS sequence. In another ~2B3455 45~R496 presently preferred implementation, however, the guardband field (or in addition to) rather than the outside address field OA is used to carry information which permits repeater 54 and DEM 56 to distingui~h between a digital data messaqe and a digital voice message In the preferred embodiment, instructlons can be passed rom DOM 52 to DEM 56, and from the DEM
back to the DOM, via the guardband within the IV/SS
~lgnalllng ~equence of preamble 158 F~GURE SA
~how~ the preferred format for the guardband In thc preferred embodiment, the guardband contains command, selective addressing, format control, error checking, and other information Moro particularly, the guardband include~ the following fields A 4 bit command field 190, a 1 bit NP (not participating) field 192, a 1 bit MC
(mid eommand execution) field 194, an 8 bit SUBGS
(subgroup ~ource) field 196, an 8 blt SUBGD
(~ubgroup destlnation) fleld 198, a 6 bit BPP (bytes per packet) ield 200, a 6 bit PPB (packets per bur~t) f~eld 202, a 14 bit working field 204, and a 16 bit CRC (error checking) field 206 The SUBGS and SUBGD ields 196, 198 are used in connection with the SS field to provide selective addres~ing In tho preferred embodiment, the SS
field iR used to de~ignate a group of radio transceivers, while the SUBGS and SUBGD field~
designate a sub~et of that group --the SUBGD field ~pecifying a subset of the group to receive the me~age (i e , D~Ns intended to receive the meJsage), and the SU8GS field ~pecifying the ~ubset which the transceiver origi~ating the me~sage (i e , the DOM) ~s a member of.
In the preferred embodiment, the number N of data packet~ per data burst 150 is preset for any given messaqe as i8 the number M of byte~ per data pac~ets. In the preferred embodiment the~e preset numbers N and M are not fixed, but instead can be varied as de~ired dependlng upon a number of different factors (e.g., me~sage length or me~sage content). In th~ preferred embodiment, the BPP
field 200 indicates the number of byte~ per packet (M), and the PPB fleld 202 indicates the number of packets per data bur~t (N).
The working ield 204 of the guardband contains a maximum of 14 bits used to carry parameters associated with the command(~) indicated by the command field 190. The CRC field 206 contains convontlonal CRC error checking informatlon protecting the entire guardband.
The NP and MC fields (190, 192 are single bit control field~ u~ed to convey speclic control ln~ormatlon. The NP blt when set indicates to the rec-iving trsnscelver that the current data burst 150 contalns no data packets. A set MC bit drive~ a roceivlng transcelver to change formats in the middle of a message to those specified by other guardband fields.
Reerring once sgain to FI GURE 5, the initial~zation vector (I~) within IV/SS sequence 166 contains the conventional 64 bit long initialization vector required by the Data Encryption Standard, and iB used to e~tablish cryptographic synchronization between DOM 52, repeater 54 and DEM 56. Selective ~ignalling word SS is 16 bits long in the preferred ~283455 4sr~R4s6 embodiment and may be used (ln configuration with guardband flelds 196, 198) or ~elective calling of indiv$dual~ or groups using the same DES
cryptographic key The SS field (along with the SUBGS and SUBGD
field~ 196 and 198 within the guard band) provides truly ~elective ~ignalling capabilities within a cryptographic communications network The 16 bit SS
1eld and the SUBCD fleld may ropr~ent, for example, a u-er group with lndlvldu-l addresses de-ignating particular user-, 80 that users with the ~ame cryptographic key may nevertheless have the ablllty to further llmit their calls to receptlon by lndividual or group~ of tran~ceiver~ within their particular network The SS 1eld and the SVBGD
fleld may also be encrypted to acilitate selective ~lgnalllng wlthin ~ group of u~ers having the ame DES k-y whll- provldlng no lnformatlon to a u~er with a difer-nt key (or to an eave~dropper) Th- group of word~ lncludlng the guardband, the lniti-llzatlon v~ctor and the SS word are preferably r-p-ated nine times to provlde fate protection As mentioned previously, a ~5-out-o-9" vote 1~
utllized in the preerred ombodiment or analyzing the nlne time~ repoated IV/SS data ~eguence 166 For e~ample, at the receiver, each of the nine sequential GB/IV/SS data fields i8 voted bit-by-bit on at lea-t a 5-out-of-9 ba~i B . If at lea~t S of the 9 ver~ion~ o this rece~ved group o ~ignals do not match exactly, the DEM 56 concludes that it ha~
incorrectly received preamble 158 and require~ the DOM S2 to retransmit If at least 5 versions are voted on~ (i e , found to match), the voted re~ult~

~2~34SS

are stored and used as the correct IV/SS vectors for cryptographic synchronization and ~elective ~lgnalling purposes FIGURE 6 is a ~chematic diagram of an exemplary ~ubpream~le portion 160 shown in FIGURE 4 The subpreamble portion 160 includes a dotting portion 162 and a synchronization ~equence 164, but not an IV~SS se~uenco 166 In subpreamble 160, out~ide address OA of synchronization ~equence portion 164 1~ ropeatod in uncomDlimentod form (compare the compl-mented repoated outsldo addre~s OA in the ynchronizatlon ~eqUQnce 164 of preamble 158) DOM
52, repeater 54, and DEM 56 use this feature to di~tingui~h between preamblo 158 and subpreamble 160 (i o , if a transceiver receives a synchronization ~equence portion 164 ln which the repeated outside addre-s OA is ldentical to the fir~t occurrence of the out~ide addro~ word, then the synchronization ~oguonce portion is part of a subpreamblo 160; on the other hand, if a transcelver receives the out-ide addre~J word followed by its compliment, a pre~mble 158 i~ being received) FIGURE 7 is a schematic diagram a data packet collection portion 154 shown in FIGURE 4 Data packet collection portion lS4 includes N data packets 154a, where N i~ an integer multiple of 8 in the preferred embodiment In the preferred embodiment, each data burst 150 contains the same number N of data packets 1~4a, and each data packet 154a contains the ~ame number M bit~ of data ~although the guardband shown in FIGURE 5A can be used to specify N and M for different message transmissions) lZ8345S
45~R496 During any particular tran~mission of a data burst 150, data packets 154a could all be diferent -- or ~ome data packets could be repeats of otherY.
At the beginning, the middle and the end of data packet collection lS4, a "repeat" (R) byte i8 transmitted which indicates if the data burst 150 is, in toto, a repeat of an earlier-transmitted data burst. For e~ample, W M 52 repeats the la~t-transmitted data bur~t 150 lf it fail~ to receive a propor acknowledgement from DEM 56 (and transmits this literal data burst repeat with the contents of repeat field R indicating the transmitted burst is a repeat). DOM 52 also repeats the last-transmitted data packet if errors in a received acknowledge message prevent the DOM from determining which data packets to send next.
Each data packet 154a includes M bytes of data followed by a 16 bit cyclical redundancy check (CRC) fleld (or other de~lred error detectlon field). The total number of bits in data packet collection 154 ia equal to 24 + (M*8+16) ~ N, where M+8 is a number of blts in each data packet 154a, N is the number of data packets in each collection 154, 16 is the number of bits in each CRC field, and 24 i8 the combined length of the three repeat ields R. The time it takes to transmit data packet collection 154 is thus time ~ (24+~M*8+16) . N)/9600 .
for a data transmission rate of 9600 baud.

45~R496 Command Handlina Referring once again to FIGURE 5A, command field 190 of the preamble guardband contain~ (or may contain) a command the receiving transceiver i to execute. A command to control transceiver~ 52, 56 may be iJau~d by inputting the command into data ter~inal 100 and/or by tran~mlttlng the command in the guardband of preamble 158 preceding a data bur~t 150 (the data burst may but need not carry data packet~) or an acknowledge bur~t 170. A
~lightly different command format i8 used for commands inputted via data term~nal 100 (these command~ are formatted 80 as to be user friendly) ver~us commands provided via the guardband (which mu~t b- bit efficiont). The terminal command ormat wlll now b- di~cu~ed (the guardband formats belng imply ~traight-forward d-cimal-to-binary conver~lons o the terminal ormat~).

The command intorfaco i8 broken down into 8iX
commands. The commands indicato the type of data (ASCII or binary) to be tran~erred or control the data flow (~et the format or fitOp the current functlon). Each command is preceded by a control character to reset the command parse buffer allowing for a new command to be entered. The commands are shown below:
Code Name Number DescriDtion XFERA O Tran~fer ASCII bytes until the STOP command i 8 recei~ed 12834~5 XFERB 1 TranRfer a fixed numbcr of binary byteR (O to 2047 bytes) XEERLA 2 Transfer ASCII data one line at a time (O to 255 bytes per line) until a STOP command i~
received FORMAT 3 Specify data format: bytes/
packet, packets/burst, and voting STOP 4 Terminate current command (oxcept XEERB) NULL No Number Cancel current data entry -u~ed in XFERB to abort data on the current entry, reJet command parse buffer RETRANSMIT No Number Resend last data me~age (between MDI and MDT) ACKNOWLEDGE No Number Acknowledge command llne NOACK No Number No Acknowledge command line (retransmit) XON/XOFF No Number Controls data flow during XEERA and XFERLA modes of operation A complete description of each of these commands follows.
A. XFERA - CONTINUO~S ASClI TRANSFER
The ormat for this message ls:
< D>OtggggcCR> (note: D = nEOT") where t,g s '0','1','2', . . . ,'9' t = call type: O - use radio settings 1 - call multiple units on group 'gggg' with no acknowledges 2 - call individual 'gggg' with acks gggg= group ID to call (O to 2047) or individual ID to call (O to 4095) ~2E~3455 Thi~ command i8 used to transfer continuous ASCII
data from the mobile data terminal (MDT) to the specified unit. The data will continue until a STOP
command i~ rcceived.
EXA~LE: < D>021234<CR>
The above example is u~ed to set-up continuous ASCII
data from the MDT to the unit with Individual (or Logical) ID 1234.
B. XFERB - FIXED LENGl~l BINARY TRANSFER
The ormat for this mes~age i9:
< D>ltggggnnnn<CR>
where t,g,n = '0','1','2', . . ., '9' t = call type: O - use radio ~ettings 1 - call.multiple units on group 'gggg' with no acknowledges 2 - call individual 'gggg' with ack~
gggg = group ID to call (O to 2047) or individual ID to call (O to 4095) nnnn = number of binary bytes to transfer (O to 2047) Thi~ command i3 used to transfer a fixed number of BINARY data byte from the MDT to the specified units(s). Since the data iQ binary, no control commands are recognizable ~o the process cannot be interrupted until all the bytes have been received.
EXAMPLE: > D>0212340135~CR>
The above example is uRed to set-up for 135 bytes of binary data from the MDT to the unit with Individual (or Logical) ID 1234.
C. XFERLA - ASCII LI2~E-BY-LINE TRANSFER
The format for this message is:
~ D>2tgggg<CR>

1~83~

wh-re t,g = '0','1'.'2', . . . ,'9' t = call type: O - use radio settings 1 = call multiple units on group 'gggg' w$th no acknowledge~
2 - call individual 'gggg' with acks gggg = group ID to call (O to 2047) or individual ID to call (o to 4095) Thi8 com~and ~J used to tran~fer line by line data from the MDT to the ~pecified unit(~). A line may contaln up to 255 byte~. A complete llne can be terminated by ~ending the NULL command seguence.
The XFERLA ~eguence can be terminated by sending the STOP command ~equence.
When in the XFERLA mode, all cLF~ are ignored by the MDI. Line~ are delineated by a <CR>.
EXAMPLE: ~ D~221234~CR>
The above examplo is used to set-up llne-by-line ASCII data from the MDT to the unit with Individual (or Logical) ID 1234.
D. FORMAT
The form~t for this me~sag- 18:
~ D>3vxxyycCR>
where v,x,y = 'O'c'1','2', . . ., '9' xx= bytes per packet yy= packets per burst v ~ voting: O - no voting 1 - 2/3 voting ThiR command is used to ~pec~fy tho data format used in the data transfer.
EXAMPLE: < D>301632cCR>
The above example is u~ed to specify the data format for the next command as 15 byte~ per packet and 32 ~2834~i5 packets per burst with no voting E STOP COMMAND
The format for this message is < D>4~CR>
Thi~ command 18 used to stop execution of all current command~ except the XEERB
~XAMPLE ~ D~4CCR~
F NULL COMMAND
Th- format for this mesJage i8:
~ D~CR~ (<CR> iB optional) Thi~ command i8 u~ed in the XFERLA mode to torminate an input line The line i~ cleared when the <
D>~CR> (both characters) seguence is received Wh-n ntering command, a ~ D> cause~ the command par-- buffer to be cleared, llowing a new co~mand to be nterod Thereoro, if an orror io made on the input command lino, lt can be cleared by sending < D> nd ~ending the correct command If a c D><CR>
i~ receiv~d (e g , from a terminal) a <CR><LF> will b- ~choed back to cause tbe unit to go to the next lin-G. RET~ANSMIT
The format for thi~ me~age i~
< DZ RTR< G><CR>
This command is used to regusfit that a dta messageb- retransmitted ln either direction When a t-rminal ~ u~ed, tbi~ me~age would leave "RTR" at th- end of the line a~ a visual indicator to r--enter tbe data and would al~o ~ound the terminal bell For the intell~gent MDT the sequence reguest tb- data bo r-tranJmittsd automatically and can be u~ed in either direction ~. ACKNOWLEDGE
Tbe format or this message i8:

128345~;
45~R496 < F><LF~<CR> (Note: F = ~ACK) This message is used to acknowledge a command line.
If a terminal i8 used, the me~sage will re~et the terminal cursor to the ~tart of the next line. If a MDT is used, the command is simply an acknowledge that the two unit~ are now ready to transfer another command or data.
I. NOACKNOWL~DGE
Tho format for thi~ meJ~age i~:
< U~ RTR<CR> (Note: U = ~NAK") Thi~ ~essago iB u~ed to no-acknowledge a command l'ne. I a terminal i8 used, the message iwll di~play an RTR at the end of the command line and move the cursor to the srart of the current line (i.e., no <LF>). If an MDT is used, it will automatically retran~mit the command line.
J. XON n OFF
The format or thi~ data i8:
< S~ OR < Q~ (Note: or "DCl" / ~DC3~) These control commands are accepted/issued when the MDI i- in ~n ASCII data transfer mode. They are used to stop and ~tart data tran~fer~ when the internal bufers are full. In the binary transfer modo (XFERB), tho modem controls - CTS, RTS - are tho only way to temporarily stop the data transfer.
Acknowlodae Messaae Handshakina FIGURE ~ i~ a schematic diagram of an exemplary acknowledge mes~age 170 tran~mitted in the preferred embodiment by DEM 56 to DON 52 upon receipt of data bur~t 150. Aftor DOM 52 ha~ transmitted a data bur~t 150 to DEM 56, the DEM responds with an acknowledge message 170. If no acknowledge mes~age 170 is received by DOM 52 (by the time a predefined timeout period has expired), DOM 52 retransmits the lZ8345S

3~

last-transmitted data burst lSO. A repeated data burst 150 is marked by setting the contents of repoat field R (see FI W RE 7) to a predetermined value. If, on the other hand, acknowledge message 170 is received correctly by DOM 52, the DOM uqes the content~ of the acknowledge message to construct the next data burst lSO to be transmitted.
The acknowledge message 170 trannmitted by DEM
56 includes two important pieces of informatlon:
(1) Which of data packot~ 154a in the la~t-tran~mitted data bur~t 150 were received correctly or incorrectly by the DEM; and (2) ~ow many (new) data packets can be accepted by the DEM
ln ths data burst 150 next to be transmitted.
Acknowlodge message 170 includes a subpreamble portion 160 (as shown in FIGURE 6); an acknowledge ~eguence 172 and an end of message portion 156.
Acknowledge sequence 172 includes a repeated acknowledge data burst 174 (in tho preferred ombodim-nt this acknowlodge data burst i8 repeated 9 tlmo~). Each acknowlodge data bur~t 174 includes a ~tatus field 176, a me~sage field 178, and an error ch-ck~ng (C~C) field 180. Each message field 178 includes a control field 182 and a "NEWPACKET~ field lB4. In tho preferred embodiment, the total number of bits in acknowledge message 170 is 1016 1 9 . N
(where N ~8 the number of bits in status field 176). NOTE; Status field 176 is a bit map of N
bits -- 1 bit for each data packet. Ihe state of th- bit indicates whother tho packet was received correctly or not. By using the bit map, no overhead associated with transmitting packet numbers is incurred. Also, DOM does not send a packet number 45~R496 wlth each packet.
Acknowledge me~sage 170 indicates which data packets 154a in the last-tran~mitted data burYt 150 were correctly or lncorrectly received, and also specifies how many not-previously-transmitted data packets can be accepted in the next transmission.
DOM 52 generally transmits data packets 154a sequentially ln an order predetermined by data terminal 100. For example, lf a textual mcssage lncludlng a plural$ty of individual character~ i~
input to data terminal 100 or transmis~ion to DEM
56, DOM 52 attempt~ to transmit thoso characters in tho ~ame order they were lnputted. Likewise, DEM 56 e~pects to receive a sequence of data packets 154a containing characters ordered in the same way they wero inputted to data terminal 100 (80 that the contents of those data packet~ can be displayed or otherwlse proce~sed in the order they are received).
Sometimes, however, noise, fading or other phenomenon pre~ont on communication link 58 and/or communieation llnk 60 causes DEM 56 to incorrectly rocelve ~ome of tho transmitted data packet~ 154a.
Instead of sending a data stream with embedded ~gap~n to terminal 100, DEM 56 transmit~ an acknowledge message 170 requestlng DOM 52 to retransmit incorrectly received pacXet~ and meanwhile store~ tho correct, received data packetg in a ~uffer until DOM retran~mits the incorrectly roceivod packets and the DEM correctly receives them. Once DEM 56 correctly receive~ the retransmitted packet~, it proces~es them in their correct order with respect to the - ~2~33~5~;

e-rlier-transmitted correctly received (and already ~tored) packets DEM 56 preerably proces~e~ received packet~
154a in block~ (the length of the e block~ in the preferred embodiment is a multiple of the number of packet~ 154a transmitted in each data burst 150 plu~
a few extra) In the preferred embodiment, DEM 56 accumulate~ a block of data (containing, e g , 18 packet~) and pro~ent- thi~ block of data to data terminal 100 New pack-t field 184 within acknowledge me~age 170 indlc-te~ to DOM 52 how many additional ~new~
packet~ DEM 56 requires to fini~h ~building" a full blo~k of data A~ can bo soen from the transmiss$on formats ~-t forth ln EIGURES 4-9, all critlcal data (lncluding acknowledge ~equonce 172 or acknowlodge me~sage~ 174) tran~mittod in the preorred embodlment i~ checkQd u~ing conventlonal cyclical redundancy checklng algorithm in order to guarantee data int-grlty The ma~ority of transmiss~on errors occur within data packets 154 since they are large r-lative to the re~t of the transmis~ion Recovery from the~e rror~ occurs quite ~moothly in the preferred ombodiment of the pre~ent invention Error~ occurring within the control field~ po~e a om-what greater problem, even though they occur le~ often In the preferred embodiment, the total number N
of data packet~ within each data burst 150 is transmitted within the preamble guardband of the initial data burst (e g , as a parameter of the tran~mitted XFERA command) ~83455 If the number of different data packets to be sent in a given data burst 150 is les~ than N (where N is the number of data packet~ within the data burst), then the packet~ being sent are repeated in the preferred embodiment from lowest to h~ghest order over and over untll all N data packetQ in the outgoing data burst have been filled.
When DEM 56 acknowledge~ the receipt of a data burJt 150, it notiie~ DOM 52 which packets were correctly or incorrectly reeeived (according to convention~l error check~ng u~ing the CRC code~
within the data burst). In addition, DEM 56 notifies DOM 52 how many packets the DEM can accept in the next transmission.
For example, if a total of 16 data packets 154 (Pl-P16) are to be transmitted, DOM 52 initially communicates ~he value 16 to DEM 56, and then transmits a data burst 150 containing all 16 data packets (assumlng in thls example that N, the number of data packets within each data burst, i8 16).
When DEM 56 raceives the transmitted data burst, the DEM determines if any transmission errors have occurred by analyzing the received embedded CRC code on each data packet in a conventional manner.
Suppose DEM 56 discovers a transmission error in the third packet transmitted (P3) but recei~es all of the other data packets correctly. The acknowledge me~sage 170 transmitted by DEM 56 to DOM
52 indicates (in status field 176) that the third packet was not correctly received and that the other data packets were correctly received. Acknowledge message 170 also indicates (in new packet field 184) that DOM 52 should transmit no new data packets 12~33455 (~ince all sixtsen data packetQ of the message have already been transmitted at leaQt once).
DOM 52 transmits the next data burst 150 in response to received acknowledge message 170. Thig next data burst 150 includes not ~uot one, but 16 data packets 154a ~since in the preferred embodiment, all data burst3 150 have the same number of-data packets for given transmission). Each one of th~ 16 data packet fields 154a wlthin this data bur~t 150 contain the third data packet P3 (80 that the data bur~t repeats packet P3 16 times).
DEM 56 analyzes the CRC fields within roceived data burst lS0 to determine whether at least one of the 16 rece~ved P3 data packets was received correctly. If at loast one P3 data packet was receiv-d correctly, DEM 56 transmits an acknowledge me~sagQ 170 having a ~tatus f~eld 176 ~pec~ying that packet P3 wa~ received correctly and a new packet field 184 ~p-clfying that no new packets are expected -- and the me~age transfer is complete.
A~ another example, Juppose that a meQsage contains a total of 19 different data packet~
Pl-Pl9. Initially, DOM 52 informs DEM 56 that 19 unique data packets 164 wlll be tran~mitted, and then begins tran~mitting data bur~t 150. As~um~ng that each data bur~t 150 contain~ 16 data packet~
154a, at least two data burQts will be required to transmit the entire message.
DOM 52 transmits first data burst 150 cont~inin~ data packets Pl-P16. Suppo~e that DEM S6 incorrectly receiveQ packet~ Pl and P7, but correctly receives the remainder of the first 16 packets. DEM 56 transmits an acknowledge message ~Z83455 170 including a receive status field 176 indicating that packets P1 and P7 were incorrectly received.
As mentioned previously, data terminal 100 expect~ to receive data packets in sequential order. Since DEM 56 incorrectly received packet P1 and DEM data terminal 100 expects to receive packet Pl first, it is not yet po~sible for the DEM to communicate any data packet~ to its data terminal.
Suppo~e DEM 56 is capable of buffering only 17 data packet~ at a time. DEM S6 can accept only three data packets in the next data burRt 150 (oince it needs packets Pl and P7 before it can communicate the contents of its buffer to DEM data terminal 100). Therefore, it is capable of storing only one new data packet (previously untransmitted data packet P17 in addition to the data packets that have already been correctly recelved and the data packets P1 and P7 it ~till needs). Accordlngly, the NEWPACKET field 184 o acknowledgo message 170 notifies DOM 52 that DEM 56 can only receive one new data packet in the next data burst 150.
~ n respon~e to acknowledge mes~age 170, DOM 52 transmits a data burst 150 containing only three different data packets: P1, P7 and P17. This group of three data packets iR repeated as many times a~
is neces~ary to completely fill the 16 data packets 154 within data burst 150. As a result, the second data burst transmitted by DOM 52 contains the following data pac~ets:
.~
Pl P7 P17 P1 P7 P17 Pl P7 P17 Pl ... Pl Suppo~e now that DEM 56 correctly receives packets lZ834S5 P7 and P17, but incorrectly receives all 7 occurrences of packet Pl (this is 6tatistically unlikely, but possible if the communications channel is subject to heavy fading). In the next acknowledge message 170 transmitted by DEM 56 to DOM
52, statu~ field 176 indicates that packet P1 i~
~till needed, and new packet field 184 indicates that the DEM can accept no new packets). Both DOM
and DEM therefore know that only 1 data packet wlll be ~ent Pl ropeated 16 tlme~.
The next data burst 150 transmitted from DOM 52 to DEM 56 includes data packet Pl repeated 16 times.~ DEM 56 need only recelve one of these 16 occurrences of packet Pl correctly to complete the block of data stored in its data buffer and communlcate that data block to DEM data terminal 100 -- and it is extremoly llkely that the DEM will correctly receive at lea~t one of these 16 repeat~
of packet Pl. Assuming that at loast one occurrence o~ p~cket Pl 1~ correctly received, DEM 56 comm~nicates packets Pl-P17 to DEM data terminal 100 and tran~mit~ an acknowledge message 170 to DOM 52 lndicating in statu~ fleld 176 that packet Pl was correctly received and indicating in new packet field lB4 that DEM 56 is ready to receive two additional packets ~since there are only two packets P18 and Pl9 remaining ln the 19 packet message).
The next data bur~t lS0 transmitted by DOM 52 to DEM 56 include~ the following packetQ

P18 Pl9 P18 Pl9 ... PlB Pl9 If DEM 56 correctly receives at least one occurrence 128345~;

of each of the~e packets, it transmits an acknowlodge mes~age 170 to DOM 52 indicating that both packots were correctly received and that no moro packet~ will be accepted (the entire me~sage has now been transmitted and correctly received).
DOM 52 also keeps track of the number of packets which have been correctly received, and therefore determines independently that the message e~change i~ complete.
If DOM 52 must repeat an entire data bur~t 150 (e.g., becau~e DEM 56 fail~ to receive any of the 16 data packet~ corr-ctly or DOM 52 fails to receive acXnowledge message 170 after a predetermined timeout period), DOM 52 retransmits the data burst and sets tho repeat word R (8eo FIGURE 7) to indicat~ that the burst i~ a llteral repeat of a prevlou~ly-tran~mitted bur~t.
Som-times, DOM 52 receives acknowledge message 170, but 18 unable to ~uccessfully perform 5-of-9 votlng on the acXnowledge field 174 (this fiold is vot-d on a~`w-ll a~ proces~ed using conventional error chccklng routlne~ and embedded C~C codes to d-termine correct reception). In this case, DOM 52 cannot accurately determine which data packets 154a ln the la~t-tran~mittod data burst lSO were correctly received by DEN 56. Accordingly, DOM 52 aimply repeat~ the entire last-transmitted data burst lSO nd indicates that the data burst i8 a repoat via the repeat fields. If at any time a data bur~t 150 ia repeated and the mesJage is encrypted, the initialization vector (IV) used for the original data burst is also used for the repeated data bur~t.

' 41 If DEM 56 fails to correctly receive control fields within any data bur~t 1~0 (e.g., the initial data bur~t including preamble 158), it can regue~t DOM 52 to repeat the entire data burst. If DEM 56 requires DOM 52 to repeat the initial data burst, DOM 52 retran~mit~ preamble 158 along with all data packets 154 (if any) contained within the first data burst. If DEM 56 fail~ to reeeive the first data burst 150 altogether, it will not transmit an acXnowledge me~age 170 and DOM 52 will time-out waiting for a response. Any time DOM 52 time~ out waiting for a respon~e, it ~imply retransmits the last-tran~mitted burst (marking the repeat fields to indicate the burst iB a repeat). In the preferred embodiment, ~OM 52 "gives up" after it has tran~mittad a particular data burst 150 three times nd fails to receive any acknowledge mesJage 170.
Errors occurring in the preamble 158 or subpreumble 160 of a data burst 150 could prevent correct reception of the data burst (or the acknowledgo mo~sage 170 if the acknowledge message ~ubpreamble 160 includes errors). If DOM 52 receive~ an acknowledge message 170 and fail~ to correctly receive subpreamble 160, it simply times out and retransmits the last-transmitted data packet. If DEM 56 fails to correetly receive a data packet preamble 158 or subpreamble 160, it doe3 not transmit an acknowledge me~sage 170 in re pon~e to the data burst, and DOM 52 again time~ out and retransmits the last-transmitted data burst 150.

Exem~lary Data Structures - lZ83455 FIGURE 9 is a ~chematic diagram of exemplary data storage (buffering) structures used by the preferred embod~ment to tran~fer digital data between transmit/receive interface 92 and terminal interface 102. In the preferred embodiment, the data structures shown in FIGURE 9 are implemented, for the most part, by storing data in an external random accoss memory. In the preferred embodiment, all but tran~mit/receive lnterface 92, DES clrcuit 86 and terminal interface 102 shown in FIGURE 9 ~chematic block dlagram are data structure~ within a random acces~ memory rather than hard-wired, lndividual regi~ters and register files (although it will be undor~tood that the FIGURE 9 circuit could be implemented using hard-wlred registers if de~ired).
Data to be transmitted 18 lnputted to terminal 100 in the preferred embodiment, and is paQsed on to terminal interface 102. Commands inputted to terminal interface 102 aro loaded into a command buffer called PARSEBUFE 302 for decoding by control microproce~or 74. Digital data, on t~e other hand, i~ loadod into a fir~t in and first out (FIF0) regi~ter ile TXBUFF 304. TX~UFF 304 stores several packets o~ digital information (and preferably is large enough to ~tore the entire message).
The regi~ter TXDATABUFF 306 stores N (16 in the preferred embodiment) data packets 154 to be transmitted. These data packetc are either directly loaded into TXDATABUFF 306 from the "top" of TXBUFF
304 (if no encryption is required), or alternatively, are encrypted by DES circuits 86 before being loaded into TXDATABUFF. Another ~28345~i register, TXPREAMBUEF 30B, stores a preamble 158 (or subpreamble 160) to be transmitted as the "header"
portion of the to-be-transmitted data burst 150.
Control microprocessor 74 executes interrupt driven routines to format the contents of TXPREAMBUFF 308 before transmitting each data b~rst, as will be explained.
. The contents of TXP~EAMBUFE 308, and then the content~ of TXDATABUFF 306, are passed on to transmit/receive $nterface 92 (e.g., a byte at a time over data bus 76) for further signal proce~sing, filtering, and transmi~sion by tran~mitter 70.
In the recelve mode, transmit/recelve interface 92 receives bytes o data a~d loads the received bytes into either RXPREAM8UFF 310 (for header ~n~ormation) or RXDATABUFF 312 (for dlgltal data).
Once head~r inormation ha~ been loaded into req~ter 310, microproce~sor 74 decode~ the header informati~n and analyzes it. Dlgital data stored in RXDATABUFF 312 is loaded, (a data packet at a time) into a first-in-fir~t-out ~FIFO) register file 314 called PKBUFF (which stores 18 data packets in the preferred embodiment). Data ~n RXDATABUFF i 8 checked for being correctly received, a pac~et at a time. If a packet i8 correctly received, it iY
placed in PKBUFF, eonsecutively. If a pac~et i8 incorrectly roceived, a space is re~er~ed for it in PKBUFF. Once an entire block of lB data packets is stored in PKBUFF 314, data packet~ are tra~sferred via output register in TERMBUFF 316 to terminal interface 102 ~or di~play (or other proce99ing) by terminal 100.

~Z~ S

The tran~fer, manipulations, and processing of data by microproce~sor 74 and the blocks shown in FIGURE 9 will now be discussed in connection with flow charts showing exemplary microproces~or program control steps.
The procedure XMAIN shown in FIGURE 10 i8 the main "oxecutive" program which oversees the general operation of transceivers 52, 58 and monitors the ~tatus o tho transceivors. Thi~ routine is xecuted in a continuous loop, with microprocessor I/0 being serviced by interrupt driven routines ( ~hown in FIGURES 16-28).
Decision block 402 of FIGURE 10 determines whether the user has rocently inputted data via the display tsnminal 100. As mentioned previously, a u~or can input data by ~triking de~ired keys of tho data terminal keyboard indicating a transfer command and then depr-ssing the transmit (carriage return) key -- the d-p:e~ion o tho transmit key cau~ing the inputted command data to be tran~ferred to the microproco~or via a ~erial I/0 link (inter~ace 102) and ~tored ~n the buffer PARSEBUFF 302, and also cau~ing a flag within the microprocessor to be set.
If the user has recently inputted data to be transmitted, calculations are performed to initialize the message preamble 158 stored in TXPREAMBUFF 30B (block 404). In this step, the number of bytes in the message to be sent i~
counted, flags are set, etc. -- and the variou~
othor ield~ of the preamble are loaded into TXPREAMBUFF 308 (this process is actually performed over time by timer interrupt driven routines, as will be explained). For example, in block 404, a lz83455 ~ 45MR496 .. 4~

flaq indicating radio i8 a DOM is set. Otherwise, radio default state i~ a DEM. Because the steps performed by block 404 are required only once for each me~sage to be transmittet, they are byp~ssed if no new user message has been lnputted.
Decision block 406 determines whether the transceiver is busy either receiving or transmitting a-data burst 150. In the preferred embodiment, block 406 testJ the value of a ~busy~ flag ~et by block 404 or oth-r routinos. If tho flag i~ set ~lndicating that a message is to be or i~ being ~ont or that a me~sage i8 being received), blocko 408-414 aro executed. The "busy" flag indicates that the radio i~ ~n the process of transferring a data message between DOM and DEM. If the flag i8 not set ($nd~cating that no message is being transmitted or roceived), program control skips to block 416.
If decision block 406 determines that a message is being transmitted or received, decision block 408 tests anot~er flag to determine whether the tran~cei~er is acing as a data originating mobile, or ~DOM" 52. Th- message could be either a data burst or an acknowledgement as the ~OM tran~mits messages and receives ACK while a DEM receives a data burst and transmits ACK (in an RF senso of transmit and receive). If the tran~ceiver i8 originating a me~sage, a routine XDOM i8 called (block 410) -- th~ 8 XDOM routine performs the steps which cause data to be transmitted. Otherwise, a decision block 412 determinesif the transceiver is acting a~ a de~tination mobile, or "DEM" 56). If the transceiver i8 receiving a me~age, a routine XDEM (which performs steps to receive data and ~.Z83455 4 5~R4 9 6 process the received data) i8 called (block 414).
If the transceiver $8 not originating or receiving a me~sage, program control i~ tran~ferred to block 416.
Block 416 test3 whether the flag ALL DONE is set (indicating that the transceivcr was but no longer i~ bu~y). ALL DONE, when set, indicates if radio is finiJhed with the transmit or receive of entire me~sage, for both DOM or DEM (i.e., all data packets corr-ctly received by DEM). If this flag is not ~et, program control return~ to block 402. If the ALL DONE flag 1~ ~et, bloek 418 determines whether data terminal l00 l~ active. If the terminal is active, program control returns to block 402. On the other hand, block 420 returns the transceiver to the receive ~tate if the ALL DONE
flag is set and the terminal l00 is found to be inactive by block 4la. Block *20 also sets up transc~iver to once again allow a message from the terminal and clear~ DOM flag.
Routine XDOM ~block 410) ~shown in detail in FIGURES llA-llB) eontrol- the transceiver to tran-mlt a me~age. Thi~ XDOM routlne causes the tran~ceiver to transmit a data bur~t 150 containing ~ome or all of the digital data inputted by the user ~ia data termlnal l00. Thi~ data burst may contain all "new~ (i.e., not previously transmitted) packet~
of data, all "old" packets (which must be retransmitted because they were incorrectly received by the DEM), or a combination of new and old packets.
The XDOM routine determines if there are any new data packets (stored in TB UFF 304) which are part of the mes~age being transmitted and have not yet ~een tran~mitted. The XDOM routine also ~-Z83455 det~rmine~ (in response to receipt of an acknowledge me~sage 170) whether XDEM 56 (i.e., the destination mobile transceiver) has succe~sfully received the data packets of the data burst last transmitted, and controls DOM 52 to retransmit any packets which have not been successfully received (thus providing a funct~on which adapts to degraded transmission ch~nnel performance). A detailed flowchart of thiQ
routine i~ ~hown in FIGURES llA~
Decision block 502 checks to see whether an acknowledqe message 170 ha~ yet been received from DEM 56. As discussed previously, the DEM 56 tran~mits an acknowledge message 170 in response to each data burst 150 transmitted by the DOM -- this acknowledge message 170 indicating which data packet~ within the burst were successfully received and which packets were not ~uccessfully received. A
flag callod RXDONE is set by the microprocessor within the DOM when this acknowledge message 170 has been r-ceived. Declsion block 502 simply tests the value o thi~ flag. I no acknowledge message 170 ha~ been received, control steps ~umps to ~lo~k 518 (F~GURE llB) where DOM 52 processes data packets to be transmitted.
As the acknowledge message 170 is received, the DOM uses conventional error checking techniques (e.g., cyclical redundancy checks on the CRC fields contained in acknowledge message 170) to determine if the recei~ed acknowledge message i8 "valid" --meaning that its content can be understood by DON.
A~ each acknowledge sequence 174 is received, its validity is checked. Large amounts of noise on the RF channel might, for example, 90 corrupt the 12834~;5 ac~nowledge message 170 received by the DOM that the DOM cannot decode the received message to determine which data packets have to be resent. Another flag, called VALID ACK, is ~et by DOM 52 if the error checking function performed on a received acknowledge sequence 174 indicates that the signal can successfully be decoded to yield useful information (flag VALID ACK is not set otherwise).
Any one of the nine acknowledgement sequences can be received correctly.
If decision block 502 determines that an acknowledge Jequence 174 has been received, deci~ion block 504 determines whether the transmit buffer D ATABUFF must be filled w~th data from TXBUFF. In block 502, the flag FI~LTX3UFF, if set, indicates ~XDATABUFF need~ to be filled with new packet~ from TXBUFF. If not set, an acknowledge must be analyzed and possibly shuffle the packets in TXDATABUFF.
When set, a call to SHUFTX i8 not needed. When not sot, a call to SHUFrX must be done. FILLTXBUFF flag is sot mainly for first pass through XDOM to initlally flll TXDATABUFF for the first data burst.
If D ATABUFF must be loaded, block 506 clears the RXDONE flag (which was determined by block 502 to be set). Dectsion block 508 then determines whether the received acknowledge message 170 can be used to provide useful information `oy testing the value of the VALID ACK flag.
If the acknowledge message 170 cannot be doeoded to produco useful information regarding receive statu6, there is no way to tell whether DEM
received the data pac~ets in the last-transmitted data burst 150 correctly and therefore, the entire ~Z8345~

data bur~t contained in TXDATABUFF must be repeated. Block 510 simply sets the REPEAT fields in the data burst preamble to indicate that the burst is an e~act repeat of the last-transmitted burst.
If bloc~ 508 determines that the acknowledge signal can be decoded, a routine SHUFTX i~ called (~lock 512). The S~UFTX routine analyzes the acknowledge slgnal to determine which data packets in the last bur~t were incorrectly received by DEM, and "~huffle~ the~e incorrectly received packets to the ~top" of the TXDATABUFF ~o that they will be retransmitted as part of the next data burst. A
flowchart of thi8 routine i8 shown in FGURES
12A-12B.
Briefly, the routine SHUFTX must determine whether each unigue packet transmitted in the last burst was correctly received at lea~t once. A~
mentioned above, a given packet may be repeated several times in the ~ame burst -- and DEM need only recoive ono occurrence of the packet correctly to eorractly receivo the packet ~since it discards all lncorreetly reeelvod packets).
The routine SRUFTX includes outer and inner nested loops. The outer loop is controlled by a loop countor J, which is used to keep track of whether all unique packets in the last transmission have been tested for correct reception. The inner, nosted loop iB controlled by another loop counter I
-- which is used to keep track of whether all occurrences of a packet transmitted several times in the last tran~mission have been tested for correct reception.

~283455 4 5~1R4 9 6 The first step in the routine SHUFTX i8 performed by block 602, which initializes a pointer called NEXT FREE and sets outer loop counter J to the value 1. Block 604 then clears a nDONE~ flag and sets the value of inner loop counter I equal to the value of J.
Block 606 then determines from the received PACKET RX STATU5 field 176 (stored in RXDATABUEE
312) whether the Ith packet in the last-transmitted bur~t was correctly received. In the preferred ~mbodlment, the acknowledge Qignal (which 18 PACKET
RX STATUS fleld 176) iJ analyzed all at one tlme, and its contents are stored in a table called CRCMAP
(whlch ln the preferred embodiment ~ncludes a bit or each of the 16 packets in a burst, this bit being ~et if the corresponding packet was correctly recelvod and i8 otherwise unset).
Block 606 in the preferred embodiment retrieves the information about reception status for the Ith packet in the last-transmitted burst rom the table CRCMAP. If this retrieved blt i~ ~et, the corrQsponding packet doos not need to be r~transmitted and the done flag is set (block 610).
Otherwise, the SHUFTX routine determines whether the incorrectly received packet might have been transmitted more than once in the last transmission and correctly received at least once by DEM 56 (blocks 612-616).
Block 612 increment6 the value of loop counter I by the number of unique packets in the last tran6mission in order to locate the next occurrence (if there i8 one) o the packet determined by decision block 608 to have been incorrectly 1~8345~;
45~R496 .

race~ved. Dacision block 614 then determines whether the new value of I is greater than N, the total number of packets in each data burst. If I >
N (where N is the number of packets in each bur~t --16 in the preferred embodiment), then there are no remalninq occurrence~ o the packet to check, and the packet must be retran~mitted. In this case, block 616 ~ot~ the ~ONE flag, transfers the Jth packat to the ~top" of TXDATABUFF, and then increment~ NEXTFREE (tha pointer into TXDATABUFF) by 1 ~o that thi~ polnter now points to the ne~t free location in T D ATABUFF.
If decision block 614 determines that the incorrectly rac~ived packet was tran~mitted more than once and that an additional occurronce of the lncorrectly recaived packet may not yet have been chackad to detarmino wheth~r it wa~ correctly recaived, program control return~ to block 606 to analyze the ac~nowledqe ~iqnal with re~pect to anothor occurrenca of tha incorrectly received packet ~inco tbe dona flag has not yet been set, tha re~ult of the test of decision block 618 i8 fal~e). Otherwi~e, progr~m control proceeds to block 620, which increment~ the value of J by one (in preparation for examinin~ the receive status of another unigue packet transmitted in the last data burst).
Dacision block 622 determines whether the rece~ve status of all unique packets in the last data ~urst have been checked (preferably by comparing tha value of J with the number of unique packet~ in the last data burst). If all unique packets have now been checked, the flag FILLTXBUFF

128345~
. 45~R496 .. 52 i~ ~et (block 624) to indicate that the TXDATABUFF
buffer 306 is ready to be filled with new packets from TXBUFF -- and program control returns to block 514 ~hown in FIGURES llA-llB.
Program control returns to block 604 to check the receive Jtatus of the next (Jth) packet if decision block 622 determineJ there still are unique packets which havo not yet been checked.
Referring now once agaln to FIGURES llA-llB, after program control return~ from routine S~UFTX a docision block 514 determineJ whether there i~ any additional data in the present message which has not yet been transmitted (e.g., by teJting the value of a pointer which points into TXBUFE 304 and which is incremented as packets are transferred from that buffer to TXDATABUFF 306. If all data ha~ been tran~mitted, a 1ag called ALL DONE i~ Jet, the terminal i~ controlled to display a mes~age to the user that hi~ message has been successfully transmitted, and the flag FILLTB UFF i8 cleared (blocX 516).
Deci~ion block 518 then determines whether TXDATABUFF i~ full (e.g., by testing FILLTXBUFF
flag). If TXDATABUFF i8 not full, a routine called FILLTX i~ called to load packets of data from the TXBUFF register ~ile 304 in to TXDATABUFF 306 for transmission (block 520). A flowchart of the FILLTX
routine i8 shown in FIGURE 13.
Routine FILLTX first set~ up itg own pointer which points into the TXDATABUFF 306 ~blocX 702).
Declsion block 704 then determines whether it is possible to tran~mit any as-yet-untransmitted (i.e., ~new~) data packets in the next data burst. In the ~Z83455 preferred embodiment, block 702 compares tho value of polnter NEXTFREE, which points to the next free location in the TXDATA8UFE register file (and was set by the SHUFTX routine, block 616 of EIGURES
12A-12B). NEXTFREE is compared to NEWPACKET.
NEWPACKET was ~ent by DEM in the acknowledge message in the NEWPACKET field 184. Whenever NEXTFREE is 1~J~ than or equal to NEWPACXET there remains at least one additlonal unique packet which mu~t be loaded into TXDATABUFE 306 before tho next data burst 150 can be tran~mittod.
If at least one new packet must be provided, the routine FILLTX attempt~ to fill the empty packet(s) with not-yet-tran~mitted data (e.g., with ~new~ data).
If decision block 704 determines that previou~ly untransmitted packets can be transmitted in the ne~t data burst, decision block 706 determines whether any new packet~ exi~t. If at lea~t one new packet exist~, one packet of new information iJ loadod from TXBUFF 304 into TXDATABUFF 306 (dotting pattern is used to fill up this packet in TXDATABUFF if there is insufficient new data to do BO -- ~inco a user message can be of any arbitrary length and thus need not be on a 16 byte boundary).
Decision block 710 thon determines whether tho data burst stored in TXDATABUFF 306 iR filled. If the burst is filled, program control is transferred back to block 704, which determines whether it is posslble to transmit any additional as-yet-untransmitted (i.e., "new") data packets in the next databurst.

12834~5 On the other hand, if TXDATABUFF 306 is not filled, the variable NEXTF~EE is incremented by 1 ~block 712), and program control returns to decision block 704.
If deci~ion block 706 determines there are no new packets to transmit or block 704 determines that it i8 not possible to transmit any (or any additional) as-yet-untransmitted data packets in the ne~t burst, deci~ion block 714 determine~ whether the required number o packot~ (e.g., 16 in the proforred embodiment) are ready to transmit.
If at least 16 different packet~ are ~tored in TXDATABUEF 306 ready to transmit, no packets need to be repeated and control returns from the FILLTX
routine to block 522 of FIGURES llA-llB. If doci~ion block 714, on the other hand, determine~
that an $nsufflciont number of uniquo packets xi~t to orm a full data burst, blocks 716-720 copy the diferent packet~ a~ many time~ a~ nece~sary to re-ult in a number of pack~ts egual to N (e.g., 16 in the proferred embodiment).
Block 716 first clears the FILLTXBUFF flag, and then sets a pointor UNIQUE PACKET to point to tho la~t location in TXDATABUFF 306 filled with a data packet. (UNIQUE PACKET holds number of NEWPACKETS
DEM will accept.)Decision block 718 then compares tho value of pointer NEXTFREE with the value N (the roguirod number of packets). If NEXTFREE i8 1eS8 than or equal to N, block 720 copies the "top"
packet ~tored in ~XDATABUFF to the first empty location at the "bottom" of TXDATABUFF, and increments NEXTFREE by 1. Decision block 718 then check~ whether any additional packets are needed.

12834~

45~R496 If still additional packets are needed, block 720 cDpie~ the next unique packet from the top of TXDATABUFF (if ~uch a unique packet exists). Thi~
process continues until the number of packet3 stored in TXDATABUFF 306 i8 egual to N -- each unique packet being copied ~ times before any packet i8 copiod ~1 times.
When dQcision block 718 determines that no additional packet~ are needed to fill TXDATABUFF
306, progrum control ret~rns to the routlne XDOM
beginninq at block 522 of FIGURES llA-llB.
Decislon block 522 determines whether a preamble 158 or a subpreamble 160 i B to be transmitted. A long preamble, it will be recalled, 1~ transmitted at the beginning of each new message and also transmitted whenever the data format i8 to be changed. If a preamble 158 is to be sent, block 524 format~ the data in register TXPREAM~3UFF 308 ~ppropriately to eontaln tho preamble, and control~
the tran~celvcr to begin transmltting the data burst (which is now contained in TXPREAMBUFF 308 and TXDATABUF~ 306).
Decision blocX 526 then determine~ whether the data ln the data bur~t being transmitted has yet been sent. If the data transmission i8 not yet completed, program control return~ to the execute routine XMAIN shown in FIGURE 10. If all of the data packets have already been transmitted, block 528 controls the transceiver to begin transmitting the end of message (EOM) field 156.
Block 530 then te~ts whether the entire data bur~t ha~ been transmitted. If bur~t transmission i8 complcte, block 532 sets up the tran~ceiver for - ~28345~;

the receive state. Otherwise, program control roturns to XMAIN.
As mentioned previously, the FlGURE 10 routine XMA~N calls routine XDEM when the transceiver acts as DEM 56 (i.e., to handle received data burst~).
This XDEM routine is executed by DEM 56 (i.e., a transceiver acting as a destination mobile). The XDEM routine will now bo described in connection with the flow chart~ set forth in FIGURES 14A-14B.
Decision block 802 fir~t tests whether a hoader (pre~mble or ~ubpreamble) has been received by DEM
58, atored ln AXPREAMBUEF 310, but not yet analyzed. If a header has been received but not yet ~nalyzed, decision block 804 determines whether the heador i8 ~valid" (e.g., by'analyzing the CRC bytes ~nd performing error checking). If the received haader data i~ valid, decision block 806 tests whether the header i8 a preamble 158, and if lt is, lt e~tracts and analyze~ the data from tho preamble ~block 808;.
If a recelvod valid header is a subpreamble 160, microproce~or 74 typically does not need the hoader contents (although interface 92 makes use of the subpreamble to reacguire lost synchronization, for example). Control is thuJ transferred to doclsion block 810.
Decision block 810 determines whether a data burst 150 has been received and is ln RXDATABUFF
~e.g., by determining if a complete data burst i B in RXD~TABUFF and must now be analyzed). If a burst i8 currently being received, no data can yet be loaded into register file PKBUFE 314 (since in the preerred embodiment, data iR transferred into this ~z~34~;~

register file only when a complete data burst i8 stored in RX DATABUFF 312). On the other hand, if a data burst i8 not currently being received ~.e., 2XDATABUFF has a data burst in it, it i~ neceYsary to analyze the content~ of RX ~ATABUFF 312 for validlty, and trancfer valid data packets into register f~le PKBUFF 314. These ta~k~ are performed by routlne INPBFF, which i~ called by block 812 of FIGURE 14A.
A flow chart INPBFF is set forth in FIGURES
15A-15B. A pointer NEXTFREE i8 initlalized to the value of 1, and ~ flag called DONE ~ 8 cleared (block 852). Decis~on block 854 then determines whether the DON~ flag 18 ~et. If the DONE flag is not set, a data packet within RX DATABUFF 312 i8 analyzed by execution of blocks 856-864.
Pointer N%XTFREE is used to point into PKBUFF
314, NEXTFREE polnt~ to PKBUFF, and indicates the blt in PBMAP corre~ponding t the packet in PXBUFF.
Deci~ion block 856 compare~ the value of NEXTFREE to the ~ize PKBUFF register file 314, size of PKBUFF is the number of data packets PKBUFF can hold to determine whether there i 8 enough storage space within the register file to load into it a data packet contained within RX DATABUFF 312. If in~ufficient space exists within register file 314, program control i8 transferred to decision block ~66. Bl~c~ 858 get~ the bit pointed to by NEXTFREE
from the PBMAP. PBMAP i~ a bit map with 1 bit for every packet PKBUFF can hold. PBMAP keepc track of the correctly recelved packets which have been tran~ferred from RXDATABUFF to PKBUFF.
When routine INPBFF is first called, it checks PBMAP to find the first location of an unreceived packet. DEM ~knows" that the first packet in the current data burst from the DOM (if the packet was received correctly) should be placed in the first ~empry" location in PKBUFE, which NEXTFREE is pointing to.
For block B60, if the PBMAP bit which corresponds to NEXTFREE = 1, then that locat~on in PKBUFF is already filled with a data packet, so NEXTFREE is incremented and the bit corresponding to NEXTFREE i8 retrieved from PBMAP. This process continues until NEXTFREE = the size of PKBUFF (i.e., the number of data packets PKBUFF can hold) or until a bit in PBMAP = O.
The DEM uses PBMAP to keep track of the valid packet~ that are placed in PKBUFF, and where in PKBUFF tho packets are located, without using any packet numbers for the packets.
If the bit in PBMAP pointed to by NEXTFREE is zero, the DONE 1ag B62 is ~et to indicate that PXBUFF has space or at least 1 data packet, and the packet will go into the location pointed to by NEXTFREE. Otherwise, pointer NEXTFREE is incremented by 1 (block 864) and blocks 854-864 are executed again.
After blocks 856-864 are executed repeatedly until EITHER AN EMPTY LOCATION IN PKBUFF is found for a packet or NEXTFREE > PKBUFF size (i. e., all locations in PKBUFF have valid data packets), decision block 866 then tests whether the received data contained within RX DATABUFF 312 is a repeat (this test performed by simply testing the value of the REPEAT bytes within the received data burst).

~;~834~;5 .
.. 5~

If the received data burst i8 not a repeat, the variable UNIQUE PACKET is set to the ~alue of NEWPACKET. NEWPACKET is a pointer u~ed to indicate the number of new previously untransmitted DATA
PACKETS DEM can accept in the next data burst, unreceived data packet~ ~tored in RX DATABUFF Block 870 then clear~ NEWPACRET, and initializes the value of a loop counter I to 1. Loop counter I controls routine INPBFF to execute the sequence of ~teps contalned wlthin an outer loop of the routine oncè
for each different ~i.e., non-repeated) data packet contained wlthin RX DATABUFF 312.
Decision block 872 then compares the value o loop counter I with UNIQUE PACXET. If I is less than or equal to UNIQUE PACKET, packet~ remain to be loaded rom RX DATABUFF 312 into register file PKBUFF 314 -- and an inner loop counter J i 8 initialized to the value of loop counter I and a fla~ called DONE ls cleared (block 874). Loop counter J ls used aa a pointer into RX DATABUFF 312, and in particular points to repeats of an incorrectly-received data packet.
If the DONE 1ag was not set in 862, then PKBUFF has no room for any data packets. ~owe~er, DONE flag set in 862 i8 checked in 854 and signals first check of P~MAP is finished. DONE flag checked in 876 check3 another search instead -- that a correctly received data packet was found.
Otherwi~e, 80 long as J is less than or equal to N
(the number of data packets stored in RX DATA~UFF
312) (also tested for by decision block 876), the map bit result of the CRC test previously performed with respect to the Jth data packet is retrieved lZ834~

(block 878) and tested to qee if it is set (block 880) ln order to determine whether the Jth data packet was correctly received.
If the Jth CRC map bit is not set, the Jth data packet was incorrectly received, and in the preferred embodiment, it is next determined if this packet was repeated in the received transmission (~ince a later repetition of the same data packet m~ght h~ve been correctly received). Loop counter J
iB lncremonted by the value o the variable UNIQUE
PACKET (block 882), BO that it point~ to the next occurrence within RX DATABUFF 312 of the same data packet (if another occurrence e~ists). Decision block 876 then determines whether the new value of J
i~ less than or equal to N (since if J i8 greater than N, there are no more occurrences of the same data packet to be te~ted, and an acknowledge message 170 mu~t be ~ent by DEM 58 to DOM 52 requesting that thiQ data packet be retransmitted).
If, on the other hand, decision block 8ao determines that the Jth data packet was correctly roceived, the DONE flag is set (block 883), the Jth data packet i~ transferred from RX DATABUFE 312 to PKBUFE 314 (block 884) at the location in PKBUFF
pointod to by NEXTFREE, and a bit corre~ponding to the Jth packet in a data structure called PBMAP is ~et (block BB6) (this PBMAP data structure is used to indicate which valid data packets have been stored into register file PKBUFF 314).
If the DONE flag is ~et or J is greater than N, decision block 87~ transfers program control to decision block B8B. Decision block 888 tests the value of the DONE flag to determine whether it was 128345~i 45~1R496 set by block 883 (the DONE flag was cleared by block 874). If the DONE flag wa8 set at deci~ion block 883, the Jth data packet i8 valid (i.e., correctly received). If decision block 888 determines that the DONE flag i8 not set, then block 890 increments the variable NEW PACKET (used to indicate the number of previously-untransmitted data packets which can be accepted in the ne~t data burst transmission).
Nbxt, the pointer NEXTFREE is incremented, and thQ DONE flag is cloared once agaln (block 892). If NEXTEREE is les~ than or equal to PKBUFF size, then P~MAP can still be checked to determine i PKBUFF
can accept any more data packets.
If ~11 bits in PBMAP have not been checked, the PBMAP> bit corresponding to tbe pointer NEXTFREE is toRted to determine whether it was Qet, indicating that the corresponding location in PKBUFF already is f~lled by a valid, previou31y received data packet.
NEXTFREE i8 incremented if the PBMAP bit corre~ponding to NEXTFREE i~ set (block 900), QO
that block~ 894-898 can search for the next empty storage location in register file 314.
Once deci~ion block B98 locates the next empty ~torage locat~on in PKBUFF (as tested for by decision block 898), the DO~E flag is ~et (block 902), and decision block 894 transfers program control to block 904 -- which increment~ loop counter I and returns program control back to decision block 872.
At some point, loop counter I incremented by block 904 80 that it exceed~ the number of unique packets tran~mitted in the last data burst (i.e., the variable I will either point beyond the last ~Z834~iS

45~R496 data packet storage location within RX DATABUFF 312, or it will point to a repeat of a data packet transmitted more than once). When decision block 872 determines that I exceed~ UNIQUE PACKET, declsion block 906 determines whether there are any more storage locations within register file PKBUFF
314 which must be checked to see if these locations ar~ empty or contain previously received data packet~.
If all location~ ln PKBUFF have been checked by u~lng PBMUP ~i.e., NEXTFREE > PACXET BUFF S IZE), th-n routine INPBFF returns to block 814 of the XDEM
rout~n~ shown in FIGURE 14A. If all locations of PKBUFF have not been checked as to whether or not they contain data packets, then decision block 90~
determlnes whether the value stored in NEWPACKET is les~ than the number N of packet~ within a data burst. If NEWPACKET i8 lecs than N, then block~
910, 912 determine whether the data packet corresponding to pointer NEXTFREE i8 already ~tored in register file 314 (and if it is, NOT NEWPACKET is incremented at block 914). If the location i8 empty, then PRBUFF can accept a packet there --hence NEW PACKET is incremented. Pointer NEXTFREE
is then incremented (block 916), and the test performed by decision blocks 906, 908 occurs again until all locations of PX3UFF have been checked. By this process, the number of new packets which can be accepted ln the next data burst transmission is counted based on the number of packets already stored in PRBUFF register file 314. This number of new pac~ets which can be accepted is returned to routine XDEM in variable NEWPACKET.

1283~5S

, 45MR496 Referring once again to FIGURE 14A, the contents of register TX PREAMBUFF 308 is initialized u~ing the acknowledge message format shown in FIGURE
8 -- with the contents of statu~ field 176 being specified according to CRCMAP bits, and the contents of NEWPACKET field 184 being specified by the value stored in variable NEWPACKET (block 814). Then, it is determined whether any data packet~ Rtored in reg~ster file 314 can be transferred to output regtstor TERMBUFF 316 while preserving the order of the received data packets, and if it i~ possible to do ~o, a data packet i8 loaded into the output register 316 for communication over data bus 76 to terminal interface 102 (blocks 816, B18, 820).
Ne~t, the acknowledge message 170 now stored in registers 306, 308 i~ transmitted via tran~mit/receive interface 92 ~block 822).
If a data bur~t i~ not in RXDATABUFF(as tested or by decision block 810) or if an acknowledge me~sage has been or iJ being tran~mitted (by block 822), then decision block 824 determines whether an end of mes6age field needs to be transmitted at the end of an acknowledge mesqage -- and block 826 begins transmitting an end of message string i necessary.
Next, decision block 828 determines whether a complete acknowledge message 170 has been transmitted and if it has, decision block 830 determines whether all data packets for the entire meRsage were correctly received. If a complete, valid data burst has been received, the ALL DONE
flag is set (block 832). ALL DONE flag indicates that no more data packets should be sent by DOM. If ~283455 the ALL DONE flag is set and the PKBUFF register file 314 is not empty (as tested for by decision block 834), data pac~ets are transferred from the register P~BUFF file into output buffer TERM~3UFF 316 until the output register is full (block 836, decision block 838), and the ~ontents of the output register are tran~ferred to TERMINAL INTERFACE 102.
Routine XDEM then returns program control to routine XMAIN.
FIGURES 16-19 are ~chematic flow charts of serial interrupt-driven I/O routines used in the preferred embodiment to control the operation of the TE~MINAL INTERFACE 102. These rout~nes effect the transfer of data between data terminal 100 and the rost of the transceiver. FIWRE 16 is a schematic diagram of the main ~erial interrupt handler routine.
It iB nece~ary to transfer data from terminal interface 102 to PMSEBUFF 302 and TXBUFF register file 304 -- and to tran~er data from the output ~uffer ~ERM3UFF 316 to the data terminal. The routine GETDAT called by the FIGURE 16 interrupt routine block 925 ~and shown in detail in FIGURE 17) takes care of the transfer from data terminal interface 102 to register 302 and register file 304 upon receipt of a data byte ~decision block 927).
The ~erial interrupt occurs everytime the microprocessor 74 receives a byte over its serial port.
If the transceiver acts as DEM 58 (as tested for by block 929) it may be requi.ed to transfer data fro~ output register TERMBUFF 306 to terminal 100 for display, storage or other purposes. The 12834~;

45~1R496 routlne OUTDAT (block 931 -- shown in detail in FIGURE 19) transfers bytes of information from TERMBUFF 316 over data bu~ 76 to data terminal interface 102.
The T~MMSG routine (block 933; see EIGURE 18) is called by the FIGURE 16 interrupt routine when transceiver is a DOM. It transfers 1 of 2 ~canned"
me~sages to data terminal interface 102 for display on terminal 100.
Referring to FIGU~E 17, the routine GETDAT
communicates data from terminal interace 102 (via a serial port of the microproces~or) to TXBUFF 304. A
~erial int~rrupt i8 to/from the microprocessor and the terminal interface 102.. The serial interrupt, and routines GETDAT, OUTDAT, and TRMMSG describe the microproce~sor ~ide of operation. LOOK command b~t i~ sct whenever the transceiver is fir~t initialized and the radio i8 restored in block 420 of FIGURE
10. Dec~sion block 952 tests the value of this LOOK
command bit when an interrupt occurs.
If the LOOK command bit is set, then the be~inning of a new line of te~t poQsibly i8 being received, and decision block 954 determines whether the first character recei~ed from data terminal 100 iB the "start~ character (the ESC character in the preferred embodiment). If the first character is not the ~start" character, the interrupt is ignored -- and it is assumed that the user mistakenly depre~sed a key.
If the byte received is the "~tart" character, then a flag i8 set indicating that the transceiver is acting as a DOM 52 (decision 95B), and the LOOK
command bit is cleared (block 95B). In addition, a lX834~;5 bit is set to indicate that data terminal 100 is active (block 960), and flags GETMSG and MSG 1 are both set to indicate (upon a later call to the FIGURE 16 interrupt routine) that the microprocessor is sending a "canned" message for display on the data terminal. This megsage is not a data burst message. The ~teps involved in sending the MSG 1 data stream are begun (block 964), and a counter i~
~nitialized in preparation for counting the number of data bytes in the m~s~age (block 966).
If deci~ion block 952 determine~ that a transceiver i~ not "looking" for a command character inputted via data terminal 100 (because the transceiver already recognizes that a me~sage is being inputted, or because the interrupt was erroneou~ly generated or generated due to another cause), a decision block 968 determines whether the GETMSG fla~ wa~ previously set by block 962. If this flag was not previously set, then the interrupt i8 ignored. If this flag waR previously set, then the interrupt i8 caused by yet another byte inputted via data terminal 100 which is to be added to a message to be transmitted, and decision block 970 tests whether the incoming byte is an "end o mes~age" character (a carriaqe return in the preferred em~odiment). If an end of message character is received, then the flag GETMSG is cleared and a flag called STA~TUP is set to indicate that the entire me~sage has been stored in TXBUFF
304 and i~ ready to be put into TXDATABUFF 306 (block 972). If the byte is not the end of message character, then the byte is transferred into register file TXBUFF 304 (block 974).

. 67 The T~MMSG routine handles the transfer of one of two "canned" messages from the DOM to data terminal 100, to be displayed on the terminal.
The DOM ~tarts to send MSG 1 from block 9~4 of the GETDAT routine, after it ha3 determined that the data terminal has a data me~sage for the DOM to transmit to a DEM. MSG 1, when displayed on the terminal, tells the user to start entering the data moJsage at the terminsl.
The DOM starts to ~end MSG2 from block 516 in the XDOM routine, after it has determined that the DEM succe~fully received all data packet~ in the data message. Therefore, NSG 2 informs the user that the data message ha~ been ~uccessully received by the DEM.
If decision 980 determines that data terminal 100 i~ active, then it i8 determined whether MSG l i~ currently being tran~mitted (decision 982). If MSG l ls not currently being transmitted, then docision block 984 determines if MSG 2 i8 being transmitted. If neither MSG l nor MSG 2 are being transmitted, then no bytes of a mes~age need to be c~mmunicated from the DOM 52 to data terminal 100 and the routine T~MMSG is exited. On the other hand, if either MSG l or MSG 2 is ~einq ~ent, then it ~8 determined whether all ~ytes of the message being transmitted have alresdy been transmitted (decision bl~cks 9~6, 9~ f the currently-transmitted message has already been completely transmitted, then the appropriate flag ~MSG l if message MS~ 1 is being transmitted; MSG 2 if messsge MSG 2 i~ bein~ tran~mitted) is cleared.
~f MS~ 1 is finished, GETMSG flag is set (~lock 1~83455 990). If MSG 2 is finished, TERMACTIVE flag i8 cleared, (block 992) to ~ignal that the microproce~sor's serial transmit port is no longer active. If MSG 1 ha~ fini~hed, the GETMSG flag i8 set to indicate that the DOM microproces~or i~ ready to accept the data me~sage to place into TXBUFF 314, (block 990). On the other hand, if a message i~
currently being sent and bytes of the me~age remain to be transmitted, the next byte of the meJsage i8 tranoferred from the DOM to the data terminal ~blocks 994, 996).
The routine OUTDAT shown in FIGURE 19 effect~
the transfer of data from TERMBUFF 316 to terminal interface 102 for display or other procesJing (e.g., storage) by data terminal 100. Routine OUTDAT fir~t determines (block 998) whether data terminal 100 is active (e.g., by te~ting a flag). If the data terminal i 8 not activQ, then no data need~ to be ~ent to it, and the OUTDAT routine i8 exited. If data terminal 100 i~ active, then the contents of TERM3UFF 316 are te~ted to determine whether data to be communicated to data terminal 100 is ~tored in that buffer (decis~on block 1000). If TERMBUFF 316 is not empty, then a byte of data i~ retrieved from TERMBUFF and sent to data terminal interface 102 (block 1002). If TERM~UFF 316 is empty, on the other hand, then a flag indicating that data is being sent to the data termlnal is cleared (block 1004) and it i~ then determined whether all data in from all pac~et~ the me~sage has been 6ent to the data terminal (decision block 1006). If all data ha~ been Qent to the terminal, then the terminal active flag previously tested by decision block 998 8345~;
45rlR496 i~ cleared to indicate that the data terminal i8 no longer active (block 1008). If all data has not been ~ent to the data terminal, the terminal active flag remains ~et, and TERMBUFF will be filled with more data packets on next pass through XDEM.
Control microproces~or 74 also ha~ interrupts applied to it which are generated by tran~mit/receive ~nterface 92 (sometimes called a ~modem"). Tran~mit/receive interface 92 generates an interrupt ~ignal whenever it receive~ a byte of data from receiver 72 and al~o whenever it has transferred a byte of data for transmission by transmitter 70. When microprocessor 74 receives an interrupt from transmit/receive interface 92, it executes the interrupt routine "modint~ shown in EIGURE 20.
M~croprocessor 74 first determlnes whether the transceiver is in the tran6mit or in the received mode (block lOS0 ~hown in FIGURE 20). After performing ~everal additional tests, microprocessor 74 "pushe~" modem vector address bytes onto an internal ~stack" at 1200, these modem vector address byte~ containing the address of the routine which is to handle the tran~fer of one byte to/from transmit/recelve interface 92. Control microprocessor 74 then executes a return (not a return from interrupt) 80 the control automatically vectors to and executes the appropriate routine the address of which is specified on the internal stack. a return from interrupt occurs after the handlin~ routine has finished.
All handler routines either transfer one byte to the modem chip or receive one byte from the modem ~Z83455 chip. Any additional processing on the byte received or transmitted may also occur in the particular handler. Then the handler routine performs a RETURN FROM INTERRUPT. Thus a handler routine may be e~ecuted many times before a different handler routine takes over.
The ~se of the vector address is a coding technique to ~ump to a specific routine without u~ing a CALL command. Those familiar with 8031 mlcroprocessor code will recognize this technlgue.
Sinc~ the tranQmission or receptlon of data occurs in a specific order (i.e., dotting, pr~amble or ~ubpreamble, data packets, EOM) when one section ls finished the next section to proceQs is known, ~nd the vector address is set up in the preceding routine.
The routine modint (FIGURE 20) is set up for receive (a default ~tate) unless STRTTX (FIGURE 20A) i~ called to start data transmission. Hence modem voctor address i~ set to the routine RCVENT
initially. (See flowchart of RCVENT in FIGURE 20B).
Subroutlne STRTTX (FIGURE 20A) is not a part of the modem interrupts per ~e -- ~nstead it is called from main routines to ~tart tran~mitting data.
Subroutine STRTTX i8 called by the DOM from the XDOM
routine block 524 to start transmitting the dotting of a data burst. STRTTX ~8 also called by the DEM
from the XDEM routine block 822 to srart transmittlng the dotting for an acknowledge message.
Th~ STRTTX routine initializes transmit/receive interace 92 for the tran~mit mode and, the flag TXMODE i~ set to indicate that the transceiver is in the transmit mode. A byte of dotting ~101010...) is ~28~45~i transforred to transmit/receive interface 92 and a byte counter value is initialized to 1 (this byte counter simply count~ the number of bytes transferred to transmit/receive interSace 92).
~e~t, the microprocessor modem vector address is set to the starting address of the routine TXDOT (which effects transmission of the dotting portion 162 shown in FIGURE 5) and command returns to the calling routine.
The modem interrupt handler vectors to TXDOT
when dotting i~ being transmitted, the FIGURE 24 routine TXDOT send~ a byte of dotting to interSace 92 (block 1066) and increments the byte counter.
Ne~t, the value of the byte counter is tested to determine if it is equal to-48 (decision block 106B) -- since if it is, 384 bits of dotting have been transmitted and the dotting pattern transmission has been completed. E~tra dotting is sent to allow the transmitter to turnover. If decision block 1068 detcrmines more dotti~g needs to be transmitted, it ~imply returns Srom the modem interrupt (block 1070). On the other hand, if the dotting pattern transmission is over, the byte counter is cleared and the microprocessor 74 modem vector addres~ is ~et to the routine called TXAMBLE which effects transmission oS the preamble 15B (block 1072) or the subpreamble 160. Then it returns from the modem interrupt.
The modem interrupt handler vectorc to TXAMBLE
when the preamble or subpreamble i8 being transmitted. The routine TXAMBLE is shown in FIGURE
25. In the preferred embodiment, the format for preamble 158 or subpreamble 160 is stored ~2~3345~

inTXPREAMBUFF 308. The FIGU~E 25 TXAMBLE routine simply reads out stored preamble/subpreamble pattern, one byte at ~ t~me from TXPREAMBUFF, and transfers those pattern~ to transmit/receive interface 92 (block 1074). Once a complete synchronization ~equence 158 ha~ been transmitted (as tested for by decision block 1076), a GROUP
COUNTER which keep~ track of the number of synchronization seguences 158 already transmitted i8 incremented (block 107a) and deci~on block 1080 tests whether 12 repeatJ of synchronlzatlon se~uence 158 have been tran~mitted. If less than 12 ~ynchronizations seguence repeats have been transmitted, a return from interrùpt i 8 performed to give transmit/receive interface 92 time to process the byte communicated to it by block 1074. If all 12 repeat~ of synchronization sQquence 158 have transmitted, then decision block 10B2 tests whether the transceiver is acting as a DOM 52. If radio i8 DOM, TXHDR i8 ~ent only if the flr~t data burst is ~ent. If not fir~t data ~urst data packets are sent immediately after the subpreamble. If the transceiver i8 acting as a DOM, then the next step is to transmit IV/SS seguence 166 in the next modem interface interrupt, so block 1084 causes the microprocessor 74 modem vector address to be set to a routine called TXHDR (see FIGU~E 2~) which transmits the IV/SS sequence 166. On the other hand, if the transceiver is acting as DEM 58, the preamble just transmitted preceded an acknowledge message 170, and the microprocessor modem vector address is set to the beginning address of the routine TXACK ~see FIGURE 27) which transmits the ~Z~34~5 45~R49 re~t of acknowledge me~sage 170 (block 1086). A
return from interrupt then occurs.
The routine TXHDR shown in FIGURS 26 i8 re~pon~ible for effecting tran~mission of IV/SS
sequence 166. Block 1088 effects transmission of the guardband, initialization vector and selective signalling fields of IV/SS sequence 166. Decision block 1090 tests tbased on the value of the byte counter used to keep track of the number of byt2s already tran~mitted) whether an entire repetition of the guardband, initiallzation vector and selective cignalling words have already been transmitted (blocks 1090, 1092). Blocks 1094, 1096 effect tran~mission of the CRC field within the guardband.
In addition, block 1096 clear~ the value contained in the byte counter after each repetition of the IV/SS sequence 166 has been transmitted, and increment~ a GROUP COUNTER u~ed to keep track of the number of repetitionR of the ~V/SS ~equence which have been transmitted. Deci~ion block 1098 determines whether all 9 repeats of the IV/SS
~equence have already been transmitted, and if they have been, block 1100 ~tore~ the beginning addres~
of routine T D ATA into the microprocessor 74 vector addre~.
The routine TXDATA shown in FIGURE 28 effects transmi~ion of data packet collection 154 by DOM
52. The FIGURE 28 TXDATA routine i8 executed after header portion 152 has been transmitted.
Deci~ion block 1102 ~hown in EIGURS 24 test~
whether the byte counter (which keep3 track of the number of byte~ of the data packet being transmitted) is less than the number of bytes per ~8345~i packet (i.e., the value M). ~f the byte counter i8 le~s then M, a byte of data i8 transferred from D ATABUFF 306 to transmit/receive interface 92, and the byte counter i8 incremented (block 1104~. Also, C~C i8 calculated (see FIGURE 28). If the byte counter i8 not le~s than M, then decision block 1106 checks whether the byte counter is egual to M
(indlcatlng that the byte 1~ the last byte in the currently-transmitted data packet). Block 1104 chocks whether the byto counter is less than M. ~f the ~yte counter 18 equal to M, the low byte of the CRC field at the end of each data packet is transmitted by block 1108, and the byte counter is lncromented.
on the next pass of the TXDATA routine, the byte counter will e~ceed by 1 the value of M, and block 1110 i8 exocuted to transmit the high byte of the CRC fleld, clear tho byte counter and increment tho GROUP COUNTER (in thl3 routine the GROUP COUNT~R
~ od to ~eep track of the number of data packets which have been transmitted).
Next, decision block 1112 determines whether the GROUP COUNTER i~ equal to N (the number of data packets in each data burst). If the value of the GROUP COUNTER is less than N, more data packets are to be transmitted in the current data burst and a return from interrupt occurs (block 1114). If the value of the GROUP COUNTER i8 equal to N, the microprocegsor moBem vector address is set to the boginning address of the routine TXDOT (to start to tran6m~t the end of message field 166) and an end of meRsage flag is also set (block 1116). EOM field is started in modem interrupt, EOM is transmitted ~283455 "directly" by XDOM or XDEM routine.
Referring once again to FIGURE 25, if decision block 1082 determine~ that the transceiver is a DEM, then the ac~nowledqe message 170 shown in ~I~URE 8 must be transmitted, and the control microprocessor 74 vector~ to the routine TXACK set forth in FIGURE
27. ~ecision block 1118 tests the value of the byte counter to determine whether an entire repetition of the acknowledge field 174 ha~ been transmitted. If the entlre acknowledgo field ha~ not yet been transmitted, block 1120 transfers a byte of data from TXDATABUFF 306 to transmit/receive interface 92 (lndicating, e.g., the packet receive status or a part of message field 178).
When a packet or a status fleld 176 and message field 178 have been completely transmitted (as tested for by block 1122), blocks 1124, 1126 transmit CRC field 180, clear the byte counter, and increment the GROUP COUNIER (in this routine, the GROUP COUNTER i~ used to count the number of rep~titionJ of acknowledge field 174).
Deci~ion block 1128 determines whether acknowledge field 174 has yet been tran~mitted 9 times. If the acknowledge field ha~ not yet been transmitted 9 times, a return from interrupt occur~
~block 1130) ~o that upon the occurrence of the next interrupt, the routine TXACK will be entered once again to transmit the rest of acknowledge ields 174. If 9 repetitions o acknowledge field 174 have already been transmitted, block 1132 clears the GROUP COUNTER, and sets the microprocessor 74 vector addre~ to the beginning address o ro~tine TXDOT
(which starts to transmit the end of message field ~X83455 156).
FIGURE 21 is a flow chart of the routine RXE~R, which performs the task of receiving header portion 152 when the transceiver acts as a DEM 58. Decision block 1220 keeps track of the number of bytes of the header 152 which have been received, and block 1222 perform~ the tasks of transferring information from tran~mit/receive interface 92 to RXPREAMBUFF 310;
performing error checking functions on the received ~ytes; and incrementing the byte counter (thereby keepinq track of the number of bytes of header which hav~ been received). When an entire repetition of the header has been received (decision block 1220), then decision block 1224 determines whether the received data is free from errors. If the received data is free of errors, then it is determined whether a flag called valid header 18 already set ~lf it i~, an error-free header has already been received for this message) (block 12~6). If this is thQ first valid header which has been recei~ed in the current me~sage, then block 1228 sets the valid hoader 1ag. Block 1230 clears the byte counter and increments the GROUP COUNTER in preparation o another repeat of the header. When all o the header repeat~ have been received (as tested for by block 1232), a pointer is initialized to point into RXDATABUFE 312 and the microproce~sor 74 modem vector address is set to the beginning address o the routine RXDATA set forth in FIGURE 22 -- both in preparation of receiving data packet collection 154 (block 1234).
The routine RXDATA set forth in FIGURE 22 tran~fer~ data packet collection 154 from ~Z8345~;
45'`1R496 transmit/receive interface 92 to RXDATABUFF 312.
Decision block 125() keeps track of the number of bytes of the dats packet currently being received which have already been received, and block 1252 performs error checking on the received data bytes as they arrive and also transfer~ the received data bytes into RXDATABUFF 312. When decision block 1250 determines that an entire data packet has been received, deci~ion block 1254 determines whether the data packet was rec-ived without error (bas~d upon the re~ult~ of tho error checking performed by block 1252) and set~ a bit accordingly ~blocks 1256, 1258). Block 1260 then ~tores the error-indicating bit into the CRC map discussed earlier, and block 1262 clQars the byte counter Deci3ion block 1264 then determines whether all N data packets of the current me~sage have already been received. If the current mes~age i~ not yet completed, a return from interrupt occurs (block 12~6) 250 that the next time the routine RXDATA is entered, and an additional byte o the ne~ct data packet will be received. If all N data packets have been rec-ived, block 126B
~ets a flag called RXDONE to indicate that the entire message has been received, and interrupts are disablod to prevent the routine MODINT from being called until after the acknowledge me~sage ha~ b~een tran~mitted The routine RXACK set forth in FIGURE 23 and u~ed by the DOM performs the tasks of tran6ferring received acknowledge message~ 170 from transmit/receive interface 92 to RXDATABUFF 312.
Deci~ion block 1300 keeps track of the number of bytes of the acknowledge signal which have received, ~ 45MR496 .. 7~

and block 1302 actually trangfer3 acknowledge message bytes from interface 92 to RXDATABUFF 312 (as well as performing CRC error checking on each byte as it is received, and incrementing the byte counter). When decision block 1300 determines that an entire acknowledge field 174 has been received, decision block 1304 tests whether the received acknowledge field i error-free based on the CRC
r~sult~ calculated by block 1302. If the received acknowledge field i8 error-free and this is the first error-free acknowledge field which has been received in this mes~age (as tested for by block 1306), a flag called VALIDACK is set and the contents of packet RX status field 176 from the correctly-received acknowledge field is loaded into the CRC map data structure (block 1308) (this CRC
map data structure is used by DOM 58 to determine which data packets were incorrectly received by DEM
sa and have to be retran~mitted). Block 1310 reinitializes the byte counter and GROUP COUNTER in preparation for receipt of the next repeat of acknowledge field 174, and decision 1312 determines whether all acknowledge field repeats have been received. When all acknowledge field repeats have been received, block 1314 sets a flag called RXDONE
to indicate that the entire acknowledge message 170 has been received.
One important feature of this invention is that the CRCMAP is used to communicate the status of packets received by the DEM. No pac'~et number~ are transmitted with the packets sent by the DOM. Nor are packet numbers sent by the DEM in the acknowledgement. The use of the CRCMAP reduces the 12834~;5 . 45~R496 .. 79 overhead on the number of bit sent in either mes~age (acknowledge or data). Thus helping to achieve the effective data rates earlier ment~oned herein.
A digital radio transmitting and receiving ~ignalling protocol and associated system has been described which has a very low error rate per bit, i- adaptive to deleterious communication3 channel p~enomena such as noise and fading, and is compatible with a prior protocol. While the pre~ent lnvention has been described with what is pre~ently considered to be the most practical and preferred embodimcnts, it i 8 to be understood that the ~ppended claims are not to be limited to the disclo~ed embodiment~ but on the contrary, are intended to cover all modifications, variations and equivalent arrangement~ which retain any of the novel features and advantages of this invention. By way o non-limlting example, although the preferred embodimQnt of tho present invention includes radio transceivers, the invention could be used with a transmltter, a receiver or other radio communications device.

Claims (20)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. A method for reliably and quickly exchanging bursts of digital data packets between a first site and a second site, said method comprising the steps of:
(a) transmitting a plurality N digital data packets from said first site to said second site;
(b) checking for the correct receipt of all N packets at said second site;
(c) transmitting a binary code N-bit map of digital data from said second site back to said first site identifying any data packets not yet correctly received at said second site;
(d) retransmitting at least such identified data packets, if any, from said first site to said second site; and (e) repeating said steps (b)-(d) until all N-packets have been correctly received at said second site.

2. A method of transmitting digital signals from a data originating digital radio transceiver over a RF communication channel to a destination digital radio transceiver, said method comprising:
(a) transmitting, from said data originating transceiver to said destination transceiver over said RF channel, a plurality N of successive data packets in a first data burst;
(b) receiving said first data burst with said destination transceiver;
(c) determining at said destination transceiver which of said N data packets were correctly received by said destination transceiver and which of said data packets were incorrectly received by said destination transceiver and transmitting a bit map from said destination transceiver to said source transceiver specifying at least said incorrectly received, packets; and (d) retransmitting, from said data originating transceiver to said destination transceiver, a further data burst including N
successive data packets, said further data burst data packets including said incorrectly received data packets and no correctly received ones of said data packets of said first data burst.

3. A method as in claim 2 further including the steps of transmitting an acknowledge message from said destination transceiver to said originating transceiver over said communication channel, said acknowledge message indicating which of said data packets within said first data burst were correctly received and which of said data packets within said first data burst were incorrectly received.

4. A method as in claim 2 wherein:
said method further includes the step of transmitting an acknowledge message from said destination transceiver to said originating transceiver over said communication channel in response to receipt of said first data burst by said destination transceiver, said acknowledge message including the results of said determining step; and said retransmitting step includes the step of selecting data packets for retransmission in response to said acknowledge message.

5. A method of transmitting digital signals from a data originating digital radio transceiver over a RF communication channel to a destination digital radio transceiver, said method comprising:
(a) transmitting, from said data originating transceiver to said destination transceiver over said RF channel, a plurality N of successive data packets in a first data burst;
(b) receiving said first data burst with said destination transceiver;
(c) determining at said destination transceiver which of said N data packets were correctly received by said destination transceiver and which of said data packets were incorrectly received by said destination transceiver and transmitting a bit map from said destination transceiver to said source transceiver specifying at least said incorrectly received packets; and (d) retransmitting from said data originating transceiver to said destination transceiver, a further data burst including N
successive data packets, said further data burst data packets including said incorrectly received data packets and no correctly received ones of said first data burst data packets, wherein said retransmitting step includes retransmitting each of said incorrectly received data packets plural times, none of said incorrectly received data packets being retransmitted more than one time more than any other of said incorrectly received data packets is retransmitted.

6. A method of transmitting digital signals from a data originating digital radio transceiver over a RF communication channel to a destination digital radio transceiver said method comprising:
(a) transmitting, from said data originating transceiver to said destination transceiver over said RF channel, a plurality N of successive data packets in a first data burst;
(b) receiving said first data burst with said destination transceiver;
(c) determining at said destination transceiver which of said N data packets were correctly received by said destination transceiver and which of said data packets were incorrectly received by said destination transceiver and transmitting a bit map from said destination transceiver to said source transceiver specifying at least said incorrectly received packets; and (d) retransmitting, from said data originating transceiver to said destination transceiver, a further data burst including N
successive data packets, said further data burst data packets including said incorrectly received data packets and no correctly received ones of said first data burst data packets, wherein:
said method further includes the step of transmitting an acknowledge message from said destination transceiver to said originating transceiver over said communication channel in response to receipt of said first data burst by said destination transceiver, said acknowledge message including signals indicating the results of said determining step; and said retransmitting step includes the step of selecting data packets for retransmission in response to said acknowledge message and retransmitting each of said selected data packets multiple times x until N data packets have been transmitted in said further data burst, none of said selected data packets being transmitted more than x +
1 times.
7. A method of transmitting digital signals from a data originating digital radio transceiver over

Claim 7 continued:
a RF communication channel to a destination digital radio transceiver, said method comprising:
(a) transmitting, from said data originating transceiver to said destination transceiver over said RF channel, a plurality N of successive data packets P(1) - P(N) in a first data burst;
(b) receiving said first data burst with said destination transceiver;
(c) determining which of said data packets P(1) - P(N) were correctly received by said destination transceiver and which of said data packets were incorrectly received by said destination transceiver;
(d) storing said correctly received data packets into a buffer capable of storing a maximum of Q data packets;
(e) calculating the number X of new packets P(N+1) - P(Q) which can be stored in said buffer while reserving space in said buffer for said incorrectly received data packets;
(f) transmitting an acknowledge message from said destination transceiver to said data originating transceiver, said acknowledge message indicating the data packets which were incorrectly received by said destination transceiver and the number of new packets said buffer can store in addition to said incorrectly received data packets; and (g) retransmitting, said data originating transceiver to said destination transceiver, a further data burst including said incorrectly received data packets and said number X of new data packets, said incorrectly received data packets being repeated in sequence until the number of data packets in said further data burst totals N, none of said data packets within said further data burst being repeated more than one time more than any other data packet within said further data burst.

8. A transceiver for sending and receiving digital control and digital data signals over a communication channel, said transceiver comprising:
transmitting and receiver means for transmitting and/or receiving a succession of digital signals; and control means connected to said transmitter and receiver means and including a digital data microprocessor system programmed so as to control said transmitter and receiver means to process said digital signals occurring in substantially the following time sequence:
(a) a preamble portion having:
(1) an alternating 1,0 dotting pattern, (2) twelve repeated sets of (i) a 16 bit synchronization word S
including a multiple bit Barker code, (ii) a 16 bit outside address word OA
including a multiple bit sequence repeated at least once, said outside address word indicating whether a later-processed string of digital data includes digitized voice signals or other types of digital signals, (iii) a 16 bit sync number code (identifying which of 12 repeats is involved), (3) nine repeated sets of (i) a 64 bit guard band, (ii) a 64 bit cryptographic initialization vector, (iii) a 16 bit selective signalling code identifying the intended message recipient(s), (b) a plurality of successive data packets each including a string of digital data, said data repeating either digitized voice signals or other types of digital signals, an 8 bit repeat byte (indicating whether said successive data packets are repeats of previously-transmitted packets) separating some of said data packets, and (c) an end-of-message work signifying the end of a given message.

9. A transceiver as in claim 8 wherein said control means processes said 64 bit guard band by processing digital signals in substantially the following sequence:
(a) a 4 bit command code indicating a task to be performed, (b) a 1 bit NP code (indicating if said plurality of successive data packets are not present in a given message), (c) a 1 bit mid command execution control bit, (d) an 8 bit sub-group source code SUBGS
(indicating the transceiver generating said message), (e) an 8 bit sub-group destination code SUBGD (indicating, in conjunction with said selective signalling signals, the intended recipient of said message), (f) a 6 bit BPP code indicating the number M
of bytes of digital data in each of said plurality of data packets, (g) a 6 bit PPB code indicating the number N
of said plurality of successive data packets, (h) 14 additional bits of digital signals, and (i) 16 bits of error checking signals.

10. A method for reliably and quickly exchanging data bursts of digital data packets over an RF communications channel between a data transmitter and a data receiver, said method comprising the steps of:
(a) transmitting a plurality N of discrete digital data packets from said transmitter to said receiver without transmitting identifications for each of said discrete packets;
(b) checking for correct receipt of all of said N packets at said data receiver;
(c) transmitting a binary coded N-bit map of digital data from said data receiver back to said data transmitter, said map identifying which of said N
packets have not yet been correctly received by said data receiver without expressly identifying said incorrectly received packets;
(d) retransmitting said identified packets from said transmitter to said receiver; and (e) repeating said steps (b) - (d) until all of said N packets have been correctly received by said data receiver.

11. A method as in claim 10 wherein said transmitting step (c) includes transmitting said N
bits of said map in a sequence corresponding to the sequence said transmitting step (a) transmits said N
packets, each of said N bits corresponding to one of said packets.

12. An arrangement for reliably and quickly exchanging data bursts of digital data packets over an RF communications channel between a data transmitter and a data receiver, said arrangement comprising:
means for transmitting a plurality N of discrete digital data packets from said transmitter to said receiver without transmitting identifications for each of said discrete packets;
means at said receiver for checking for correct receipt of all of said N packets; and means connected to said checking means for transmitting a binary coded N-bit map of digital data from said data receiver back to said data transmitter, said map identifying which of said N packets have not yet been correctly received by said data receiver without expressly identifying said incorrectly received packets, wherein said first-mentioned transmitting means is also for retransmitting plural versions of said identified packets from said transmitter to said receiver plural lines and said checking means is also for checking for correct receipt of at least one of said plural retransmitted versions of each of said retransmitted packets until all of said N packets have been correctly received at least once by said data receiver.

13. An arrangement as in claim 12 wherein said bit map transmitting means includes means for transmitting said N bits of said map in a sequence corresponding to the sequence said packet transmitting means transmits said N packets, the positions of said N bits corresponding to and associated with said N
packets.

14. A method for exchanging of data bursts of digital data packets over an RF communications channel, comprising the steps of:
(a) transmitting a data burst from a source RF transceiver to a destination RF transceiver, said data burst comprising a number N of discrete digital data packets, N being greater than one;
(b) testing for correct receipt of said N
digital data packets at said destination transceiver;

(c) in response to said testing step, transmitting an acknowledgment message from said destination transceiver to said source transceiver, said acknowledgment message identifying at least which of said N packets were incorrectly received; and (d) in response to said acknowledgment message, transmitting a further data burst from said source transceiver to said destination transceiver, said burst comprising said number N of discrete digital data packets, including the step of repeating each of said incorrectly received data packets a sufficient number of times in sequence to provide N
packets.

15. A method as in claim 14 wherein said transmitting step (c) comprises transmitting a binary coded bit map comprising N bits corresponding to said N packets, a one-to-one correspondence existing between said N bits of said bit map and said N packets in the last transmitted data burst.

16. A method for reliably and quickly exchanging bursts of digital data packets between a first site and a second site over an RF communications channel, said method comprising the steps of:
(a) transmitting a plurality N digital data packets from said first site to said second site;
(b) checking for the correct receipt of all N packets at said second site;
(c) transmitting a binary coded N-bit map of digital data from said second site back to said first site identifying which data packets were correctly received at said second site;
(d) retransmitting the data packets, if any, not correctly received at said second site from said first site to said second site in response to receipt of said map; and (e) repeating said steps (b) - (d) until all N packets have been correctly received at said second site.

17. A method as in claim 1 wherein said transmitting step (c) comprises transmitting a binary coded bit map comprising N bits corresponding to said N packets, a one-to-one correspondence existing between said N bits of said bit map and said N packets in the last transmitted data burst.

18. A method as in claim 2 wherein said step (c) includes transmitting a binary coded bit map comprising N bits corresponding to said N packets, a one-to-one correspondence existing between said N bits of said bit map and said N packets in the last transmitted data burst.

19. A method as in claim 5 wherein said step (c) includes transmitting a binary coded bit map comprising N bits corresponding to said N packets, a one-to-one correspondence existing between said N bits of said bit map and said N packets in the last transmitted data burst.

20. A method as in claim 6 wherein said step (c) includes transmitting a binary coded bit map comprising N bits corresponding to said N packets, a one-to-one correspondence existing between said N bits of said bit map and said N packets in the last transmitted data burst.