JPH012435A - Method and apparatus for transmitting digital data over wireless communication lines - Google Patents

Abstract

(57) [Summary] This bulletin contains application data before electronic filing, so abstract data is not recorded.

Description

DETAILED DESCRIPTION OF THE INVENTION Relationship to Related Applications This application is filed under pending U.S. Patent Application Ser. It is related to

FIELD OF THE INVENTION This invention relates to digital radio frequency communication systems and, more particularly, to communication protocols for transmitting and receiving digital signals over radio frequency communication lines.

BACKGROUND AND SUMMARY OF THE INVENTION It is well known to communicate digital control and message data signals over wireless communication links. For example, U.S. Patent Nos. 4,027,243 and 4.369.44.
No. 3, No. 4.434,323, No. 4.322,5
No. 76, No. 4,267.592, No. 3.801.
No. 95'6, and No. 4,41L 425.

U.S. Pat. No. 4,027,243 describes a digital message generator for digitally controlled radio transmitters and receivers in wireless communication systems. In this communication system, means are provided for achieving word and bit synchronization in each stable series of digital command messages transmitted between radio station locations.

Pending U.S. Patent Application Ser. A signal format is described that provides capability, late join, word and crypto synchronization recovery, and protection against fading and noise. FIG. 1, illustrating the prior art, shows the preferred time order of digital signals transmitted and received in the communication system described in this U.S. patent application. For details of this digital signal order, please refer to the specification of this US patent application, but the order shown in FIG. 1 will now be briefly described.

The digital signal sequence shown in FIG. 1 is a preamble followed by one or more data frames. The preamble contains data for dot/frame synchronization, repeater addressing, cryptographic synchronization, and selective communication control. A data frame has its own synchronization data as well as a digitized encrypted voice signal or other data signal.

The prior art form of communication, shown in Figure 1, involves transmitting certain information repeatedly, either in the preamble or at regularly spaced points in an encrypted audio data stream, over radio frequencies. Allows the receiver to initially synchronize with the transmitter, even with the normal Rayleigh order fading expected in communication lines (if the Brianbundle is "dropped" or if its decoding is successful). This allows for "later joins" (if the message did not exist) and/or recovery of synchronization (if the synchronization initially achieved in the preamble is subsequently lost before the end of the message).

In the communication protocol shown in Figure 1, initial frame synchronization,
Continuous frame synchronization, repeater addressing, crypto synchronization, and selective communication signals are all transmitted repeatedly with a relatively long preamble section to protect against fading, as well as subsequent encrypted voice data. - It is also retransmitted repeatedly at regularly spaced points in the stream. Due to the placement and repetition of the various control fields in the protocol of FIG. 1, this protocol has a very high probability of obtaining correct initial synchronization and addressing functionality.

The preamble part of the communication protocol in Figure 1 is (a)
dot pattern, (b) a synchronization order that includes repeated groups of synchronization signals, and (c) an initialization vector (IV) and selective communication (SS) order (which includes repeated selective communication signals, initial Setting vector and guard band (G
B) including a data signal).

Each data frame of the FIG. 1 protocol has a "header" portion, a message portion, and an end of message portion. The header part contains the synchronization order and isomorphism of the IV and SS order transmitted in the preamble part. The message portion contains the digital signal (eg, encrypted voice data) to be communicated. The transmitted message ends with an end of message (EOM) word that includes a sync field and a dot pattern.

The dot sequence in the preamble portion of Figure 1 is a pattern of alternating ones and zeros (e.g., 1010
1010...) is preferable. This dot pattern indicates that the circuit in the receiver of the communication method
To enable bit synchronization to be achieved quickly.

The synchronization order that appears after the dot pattern in the preamble portion consists of three repeated fields: a 16-bit synchronization word “S” (preferably 111000
11-bit Barker like 10010
) address code and 5 bits of "fill" or dots) and an 8-bit "outer address J (OA
), repeated 3 times to complete the third 16-bit field (with the second repetition in complement form), and finally a 5-bit synchronization number with one odd parity code bit added. (SN).

The repeated IV and SS sequences that follow the synchronization sequence include a 64-bit guard band (GB), a 64-bit initialization vector (IV), and a 16-bit selective communications address (SS). In the conventional protocol shown in Figure 1, the 64-bit Gartband GB provides protection against fading and is not used to convey useful information), and the 64-bit IV field is used for ordinary DES.
(This is described, for example, in the Data Encryption Standards, Federal Information Processing Standards, Publication No. 46, United States Department of Commerce, NTIS, 5285 Port Royal Road, Springfield, VA 2216L). do. A 16-bit selective communication field SS provides group and individual selective communication capabilities within the wireless communication network (i.e., an "address" identifying a particular individual or group of receivers may be used in this field). ).

The IV, GB and SS fields are repeated nine times in the protocol of FIG.

Preferably, the preamble is followed by successive data frames, each of which includes a sub-preamble (heading) portion and successive bits of a digital data signal (eg, encrypted audio data).

Heading is synchronization word S1 outer address field O
A. Initialization vector IV and optional communication address S
Contains one repetition of S. Each heading section contains information on incoming messages or conversations that can be joined later, and/or lost frames or cryptographic synchronization (e.g., fading or multipath interference in typical radio frequency communication lines). Sufficient information is provided to enable resetting (which may occur due to temporary loss of signal, etc.). The synchronization maintenance control function of the receiver monitors the header of the ongoing received data frame and can re-establish bit synchronization, frame synchronization, crypto synchronization and selective communication controls from the header portion alone.

An end of message (EOM) signal is generated at the end of a message transmission to alert the receiver that the message has ended.

The communication protocol of Figure 1 has been very successful and can be used at sufficient data rates and with very low probability of error over wireless (or other) communication lines that are subject to fading, noise, and other phenomena. To enable extremely reliable digital signal communication. However, further improvements are possible.

For example, while the communication protocol of Figure 1 is designed to communicate encrypted digitized voice data (although not limited to communicating this type of information), it is not limited to communicating encrypted digitized voice data or pure data such as data terminal equipment. It is desirable to selectively communicate digital information provided by a digital signal source, as well as to provide communication control signals within the communication protocol that inform the receiver of what type of message information is being communicated. There is a great need for wireless transceivers that are capable of conveying not only voice information, but also digital information generated by data terminal equipment or computers. Although the protocol shown in Figure 1 is not limited to voice data communication (messages, data,
(virtually any type of digital data can be conveyed within a frame), and a transmit indicator signal indicating the type of data being transmitted allows a receiver to manipulate the received digital information in an appropriate manner. (For example, converting the data to an audible analog signal for application to a speaker, or leaving the data in digital form for display on a data terminal device or storage in a computer's memory).

Further improvements in error-free transmission at high data rates are also possible. An effective data rate of 3600 baud on an error-free line is desired. This effective data rate drops to about 2400 baud on a 1.0% BER line without RF fading. On a 1.0% BER, non-fading line, the probability of receiving a 9600-bit message incorrectly should be on the order of 0°0001; if the line has typical fading, this probability is 0. It should not increase above about 0.01.

The communication protocol should have some ability to adapt to deleterious phenomena (eg noise and/or fading) present on the communication line. When communication lines are affected by noise and/or fading, it may be necessary to repeat the same data many times to ensure accurate reception.
Such repetition reduces the effective data rate and may not be necessary when communicating signals over optimal links with little or no fading and noise. If the receiver has a problem receiving a particular data packet, the transmitter should somehow adapt and repeat that packet. ``Overhead'' on the line used to communicate control signals rather than useful data signals - Data packets should be repeated more times as the communication's bit error rate increases without noticeably increasing traffic It is.

Furthermore, such an adaptive shadow signal format may be compatible with the conventional communication format shown in Figure 1 (and thus with existing communication devices such as repeaters and mobile transceivers designed to communicate using this protocol). It is desirable to have compatibility.

These and other features of the invention will be more fully understood from the following detailed description of the presently preferred embodiments with reference to the drawings.

Overall Scheme FIG. 2 is a schematic diagram of a digital wireless communication scheme 50 of the presently preferred embodiment of the invention. The communication system 50 includes a data originating mobile digital wireless communication transceiver (hereinafter referred to as DOM) 52, a relay wireless communication transceiver (repeater) 54, and a destination digital wireless communication transceiver (hereinafter referred to as DEM) 56.

DOM 52 transmits digital data to DEM 56 via repeater 54 (operating on one or more scheduled radio frequency communication lines).

Upon receiving the transmitted data burst, the DEM
56 confirms the reception of the data and sends a confirmation signal indicating whether the data was received correctly.

Send to M52.

DOM 52 transmits digital φ data, formats the digital data into a predetermined communication format, and modulates a radio frequency carrier signal with the formatted digital data to generate RF data bursts. These radio frequency data bursts are transmitted from DOM 52 to repeater 54 via RF communications link 58 (which in the preferred embodiment is a selected RF communications line).

A repeater 54 receives, detects, and regenerates the data burst to a DEM (destination mobile station) 56 via a radio frequency communication link 60 (preferably another selected RF communication line).
to resend. A DEM 56 receives the regenerated and retransmitted RF data burst, demodulates it, and extracts the digital data signal it carries.

Each data burst transmitted from DOM 52, relayed by repeater 54, and received by DEM 56 has N (preferably 16 or 32) data "packets", each of which has M (preferably has 64 or 128) bits of digital signal information. Each packet in a data burst may be unique or identical to each other in the preferred embodiment, depending on several different factors (as explained below). .

DOM 52 (via repeater 54) DEM
After sending the data burst to 56, in the preferred embodiment, the DEM responds by sending a "confirmation" message. This message has one bit corresponding to each packet in the data burst that identifies which packets in the data burst transmitted from DOM 52 were received correctly, and
It consists of a bit Φ map that indicates how many new packets can be received. This confirmation message is received at repeater 54 (via RF link 60);
It is detected, regenerated, retransmitted from the repeater, and received at DOM 52 (via link 58). The received confirmation message at least partially determines which data packets DOM 52 transmits in the next data burst in sequence.

In the preferred embodiment, DEM 56 acknowledges each data burst it receives by sending an acknowledgment message. In the preferred embodiment, the transfer of data bursts includes (1) transmissions from DOM 52 to DEM 56, and (2) response (handshake) transmissions from DEM to DOM.

The first data burst in the message sent by DOM 52 initializes repeater 54 and DEM 56 and contains some special information (e.g., "outer address"
and “initialization vector”). After DOM 52 sends this initial information, it sends a data burst containing N data packets. After transmitting the first data burst, DOM 52 waits to receive a confirmation message transmitted from DEM 56. Based on the content of the received confirmation message, DOM 52 can retransmit another data burst containing some or all of the data packets it has already transmitted, or it can retransmit N data packets that were not previously transmitted. A new data burst can be sent containing a data packet of . This process continues until the entire digital message to be sent is successfully received and verified by the DEM.

Wireless Transceiver In the preferred embodiment, DOM 52 and DEM 56 are identical, each having the configuration shown in FIG. This figure is a simplified block diagram of a preferred digital wireless communication transceiver (which can act as a DOM or a DEM, as controlled by the user). Next, regarding Figure 3, DOM 52 and DEM
The configuration and operation of 56 will be explained.

The transceiver shown in FIG. 3 is a conventional radio frequency transmitter 70.
and a radio frequency receiver 72 (or any other communication line transmitter and receiver, such as the transmit and receive lines of a common wireline modem). As shown in Figure 3,
The transceiver may communicate with one or more repeaters or other transceivers or base stations via radio frequency or other forms of communication links.

The transceiver shown in Figure 3 is in "clear" mode or "
It can operate in either "Confidential" mode.

In "Confidential" mode, the data to be transmitted is encrypted using the Data Encryption Standard (see NTIS FIPS Publication No. 46), and similarly, the received data is encrypted using DES before outputting from the transceiver. be deciphered.

Specifically, a microprocessor circuit receives a conventional input signal (e.g., from a microphone or audio amplifier, etc.) and converts it into a cryptographically encoded stream of digital signals that is input to a modulator in transmitter 70. Convert to On the receiving side, the stream of digital signals generated at the output of the detector of receiver 72 is finally decoded and converted to an output signal before being routed to the conventional receiver's audio output circuitry (e.g., audio amplifier, speaker, etc.). ) will be sent to.

The overall configuration of the microprocessor control system shown in FIG. 3 is generally conventional. The heart of the system is a control microprocessor 74 (eg, an Intel 8031 integrated circuit chip), which communicates with other digital circuits via an internal data bus 76 and an external data bus 78. The ordinary buttonstalk (PTT) switch 80 is
If desired, it can be considered as one line of the control bus 78. This system uses ordinary codecs (COD
EC> 82 (e.g., an Intel 2916 integrated chip) and a digital signal processor (DSP) suitably programmed to convert the audio signal to digital/analog form and vice versa according to well-known audio digitization and processing algorithms. , (for example, NEC7
720 integrated circuit chip).

The transceiver of FIG.
According to the invention described in No. 98, a hybrid subband coding scheme can be used. The data encryption standard is constituted by a DES circuit 86 (eg, an MC6859 integrated circuit chip) and a conventional DES key memory 88. In order to physically implement the program control structure appropriate for the system shown in Figure 3, a suitable conventional RO
An M circuit 90 (eg, 4 kilobytes) is also provided.

Transmit/receive interface circuit 92 is sometimes referred to as a "modem" circuit, and may also be of conventional design. It preferably has a bit recovery circuit of the type described in US Pat. No. 4,382.298. U.S. Pat. 4゜02
See also No. 7.245.

As one skilled in the art will appreciate, in order to process the stream of digital output signals prior to sending them to the modulator of transmitter 70,
Preferably, a conventional Gaussian minimum shift key (GMSK) filter 94 (eg, a Bessel type 4th order low pass filter with a cutoff frequency of approximately 7 kilohertz, measured at 3 dB) is provided.

The output of the receiver 72 (eg, from the FM discriminator) is also preferably passed through a conventional limiter circuit 96 to eliminate the effects of DC bias that would otherwise be present at the receiver's discriminator output. For example, as one skilled in the art will readily appreciate, limiter 96 may utilize a simple comparator that compares the instantaneous incoming signal from receiver 72 to a moving average value over a relatively short period of time. I can do it.

In addition to transmitting and receiving voice information, the transceiver shown in FIG. 3 can also transmit and receive digital data signals generated by data terminal equipment 100. Data terminal 100 is preferably a conventional digital data terminal including a keyboard or other input device and a display or other output device. Data terminal equipment 100 is connected to data terminal interface 102, which interfaces the data terminal equipment with bus 76 and transceiver control bus 78.

The operator using the transceiver of FIG. or other digital message) and read the received digital body message on a display device associated with the data terminal equipment (or otherwise control the data terminal equipment to process the received signals). You can choose.

The transceiver of FIG. 3 transmits digital information generated by or sent to data terminal equipment 100;
A distinction can be made between audio information generated by a microphone or sent to an audio output circuit. Furthermore,
The transceiver of FIG. 3 encrypts the digital data transmitted by the data terminal device 100 before transmitting it, or encrypts the received data before applying the received data to the terminal device 100. can be deciphered.

Using a transceiver similar to the one in Figure 3,
Aspects of transmitting and receiving audio signals are disclosed in pending U.S. Patent Application Ser. No. 6, filed October 17, 1984.
It is described in detail in No. 61.733. In the present invention, the transceiver of FIG. 3 uses a communication protocol compatible with the protocol shown in FIG.
00 and receives digital data for display or other processing by a data terminal.

Communication protocol
ol) FIG. 4 is a diagram illustrating the general format of a digital data burst 150 transmitted by DOM 52 in the presently preferred embodiment of the invention. Burst 150 has three parts: (a) header part 152, (b) data packet collection part 154, and (c) end of message (EOM) part 156.

Heading portion 152 includes Bits, Frames and Cryptographic Synchronization;
It has signals used for things such as selective addressing (more on this shortly). Data packet assembly part 1
54 contains a "packet" of digital signals representing the message to be conveyed. End of message 15
6 includes a signal indicating the end of data burst 150.

In a preferred embodiment, heading portion 152 has either a preamble 158 or a sub-preamble 160. Because data bursts 150 have a predetermined length, multiple data bursts 150 are required to send one message of digital data (messages can have any length). It may be necessary.

Each data burst contains only a portion of the message. Interchanger 54 and DEM 56 must be turned off and synchronized with DOM 52 before transmitting messages. Preamble 158 is ・DOM
52, bit synchronization between repeater 54 and DEM 56;
Establishing frame and crypto synchronization (as well as selectively addressing individual or groups of DEMs)
It has the necessary signals (to perform other functions as well).

To increase the effective bit rate, preamble 158 is transmitted only at the beginning of a message transmission (e.g., at the beginning of the first transmitted data burst 150 containing the first part of the message), but may be transmitted as needed (e.g. , may be sent during one or more subsequent data bursts (to indicate that a change in data format occurs in the middle of the message transmission). Sub-preamble 160 contains some of the same initialization information that is in preamble 158, but is much shorter than the preamble (so that the effective data rate can be maximized). Sub-preamble 160 is transmitted at the beginning of each data burst 150 after the first burst in the preferred embodiment.

FIG. 5 is a schematic diagram of the preamble portion 158, which includes (a) dot order 162, (b) synchronization order 164, and (b) synchronization order 164.
/') Contains IV/SS order 166.

In the preferred embodiment, synchronization order 164 and IV/SS order 166 are each repeated multiple times in preamble 158 to ensure proper recognition and to protect against fading.

Dot order 162 (96 bits of dot pattern,
For example, 101010...) allows repeater 54 and DEM 56 to efficiently establish bit synchronization with DOM 52.

The synchronization order 164 has a synchronization word S1, an "outside address" word OA, and a synchronization number word SN.

In the preferred embodiment, the synchronization word S is a digital word with a length of 16 bits used to set up the synchronization, specifically 5 bits of padding or dots (e.g., 10 bits).
11, such as 11100010010, preceded by 101)
Barker code of bits.

The outer address word OA is 8 bits long in the preferred embodiment and is repeated in complemented form immediately after being transmitted in its original form for a total length of 16 bits. In the preferred embodiment, this outer address word OA indicates whether the message being transmitted has digital data or digitized audio. That is, in the presently preferred embodiment, the digital value contained in the outer address word OA is set to 55AAH'' if the message contains digitized audio; 'AA55
It is set to "H".

The synchronization word SN has the repetition number of the "group" (of the synchronization word S and the outer address word OA) to which this synchronization word SN is associated. In the preferred embodiment, this group is repeated twelve times in the synchronization sequence 164 (the synchronization word SN indicates the number of each repetition). Sync word SN
has a protective effect against fading and DE
M 56 helps determine whether preamble 158 was received correctly.

In the preferred embodiment, the I V/S S order 166 is (
It has a) guardband field gb, (b) initialization vector (IV), and (c) optional communication word SS. IV carries decoding information and word SS carries selective addressing signals. In one example, the guardband field has only dots or other padding and is used to provide protection against fading during transmission of IV/SS sequences. However, in another configuration currently considered preferred, the outer address field OA
Instead (or in addition), the guardband field is used to convey information that allows repeater 54 and DEM 56 to distinguish between digital data messages and digital voice messages.

In a preferred embodiment, the IV/SS of preamble 158
00M52 to D through the guardband in the communication order
Instructions can be passed to the EM 56 as well as from the DEM to the DOM. Figure 5A shows a preferred form of guard band.

In the preferred embodiment, the guardband contains commands, selective addressing, format control, error checking, and other information. Specifically, the guardband consists of the following fields: 4-bit command field 190.1-bit NP (not participating) field 192.1-bit MC (command central execution) field 194.8-bit 5UBGS
(Subgroup source) field 196.8 bits 5U
BGD (subgroup destination) field 198.6 bits BPP (bytes per packet) field 20
Includes a 0.6-bit PPB (packets per burst) field 202, a 14-bit working field 204, and a 16-bit CRC (error checking) field 206.

The 5UBGS and 5UBGD fields 196° 198 are used in conjunction with the SS field to provide selective addressing. In the preferred embodiment, the SS field is used to select a group of wireless transceivers and
The GS and 5UBGD fields select a subset within the group.

The 5UBGD field specifies the subset of the group that will receive the message (ie, the DEM that is supposed to receive the message), and the 5UBGS field specifies the subset of which the transceiver from which the message originated is a member.

In the preferred embodiment, the number N of data packets per data burst 150 is preset for any given message, and the number M of bytes per data packet is also the same.

In a preferred embodiment, these preset numbers N and M are not fixed, but can be varied as desired depending on a number of different factors (e.g., message length or message content). .

In the preferred embodiment, the BPP field 200 indicates the number of bytes per packet (M) and the PPB field 202 indicates the number of packets per data burst (N).
shows.

The guardband working field 204 has a maximum of 14 bits, which is used to convey parameters associated with the command indicated by the command field 190. C
The RC field 206 contains the usual CRC error checking information that protects the entire guard band.

The NP and MC fields '90.192 are 1-bit control fields used to convey specific control information. When set, the NP bit indicates to the receiving transceiver that the current data burst 150 is
Informs that the packet is not being served. When set, the MC bit drives the receiving transceiver to change the format in the middle of the message to the format specified by the other guardband fields.

Returning to Figure 5, TV/SS order 1
The initialization vector (IV) in 66 has a conventional initialization vector of 64 bits in length as required by data encryption standards to establish cryptographic synchronization between DOM 52, repeater 54, and DEM 56. used for. In the preferred embodiment, the selective communication word SS is 16 bits long and can be used (along with the Gartband field 196.198) to selectively call individuals or groups using the same DES cryptographic key. I can do it.

The SS field (along with the SUBGS and 5UBGD fields 196 and 198 in the guardband) provides true selective communication capability within the cryptographic communication network. 1
The 6-bit SS field and the 5UBGD field can, for example, represent a group of users where each individual address selects a particular user, so that users with the same cryptographic key can access each transceiver in a particular network. The call can be further restricted to individual or group reception. S
The S field and 5UBGD field are also encrypted,
Selective communication among a group of users with the same DES key can be facilitated without giving any information to users (or eavesdroppers) with different keys.

Preferably, the word group containing the guard band, light setting vector, and SS word is repeated nine times to provide protection against fading. As previously mentioned, the preferred embodiment utilizes "9-5" voting to parse the ■V/SS data order 166 that is repeated nine times. For example, at the receiver, each of the nine sequential CB/IV/SS data fields is voted bit by bit based on at least a 9-5 scheme. If at least 5 out of 9 of these received signals do not match exactly,
DEM 56 concludes that the reception of preamble 158 is incorrect and requests retransmission from DOM 52.

If at least 5 times are "voted on" (ie found to be a match), the voting result is stored and used as the correct IV/SS vector for cryptosync and selective communication.

FIG. 6 is a schematic diagram of the exemplary sub-preamble portion 160 shown in FIG. Sub-preamble part 160
has a dot portion 1 62 and a synchronization order 164, but does not have an IV/SS order 166. The sub-preamble 160 repeats the outer address OA of the synchronization order portion 164 in uncomplemented form (in contrast to the outer address O A of the synchronization order 164 of the preamble 158
A is repeated in complement form). DOM 52, repeater 54, and DEM 56 use this feature to identify preamble 158 and subpreamble 160 (i.e., the transceiver ensures that the repeated outer address OA is the same as the first occurrence of that address word). If the transceiver receives the outer address word followed by its complement, then the transceiver has received the preamble 158).

FIG. 7 shows the data packet assembly part 164 shown in FIG.
This is a schematic diagram. Data packet assembly 164 has N data packets 154a, where N is an integer multiple of eight in the preferred embodiment. In a preferred embodiment,
Each data burst 150 has the same N data packets 154a, with each data packet 154
M data pins with the same number of a!・Have (however, the 5th
Using the guard bands shown in Figure A, N and M can be specified for different message transmissions).

During any particular transmission of data burst 150, data packets 154a may consist entirely, or some data packets may repeat from others. At the beginning, middle, and end of the data packet assembly 154, "repeat" (R) bytes are sent. This byte indicates that the data burst 150 as a whole is
Indicates a repeat of a previously transmitted data burst.

For example, if the DOM 52 does not receive a correct confirmation from the DEM 56, it repeats the last transmitted data burst 150 (and this literally repeats the data burst, the contents of the repeat field R indicates that the transmitted burst is repeated). ). DOM 52 also repeats the last data packet sent if the DOM cannot determine which data packet to send next due to an error in the received confirmation message.

Each data packet 154a has M data bytes followed by a 16-bit cyclic redundancy check (CRC) field (or other desired error detection field). The total number of bits in the data packet assembly 154 is 24+(MX8+16)XN, where N1+
8 is the number of bits in each data packet 154a, N is the number of data packets in each aggregate 154, 16 is the number of bits in each CRC field, and 24 is the number of bits in each CRC field. This is the total length of field R. Therefore, the data packet assembly part 15
The time required to send 4 is the data transmission speed of 9,
For 600 baud, time - (24 + (MX 8 + 18)
XN)/9600.

Processing Commands Referring again to Figure 5A, the preamble guardband command field 190 contains (or can contain) commands to be executed by the receiving transceiver. The commands controlling the transceivers 52 and 56 are:
By inputting commands to data terminal equipment 100 and/or preamble 158 preceding data burst 150 (which may, but need not have, data packets) or confirmation burst 170. It can be issued by sending a command using the guard band. For commands input manually via the data terminal device 100, commands input via the guard band (this must be bit efficient)
Uses a slightly more specific format for commands than . Next, we will explain the format of commands from the terminal device (Gartband commands simply change the format of the terminal device directly from decimal to 2
(converted to decimal notation).

The command interface is divided into six commands. A command indicates the type of data to be transferred (ASCII or binary) or controls the flow of data (setting the format or stopping a current function). Each command is preceded by a control symbol that resets the command bird buffer so that a new command can be entered. The instructions are shown below.

Transfers ASCII bytes until code XPERA O5TOP command is received.

XFERB l Transfer a fixed number of binary bytes (0 to 2047 bytes).

XPERLA 2 Transfers one line of ASCII data at a time until a 5TOP command is received.

FORMAT 3 Specify the data format.

byte/packet, package Butto/burst and voting.

5TOP 4 End the current command (X
(excluding PERB).

NULL No number To abort the data of the current entry, cancel the current data entry used by XPERB and reset the command bar buffer.

RHTRANSMIT Unnumbered Retransmit last data message (between MDI and MDT).

ACKNOWLEDGE No number Check command line.

N0ACK No number Retransmitted without confirmation of command line).

XON/X0PF No number XPERA and XF
Controls the flow of data during the ERLA mode of operation.

Each of these instructions will now be described more fully.

A, XFERA one continuous ASCII transfer The format of this message is <D) Otgggg (CR>) (Note:
D-“EOT”) t at the knee, g-’O’,’
L", 2°, ..., '9° - Call format 20 -
Use wireless settings.

1 - Call a number of devices in the group °gggg' without confirmation.

2- Call each °gggg' with confirmation.

gggg - Group ID to call (0 to 2047) or (
Individual ID to call (0 to 4095).

This command is used to transfer continuous ASCII data to a device consisting of a mobile data terminal (MDT). The data continues until the 5TOP command is received.

Ishi <D)021234<CR>This example is
Used to set continuous ASCII data from MDT to device with individual (or logical) ID 1234.

B, XFERB - Constant length binary transfer The format of this message is as follows.

<D>1tggggnnnnncCR> Here t, g, n-'0°, 'l', '2
' , -...-, ' 9° - Call type 20 - Use wireless settings.

l - Call multiple devices in the group 'gggg' without confirmation.

2- Call each °gggg' with confirmation.

gggg-(O to 2047) I+) or (
0 to 4095).

nnnn - number of binary bytes to be transferred (0 to 2047
) This Directive applies to equipment (one or more) consisting of an MDT.
is used to transfer a fixed number of binary data bytes. Since the data is binary, the control commands cannot be recognized and therefore the process cannot be interrupted until all bytes have been received.

Example: <D)0212340135(CR>
This example is used to set 135 bytes of binary data from the MDT to a device with a unique (or logical) ID of 1234.

C, XFERLA - ASCII transfer per line The format of this message is as follows.

(D) 2tgggg(CR> t, g, -='O°,'l','2°,...
...5'9° - Call format 20 - Use wireless settings.

l - Call multiple devices in the group with 'gggg' without confirmation.

2- With confirmation, call the individual °gggg'.

gggg-(O to 2047) calling group ID or (0
to 4095).

This command is used to transfer data line by line to devices consisting of VDTs. A line can have up to 255 bytes. A complete line can be terminated by sending a NULL command sequence. The XFERLA order is
It can be terminated by sending a 5TOP command sequence.

When in XFERLA Monido, JiDI is all <LF>
ignore. Lines are delimited by <CR>.

Example: <D>221234<CR> This example is used to set per-line ASCII data from the MDT to a device with a unique (or logical) ID of 1234.

D. FORMAT The format of this message is as follows.

<D>3vxxyy<CR> Knee v, x, y -'O', 'l', '2', --...
-・-,'9゜XX-bytes per packet yy-t<-putty per strike■-Vote: 〇-No vote 1-2/3 vote This command specifies the data format used for data transfer. used to identify.

Example (D)301632(CR>This example is used to specify the data format for the following commands as 16 bytes per packet, 32 packets per burst, and no voting.

E, 5TOP command The format of this message is as follows.

(D>4(CI?>) This example is used to stop execution of all current commands except XFERB.

Ishi <D> 4 <CR> F, NULL command The format of this message is as follows.

(D) 4(CR>(<CR> is an optional selection)
This command is used in XFERLA mode to terminate an input line. <D><CR> (both symbols) Clear line when order is received.

When entering a command, <D> clears the command bar buffer so that a new command can be entered manually. Therefore, if an error is made on the manual command line, it can be cleared by sending <D> and then sending the correct command. If <D><CR> is received (e.g. from a terminal device), in order for the device to go to the next line, <CR><
LP> is sent back as an echo.

G.RETRANSMIT The format of this message is as follows.

<DZ RTR><CR> This command is used to request retransmission of a data message in either direction. When using a terminal, this message leaves "RTR" at the end of the line as a visual indicator to re-enter the data and rings the terminal's bell. In an intelligent MDT, this order requires automatic retransmission of data and can be used in either orientation.

H, ACKNOWLEDGE The format of this message is as follows.

<P>(LP><CR> (Note: F-
“ACK”) This message is used to confirm the command line. When using a terminal, this message resets the terminal's cursor to the beginning of the next line.

When using MDT, this command is simply a confirmation that the two devices are ready to transfer another command or data.

1.N0ACKNOWLEDGE The format of this message is as follows.

(U) RTR<CR> (Note: U-“
NAK”) This message is used for non-acknowledgment of the command line. When using a terminal device, this message displays RTR at the end of the command line and moves the cursor to the beginning of the current line (i.e. <LF>none). If MDT is used, this automatically retransmits the command line.

J, XON/X0FF The format of this data is as follows.

<S>OR<Q) (Note: OR-“D
CI"/"DC3") These control commands are received/generated when the MDI is in ASCII data transfer mode. They are used to stop and start data transfers when the internal buffer is full.2 In forward transfer mode (XFERB), modem control - CTS, R
TS- is the only way to temporarily stop data transfer.

Confirmation Message Handshake FIG. 8 shows the preferred embodiment data burst 150
17 is a schematic diagram of an example confirmation message 170 sent from DEM 56 to DOM 52 upon receipt of a message. DOM
After 52 sends the data session burst 150 to DEM 56, the DEM responds with a confirmation message 170. (
If DOM 52 does not receive a confirmation message 170 (by the expiration of a predefined time period), DOM 52 retransmits the last transmitted data burst 150. A repeating data session burst 150 is marked by setting the contents of the repeat field R (see FIG. 7) to a predetermined value. On the other hand, the confirmation message 170 is DOM
52 is successfully received, the DOM uses the contents of the confirmation message to determine the next data burst 150 to send.
Configure.

The confirmation message 170 sent from the DEM 56 contains two important pieces of information: (1) which data packet 154 in the last transmitted data burst 150 was sent to the DEM;
received correctly or incorrectly; and (2) how many (new) data packets the DEM can receive in the next transmitted data burst 150.

The confirmation message 170 has a sub-preamble part 1δO(
(as shown in FIG. 6), a confirmation order 172, and an end-of-message portion 156. Confirmation sequence 172 includes repeated confirmation data bursts 174 (in the preferred embodiment, this confirmation data burst is repeated nine times). Each confirmation data burst 174 has a status field 17
6. Message field 178 and error checking (CR
C) includes field 180. Each message field 178 includes a control field 182 and a "new packet" field 184. In the preferred embodiment, the total number of bits in the confirmation message 170 is 1016+9xN
(N is the number of bits in status field 176). Note that status field 176 is an N-bit bit map, one bit per data packet. The state of the bit indicates whether the packet was received correctly. By using bit maps, there is no overhead associated with the number of packets sent. D.O.
M does not send a packet number with each bucket.

Confirmation message 170 indicates which data packets 154a in the last transmitted data burst 150 were received correctly or incorrectly, and how many data packets that were not previously sent will be sent in the next transmission.・Identify whether the packet can be received. DOM5
2 typically transmits data packets 154a sequentially in an order predetermined by data terminal equipment 100. For example, if a textual message containing multiple individual symbols is entered into data terminal equipment 100 for transmission to DEM 56, DOM 52 will attempt to transmit the symbols in the same order in which they were entered. shall be. Similarly, the DEM 56 (the contents of the data packet)
A series of data packets 1 containing symbols in the same order as they were input to the data terminal 100 (so that they can be displayed or otherwise processed in the order in which they were received)
54a is expected to be received.

However, sometimes communication link 58 and/or communication link 6
Due to noise, fading, and other phenomena present in 0, DEM 56 may incorrectly receive certain transmitted data packets 154a. Terminal device 1
Instead of sending a data stream filled with "gaps" for 00, DEM 56 sends a confirmation message 170 requesting that DOM 62 retransmit the incorrectly received packet, while Correctly received data packets are stored in a buffer until the incorrectly received packets are retransmitted and the DEM receives them correctly. - Once the DEM 56 correctly receives retransmitted packets, it processes them in the correct order relative to previously transmitted and correctly received (and already stored) packets.

DEM 56 preferably processes received packets 154a in blocks (in a preferred embodiment,
The length of such a block is the length of each data burst 1
50 plus some extra). In a preferred embodiment, DEM
56 accumulates a data block (including, for example, 18 packets) and sends the data block to data terminal equipment 100.

The new packet field 184 in the confirmation message 170 indicates how many more "new" packets the DEM must add to complete the "assembly" of a complete data block.
56 informs DOM 52 what it needs.

As can be seen from the transmission format shown in FIGS. 4-8, all important data transmitted in the preferred embodiment (confirmation order 1
72 or confirmation message 174) are checked using conventional cyclic redundancy check algorithms to ensure data integrity.

The majority of transmission errors occur within data packets 154. This is because it is large compared to other parts of the transmission. In the preferred embodiment of the invention, recovery from such errors is very smooth. Errors that occur within the control field, although less frequent, pose a somewhat larger problem.

In a preferred implementation, the total number N of data packets within each data burst 150 is transmitted within the guardband of the preamble of the first data burst (e.g., as a parameter of the transmitted XFERA command). be done.

The different number of data packets to be sent in a given data burst 5θ is N (where N is the number of data packets in a data burst).
(number of packets), in the preferred embodiment, the packets sent are repeated many times from lowest to highest until all N data packets in the outgoing data burst are filled.

Once DEM 56 acknowledges receipt of data burst 150, it uses the CRC code within the data burst to inform DOM 52 (subject to normal error checking) which packets were received correctly or incorrectly. Additionally, the DEM 56 determines how many packets the DEM can receive in the next transmission.
Let 52 know.

For example, a total of 16 data packets 154 (PI-
PI6), DOM 52 first sends D
EM 56 with the value 16 and then transmits a data burst 150 containing all 16 data packets (in this example, the number N in each data burst
is assumed to be 16). When the DEM 56 receives a transmitted data burst, the DEM determines whether a transmission error has occurred by conventionally analyzing the received CRC code embedded in each data packet. judge.

DEM 56 receives the third transmitted packet (P3
), but assume that all other data packets were received correctly.

A confirmation message 170 sent from DEM 56 to DOM 52 informs (in status field 176) that the third packet was not received correctly and that the other data packets were received correctly. The confirmation message 170 includes (16 pieces of message data)
DOM 52 indicates (in new packet field 184) that there is no new data packet to send (since all packets have already been sent at least once).

In response to the confirmation message 170 received by DOM 52, it transmits the next burst of data 150. This next data burst 150 is not one data packet, but 16 data packets 154a (in the preferred embodiment, all data packets 154a for a given transmission are
burst 150 has the same number of data packets).

Each one of the 16 data packets Φ fields 154a in this data burst 150 contains a third data packet P3 (so that the data burst repeats packet P3 16 times).

DEM 56 is the C of the received data burst 159.
The RC field is analyzed to determine whether at least one of the 16 received P3 data packets was received correctly. If at least one P3 data packet was received correctly, the DEM 56 sends a status field 176 indicating that packet P3 was received correctly, and a new packet Φ field 184 indicating that no new packet is expected. A confirmation message 170 is sent. The message transfer is thus completed.

As another example, assume that the message contains a total of 19 different data packets Pi-P19. Initially, DOM 52 signals DEM 56 to transmit 19 unique data Φ packets 164 and then begins transmitting data bursts 150.

Assuming that each data burst 150 includes 16 data packets 154a, at least two data bursts are required to transmit the entire message.

DOM 52 transmits a first data burst 150 containing data packets Pi-P16. DEM
56 received packets P1 and PI incorrectly, but received the rest of the first 16 packets correctly. DEM 56 receives packets P1 and Pl
Reception status field 1 indicating that the was received incorrectly.
Send a confirmation message with 76.

As previously stated, data terminal equipment 100 expects to receive data packets in sequential order. D
EM 56 receives packet P1 incorrectly and DE
Since M's data terminal 100 expects to receive packet P1 first, the DEM cannot yet convey the data packet to that data terminal.

Assume that DEM 56 can only buffer 17 data packets at a time. DEM
56 (because packets P1 and Pl are required before the contents of the buffer can be conveyed to the DEM's data terminal equipment 100), the three data are transmitted in the next data burst 150.・Can only receive packets. Therefore, it can only store one new data packet (i.e., in addition to the data packets that have already been correctly received and the data packets P1 and Pl that it still needs, the previously sent data packet P17).

Therefore, the new packet field 184 of the confirmation message 170 indicates that the DEM 56 will receive the next data burst 150.
signals the DOM 52 that it can only accept one new data packet.

In response to the confirmation message 170, the DOM 52 transmits a data burst 150 containing only three distinct data packets Pi, P7 and Pl7. This group of three data packets is a data burst of 150
It is repeated as many times as necessary to completely fill the 16 data packets 154. As a result, DOM
The second data burst transmitted from 52 includes the following data packets.

PIP7P17PIP7P17PIP7P17...
...Pl...Assume that the DEM 56 correctly receives packets P7 and Pl7 at every P, but packet P1 occurs seven times and receives all of them incorrectly (this is statistically Although unlikely, it can occur if there is strong fading on the communication line). In the next confirmation message 170 sent from DEM 56 to DOM 52, status field 176 indicates that packet P1 is still needed and new packet field 184 indicates that the DEM is unable to accept new packets. Therefore, it is known that in both D.OM and DEM, one data packet P1 is sent repeatedly 16 times.

The next data burst 150 transmitted from DOM 52 to DEM 56 includes data packet P1 repeated 16 times. The DEM 56 requires one of the 166 packets P1 to complete the data block stored in its data buffer and communicate the data block to the DEM's data terminal 100.
It is only necessary to receive the data correctly once. It is extremely likely that the DEM will correctly receive at least one of these 16 repetitions of packet P1. Packet P1
Assuming that at least one occurrence of (19
(Because only two packets P18 and Pl9 remain in the message consisting of 5 packets) DEM 5
DOM 52 sends a confirmation message 170 indicating in new packet field 184 that DOM 6 is ready to receive two more packets.

The next data burst 150 sent from DOM 52 to DEM 56 includes the following packets.

Pi 8P19P18P19...P18P19
If the DEM 56 correctly receives at least one occurrence of each of these packets, it indicates that it has received both packets correctly and will not receive any more packets (then the entire message has been sent and correctly received). DOM confirmation message 170 indicating that the message has been received)
52. DOM 52 keeps track of correctly received packets and therefore independently determines that the message exchange is complete.

(For example, if DEM 56 did not receive any of the 16 data packets correctly or
DOM 52 sends data burst 150 (because DOM 52 did not receive confirmation message 170 after the scheduled time period)
If the entire data burst must be repeated, DOM 52 retransmits the data burst and sets the repeat word R (see Figure 7) to indicate that this burst is a literal repeat of the previously transmitted burst. .

In some cases, DOM 52 confirms message 17
0 is received, but a 9-5 vote in confirmation field 174 (this field is processed and voted on using normal walkthrough routines and an embedded CRC code to determine correct receipt). It may not be possible to achieve this successfully. In this case, the DOM 52 is
It is not possible to accurately determine which data packet 154a in the last transmitted data burst 150 was correctly received by DEM 56.

Therefore, DOM 52 simply repeats the entire last transmitted data burst 150 and signals that this data burst is a repeat by the repeat field. the data burst 150 is repeated at any time;
If the message is encrypted, the initialization vector (IV) used for the first data burst is also used for repeated data bursts.

When DEM 56 is unable to correctly receive the control field within any data burst 150 (e.g., the first data burst containing preamble 158), the DO
M52 can be asked to repeat the entire data burst. If DEM 56 requests DOM 52 to repeat the initial data burst, DOM
52 retransmits the preamble 158 along with all data packets 154 (if any) contained in the first data burst. If the DEM 56 is unable to receive the first data burst 150 at all, it does not send the confirmation message 170 and the DEM 56
2 waits for a response and times out. DOM52
When the DOM runs out of time waiting for a response, the DOM simply retransmits the last sent burst (the repeat field marks the burst to indicate that it is a repeat). In the preferred embodiment, DOM 52 transmits a particular data burst 150 three times and "gives up" when it does not receive an equivalency confirmation message 170.

Errors that occur in preamble 158 or sub-preamble 160 of data burst 150 cause data burst (
Alternatively, if the sub-preamble 160 of the confirmation message contains an error, it may prevent correct reception of the confirmation message 170). DOM 52 confirms message 172
If the sub-preamble 160 cannot be received correctly, it simply times out and retransmits the last transmitted data packet. DEM 56 is data
Packet preamble 58 or sub-preamble 16
0 cannot be received correctly, no confirmation message 170 is sent in response to the data burst, and DOM 52 still times out and retransmits the last data burst 150 sent.

Example Data Organization FIG. 9 is a circuit diagram of one example of a data storage (buffer) structure used in the preferred embodiment to transfer digital data between transmit/receive interface 92 and terminal interface 102.

In a preferred embodiment, the data structure shown in FIG. 9 is constructed in large part by storing data in external random access memory. In a preferred embodiment, the ninth
A transmit/receive interface 92, a DES circuit 86 and a terminal interface 102 are shown in the simplified block diagram of the figure.
All other circuits are data structures in random-access memory rather than hard-wired individual registers and register files (although the circuit in Figure 9 can be used with hard-wired registers if desired). ).

In a preferred embodiment, the data to be transmitted is
00 and sent to the terminal interface 102. The command input into the terminal interface 102 is
For decoding by control microprocessor 74, P
It is loaded into a command buffer called ARSEBUFF 302. On the other hand, digital data is first-in, first-out FI.
FO) is loaded into register file TXBUFF 304. TXBUFF 304 stores several packets of digital information (preferably large enough to store an entire message).

Register TXDATABUFF 306 stores N (16 in the preferred embodiment) data packets 154 to be transmitted. These data packets (if they do not require encryption)
TXDATABUFF 306 from “Top”
or alternatively, the DE
After being encrypted by S circuit 86, TXDATAB
Loaded into UFF. Another register T X P RE
A M BUFF 30g is the data to be sent.
As the "heading" portion of the burst 150, the preamble 158 (or sub-preamble 160) to be transmitted is stored. Control microprocessor 74 executes an interrupt driven routine to
The contents of F 308 are formatted before each data burst is transmitted, as will be explained later.

The contents of TXPREAMBUFF 308, and then the contents of TXDATABUFF 306 (e.g.
(one byte at a time) via data bus 76 to transmit/receive interface 92 for further signal processing and filtering and transmission from transmitter 70.

In receive mode, the transmit/receive interface 92 receives data bytes and sends the received bytes to the RXPREA.
MBUFF 310 (for heading information) or RXD
ATABUFF 312 (for digital data).

- Once the heading information is loaded into register 310, microprocessor 74 decodes and parses the heading information. The digital data stored in RXDATABUFF 312 (-one data packet at a time)
A first-in-first-out FIFO called PKBUFF is loaded into a register file 314 (which stores 18 data packets in the preferred embodiment). RXD
The data in ATABUFF is checked one packet at a time to see if it has been correctly received. If the packets are received correctly, they are placed in PKBUFF one after another. If a packet is received incorrectly, the PK
BUFF leaves space for this purpose. -Dan1
The entire block of 8 data packets is PKBUFF
314, the data packet is stored in TER
It is forwarded via an output register in MBUFF 316 to terminal interface 102 for display (as well as other processing) on terminal device 100.

Next, the blocks and microprocessor 74 shown in FIG.
The transfer, manipulation, and processing of data by the microprocessor will now be described with reference to a flowchart illustrating one example of a microprocessor program control process.

The procedure XMAIN shown in FIG.
58 and monitors the status of the transceiver. This routine is executed as a continuous loop, with microprocessor I10 being serviced by an interrupt driven routine (shown in FIGS. 16-28).

Decision block 402 of FIG. 10 determines whether a user has recently entered data via display terminal 100. Decision block 402 of FIG. As previously explained, data can be entered by hitting the desired key on the data terminal device indicating the transfer command and then pressing the send (carriage return) key. When the send key is pressed, the input command data is transferred to the serial I10 link (interface 102
) to the microprocessor through the buffer P
ARSEBUFF 302 and a flag within the microprocessor is set.

TX if the user has recently entered data to be sent.
Calculations are performed to initialize the message preamble 158 stored in PREAMBUFF 308 (block 404). This step involves counting the number of bytes in the message to be sent, setting flags, etc., and setting various other fields of the preamble to the TX
PREAMBUFF 308 (this process is actually done over a period of time by a timer interrupt driven routine, as explained below).

For example, at block 404, a flag is set indicating that the radio is a DOM. Otherwise, the missing radio condition is DEM. Since the step performed by block 404 is only required once for each message being sent, it is bypassed if a new user message has not been entered.

Decision block 406 determines whether the transceiver is busy receiving or transmitting data burst 150. In the preferred embodiment, block 406 tests the value of a "busy" flag set by block 404 or other routines. The flag is set (
Should or is sending a message;
or otherwise indicates that a message has been received), blocks 408-414 are executed. The "busy" flag indicates that the radio is in the process of transferring data messages between the DOM and DEM. If the flag is not set (indicating that a message is neither being sent nor received), control of the program passes to block 4.
Jump to 16.

If decision block 406 determines that a message is being transmitted or received, decision block 408 determines whether the transceiver is operating as a data originating mobile station or "DOM" 52. The message is DO
It may be a data burst or acknowledgment when M sends a message and receives an ACK, while the DEM receives the data burst and sends an ACK (in the RF sense of transmit and receive). If the transceiver is transmitting a message, call routine XDOM (block 41).
0). This XDOM routine performs the steps to send data. Otherwise, decision block 412
However, when the transceiver is connected to the destination mobile station, i.e. “DEM” 56
Determine whether it is working as If the transceiver is receiving a message, routine XDEM
(which performs steps to receive data and process the received data) (block 414). If the transceiver is not transmitting or receiving messages, program control passes to block 416.

Block 416 tests whether the flag ALL DONE is sent (indicating that the transceiver was previously busy but is no longer busy). ALL
DONE, when set,
However, it indicates whether the radio has finished transmitting or receiving the entire message (ie, whether all data packets were correctly received by the DEM). If this flag is not set, program control returns to block 402. If the ALL DONE flag is set, block 418 determines whether data terminal 100 is activated.

If the data terminal is activated, program control returns to block 402. On the other hand, if block 418 determines that the ALLDONE flag is set and terminal 100 is inactive, block 420 returns the transceiver to the receive state. Block 420 configures the transceiver to readdress messages from the terminal and clears the DOM flag.

Routine XDOM (block 410), shown in detail in FIGS. 11A and 11B, controls the transceiver that transmits the message. This XDOM routine generates a data burst 15 containing some or all digital data entered by the user via the data terminal device 100.
0 is transmitted by the transceiver. This data burst may contain all "new" (i.e. not previously transmitted) data packets, or all "old" packets (which the DEM did not receive correctly and must be retransmitted). ) or a combination of new and old packets.

The XDOM routine detects new data packets (TX
BUFF 304). The XDOM determines (in response to receipt of the confirmation message 170) whether the XDEM 56 (i.e., the transceiver of the destination mobile station) successfully received the data packets of the last transmitted data burst; If there is a packet that is not well received, the DOM 52 is controlled to retransmit that packet (thus, it acts to adapt to the deterioration in the performance of the communication line). A detailed flowchart of this routine is shown in Figures 11A and 1.
Shown in Figure 1B.

Decision block 502 tests whether a confirmation message 170 is received from DEM 56 .

As previously discussed, DEM 56 sends a confirmation message 170 in response to each data burst 150 sent from DOM. This confirmation message 1
72 indicates which data packets within the burst were successfully received and which packets were not successfully received. When this confirmation message 170 is received, a flag called RXDONE is set by the microprocessor within the DOM. Decision block 502 simply tests the value of this flag. Confirmation message 17
If 0 is not received, the control process continues at block 518 (
Jump to Figure 11B) and stay there.

M 52 processes the data packets to be transmitted.

Upon receiving the confirmation message 170, the DOM uses normal error checking methods (e.g., the C
A cyclic redundancy check (of the RC field) is used to determine whether the received confirmation message is "valid", ie, whether its contents can be understood by the DOM.

As each confirmation order 174 is received, its validity is checked. For example, due to a large amount of noise on the RF line, the confirmation message 170 received by the DOM is so corrupted that the DOM is unable to decode the received message and determine which data packets must be retransmitted. Sometimes. If the error checking function performed on the received confirmation sequence 174 shows that the signal can be successfully decoded and useful information can be retrieved, then VALI
Another flag called D_ACK is set by the DOM 52 (otherwise the flag VALID
ACK is not set). Any one of the nine confirmation orders can be received correctly.

Decision block 502 determines that confirmation order 174 has been received, and decision block 504 determines that confirmation order 174 has been received, and decision block 504 determines that transmit buffer TXDA
Determine if TABUFF should be filled with data from TXBUFF. At block 502, the flag F I LLTXBUFF, if set, indicates that TXDATABUFF should be filled with new packets from TXBUFF. If not set, the confirmation must be parsed and the TXDATA
It may be necessary to move packets that are in the BUFF. When set, no call to 5HUFTX is necessary. When not set, a call to 5HUFTX must be made. FILLTXBUFF flag is mainly set at the first bus of XDOM,
TXDATA first for the first data burst
Fill BUFF.

If TXDATABUFF must be loaded, block 506 clears the RXDONE flag (determined to be set by block 502). Decision block 508 then determines whether VALID A
Testing the value of CK7-7 determines whether the received confirmation message 170 can be used to provide useful information.

If the confirmation message 170 cannot be decoded to generate useful information regarding the reception status, D.E.M.
The data in the last data burst 150 sent by
There is no way to know if the packet was received correctly,
Therefore, the entire data burst contained in TXDATABUFF must be repeated. Block 510 simply sets the REPEAT field in the preamble of the data burst to indicate that this burst is an exact repetition of the last transmitted burst.

If block 508 determines that the confirmation signal can be decoded, routine 5HUFTX is called (block 512). The 5HUFTX routine analyzes the acknowledgment signal to determine which data packets in the last burst
and moves these incorrectly received packets to the "top" of the TXDATABUFF so that they are retransmitted as part of the next data burst. A flowchart of this routine is shown in Figures 12A and 12B.

Briefly, Routine 5HUFTX must determine whether each unique packet sent during the last burst was correctly received at least once. As mentioned earlier, a given packet can be repeated several times in the same burst, and the DEM must It is only necessary to correctly receive one occurrence of .

Routine 5HUFTX has outer and inner nested routines. The outer loop is controlled by a loop counter J, which is used to track whether all unique packets in the last transmission have been tested for correct reception. The nested inner loop is controlled by another loop counter I, using this
Track whether all occurrences of a packet sent several times during the last transmission were tested for correct reception.

The first step in routine 5HUFTX is performed by block 602, which initializes a pointer called NEXT FREE and sets the outer loop counter J to a value of one. Block 604 then clears the DONE flag and sets the value of the inner loop counter ■ equal to the value of J. Next, block 60B received a “packet reception status” field 176 (RXDATABUFF
312) to determine whether the first packet in the last transmitted burst was received correctly. In the preferred embodiment, the acknowledgment signal (which is the packet reception status field 176) is parsed all at once and its contents are stored in a table called CRCMAP (in the preferred embodiment, this table is each packet has one bit with λ=t, and this bit is set if the corresponding packet is correctly received, otherwise it is not set)
.

In the preferred embodiment, block 606 includes table CR
Information regarding the reception status of the first packet in the last transmitted burst is retrieved from the CPvI AP. If this retrieved bit is set, the corresponding packet does not need to be retransmitted (set the DONE flag (block 610); otherwise,
The 5HUFTX routine determines that a packet that was received correctly or incorrectly may have been transmitted more than once in the last transmission and may have been correctly received by DEM 56 at least once (blocks 612-61).
6).

Block 612 checks the last transmitting unique packet (LINIQUE PACKET) to determine where the next occurrence (if any) of the packet determined to be incorrectly received by decision block 608 will be.
) is incremented by the value of loop counter I. Decision block 614 then determines whether the new value of ■ is greater than N, the total number of packets in each data burst. l>N (Ko\deN
is the number of packets in each burst, which is 16 in the preferred embodiment), then there is no next occurrence of the packet left to examine and this packet must be retransmitted. In this case, block 616 is the DO
Set the NE flag and send the third packet to TXDAT
Transfer to the “top” of ABUFF, then NEXTFRE
E (pointer to TXDATABUFF) is incremented by 1, and this pointer becomes TXDATAB.
Point to the next empty location in the UFF.

Decision block 614 may check for additional occurrences of the incorrectly received packet to see if the incorrectly received packet was sent more than once and whether it was received correctly. If it is determined that there is not, program control returns to block 606 (DON
Since the E flag is not yet set, the test result of decision block 618 is false), and the confirmation signal is analyzed for another occurrence of an incorrectly received packet. Otherwise, control of the program proceeds to block 620, which increments the value of J by 1 (thus checking the reception status of another unique packet sent during the last data burst). (prepare for).

Decision block 622 checks the reception status of all unique packets in the last data burst (preferably by comparing the value of J to the number of unique packets in the last data burst). determine whether the

If all unique packets have been examined at this time, the flag FILLTXBUFF is set (block 62
4), TXDATABUFF buffer 306 is TXBU
Indicating that it is ready to be filled with new packets from the FF, program control returns to block 514 shown in FIGS. 11A and 11B.

If decision block 622 determines that there are unique packets yet to be examined, program control returns to block 604 to examine the reception status of the next (third) packet.

Now, returning to FIGS. 11A and 11B, the explanation is as follows.
After program control returns from routine 5HUFTX, decision block 514 determines whether there is more data in the current message that has not yet been transmitted (e.g.,
TXBUFF 304 and is incremented when a packet is transferred from this buffer to TXDATABUFF 306). If all the data has been sent, a flag called ALL DONE is set, the terminal is controlled to display a message to the user that the message has been successfully sent, and the flag F is set.
ILLTXBUFF is cleared (block 516)
.

Decision block 518 then determines whether TXDATABUFF is full (eg, by testing the FILLTXBUFF flag). If TXDATABUFF is not full, a routine called FILLTX is called to fill data packets from TXBUFF register file 304 into TXDATABUFF for transmission.
306 (block 520). FILLTX
A flowchart of the routine is shown in FIG.

The routine FILLTX first reads TXDATABUFF
306 (block 702). Decision block 704 then determines whether the next data
Determine whether any data packets that have not yet been sent in the burst (ie, "new") can be sent.

In the preferred embodiment, block 702 includes TXDATA
The value of the pointer NEXTFREE (which was set by the 5HUFTX routine at block 616 of Figures 12A and 12B), which points to the next free location in the BUFF register file, is compared. NE NEXTFREE
Compare with WPACKET. NEWPACKET is D
It is sent by the EM as a confirmation message in the NEWPACKET field 184. NEXTFREE is NE
When less than or equal to WPACKET,
At any given time, there is at least one other unique packet that must be loaded into TXDATABUFF 306 before transmitting the next data burst 150.

If at least one new packet must be prepared, the routine F I LLTX attempts to fill the empty packet(s) with data that has not yet been transmitted (eg, "new" data).

If decision block 704 determines that previously untransmitted packets can be transmitted in the next data burst, decision block 706 determines whether there are new packets.

If there is at least one new packet, one packet of new information is sent from TXBUFF 304 to TXDAT.
ABUFF 306 (if there is not enough new data to do so, T
Fill this packet with XDATABUFF. this is,
This is because the user message can be of any length and therefore does not need to be on a 16-byte boundary).

Next, decision block 710 determines whether TXDATABUFF
Determine whether the data burst stored at 306 is full. If the burst is full, control of the program is switched to block 704, which blocks the data that has not yet been transmitted in the next burst of data (
ie, whether a "new" data packet can be sent.

On the other hand, if TXDATABUFF 306 is not full, the variable NEXTFREE is incremented by one (block 712) and program control returns to decision block 704.

Decision block 706 determines that there are no new packets to send, or block 704 may send any data packets (or another packet, if any) that have not yet been sent in the next burst. If it is determined that it is not possible, decision block 714 determines that the required number of packets (
For example, in the preferred embodiment 16) determines whether it is ready for transmission.

At least 16 different packets are ready for transmission, T
If stored in XDATABUFF 306, there is no need to repeat the packet and the control action is F I LLT
Block 5 of Figures 11A and 11B from the X routine
Return to 22. On the other hand, if decision block 714 determines that there are insufficient number of unique packets to form a complete data burst, then blocks 716-720 determine that the number of unique packets is equal to N (eg, 16 in the preferred embodiment). Transcribe different packets as many times as necessary to make up the number.

Block 716 first clears the F I LLTXBUFF flag and then clears the pointer UN f QUEPACK
ET, TXDATAB filled with data packets
Set it to point to the last position in UFF 306 (
UN IQUE PACKET holds the number of new packets received by the DEM).

Decision block 718 then selects the pointer NEXTFREE.
Compare the value of with the value N (required number of packets). NEXT
If FREE is less than or equal to N, block 720 moves the "top" packet stored in TXDATABUFF to the first free location at the "bottom" of TXDATABUFF and increments NEXTFREE by one. Decision block 718 then tests whether another packet is needed. If more packets are needed, block 720 sends TXDATAB
Transfer the next unique packet from the top of the UFF (if such a unique packet exists). TXDATA
BUFF 3061: This process continues until the number of stored packets is equal to N. Each unique packet to be transcribed is transcribed by X rotations, and then any packet is transcribed by (x+1) rotations.

If decision block 718 determines that no extra packets are needed to fill TXDATABUFF 306, program control returns to routine XDOM and the eleventh
It begins at block 522 of FIGS. A and 11B.

Decision block 522 determines whether preamble 158 or sub-preamble 160 should be transmitted. As previously mentioned, a long preamble is sent at the beginning of each new message and whenever the data format changes. When transmitting preamble 158, block 524 registers TXPREA
The data in MBUFF 306 is correctly formatted to include the preamble, and the data burst (which is now TXPREAMBUFF 30g and TXDAT
control the transceiver to start transmitting (contained in ABUFF 306).

Decision block 526 then determines whether any data was sent in the data burst being transmitted. If data transmission has not yet been completed, program control is
0 returns to the execution routine XMAIN shown in FIG. If all data packets have already been transmitted, block 528
controls the transceiver to begin transmitting an end of message (EOM) field 156.

After this, block 530 tests whether the entire data burst has been transmitted. If the burst transmission is complete, block 532 sets the transceiver to a receive state. Otherwise, the control of the program is
Return to IN.

As previously explained, the routine X M AIN of FIG.
calls routine XDEM when the transceiver operates as a DEM 56 (ie, to process a received data burst). This XDEM routine is DEM56
(i.e., the transceiver acting as the destination mobile station). The XDEM routine will now be described in conjunction with the flow chart shown in FIGS. 14A and 14B.

First, a decision block 802 determines that a preamble or sub-preamble is received by the DEM 58;
Tests if stored in RXPREAMBUFF 310 but not yet parsed. If a header has been received but not yet parsed, decision block 804 determines whether the header is "valid" (eg, by parsing the CRC bytes and error checking). If the received heading data is valid, decision block 806 determines that the heading is in the preamble 158.
, and if so, extract and parse data from the preamble (block 808).

If the received valid heading is sub-preamble 160, microprocessor 74 typically does not need the contents of the heading (although interface 92 may include the sub-preamble to recover lost synchronization, for example). ). Thus, the control action is determined by decision block 810.
can be switched to

Decision block 810 determines whether data burst 150 has been received and is at RXDATABUFF (e.g., by determining whether a complete data burst is at RXDATABUFF and must be subsequently parsed). do. If a burst is currently being received (because in the preferred embodiment, data is transferred to the register file only when a complete data burst is stored in RXDATABUFF 312):
Unable to load data into register fiber PKBUFF 314. On the other hand, if a data burst is not currently being received, that is, if RXDATABUFF contains a data burst, RXDATABUFF
Analyze the mobility of the contents of F.312 and extract valid data.
Packet to register file PKBUFF 314
It is necessary to transfer the information to These tasks are performed by routine INPBFH. This is called by block 812 of Figure 14A.

Flowchart 1NPBFF is shown in Figures 15A and 15B.
As shown in the figure. The pointer NEXTFREE is initialized to a value of 1 and a flag called DONE is cleared (block 852). Decision block 854 then determines whether the DONE flag is set. DONE
If the flag is not set, RXDATABUF
The data packet in F 312 is stored in block 856
It is analyzed by executing steps 864 to 864.

Using the pointer NEXTFREE, P, K B U
FF 314, which indicates the bit in the PBMAP that corresponds to the packet in PKBUFF.

Decision block 856 compares the value of NEXTFREE to the dimensions of register file PKBUFF 314.

The size of PKBUFF is the number of data packets that PKBUFF can hold, thus in the register file RXDATABUFF
312. Determine whether there is sufficient storage space to load the data packet contained in 312. If there is insufficient space in register file 314, program control passes to decision block 866. Block 858 NEXTFRE from P B M A P
Find the bit pointed to by E. PBMAP is PKB
A bit map with one bit for every packet that UFF can hold. PBMAP is
transferred from RXDATABUFF to PKBUFF,
Tracking correctly received packets.

When routine INFBFF is called for the first time, it
Examine the BMAP to find the first location of the unreceived packet. The DEM specifies that the first packet in the current data burst from the DOM (if it was received correctly) is the NEXT packet in the PKBUFF.
It "knows" that it should be placed in the first "free" position pointed to by FREE.

At block 860, the PBN corresponding to NEXTFREE
If the AP bit is 1, that position in PKBUFF is already filled with a data packet, so the NEXT
Increment FREE and retrieve the bit corresponding to NEXTFREE from PBNAP. NEXTFRE
This process continues until the size of PKBUFF (i.e., the number of data packets that PKBUFF can hold) is reached or bit-0 of PBMAP is reached.

The DEM uses PBMAP to track valid packets that have been placed in the PKBUFF and where in the PKBUFF this packet is located, without using any packet numbers for the packets.

If the bit in the PBMAP pointed to by NEXTFREE is O, block 862 sets the DONE flag;
Indicates that PKBUFF has space for at least one data packet, and the packet is NEXTF
Enter the position indicated by REE. Otherwise, the pointer N
Increment EXTFREE by 1 and block 8
64), blocks 854-864 are executed again.

Blocks 856-8 until a free location is found in PKBUFF for a packet or the size NEXTFREE>PKBUFF (i.e., all locations in PKBUFF have valid data packets).
After 64 is executed repeatedly, decision block 866
Test whether the received data contained in RXDATABUFF 312 is repetitive (this test is done by simply examining the value of the REPEAT byte in the received data burst).

If the received data burst is not repeated, the variable tJN
IQUE PACKET is N EWP A CAET
is set to the value of NEWPACKET is a pointer used to indicate the number of previously untransmitted new data packets that the DEM can receive in the next data burst. Received data packet is RXDATA
Stored in BUFF. After this block 870 is NEW
Clear PACKET and set the value of loop counter I to 1
Initialize to . Loop counter ■ is routine INF
The BFF is controlled to perform the series of steps contained within the outer loop of the routine once for each different (ie, non-repeating) data packet contained within RXDATABUFF 312.

Decision block 872 then compares the value of loop counter I to UNIQUE PACKET. I is UN
When IQUE is less than or equal to PKCKET, the packet is subsequently loaded from RXDATABUFF 312 to register file PKBUFF 314, the inner loop counter J is initialized to the value of loop counter I, and a flag called DONE is cleared. (block 874). Loop counter J is RX
Used as a pointer to DATABUFF 312, specifically to point to a repeat of an incorrectly received data packet.

If the DONE flag is not set at block 862, then PKBUFF has no place for the data packet. However, the DONE flag set in block 862 is checked in block 854 to signal that the first test of the PBMAP is complete. The DONE flag checked at block 876 instead performs another search, ie, that a correctly received data packet was found. Otherwise, J is N (RXDATABU
The bits of the CRC test previously performed on the first data packet are less than or equal to the number of data packets stored in FF 312 (also tested by decision block 876). Retrieve map results (block 878) and test if it is set to determine whether the first data packet was correctly received (block 8
80).

If the first CRC map bit is not set, then the first data packet was received incorrectly, and the preferred embodiment then determines whether this packet was repeated in the received transmission. (This is because by repeating the same data packet later, it may have been received correctly). The loop counter J is incremented by the value of the variable UNIQUE PACKT (block 882), so that it is
Next occurrence within 312 (if there is another occurrence)
Make it point to . Decision block 876 then determines whether the new value of J is less than or equal to N (if J is greater than N, then
This is because no more packets are generated. A confirmation message 170 must be sent from DEM 5g to DOM 52 requesting retransmission of this data packet).

On the other hand, if decision block 880 determines that the first data packet was received correctly, DONE
A flag is set (block 883) and the first data packet is RXDAPABUFF 312 to P
KBUFF 314 is transferred to the location pointed to by NEXTFREE (block 884) and sets the bit corresponding to the first packet in a data structure called PBMAP (block 886). (This PBMAP data structure is used to indicate which valid data packets have been stored in register file PKBUFF 314.) If the DONE flag is set or J is greater than N, decision block 876 takes control of the program. is switched to decision block 888. Decision block 888 is D.
The value of the ONE flag is tested to determine if it was set by block 883 (the DONE flag was cleared by block 874). If the DONE flag is set at decision block 883, the first data packet is valid (ie, correctly received). Decision block 888 is D.

If it is determined that the NE flag is not set, block 890 sets the variable NEW PACKET (used to indicate the number of data packets that were not previously transmitted but can be received in the next data burst transmission). Increment.

Then increment the pointer NEXTFREE,
Clear the DONE flag again (block 892).

If NEXTFREE is less than or equal to the size of PKBUFF, then the PBMAP is examined and the PKBU
It can be determined whether the FF can receive more data packets.

If all bits in PBMAP have not been tested, test the bit in PBMAP that corresponds to pointer NEXTFREE, it is sent, and PKBU
FF Determine whether to indicate that the corresponding position in F is already filled by a previously received valid data packet. PBM compatible with NEXTFREE
NEXTFREE if the AP bit is set
(block 900), thus allowing blocks 894-898 to search for the next free storage location in register file 314.

Once decision block 898 determines the next free storage location in PKBUFF (by testing decision block 898), the DONE flag is set (block 90
2), decision block 894 switches control of the program to block 904;

This block increments loop counter I and returns control of the program to decision block 872.

At some point, the loop counter ■ is incremented by block 904 so that it exceeds the number of unique packets sent in the last data burst (i.e., when the variable I is the last data in RXDATABUFF 312). - Refers to a location beyond the packet storage location, or a repeat of a data packet that has been sent more than once)
. Decision block 872 determines that I is a UNIQUE PAC.
Upon determining that KT is exceeded, decision block 906 determines whether there are more storage locations in register file PKBUFF 314. This kind of memory location is
These locations must be checked to see if they are free or have previously received data packets.

Using PBMAP, if all positions in PKBUFF are examined (i.e. NEXTFREE>PACKT
BUFF 5IZE), routine INPBFF is block 81 of the X D E M routine shown in FIG. 14A.
Return to 4. If all locations in PKBUFF are not checked for whether they have data packets, decision block 908 determines whether the value stored in NEWPACKET is less than the number N of packets in the data burst. do. NEWPACKET
is less than N, blocks 910, 912 determine whether the data packet corresponding to pointer NEXTFREE is already stored in register file 314 (if so, NOT NEWPA
CKET is incremented at block 914).

If the location is free, PKBUFF can receive the packet there and therefore increments NEW PACKET. The pointer NEXTFREE is then incremented (block 916) until all positions of PKBUFF have been examined, decision block 906.
The test performed with 96g is repeated. This process calculates the number of new packets that can be received in the next data burst transmission based on the number of packets already stored in the PKBUFF register file 314. The number of new packets that can be received is returned in the variable NEWPACKET of routine XDEM.

Returning to FIG. 14A, register TXPREA
The contents of MBUFF 308 are initialized using the format of the confirmation message shown in FIG. The contents of the status field 176 are determined according to the CRCM AP bit, and the contents of the NEWPACKET field 184 are determined according to the variable N.
identified by the value stored in EWPACKET (block 814). Then register file 3
It is determined whether any data packets stored in TERMBUF 316 can be transferred to output register TERMBUF 316 while preserving the order of the received data packets, and if so. , data packets are sent to output register 31 for communication via data bus 76 to terminal interface 102.
6 (blocks 816, 818, 820)
. Next, the confirmation message 170 stored in the registers 306 and 308 at this time is sent to the sending/receiving interface 9.
2 (block 822).

If the data burst is not in RXDATABUFF (as per the test of decision block 810), or if a confirmation message has been sent or is being sent (block 82
2) Decision block 824 determines whether an end-of-message field needs to be sent at the end of the confirmation message. If necessary, block 826 begins transmitting the end of message string.

Decision block 828 then completes the verification process 170.
is transmitted, and if so, decision block 830 determines whether all data packets for the entire message were correctly received.

AL if a complete valid data burst is received.
Set the L DONE flag (block 832)
. The ALLDONE flag indicates that the DOM should not send any more data packets. ALL
DONE flag is set and register file PK
If BUFF 314 is not free (as per the test of decision block 834), then the data packet is stored in register Φ
File PKBUFF is transferred to output buffer TERMBUF 316 until the output register is full (block 836, decision block 838). The contents of the output register are transferred to the terminal interface 102.

Routine XDEM then returns control of the program to routine XMAIN.

16 to 19 illustrate the terminal interface 102
1 is a simplified flowchart of the serial interrupt drive I10 routine used in the preferred embodiment to control the operation of the serial interrupt drive I10 routine.

These routines perform data transfers between data terminal equipment 100 and other parts of the transceiver. FIG. 16 is a schematic diagram of the main serial interrupt processing routine.

PAR3EBUFF from terminal interface 102
302 and register file TXBUFF 30
4 and output buffer TERMB.
It is necessary to transfer data from the UFF 316 to the data terminal equipment. Routine GETDAT, called by interrupt routine block 925 of FIG. 16 (detailed in FIG. 17), registers 3 when a data byte is received from data terminal interface 102.
02 and register file 304 (decision block 927). A serial interrupt occurs each time microprocessor 74 receives a byte via the serial port.

If the transceiver (as per the test of block 929)
58, output register TERMBUF 306 for display, storage or other purposes.
It may be necessary to transfer data from to the terminal device 100. Routine 0UTDAT (block 93
1, shown in detail in Figure 19) is TERMBUFFF 3
16 to data terminal interface 102 via data bus 76 .

When the transceiver is a DOM, the routine TRMMSG
(Block 933) (see FIG. 18) is called by the interrupt routine of FIG.

In order to display this on the terminal device 100, two "canned" (
canned) J messages to the data terminal interface 102.

Referring to FIG. 17, routine GETDAT sends data from terminal interface 102 (via the microprocessor's serial port) to TXBUFF 3
Please contact 04. Serial interrupts are from and to the microprocessor and terminal interface 102. Serial interrupts and routines GETDAT, 0U
TDAT and TRMMSG describe the operation on the microprocessor side. The transceiver is first initialized and
When the radio recovers at block 422 of FIG.
The command bit LOOK is set at any time. Decision block 952 determines that this command bit L when an interrupt occurs.
Test the value of OOK.

If command bit LOOK is set, the beginning of a new line of text may have been received, and decision block 954 determines that the first symbol received from data terminal equipment 100 is a "start" symbol (the preferred embodiment (ESC symbol)
Determine whether or not. If the first symbol is not a "start" symbol, ignore the interrupt and assume the user pressed a key by mistake.

If the received byte is a "start" symbol, a flag is set to indicate that the transceiver is operating as a DOM 52 (decision block 956) and the command bit LO
Clear OK (block 958). Additionally, a bit is set to indicate that the data terminal device 100 is active (block 960) to indicate that the microprocessor is sending a "canned" message for display on the data terminal device (block 960). flags GETMSG and MSG 1
Both are set. This message is not a data Φ burst message. Block 96 initiates processes related to sending out the MSG 1 data stream.
4) initializing a counter in preparation for counting the number of data bytes in the message (block 966);
.

Decision block 952 indicates that the transceiver does not receive data from data terminal equipment 100 (either because the transceiver already knows that a message is being entered, or because the interrupt was generated in error or due to another cause). Upon determining that the input command symbol is not "looking", decision block 968 determines whether flag GETMSG was previously set by block 962. If this plug was not previously set, ignore interrupts. If this flag was previously set, the cause of the interrupt was another byte input via data terminal equipment 100 that was added to the message being sent, and decision block 970 determined that the incoming byte is the "end of message" symbol (carriage return in the preferred embodiment)
Test whether it is. When the end of message symbol is received, the flag GETMSG is cleared and 5TAR
Set a flag called TUP so that the entire message is
Stored in XBUFF 304 and TXDATA
BUFF 306 is indicated as ready for entry (block 972). If this byte is not the end symbol of the message, save the byte to the register file TXB.
Transfer to UFF 304 (block 974).

Routine TRMMSG uses D to display on the terminal device.
Processes the forwarding of one of the two "canned" messages from the OM to the data terminal equipment 100.

DOM C. After the data terminal determines that it has a data message to send from the DOM to the DEM, from block 964 of routine GETDAT, the MSG
Start sending 1. When MSG 1 is displayed on the terminal, it informs the user to begin inputting a data message into the terminal.

The DOM begins sending MSG2 at block 516 of routine XDOM after the DEM determines that it has successfully received all data packets in the data message. Accordingly, MSG 2 informs the user that the DEM has successfully received the data conference message.

If decision block 980 determines that data terminal equipment 100 is active, it is determined whether MSG 1 is currently transmitting (decision block 982). M.S.
If G1 is not currently transmitting, decision block 984
determines whether MSG2 is transmitting. MSC
If neither I nor MSG2 is being transmitted, there is no need to convey the message bytes from DOM 52 to data terminal 100 and routine TRMMSG is activated. On the other hand, if you are sending MSG 1 or MSG 2,
It is determined whether all bytes of the message being sent have already been sent (decision blocks 986, 988).

If the message currently being transmitted has already been completely transmitted, the appropriate flag (MSG 1 if message MSG 1 is being transmitted, or MSG 2 if message MSG 2 is being transmitted) is cleared. If MSG 1 is finished, set the GETMSG flag (block 990). If MSG 2 is finished, flag TE
Clear RMACT I VE (block 992)
, signals that the microprocessor's serial transmit port is no longer active. If MSo 1 is finished, it sets a flag GETMSG to signal that the DOM's microprocessor is ready to receive data messages for placement in TXBUFF 314 (block 990).

On the other hand, if the message power is currently being sent and there are bytes of the message remaining to be sent, the next byte of the message is transferred from the DOM to the data terminal (blocks 994, 996).

Routine 0UTDAT, shown in FIG. 19, transfers data from TERMBUF 316 to terminal interface 102 for display or other processing (eg, storage) by data terminal device 100. Routine 0UTDA
T first determines (eg, by testing a flag) whether data terminal 100 is active (block 998). If the data terminal is not active, no data needs to be sent to it and routine 0UTDAT is exited. If data terminal equipment 100 is active, the contents of TERMBUF 316 is tested to determine whether data to be communicated to data terminal equipment 100 is stored in this buffer (decision block 1000). If TERMBUFFF 316 is not empty, a data byte is retrieved from TERMBUFFF and sent to data terminal interface 102 (block 1002). On the contrary, TERMBUF31
If 6 is empty, block 1004 clears a flag indicating that data is being sent to a data terminal device.
), then determine whether all data packets in the message have been sent to the data terminal equipment (decision block 1006).

If all data has been sent to the terminal, clear the terminal active flag previously tested at decision block 998;
Signal that the data terminal is no longer active (block 100g). If all data has not been sent to the data terminal, the terminal active flag remains set and on the next pass through XDEM, TERMBUFFF
is filled with more data packets.

Also added to the control microprocessor 74 are interrupts generated by a transmit/receive interface 92 (sometimes referred to as a "modem"). Transmit/receive interface 92 generates an interrupt signal whenever it receives a data byte from receiver 72 as well as when it transfers a data byte for transmission by transmitter 70. When microprocessor 74 receives an interrupt from transmit/receive interface 92, it executes the interrupt routine MODINT shown in FIG.

Microprocessor 74 first determines whether the transceiver is in transmit or receive mode (20th
block 1050). After performing several other tests, microprocessor 74 stores the modem vector address bytes in blocks of 1200 internally.
Push it into the stack. These modem vector address bytes contain the address of the routine that handles one byte transfers to and from the transmit/receive interface 92. After this, the control microprocessor 74 executes a return (not a return from an interrupt) so that control operations are automatically vectored to the appropriate routine whose address is specified in the internal stack for execution. . After this processing routine is finished, a return from the interrupt occurs.

All processing routines transfer one byte to or receive one byte from the modem chip. Other processing on received or transmitted bytes may also be performed by specific processing devices. After this, the processing routine executes a RETURN FROM INTERRUPT. Therefore, before a different processing routine takes over,
A processing routine can be executed multiple times.

Using vector-addresses is a coding method for jumping to a specific routine without using a CALL command.

Anyone familiar with 8031 microprocessor code will understand this scheme.

Data is sent or received in a particular order (i.e. dot preamble or sub-preamble, data packet,
EOM), so when one part is finished, the next part to be processed is known, and the vector address is set in the preceding routine.

If 5TRTTX (Figure 20A) is not called to begin transmitting data, routine MOD I NT (Figure 20A) is called.
) is set to receive (default state). Therefore, the modem vector address is first
VENT (Figure 20B (DRCVENTC)
Q] o-far-)).

Subroutine 5TRTTX (Figure 20A) is not itself part of the modem interrupt; it is called from the main routine to initiate the transmission of data. Subroutine 5TRTTX is block 524 of the XDOM routine.
is called from the DOM to begin sending the dot pattern of data bursts. 5TRTTX is also called by the DEM at block 822 of the XDEM routine to begin sending the dot pattern for the confirmation message.

Routine 5 TRTTX is the transmit/receive interface 9
2 to transmit mode and sets the flag TXMODE to signal that the transceiver is in transmit mode. Dot pattern bytes (101010...
. Next, the microprocessor modem vector address is set to routine TX
It is set to the starting address of DOT (which causes the transmission of dot portion 162 shown in FIG. 5) and commands a return to the calling routine.

T while the model interrupt handler is sending a dot pattern
Vector to XDOT, routine TXDOT in Figure 24
sends a dot pattern of bytes to interface 92 (block 1066) and increments a byte counter. The value of the byte counter is then tested to see if it is equal to 48 (decision block 1068
). If so, the 384et of the dot pattern has been transmitted, and the transmission of the dot pattern is complete. Send extra dots so the transmitter can take over. Decision block 1068 determines whether more dots
Once it is determined that a pattern needs to be sent, it simply returns from the modem interrupt (block 1070). On the other hand, when the transmission of the dot .phi. pattern is completed, the byte counter is cleared and the modem vector address of microprocessor 74 is set to routine TXAMBLE. This routine provides for the transmission of preamble 158 (block 1072) or subpreamble 160. Then return from modem interrupt.

The modem interrupt handler vectors to TXAMBLE when transmitting a preamble or sub-preamble. Routine TXAMBLE is shown in FIG. In a preferred embodiment, the format of preamble 158 or subpreamble 160 is TXPREAMBUFFF.
It is stored in 30g. Routine TXAM in Figure 25
The BLE simply retrieves the stored preamble/subpreamble pattern one byte at a time from TXPREAMBUFF and transfers the pattern to the transmit/receive interface 92 (block 1074).

- Once a complete synchronization order 158 has been transmitted (this is according to the test in decision block 1076), the GRO! tracks the number of synchronization orders 158 that have already been transmitted! JP C0UNT
After incrementing the ER (block 1078), a decision block 1080 tests whether 12 repetitions of the synchronization order 158 have been sent. If less than 12 iterations of the synchronization sequence have been sent, a return from interrupt is performed and the transmit/receive interface 92 receives block 1
074 to allow time to process the transmitted bytes. Once all 12 iterations of synchronization order 158 have been transmitted, decision block 1082 determines that the transceiver
Test whether it is working as Radio is DO
If M, TXHDR is sent only if the first data burst is sent. If it is not the first data burst, the data packet is sent immediately after the sub-preamble. If the transceiver is operating as a DOM, the next step is to send the I V/S S order 166 on the next modem interface interrupt, so that block 1084 sets the modem vector address of microprocessor 74 to , I V/SS sequence 166 is set in the routine TXHDR (see FIG. 26). On the other hand, the transceiver is DEM 5B
When operating as
(see Figure 7) is set to the start address of (Block 10
86). A return from the interrupt then occurs.

The routine T X HD R (1, IV
/SS order 166 transmission. Bu C1
Yuri 10gg is EV/SS order 166 guard band,
Send initialization vectors and optional communication fields. Decision block 1090 determines (based on the value of a byte counter used to track the number of bytes already transmitted) that the entire repetition of the guardband, initialization vector, and optional communication word has already been transmitted. (blocks 1090.1092). Blocks 1094.1096 transmit the CRC field in the guardband. Additionally, block 1096 includes IV/SS
After each iteration of sequence 166 is sent, clear the value in the byte counter and read the transmitted I V/S S
A GROUP used to track the number of repetitions of a sequence
Increment C0UNTER. Decision block 1098 determines whether all nine iterations of the lV/SS sequence have been transmitted, and if so, block 1100 stores the starting address of routine TXDATA in the vector address of microprocessor 74. .

The routine TXDATA shown in FIG. 28 is D.

M 52 performs the transmission of a collection 154 of data packets. Routine TXDATA of FIG. 28 is executed after header portion 152 is transmitted.

Decision block 1102, shown in FIG. 24, tests whether the byte counter (which tracks the number of bytes in a data packet being transmitted) is less than the number of bytes per packet (ie, the value M).

If the byte counter is less than M, data bytes are transferred from the TXDATABUFF 306 to the transmit/receive interface 92 and the byte counter is incremented (block 1104). A CRC is also calculated (see Figure 28).

If byte counter is not less than M, decision block 1
106 checks whether the byte contention counter is equal to M (indicating that this byte is the last byte of the data packet currently being transmitted). Block 1104 tests whether the byte counter is less than M. If the byte counter is equal to M, each data
The low byte of the CRC field at the end of the packet is transmitted by block 1108 and a byte counter is incremented.

On the next pass through routine TXDATA, the byte-counter exceeds the value of M by one, and block 1110 is executed to transmit the high byte of the CRC field, clear the byte contention counter, and increment GROUP C0UNTER ( In this routine, GROUP C
0UNTER to track the number of data packets sent).

Next, decision block 1112 determines that GROUP C0UN
Determine whether TER is equal to N (number of data packets in each data burst). GROUP
If the value of C0UNTER is less than N, more data packets should be sent in the current data burst and a return from interrupt occurs (block 111
4). If the value of GROUP C0UNTER is equal to N, the microprocessor's modem vector number address is set to the start address of routine TXDOT (to begin transmitting the end of message field 166) and the end of message flag is also set. (Block 1116). The EOM field is initiated by a modem interrupt and the routine XDOM or XDEM sends a ``directly J EOM.''

To explain about the 25th diagram, Judgment Block 1
If 082 determines that the transceiver is a DEM, it must send an acknowledgment message 170, shown in FIG. 8, and control microprocessor 74 vectors to routine TXACK, shown in FIG. Judgment block 11
18 tests the value of the byte counter to determine whether the entire repetition of confirmation field 174 has been transmitted.

If the entire confirmation field has not yet been sent, block 1120 sends the data byte TXDATABUFF
306 to the transmit/receive interface 92 (thus indicating, for example, packet reception status or a portion of the message field 178).

When the packet or status field 176 and message field 178 are completely transmitted (as per the test of block 1122), block 1124.112-6 returns the CR.
C field 180, clears the byte-counter, and increments GROUP C0UNTER (this routine uses GROUP C0UNT to factor into the number of repetitions of confirmation field 174).

Decision block 1128 determines whether confirmation field 174 has been transmitted nine times. If the confirmation field has not been sent 9 times, a return from the interrupt occurs (block 1130), and when this higher interrupt occurs, the routine TXACK is entered again and the confirmation field 17 is sent.
Send the rest of 4. If 9 repetitions of confirmation field 174 have already been sent, block 1132 is GR
Clears OUP C0UNTER and sets the microprocessor 74 vector address (to begin transmitting end of message field 156) to routine TXDOT.
Set to the starting address of

FIG. 21 is a flowchart of routine RXHDR which performs the task of receiving header portion 152 when the transceiver acts as DEM 58. Decision block 1220 tracks the number of bytes of header 152 received and block 1222 tracks the number of bytes of header 152 received.
The information from 2 is transferred to RXPREAMBUFF 310 and received.

performs an error checking function on the received bytes, and performs the task of incrementing a byte counter (thus keeping track of the number of header bytes received). When the entire repetition of a heading is received (decision block 1220), decision block 1224 determines whether the received data is error-free. If the received data is correct, it is determined whether a flag called valid heading is already set (block 1226). (If set, a valid heading has already been received for this message) If this is the first valid heading received in the current message, block 1228 sets the valid heading flag. do. Block 1230 clears the byte counter and sets the GRO
Increment UP C0UNTER. When all repetitions of the heading have been received (as per the test of block 1232), a pointer is initialized to point to RXDATABUFF 312 and the modem vector address of microprocessor 74 is set to routine RXD as shown in FIG.
Set to the start address of ATA. Both prepare for receiving a collection 154 of data packets (block 12
34).

Routine RXDATA, shown in FIG. 22, transfers a collection of data packets 154 from transmit/receive interface 92 to RXDATABUFF 312. Decision block 1250 tracks the number of bytes already received in the data packet currently being received, and block 1252 performs error checking on the received data bytes as they arrive and determines the number of received data bytes. RXDATA
Transfer to BUFF 312. Judgment block 125O
determines that the entire data packet has been received,
Decision block 1254 determines whether the data packet was received without error (based on the results of the error checking performed by block 1252) and sets bits accordingly (blocks 1256.1258).
). Block 1260 then stores the error indication bits in the previously mentioned CRC map, and block 1262 stores the bytes.
Clear the counter. Next, decision block 1264
Determine whether the entire N data packets of the current message have already been received. If the current message is not yet complete, a return from interrupt occurs (block 1266) and routine RXDATA is entered once again to receive additional bytes of the next data packet.

If all N data packets have been received, block 1268 sets a flag RXDONE to indicate that the entire message has been received, disables interrupts, and returns the routine MODI until after it sends a confirmation message.
Prevent NT from being called.

Routine R used by DOM, shown in Figure 23.
XACK sends the received confirmation message 170 from the send/receive interface 92 to RXDATABUFF.
312. Judgment block 13
00 tracks the number of acknowledgment bytes received, and block 1302 actually forwards the acknowledgment message bytes from interface 92 to RXDATABUFF 312 (along with performing a C10 error check on each byte as it is received). and increment the byte counter). If decision block 1300 determines that the entire confirmation field 174 has been received, decision block 1304 tests the received confirmation field for errors based on the CRC result calculated by block 1302. If the received acknowledgment field is error-free and this is the first error-free acknowledgment field received in this message (as per the test of block 1306), then setting the flag VAL IDACK;
The contents of the packet RX status field 176 from the correctly received confirmation field are loaded into the CRC map data structure (block 1308). (This CRC map data structure shows which data packets
8 and must be retransmitted) Block 1310 registers the in-byte counter and the GR in preparation for receiving the next repetition of confirmation field 174.
The OUP C0UNTER is reinitialized and decision block 1312 determines whether all repetitions of the confirmation field have been received.

When all repetitions of the confirmation field have been received, block 1314 sets a flag RXDONE to indicate that the entire confirmation message 170 has been received.

One important feature of this invention is the use of CRCMAP to inform the DEM of the status of received packets. The packet number is not sent with the packet sent from the DOM. DEM also does not send the packet number for confirmation. C
Using RCMAP reduces the overhead in the number of bits sent to any message (confirmation or data).

This helps achieve the effective data rates mentioned earlier.

A digital wireless transmit and receive communication protocol and associated apparatus has been described that has a very low error rate per bit, is tolerant of deleterious phenomena in communication lines such as noise and fading, and is compatible with conventional protocols. Although this invention has been described in what is presently considered to be a practical and preferred embodiment, the claims are not limited to the illustrated embodiment, but rather include any novel features and advantages of this invention. It is intended to include all modifications, variations and equivalents. By way of example and not by way of limitation, while the preferred embodiment of the invention uses a wireless transceiver, the invention also uses a transmitter,
It can be used with a receiver or other wireless communication device.

[Brief explanation of drawings]

FIG. 1 is a simplified time diagram of a conventional digital communication format, FIG. 2 is a schematic diagram of a communication system 50 according to a presently preferred embodiment of the present invention, and FIG. 3 is a diagram of a communication transceiver shown in FIG. FIG. 4 is a simplified block diagram illustrating the data burst communication format of the presently preferred embodiment of the invention; FIG. 5A is a diagram showing an example of the format of the guard band field shown in FIG. 5, FIG. 6 is a diagram of a sub-preamble part of an example of the communication format shown in FIG. 4, and FIG. is a schematic diagram of an assembly of data packets as an example of the data burst communication format shown in FIG. 4, and FIG. FIG. 9 is a simplified block diagram of an example buffer used in the transceiver shown in FIG. 3 to process the signals shown in FIGS. 4-8. , FIG. 10 is a flowchart of an example program control routine XMAIN executed by the control microprocessor of the transceiver shown in FIG. , a flowchart of an exemplary program control routine XDOM executed by the control microprocessor of the transceiver shown in FIG. A flowchart showing a program control process as an example of routine 5HUFTX, FIG. 13 is similar to FIG. 11A and FIG.
A flowchart illustrating an exemplary program control process for routine FILLTX called by routine XDOM as shown in FIG. FIGS. 15A and 15B are a flowchart illustrating a program control process as an example of routine XDEM performed by a control microprocessor of the transceiver shown in FIGS.
Routine I called by routine XDEM shown in Figure B
Flowchart illustrating an exemplary program control process for NFBFF; FIG. 16 is a program illustrating an exemplary serial interrupt routine executed in response to a serial "interrupt" received by the control microprocessor of the transceiver shown in FIG. 17 is a flowchart showing a program control process as an example of the routine DETDAT called by the serial interrupt routine shown in FIG. 16; FIG. 18 is a flow chart showing the serial interrupt routine shown in FIG. 16. The routine TRM called by
19 is a flowchart showing a program control process as an example of the MSG; FIG. 19 is a flowchart showing a program control process as an example of the routine 0UTDAT called by the serial interrupt routine shown in FIG. 16;
Figure 0 shows one of the modem interrupt routines executed by the control microprocessor of the transceiver shown in Figure 3 in response to interrupts generated by the transmit/receive interface.
A flowchart showing an example program control process,
FIG. 20A shows a flowchart of interrupt routine 5TRTTX, FIG. 20B shows a flowchart of interrupt routine RCVENT, and FIG. 21 shows program control steps as an example of a routine used to process the header portion of a received data burst. Flowchart, FIG. 22 is a flowchart illustrating exemplary program control steps of the routine RX DATA used to process the data portion of a received data burst; FIG. 23 is a flowchart illustrating the program control steps of an example routine used to process the data portion of a received data burst; FIG. FIG. 24 (this is shown on the same page as FIG. 9) is a flowchart showing the program control process as an example of the routine RXACK used for transmitting the dot pattern. FIG. 25 is a flowchart showing the program control process as an example of the routine TXAMBLE used for transmitting the preamble part, and FIG. 26 is the flowchart showing the control process.
Routine TX used to send the heading shown in the figure
A flowchart showing a program control process as an example of HDR, FIG. 27 is a routine TX for transmitting a confirmation signal.
A flowchart showing a program control process as an example of ACK, FIG. 28 is a routine TXD for transmitting data.
3 is a flowchart showing a program control process as an example of ATA.

Claims (1)

Claims: 1) A method for reliably exchanging bursts of digital data packets between a first point and a second point, the method comprising: (N) digital data packets and transmit N digital data packets at a second point.
A binary-encoded N bit map of the digital data identifying any data packets that have not yet been correctly received at the second point is checked for correct reception of all N packets. from a point to a first point, retransmits at least the identified data packet, if any, from the first point to a second point, and transmits all N packets to the second point. A method that includes the steps of repeating the process until it is received correctly. 2) A method for transmitting a digital signal from a data-originating digital radio transceiver to a destination digital radio transistor via an RF communication line, in which a plurality (N) of successive data packets are used as a first data burst to transmit said data. transmitting from an originating transceiver to the destination transceiver over the RF line, receiving the first data burst at the destination transceiver, and determining which of the N data packets the destination transceiver correctly receives. , determining which of the data packets the destination transceiver incorrectly received, and transmitting another data burst containing N successive data packets including the incorrectly received data packet to the destination transceiver; A method comprising retransmitting data from an originating transceiver to the destination transceiver. 3) The method according to claim 2), comprising the step of transmitting a confirmation message from the destination transceiver to the originating transceiver via the communication line, the confirmation message including the first data. A method of indicating which data packets within a burst were received correctly and which data packets within said first data burst were received incorrectly. 4) In the method described in claim 2), further:
transmitting a confirmation message from the destination transceiver to the originating transceiver over the communication line in response to the destination transceiver receiving the first data burst, the confirmation message determining the A method, the method comprising: the step of retransmitting comprising selecting a data packet for retransmission in response to the confirmation message. 5) The method of claim 2), wherein said step of retransmitting comprises retransmitting each of said incorrectly received data packets a plurality of times, A method in which no data packet is retransmitted more than once than any other incorrectly received data packet. 6) In the method described in claim 2), further:
transmitting a confirmation message from the destination transceiver to the originating transceiver over the communication line in response to the destination transceiver receiving the first data burst, the confirmation message determining the the step of retransmitting selecting a data packet for retransmission in response to the confirmation message and transmitting N data packets in the another data burst; A method comprising retransmitting each of said selected data packets multiple times (x) until the packet is transmitted, wherein none of the selected data packets is transmitted more than (x+1) times. 7) In a method of transmitting a digital signal from a data originating digital radio transceiver to a destination digital radio transceiver via a communication line, a plurality (N) of successive data packets P(1)-P(N) are first transmitted. 1 data・
transmitting the data as a burst from the originating transceiver to the destination transceiver over the RF line, receiving the first data burst at the destination transceiver, and transmitting the data packets P(1)-P by the destination transceiver. (N) are correctly received and which of the data packets are incorrectly received by the destination transceiver, and divide the correctly received data packets into up to Q data packets. a new packet P(N+1)-P(Q) that may be stored in the buffer, leaving room in the buffer for the incorrectly received data packet; a number also indicates the number of new packets that the buffer can store, and another data packet from the data originating transceiver to the destination transceiver, including the incorrectly received data packet and the number X new data packets. retransmitting the burst and the incorrectly received data packets are retransmitted until the number of data packets in the another data burst totals N;
12. A method comprising steps repeated sequentially, wherein no data packet in said another data burst is repeated more than once than any other data packet in said another data burst. 8) Digital control and digital
A transceiver for transmitting and receiving data signals includes transmitter and receiver means for transmitting and/or receiving a series of digital signals, and a transceiver connected to the transmitter and receiver means and having a time interval approximately Sequence (a) A preamble portion having (1) an alternating 1, 0 dot pattern, (2) (i) a 16-bit synchronization word S containing a multi-bit barker code, (ii) a 16-bit outer address word OA containing a multiple bit sequence repeated at least once such as to indicate whether the string of digital data to be subsequently processed includes a digitized audio signal or other form of digital signal; , and (iii) (indicating which of the 12 repetitions) 1
12 repeating sets of 6-bit synchronization number codes; (3) (i) a 64-bit guard band; (ii) a 64-bit cryptographic initialization vector; and (iii) a 16-bit sequence identifying the intended message recipient. nine repeating sets of selective communication codes; (b) strings of digital data, each representing a digitized audio signal or other form of digital signal; (c) a plurality of successive data packets containing an 8-bit repeat byte (indicating whether the data is a repetition of a previously transmitted packet); control means including a digital data microprocessor system programmed to control said transmitter and receiver means to process signals. 9) In the transceiver as set forth in claim 8), the control means transmits the plurality of successive pieces of data approximately in the following order: (a) a 4-bit command code indicating a task to be performed; - 1-bit NP code (indicating whether the packet is not present in a given message); (c) 1-bit command central execution control bit; (d) 8-bit subgroup (indicating the transceiver generating said message) (e) an 8-bit subgroup destination code SUBGD (indicating, along with said selective communication signal, the intended recipient of said message); (f) in each of said plurality of data packets; 6-bit BP indicating the number of bytes (M) of digital data
P code, (g) the number (N) of the plurality of successive data packets;
A transceiver for processing said 64-bit guardband by processing a digital signal with a 6-bit PPB code indicating: (h) another 14 bits of the digital signal, and (li) 16 bits of an error check signal.