Trunked radio repeater system

Description: TECHNICAL FIELD [Detailed description of the invention]

The present invention generally relates to a trunk wireless relay system. More specifically, the present invention utilizes a digital control signal transmitted via a dedicated control line, while also using a plurality of operating lines that are temporarily allocated for use by individual wireless devices. Regarding such a method. The trunk operation of wireless repeaters is well known. Early trunk schemes used analog control signals, while some recent schemes use digital control signals. Control signals are used on dedicated control lines and / or different operating lines for a variety of different reasons, but their effects are also different. We do not intend to cover conventional publications and patents that describe conventional trunk wireless relay systems, but typical examples are US Pat. Nos. 3,292,178, 3,458,664, 3,571,519, and 3. 3,696,210, 3,906,166, 3,936,616, 3,970,801, 4,001,693, 4,010,327, 4,012,597, 4,022,973, 4,027,243, 4,029,901, 4,029,901 4,128,740, 4,131,849, 4,184,118, 4,231,114, 4,309,772, 4,312,070, 4,312,074, 4,326,264, 4,339,823, 4,347,625, There are 4,360,927, 4,400,585, 4,409,687, 4,430,742, 4,430,755, 4,433,256, 4,450,573, 4,485,486, and 4,578,815. U.S. Pat. No. 4,360,927 provides a dedicated control line by performing a handshake with the controller at the repeater point on the captured "free" operating line before allowing communication with the called device. This is an example of the conventional line switching relay method that avoids using. The trunk wireless relay system actually has many uses, and various other uses are conceivable. However, one important use is the public trunk (PST) scheme. For example, it is advantageous for an urban area to utilize one system of trunk radio repeaters for efficient radio communication between individual radio devices within many different institutions. Each agency can efficiently communicate between individual units or sub-units of different groups (eg, different portables assigned by the police station to different units of the patrol car, patrol patrols). Efficient communication may be required between different units, criminal or drug investigator units, etc.). In some cases, it may be important to communicate simultaneously with a limited group of units (eg, all units, all police cars, all patrol police officers, etc.). At the same time, other agencies (eg fire departments, transport departments, water departments, emergency / emergency services departments, etc.) may require similar communications services. As is well known if you know trunk theory, a relatively small number of radio repeaters, if they are trunk-connected (ie, "as needed" among all potential units. (In a shared format), it can efficiently serve all these demands within a given geographic area. The present invention is particularly suitable for Shingled Magnetic Recording (SMR) trunk users. In this case, a company needs to set up a trunk radio relay system at one point or more points in a predetermined geographic area to perform efficient radio communication between individual units of the specific organization. Broadcast time can be sold to different independent entities or other organizations. In many respects, SMR user requirements are similar to PST user requirements. In fact, the potential benefits of public trunk wireless relay systems are so well recognized that they are therefore the Association of Public Safety Communications Officers Incorporated (formerly the Association of Police). An organization (APCO) called Communications Officers has developed a set of highly desirable features for such a scheme, commonly referred to as the "APCO-16 condition". A detailed list and description of this condition can be found in available publications known to those of skill in the art. One of the APCO-16 conditions is that any user must be able to access the voice line within 0.5 seconds of activating the PushTalk (PTT) switch. This same condition must be met, especially in urgent situations. This means that this method must also be able to aggressively drop low priority users within a very short time frame. Of course, it is also important for the efficient use of the trunk equipment to be able to quickly and efficiently drop the line allocation as soon as the line use is completed, even in cases other than emergency. The conventional trunk radio system attempts to satisfy the time condition of this APCO-16 "just". For example, the published specifications of one conventional method indicate that it is capable of updating the line within 450 ms (in the case of the 19-line method) and dropping the line within 500 ms. To achieve this, we use 3,600 bits per second (bps) of digital communication over a dedicated digital control line. Unfortunately, the time condition of APCO-16 should theoretically be satisfied by such a conventional method, but in reality, the time condition of APCO-16 is often not satisfied, or At the expense of, if met, the apparent negative consequences of somewhat unreliable digitally controlled communications (which, at best, is annoying even in non-emergency situations). Therefore, there is considerable room for improvement. The present invention is generally a digital trunk radio system of this type, which provides significant improvements in both timeliness and reliability of critical control communications. First, it uses a much higher digital communication speed (9,600 bps). However, in order to achieve an improvement rate of 9,600 / 3,600 = 2.6 times in terms of timeliness, instead of using all of the high communication speeds, most of the increased communication speed capacity is to improve the reliability of communication. Use for. Therefore, for example, the timeliness of the ability to update 19 lines has been improved by about 1.58 times (for example, from 450 ms to 285 ms), and the remaining increased communication capacity makes control communication more reliable. Used to enhance. At the same time, it takes advantage of almost all of the increased communication capacity to improve the timeliness of line drop capability (eg to 190 ms compared to 500 ms). Previously published by Bell System Technical Journal on AMPS (eg Bell System Technical Journal, Vol. 58, No. 1, January 1979, pp. 97-122, Aledondo et al. As demonstrated in the paper "Voice and Data Transmission"), the digital data rate of wireless lines should be very low (eg 200 Hz) or as high as the bandwidth of the line allows. The present invention provides the maximum high data rate (eg, a radio line with a typical 25 kHz bandwidth) for critical control line communication and control communication on the operating line, both immediately before and after the user communication period. Then, 9,600bps) is used. Further, during the user's communication, low-speed digital data lower than the audible range is also used in the operating line to further guarantee the reliability of the communication and realize additional features. In the embodiment, all the lines (control line and operating line) are full-duplex, and all the lines can communicate inward and outward at the same time. Generally, the present invention is in a trunk radio relay system having a digital control line and a plurality of operating lines assigned for temporary use by individual radio devices identified by digital control signals on the control line. Achieve reliable and immediate communication. By sending a digital request signal to the control point via the active control line, the calling radio device first requests line allocation. According to the utilization of the line, the controller at the central point allocates a specific operating line that can be used at that time for the requested communication, and sends a digital allocation signal outward through the control line. Both the calling device and the called device detect the allocation of the operating line and switch the operation of its transmitter and receiver to the correct operating line. The digital handshake signal is then exchanged again between the control point and at least one radio device (eg, the calling device) via the assigned operating line. In response to a successful handshake on the assigned operating line, the central point then sends a digital release signal over the assigned operating line, releasing the appropriate device for communication over that line. To do. As one way to increase reliability, the initial solicitation signal has triple data redundancy (at least for important data (which may have, for which it is then transmitted over the control line). The assigned signal may have as much as six redundancy of data (eg, at least important data such as representing the called party and the assigned line), after which the handshake exchanged on the assigned operating line The signal may also have triple data redundancy of at least important data, so that some of the increased communication capacity made available by high data rates (eg 9,600 bps), It is sacrificed for more reliable line allocation and communication capabilities, but still well above all APCO requirements. Digital line allocation update messages below the audible range are also transmitted over the allocated operating line to ensure responsiveness to higher priority calls. At this time, each device in this operating line monitors it. Therefore, if a higher priority call is directed to a device that is already in communication, this device is newly assigned an action to immediately receive this higher priority call. You can instantly switch to the operating line. Furthermore, in order to allow the called party to join after the ongoing communication, even after the line allocation process is successful, the digital line allocation "late join" message continues on the control line. It was transmitted via, so it returned to wireless communication after a temporary interruption from the late participant (eg, the radio that had just turned off, the one that had just exited the tunnel, or the back of a building, etc.) Those with higher priority or completed equivalent calls) can be switched to the assigned correct operating line as soon as possible. (The feature of late participation itself relates to the pending US patent application serial number 725,682, filed April 22, 1985.) In order to terminate the line allocation immediately and surely, when the PTT switch of the calling device was released, a digital key release message was sent on the assigned operating line, and this key release message was received at the control point. In response, a digital drop signal is transmitted to the assigned operating line, causing all equipment to drop immediately from this line, thus freeing this operating line for reassignment. (Needless to say, when a predetermined wireless device drops from the assigned operating line, it automatically returns to the state of monitoring the control line.) The scheme of the present invention is sometimes referred to as the "digital" trunk scheme because trunk control is performed by digital signals continuously transmitted over a dedicated "control" data line. All devices are programmed to automatically return to the scheduled primary control line when turned on or reset. If the expected control line data format is not found on this control line, this alternative possible control line is monitored one after another in the planned order until a valid control circuit is found. By doing so, it is possible to temporarily remove the ordinary control line device at the central control point (for example, for maintenance) from the business. This same feature allows the trunk system to continue operation if the legitimate control line malfunctions unexpectedly or otherwise does not work. The embodiments of the present invention are designed to meet all the requirements of the existing APCO-16 and, in many respects, outperform it. This is an available voice encryption method, mobile digital data terminal equipment (which can send digital data instead of analog voice data during the relay radio communication period) and / or available vehicle location confirmation. It can also support the method. It is preferable to use a fault-tolerant architecture to maintain trunk-style operation in the event of a central processor accidentally failing at a control point (pending US patent filed June 3, 1987). See application 057,046). When communicating digital data between radio stations or between central points, it can be processed by this method in the same manner as an analog audio signal. In particular, such digital data communications are carried out at speeds that fall within the existing audible transit band and are relayed in the same way as desired voice communications (ie, do not require a dedicated digital data communication line). To help increase the reliability of digital data communications, data transmission (as well as analog voice transmission) can be voted by a voting method using a satellite receiver connected to a central control point. In the embodiment, a digital control communication message of the following format is used. Some general features and expected benefits of this example are summarized below. In the example scheme shown here, 11 bits may be used to determine the address of a device within an institution, group or quasi-group. 12 bits can be used to determine the individual identification code (ie, its "logical ID") for a particular device. By using 11 bits to determine the address of a group within an institution, group or quasi-group, flexibility is increased and each institution can have many different groups and quasi-group structures. Furthermore, the identification code of the device is not controlled by the structure of a particular group or quasi-group. The identification codes of 4,096 devices can be divided into quasi-organizations in a way that best suits a particular method. Certain features of the scheme in this example are considered to be particularly unique and advantageous, but they are summarized below (the order in which they are described does not reflect the order of importance, and this list is inclusive. It should not be considered as restrictive to the subject or the invention). B) Expansion of retry window If the requested operating line allocation is not achieved, the request is automatically retried, increasing the duration of this retry time window as a function of the number of unsuccessful retries so far. This also provides a recovery mechanism for the request contention problem, while significantly reducing the average line access time when noise is a real problem rather than the request contention problem. B) Better use of communications below the audible range Instead of using only sub-audible communications to check line allocation, a simple counter field is used to significantly simplify this validation function, thus leaving most of the sub-audible communications capacity elsewhere. Release for the purpose of, for example, scanning the priority. In an embodiment, a "count" field below the 2-bit audible range for a given line is included for each new operation allocation for that line. Therefore, if the radio is watching for changes in this field, the radio will be programmed to immediately drop back to the control line. C) Minimize the fragmentation of prioritized communications by dynamically changing the scanning function. After initiating a priority call, the radio is temporarily (eg, for 2 seconds) on the control line to favor looking for a higher-probability, higher-priority call to come back. Inactivates normal multi-group scanning. This reduces the possibility of temporarily turning to a lower priority communication in progress at that time and, in some cases, missing a portion of the next higher priority communication. Similar temporary (eg, 2 second) scan priorities (excluding prioritized calls) for the immediately preceding group of calls also help prevent fragmentation of non-priority communications. D) Use the transmission relay bit to allocate the line The trunk system has two relay modes. 1) Transmission relay mode in which the allocation of the operating line is released as soon as the calling device releases the key. 2) A message relay mode in which the operating line is unassigned "n" seconds after one device unlocks the key if another device does not key to that line within the same "n" seconds. N is called hang time. By dynamically assuring that both the called and the called device "know" that the transmit relay mode is working, the called device immediately returns to the control line when the PTT is released. This allows the operating line to be immediately released for channel drop communication from the control point. The called device can also positively prevent continued transmission on the operating line, thus avoiding multiple key connections of the wireless device to the operating line. E) Automatic addressing of immediately returned calls The called and called device / group is identified in the initial line allocation communication. Even if the called device captures the calling device ID and the method is in transmission relay mode, if the PTT switch is pressed within the scheduled period (for example, 5 seconds) from the communication just completed, the radio of the immediately preceding caller You can automatically address the return call to. This not only simplifies the required return call procedure and shortens access time by expanding the use of the transmission relay mode, but also increases the probability of successful message exchange, especially in bad communication areas. F) 9,600 bps allows for "loose" synchronization By using high speed communication at 9,600 bps, a simple "dot" order (ie, alternating 1s and 0s string 101010 ......) can quickly achieve simple bit synchronization. You can. Therefore, it is not necessary to maintain accurate synchronized information transfer across all lines. Therefore, not only the required hardware of the system scale is reduced, but also the architecture that is highly tolerant of failure can be easily obtained at the control point. G) Improved line drop communication Channel drop communication is simply an extended dot order. Therefore, each radio can easily search for channel drop communication and confirmation of channel allocation at the same time. This allows the control point to more immediately consider a given operating line that can be used for reassignment, as well as immediately interrupting the line drop signal if it is "full of load". It means that a new channel allocation confirmation signal of the operating line can be issued (each individual radio ignores it if it is not addressed correctly). As a result, the "load state" method (ie, the method in which the existing line request is already queued) drops the operating line within approximately 100 milliseconds and immediately turns that line into a queue request. Can be assigned. A radio that happens to join the dropped call can detect this fact and drop it correctly from that line. This is because line drop communication and channel allocation confirmation communication can be searched at the same time. H) Feature programming New steps to allow the end user to do all this "programming" to avoid cumbersome feature programming (and reprogramming to add features) by factory or delivery personnel. Use. All devices are factory programmed to perform all available functions. The function function bitmap and unique physical ID are encrypted together at the factory and supplied to the user as "program code". When the user programs each device, its encrypted "program code" is input to the wireless programmer, who is characterized by the wireless device connected to it ... and Correctly set the decrypted physical ID ... and the "just programmed" bit. A "just programmed" radio is recorded in the central controller with a request for a logical ID based on its apparent physical ID. If the program code that activates the function is illegally copied, the same logical ID will be assigned, and the usefulness of the radio in the trunk relay system will be reduced. I) Double line allocation handshake ...... One is the allocation operation line The first 9,600 bps line allocation communication exchange takes place on the control line. However, after this, a confirmation (ie, a second handshake) is performed on the assigned operating line. Therefore, it is guaranteed that the desired line is successfully assigned and locked before the central controller demutes the called device on the assigned line. In the communication, if the line condition is inappropriate for voice, the handshake is not established, and thus the call is automatically terminated. The above and other objectives and advantages of the present invention will be more fully understood if the following are carefully considered to elaborate on the currently preferred embodiments of the drawings. The trunk wireless relay system as an example according to the present invention is shown in FIG. 1 as a whole. As shown, different groups of individual devices communicate with each other via a shared wireless relay line at trunk repeater control point 100 (inside or possibly outside of their own group). The transmission console 102 may be provided directly at the point 104 of the relay station, or may be provided at a remote location via another communication facility 106, as will be appreciated by those skilled in the art. As will be appreciated by those skilled in the art, there may be a large number of outgoing consoles 102 (eg, one console for each separate organization) and a master or monitoring-like outgoing console for the entire scheme. The central point is shown in some detail in Figure 2, along with point 100-1 for one or more satellite receivers. As you can see, the point of the satellite receiver is spatially distant from the central point 100, and when it is at one or the other of the selected antenna locations, the radio reception is temporarily better. There is. For this reason, the received signals from the satellite and central points are combined in a "voting" circuit to select the best signal available for the control or communication process. At the central point, transmit antenna 200 and receive antenna 202 (which may have a common antenna structure in some cases) can be used with ordinary signal combination / uncombination circuits 204,206, which will be apparent to those skilled in the art. Is. That is, the transmit and receive RF antenna circuits 200-206 individually serve a plurality of dual RF line transmit / receive circuits in the plurality of RFT "relay stations" 300, 302, 304, 306 and the like. Typically, there may be 20 such stations. The transmission and reception circuits of each station are typically controlled by a dedicated control shelf CS (eg, a microprocessor-based control circuit), also as shown overall in FIG. The logic circuits of such a control shelf associated with each station are controlled by a tracking card TC (eg, another logic control circuit based on a microprocessor) 400,402,404,406. All trunking cards 400-406 communicate with each other and / or also with the primary point controller 410 via the control data bus 412. The primary point controller (and, optionally, the assistive controller) may be a general purpose processor available on the market (eg, a PDP11 / 73 processor with an 18MHz-J11 chip device). The main "intelligence" and control capability for this system as a whole lies in the controller 410, but so that the trunk relay service can be continued even if the controller 410 malfunctions or otherwise fails. Alternate support or "failsoft" control functions can be incorporated into trunking cards 400-406 (for more information on such failsafe features, see U.S. Patent Application Serial No. 057,046, supra. See). An optional telephone interconnect 414 can also be provided for the interchangeable public telephone line. Typically, a system management terminal device, printer, etc. 416 is also provided (along with one or more outgoing consoles 102) for overall management and control of this system. If desired, special testing and alarm equipment 418 can also be provided. The signal "voting" circuit 502,504,506,508 receives multiple input digital or analog signals and connects them to selectively output the strongest and / or other form of the most reliable one of these signals. Has been done. That is, the received signal from the central point 100 is input to the voting circuits 502 to 508 of each line, while another similar input signal is generated from the receiver at the satellite receiver point 100-1. It is input to each voting circuit. The result of the voting process is then returned to the trunking card circuits 400-406, where it is further processed as a valid "receive" signal. A slightly more detailed diagram of the site architecture for control data communications is shown in Figure 3. This figure shows that the PDP11 / 73 controller 410 communicates with up to 25 trunking control circuits TC via a 19.2 kilobit link 412 to control each dual relay circuit on a separate line. Has been done. Use another high-speed 19.2 kilobit link 420 to contact hardware that assists in downlinking with the outgoing console 102. Other data communication with the central processor 410 is via a 9,600 bps link, as shown in FIG. The central processor 410 may include, for example, 128 kilobytes of code PROM, 1 megabyte of RAM and a 32DHV-11 / J compatible RS-232C port. It will be an event-driven operating system that performs multiple tasks that manage all of the various data communication ports, typically in a real-time manner that can be programmed and accepted using micropower pascals. To. For each controlled relay line, a 19.2 kilobit data bus 412 (and, if desired, a bus from an optional support controller) is monitored by the 8031 processor in the TC module. The TC trunking control module controls the control shelf CS of the associated repeater with audio, communication and control bus as shown in Figure 4, typically clock synchronization and "fail soft" display (eg, center). Indicates that normal control by controller 410 is not available, and in that case an alternate distribution control algorithm should be implemented within each trunking control module TC). It also receives input. The general architecture of a suitable mobile station / portable radio device for use in this example scheme is also as shown in Figure 5. is a base of Lee black processor. In this case, the microprocessor 550 has a suitable memory 552 and an input / output circuit 554, which is basic to the speaker as well as to interface with the display, keypad, pushtalk (PTT) of the wireless device and the switch. It also has an audio circuit 556 that receives an analog audio input from a microphone while supplying an analog audio output. Auxiliary control over the modem 558 as a digital interface (for example, for voice encryption, vehicle location or other forms of digital communication systems) can also be provided if desired. Of course, the I / O circuit 554 allows the RF receiver 560 and the transmitter 562 to have the appropriate programmed control action, and these receivers and transmitters are via ordinary signal combiner 564. , Allows full-duplex communication in both directions from the common antenna 566, which is well known to those skilled in the art. A detailed explanation of all the devices and quasi-devices of such advanced schemes will inevitably be extremely enormous and complex. However, since those skilled in the art generally already know a digitally controlled trunk relay system having a suitable RF transmitter and receiver circuit, a programmed general-purpose computer controller, etc., such a huge detailed explanation is not possible. It seems necessary. Rather, it only obscures the whereabouts of the subject matter of this invention. Therefore, the following description will focus on the communication protocol used to start and end the call within the scheme. This brings significant improvements (both in terms of reliability and speed), while making it easier to meet or exceed all the requirements of APCO-16 and still retain many of the features of the highly desirable scheme. This is because it is considered to be a thing. When making a call, the calling device first sends a special digital line request signal to the central point via a dedicated control line. On the other hand, the central point transmits a special digital line allocation signal outward from the control line. At this time, the calling device responds and immediately switches to the assigned operating line, this time with the central point sending an allocation confirmation message (again in high speed digital format) on this assigned operating line. When the calling device correctly receives the confirmation signal on the operating line, it sends the approval back to the central point on the operating line, and the second handshake (ie, the first handshake is done on the control line, and this time it operates. After completing (done on the line), the central point releases the called device to monitor the communication period requested on the operating line. Instead, if during this process the calling device receives a line update message on the control line addressed to it (the currently issued line request is an urgent or higher priority request). (Otherwise) the line request call is temporarily interrupted, after which the calling device returns to the called state to receive the incoming call. If the calling device does not receive a response (or completes in an incorrect response handshake order), it automatically waits for an irregular period of time before successfully retrying the call request (maximum). Up to 8 times). The called device is initially in a standby state, which constantly monitors digital messages coming out from the central point via the control line. Upon detecting a line allocation message addressed to it as the called party (or possibly as a member of the called group), the called device immediately switches its operation to the assigned operating line. This line also detects a confirmation signal sent outward from the central point via the operating line, and if successfully confirmed, a release or squelch release signal from the operating line (this is, for example, a calling device on the operating line). (Sent from the central point in response to the successful completion of the handshake with) wait. The called device may also receive a line update message. This typically only ensures that you are already operating on the correct line. The program for the calling device is shown in the simplified flowchart of FIG. 6 as a whole. In this figure, when the call mode is entered, a call request is sent via the control line CC in step 600. Test the call queue at 602. If it is in the queue, it switches to wait loop 603, which includes testing the detected allocation in step 604 and subsequently checking for the 30-second timer to expire in step 606 (at this time). , Control returns to the manual condition for effectively resuming the call process via exit 607)). If the call request does not enter the queue, step 608 tests whether this particular device has previously been requested as the called party. If this is the case, the call operation mode is switched to in step 610. If this is not the case, step 612 checks the allocation of the returned line. If not received at the expected time, step 614 intervenes an irregular wait and then step 616 tests whether eight attempts have been made to complete this particular call. If so, exit this subroutine at 618. If not, re-enter this subroutine from 600. If channel assignment was successfully detected on either 612 or 604, the device operation was immediately switched to the assigned operating line in step 620 and was the second handshake (confirmation communication) successful on 622? Please be tested. If the confirmation on the operating line is unsuccessful, the subroutine exits and the call ends. However, when the second handshake (eg, the handshake on the operating line) was successfully confirmed and completed, the calling device sent a long dot sequence at 624 (eg, representing the success of the second handshake). Later, on the assigned operating line, 626 sends voice (or data if a digital communication period is requested) and then exits from subroutine 628 (for example, thus searching for the release of the PTT switch and keying at 627. To a standard monitoring routine that sends a release signal). The protocol taken by the called device is shown overall in Figure 7 (for example, representing a suitable computer program that controls the device in this mode of operation). Upon entry, simply monitor at 700 for "good" messages on the control line (eg, messages addressed to this particular device). If this message is detected, check the 702 for "updated" messages. If the message is in this format, the 704 checks to see if it repeats within about 1.0 seconds. If not repeated, the call mode is re-entered. However, if the update of the incoming call with higher priority is repeated within this period, it immediately switches to the operating line assigned at that time in 706. If communication is not confirmed on the 707, immediately switch to squelch release (716) and then monitor the line. On the other hand, if the communication is confirmed on the 707, this is an indication that the normal line allocation has actually been performed, and the control action shifts to the block 714 searching for the mute release message. If the line update message is not detected on the 702, check the message to see if it had a line allocation on the 708. Otherwise, go back to the beginning of the subroutine. However, if the correct line allocation is received, the operation line is switched to the operation line assigned by 710, and then the correct confirmation communication on the operation line is inspected at 712. Then, at 714, if the correct mute release message is also received on the assigned operating line, the called device is unsquelched at 716. If the 714 does not receive a mute release message, the 718 checks for a drop message. If there is no drop message, but high-speed communication is still present on the working line (as detected on the 720), the 714 will perform another check for the unmute message. However, if there is no drop message and high-speed communication ends at 720, the called device will still be unsquelched at 716. At the end of the desired audio call, the calling radio transmitter transmits a special PTT release signal, as shown graphically in FIG. After an appropriate transmission and detection delay period, the assigned operating line responds by transmitting a line drop signal over the line. As shown in FIG. 8, as a result, the number of operations is typically available within only 167 milliseconds after the start of the PTT release signal. The typical timing of the caller protocol signal is graphed in Figure 9, where the typical caller protocol is completed in about 290 ms to initiate communication on the desired operating line. You can see that you can do it. A few bit-level maps of one related message format (as well as other related communication formats and protocols) are graphed in Figure 10. The control line sends an outward continuous transmission that repeats format 800 as shown in FIG. As you can see, each 40-bit message is sent three times (including one inverted transmission that changes all 0s to 1s and 1s to 0s), and this per repetitive message time slot. Two messages like this are sent. Needless to say, the optional dot prefix (if used) guarantees continuous bit synchronization by the receiver, and the unique barker code allows frame synchronization, followed by 40. Limit bit boundaries between bit-level messages. Since the control line sends these message slots continuously, it does not require a dot prefix and a single transmission of the word frame barker code is sufficient for each repetitive transmission cycle. .. Of course, if desired, a relatively short dot prefix can be used to further guarantee continuous bit synchronization. The inbound message of the control line CC is of the form 802 shown in FIG. 10, and includes, for example, a group / individual line allocation request transmitted from the calling device. In this case, the dot prefix is fairly long, the word frame barker code is repeated three times, the central receiver circuit is properly synchronized, and then the 40-bit message (which also has triple redundancy). ) Will be sent. To ensure that these incoming control line messages are in synchronous time slots, that is, with messages coming out of the central point via the control line (as shown by the dashed line in Figure 10 overall). It is preferable to use an appropriate transmission timing circuit in order to generate a message in the inward portion of the control line in the same time slot. The request message format for group calls is shown enlarged in Figure 10. It contains a 2-bit message type (MT) code (the message type field, needless to say, can be extended to the tree logical form to include extra bits). For this reason, the MT-A field distinguishes group calls from individual calls, for example. The communication type field consisting of 2 bits indicates the type of communication period requested. (If desired, a 1-bit priority field can also be used to indicate whether an urgent call with the highest priority is being requested.) (Representing either a group or individual device) 11 Following the called party identification code of the bit, there is a 12-bit field that represents the identification (logical ID) of the calling party device. A 40-bit message ends with 12 bits of standard DCH code for error detection and correction. This will be easily understood by those skilled in the art. The return line allocation message is actually composed of two message pairs with the format shown enlarged in Figure 10. The first 2 bits identify the message type (MT) and the next 2 bits identify the type of communication period used. The calling device identification code is then represented by a 6-digit field (for example, the most significant 6 bits are transmitted in one message in a pair of two messages and the least significant 6 bits are in the other message. Will be sent by). The next 1-bit field identifies whether it is a group call or an individual call, and the assigned operating line is identified by the subsequent 5 bits. The group or individual identification code of the called device (s) is contained in the next 12 bits, followed by the 12 bits of the BCH error detection / correction code. Once returning to the operating line to which the operation is assigned, the central point sends a confirmation message of format 804 outward on the operating line. As we will see later, this is generally in the same format as the continuous transmission of control line CC, except that the message length is reduced to 32 bits on the operating line. Again, the message is sent with triple redundancy (one inverted). The confirmation message is the operating line, and it is preferable that the confirmation message comes within the same time slot as the message transmitted by the control line. The format of the 32-bit confirmation message is also shown enlarged in Figure 806. In this case, 4 bits are dedicated to the message type code, and another 2 bits are lower due to the slower audible range (which later appears on the operating line as monitored by the device on that line). The frame count is lower than the audible range, which is useful for frame cutting of digital data and other decoding. One bit is dedicated to identify the communication period as either a transmission relay or a message relay. Another 1 bit of confirmation message 806 identifies as either a group of calls or an individual device, and the identification code of the group of calls or the individual device is contained in the following 12 bits. Confirmation message 806 ends with 12 bits of BCH error detection / correction code. Once the second handshake (ie, on the operating line) is successful, the calling device also follows the 384-bit dot (if requesting an audio communication period), as also shown in Figure 10. Send an audio. The long dot sequence transmitted from the calling device on the operating line confirms that the handshake sequence was successful, and in response, the central point is to actively mute the called device. , Sends outbound digital messages over the operating line. The format 808 of this mute release message is shown in FIG. Again, the message type code uses the first 4 bits, and the frame count below the audible range is the next 2 bits. The next bit represents a relayed or non-relayed state (eg, regular hang time), and the next bit is not used effectively (eg, it is preset to 0 for all unmute messages). Can be used for other optional purposes. The identification code of the device (s) to be demuted is shown in the next 12 bits, followed by the standard BCH error detection / correction code 12 bits. At the end of the communication period on the operating line, the calling device retransmits four 128-bit data blocks, each following a 384-bit dot. Each of these data blocks contains 16 dot bits and a 16-bit barker code (some of which may be "filled", as you can easily see) as a prefix, followed by There are 8 bit bytes. Each byte is transmitted with triple redundancy (one inverted), thus forming a 32-bit message specific to digital messages transmitted over the operating line. The format of the 32-bit unlock message 810 is also shown in Figure 10. In this case, there is a 4-bit message type code followed by two unused bits, followed by a block count of two bits. The identification code of the calling device is shown in the next 12 bits, followed by the standard BCH error detection / correction code of 12 bits. Finally, in response to the central point receiving the unlock message on the operating line, an outward digital message in ultra-extended dot order (eg, 896 to 2,816 bits) is on the operating line, as shown in 812 in Figure 10. As such, transmitted from the central point and in response, all devices on this line then drop from this particular operating line and return to a valid control line. The sequence of programmed events that occur in the point controller, calling device, and called device (s) during a typical call / end sequence is shown in the parallel flowchart of FIG. .. Each programmed device has a hibernate control line (CC) monitoring routine, and when in hibernation, all devices and point controllers are in this routine. When the calling device enters the calling subroutine from CC monitoring at 1100, it is tested at 1102 to see if this calling is a retry. Otherwise, set the retry counter to a maximum of 8 at 1106 and decrement 1 at 1108 (this process would be entered directly from test process 1102 if retries or in progress). Will be done. When the retry Kanuta is decremented to 0 by the 1110 test, at 1112, an audible beep of acquisition failure is generated and goes out to CC monitoring. On the other hand, if the maximum number of retries has not been reached, slot synchronization over the control line at 1114 (eg, time t).₁Send a line allocation request. When an inward message is detected, the point controller receives and stores the line allocation request, and allocates a free operation line in step 1200. In this example method, the inward response to the request can be delivered within the scheduled delay time. In step 1204 (time t₂Send outbound line allocation messages (ie, message pairs) over the control line as quickly as possible. A pair of line allocations consisting of two messages is received and stored on the control line by the calling device in step 1118 (the device searches for messages up to the maximum number of slots). Successful reception of any of the two message pairs is sufficient. As explained earlier, if you receive a line update in the middle, you can then go out into the called state (assuming the current call request is not urgent). According to the 1120 test, if no valid line allocation message has been received and the maximum number of slots has been reached, load an appropriate delay on 1122 and go out to CC monitoring (from there to the calling subroutine shortly thereafter). Go back in). The process of loading an appropriate delay before a retry can be seen as a gradual "expansion" of the retry window in a consciously controlled manner. There are three reasons why inward data messages from radios are unresponsive. (1) The inward message was not detected successfully. (2) The outgoing message was not detected successfully. Or (3) a conflict has occurred (two or more mobile stations have sent requests in the same inward control line slot). If there is a conflict, the conflict will continue unless the mobile station resends the request irregularly. Therefore, if the radio fails to receive a response to the inbound message, the radio waits for an "irregular" period to retransmit the request. However, in the case of (1) or (2), there is really no reason to make the retry irregular. Unfortunately, the radio cannot determine why it did not receive a response. However, the longer the mobile station waits for a retransmission, the longer the average access time in a bad communication area, as it is the place where the majority of retries are made. Random retries are often wasteful, as the cause of unresponsiveness is often noise, not competition. To remedy this problem, the invention takes some remedial action. First, non-line acquisition messages are much slower than line solicitation messages. Access time to the former is not important (as opposed to the latter). Therefore, if there is a conflict between the radio sending a message other than the line request and the radio sending the line request message, the retry speed of the former will cause a conflict with the latter in the next retry. It's so slow that it doesn't cause any fear. Second, the irregular retry rate changes with the number of retries. The retry algorithm (this is only for line acquisition messages) widens the retry window with each successive retry. This reduces the average access time in the presence of noise, but provides a recovery mechanism if the cause of the unresponsiveness is a conflict. The preferred embodiment uses the following simple rules. 1st retry Irregular changes in 2 slots Second retry Irregular changes in 4 slots Successive retries 8 slot irregular changes In order to obtain even higher efficiency, it is possible to change the width of the retry window as a function of the receive bit error rate. In the 1120 test, if a valid operating line allocation was received, the calling device immediately switched to the assigned operating line at 1124 and received the correct confirmation message sent over the operating line at 1126. wait. This confirmation message is in step 1206 at time t₃Is sent from the point controller. If the confirmation message is canceled by a drop message in the 1128 test or by a preset timer time out in 1130, the call routine is abandoned and the CC monitoring is resumed. On the other hand, upon receiving a proper confirmation message on 1126, the calling device begins transmitting 384-bit dots over the operating line on 1132, followed by voice transmission (or other desired communication period) on 1134. To do. Return to the point controller and inspect at 1208 for confirmation dots with extended duration over the operating line. If you haven't received it, go out of the routine. However, if it is received correctly, in step 1210, a two-device key connection / mute release message is transmitted outward via the operating line. While all of the above is being done, the called device (if everything is working properly) is at time t, as shown in 1300.₂Receives and stores a pair of channel allocations consisting of two messages from the control line (at approximately the same time as the calling device) (again, if there is a message of one of the pairs consisting of two messages). Is enough). In response, the called device is also switched to the operating line assigned in 1302, followed by step 1304 (time t).₃The assigned operating line is monitored for proper confirmation. Only when a proper confirmation message is received will the called device arrive at time t over the operating line.₅The mute release message sent from the point controller is searched for and received, and in response to the mute release message, the receiver of the called device is demutated on the operating line at 1306. During the subsequent communication period on the assigned operating line between the calling device and the called device (s), the point controller (via TC) is at 1212 on all operating lines. Continue to send new line allocation (and drop) data below the audible range to all devices (so that higher priority calls can be immediately received and accepted by all devices). The point controller continues to periodically send line update messages over the control line at 1214 (via the proper TC) (for example, to allow late participants to immediately move to the proper operating line). ). The point controller informs all TCs of the line allocation and drop, and in response, each TC produces a communication below the appropriate audible range for that line. In existing methods, communications below the audible range are typically used as validation by mobile stations. When a mobile station is on an operating line, it initiates communication below the audible range and makes sure it belongs to that line. There are at least two reasons to enter a line to which the radio does not belong. 1) The communication on a certain operating line is correct, but I cannot tell that it has been reassigned due to a line drop. 2) I am monitoring the control line, decrypt the message illegally, and move to the incorrect line. Problem (1) is solved by giving all radios on the line a count lower than the 2-bit audible range. Each time a call is made to the line, the TC of the line increments the count. Therefore, if the radio sees a change in the count, it "knows" that it missed the line drop order. Regarding problem (2), existing methods have a fairly high probability of incorrectly decoding outbound control messages, so typically a quick way to switch radios from lines to which they do not belong. It is provided. For this reason, typically, communication below the audible range is used only for this purpose. However, the present invention takes advantage of the high information speed of the control line and requires the mobile station to check the update message twice before moving to the operating line. It can be ignored that the late participation time becomes long, but the probability of moving to an incorrect line is virtually eliminated. As a result, data below the audible range can be used for other purposes, such as priority scanning. At the end of the desired communication period, the release of the PTT switch on the calling device was detected at 1136, resulting in 1138 (time t).₆A key release message is sent via the operating line. When in transmit relay mode, the calling device can immediately return to the control line and immediately vacate the operating line. In response, at 1216, the point controller receives an unlock message for the operating line, and at 1218, an ultra-long dot string (time t).₇896 to 2816 bits of the operating line of Of course, the called device is at time t₆I have received a key release message on the operating line, and in response, I have already muted the receiver at 1308. The called device is at time t₇It receives an ultra-long dot string sent outward from the point controller on the operating line, and in response, returns to the control line at 1310. A special priority scan order is used (in the preferred embodiment) to minimize communication fragmentation. When the radio device scans a large number of groups and calls to the group with that priority, when the radio returns to the control line, it seems to be advantageous for scanning only the group with the priority for 2 seconds. Automatically disables scanning of large groups. Since the group with the priority communicated immediately before, there is a high probability that another communication will be performed within this period. If the radio immediately scans another (non-priority) group of calls (which, by definition, has a lower priority) and then another communication is made in the priority group, this radio The machine will hear fragments of communication from the non-priority group, delaying participation in the next communication of the priority group (priority scanning is to put the radio into the priority group). It can typically take 1.0 to 1.5 seconds). Another unique feature used to minimize communication fragmentation is the selection priority that the radio automatically assigns to the previously monitored non-priority group. This is essentially the case when monitoring a non-priority communication, during the two seconds following this communication, the radio will be similar to the prioritized group's communication (of course, separate the prioritized group). Ignore all other scanned calls (as). In addition, the radio always remembers the last non-priority group monitored. Upon returning from communication with the priority group, the radio selects the last non-priority group monitored over any other group scanned. In the example below,'-' means that the group is participating in a communication line, and it is assumed that group A is the group with priority and the communication is separated by less than 2 seconds. The operation line confirmation communication includes a bit (that is, a message / transmission relay bit) that informs the radio whether the communication is a transmission relay or a message relay. This unique feature further enhances frequency efficiency. It is guaranteed that the calling radio is on the operating line and monitors the message / transmit relay bits. If this bit is set to "transmit mode", the calling mobile station knows that the line will be cut off as soon as transmission is stopped. Therefore, when the PTT is released, the calling radio automatically returns to the control line immediately. Since the TC of the operating line can start the line drop communication as soon as it detects the key release message of the calling mobile station, this enhances the line utilization efficiency. That is, in order to guarantee that the transmitting mobile station completes the transmission, it is not necessary to extend the communication, and the receiver is placed on the line so that the line drop communication is sufficiently detected by the calling mobile station. Time is guaranteed. The called radio also sees this message / transmit relay bit, for a completely different reason. If the communication is a message relay, the called radio must be able to key connect to the assigned operating line if it must respond before the line drop. However, if the communication is a transmission relay, the called radio must not transmit any of the assigned operating lines. Therefore, if the bit is set to "transmit" mode, the called radio is not allowed to key connect to the connection line. This is a very useful feature as it prevents the radio from keying in preference to other radios. Therefore, the message / transmission relay bit brings three advantages to this method. By shortening the line drop time (one-third compared to the traditional typical method), the transmission trunk operation becomes more frequency (ie, line) efficient and the user can make a key connection. Reduces the downtime between no transmissions (for example, in the current typical method, if you connect a radio during a 0.5 second drop sequence, you have to wait for this sequence to complete) and the working line. It provides absolute protection so that the radio does not have a key connection in preference to others. To make individual calls in this example scheme, the calling radio uses one inward slot on the control line to identify itself and to identify the radio to call. An outgoing message from the control line circulates to an operating line that can be used by both radios, where confirmation communication takes place. The mute release message for the called radio (when high-speed confirmation communication is completed) also identifies the ID of the calling radio. The called radio automatically memorizes the ID of the called radio, and if the PTT switch of the called radio is pressed within 5 seconds of the release of the last PTT of the calling station, individual calls are automatically made. Returns to the original calling side. This can facilitate transmission and relay, which is convenient for the user, and thus further improve frequency (ie, line) efficiency between individual calls. This allows the calling radio to come into contact with the called radio and talk without using line hang time, even if the called radio is not pre-programmed to initiate a call to the calling radio. I will also be able to do it. The communication of the embodiments is extremely efficient, minimizing line drop times and thus increasing the efficiency of the scheme. For example, it is unique in that it is a high-speed communication in contrast to the low-speed communication typically used in all other methods today. In addition, this communication is designed to minimize message traffic, especially at distributed architecture points. Without this new line drop communication, when the line starts dropping, it sends a message (via the point controller) from the TC of the operating line to the TC of the control line and all updates of the outgoing control line (ie). , The update that is directing the radio to the currently dropping operating line) must be stopped. Once the broadcast is over, the line TC can send another message to the point controller to notify it and the point controller can reassign the dropped operating line, if appropriate. Must be done. At the central point, there is another message that slows down the line drop process, as well as traditional such methods that add extra load to the point controller. On the other side of this problem, the line drop communication transmitted on the operating line is such that the radio on the line once ended does not join later due to timing ambiguity, or worse. It is that there must be a sufficient duration to guarantee that you will not join the line later after the next call has already begun to occur on that line. The embodiment uses a unique line drop communication, a unique wireless communication detection algorithm, and the timing when the TC of the line sends a line drop message to the point controller. By making the line drop communication a dot of 9,600 bps, not only can the line drop communication be detected and muted by the radio before the radio operator hears the communication, but the detection algorithm of the processor for the radio Lighten the load sufficiently so that the radio can search for dots and confirmation communications at the same time. When dropping, the TC of the operating line adheres to the following rules. 1) Send 100 milliseconds dots. 2) Send a line drop message to the point controller without interrupting the dots. 3) Send another 200 milliseconds of dots. However, when the line allocation message is received from the point controller, it is stopped and the confirmation message is started to be transmitted. When receiving a line drop message from a given line TC, the point controller observes the following rules: 1) Immediately notify the control line TC so that the transmission of updates to the operating line TC can be stopped. 2) Consider a line that can be used immediately for reassignment. When leaving the operating line, the radio observes the following rules: 1) Ignore all line updates for the group of communications and lines that have just ended for 1/2 second. When entering the operating line, the radio observes the following rules: 1) Search for dots (that is, long-lasting enough to constitute a line drop signal) and confirmation communication at the same time. 2) If you recognize the line drop dot, leave the line. 3) If the confirmation is accepted and the ID is incorrect, leave the line. Otherwise, it will remain locked to this communication and will not be muted until instructed to do so. 4) If confirmation communication stops or communication is not recognized on the line, search for a signal lower than the audible range and cancel the mute. To understand the importance of the net effect of these procedures, consider two cases: (1) when the line is not assigned immediately and (2) when it is assigned immediately. The radio can only lag behind in the line drop communication 100 milliseconds after the line drop message is sent to the point controller. Therefore, if the line has not been reassigned, the late-joining radio will acknowledge that additional dots have been transmitted and know that it should be dropped from the line. On the other hand, when there is a method load (eg, when a call request is queued at the point controller), the line is immediately assigned to the first group of queues. The radio trying to join the call just dropped acknowledges the confirmation message with the next group of calls initiated and knows that it should leave the line. As a minimum line, in a loaded manner, dropping a line requires only 100 milliseconds of communication and a single message from the point controller. Since the radio can search for line drop communication and confirmation communication at the same time, the radio that happens to join the dropped call later detects this fact. Due to the rising price of radios, PST radio manufacturers can program these extra "features" into their radios. A typical conventional method for doing this is to burn a unique PROM or EEPROM in the factory. One advantage of this method is the cost of unique programming of each radio before leaving the factory, and if the customer later desires additional features, the radio grade. It is inefficient to increase. However, the examples make it possible to eliminate the cost of programming in the factory. Since each radio is programmed by the customer in the field (eg, as a group, method, etc.), the feature should be programmed into the radio at that time. The question is how to manage the programming task to the extent that it guarantees that only the features purchased by the customer are programmed. When shipping radios to customers, attach a piece of paper with a set of programming code and physical ID (one pair for each radio). Each programming code is a "feature bitmap" and a code for the physical ID of the radio. When a customer programs a radio, there are two things to do. First, the customer programs the radio. Therefore, the customer selects a programming code that represents the characteristics purchased for the radio and puts it in the radio programmer. The customer then uses the radio programmer to program the radio, during which the programming code prevents the customer from programming the deactivated feature. Second, the user enters the radio into the method database via the method manager. In order for a radio to enter the database, the physical ID of the radio must be identified. At any time the radio programmer writes data to the radio, it sets the "just programmed" bit inside the radio's personality. This bit is inspected when the radio is switched on. If set, the radio uses its physical ID to request a logical ID from the point controller before the user can communicate in a trunk fashion. The point controller examines the method manager's database to determine the logical ID to assign to this radio. If a customer attempts to program a different radio with the same programming ID, this customer will have the same logical ID for each radio, which means that the unique identification ability has been lost. Note that it means. This is the same result that would occur if the customer posted a PROM used in the existing fashion. The result is the same level of protection while avoiding the need to program the radio in the factory. Adding features to a radio involves issuing an update programming ID. There is no ambiguity when programming the radio (for example, in existing methods, the radio can be programmed to do things that are not allowed to do so that the customer can program the radio. When programmed and it doesn't work, the customer doesn't know if the radio is misprogrammed or the feature is inactive). No special software is written on the mobile station, only the radio programmer. The final advantage is that fixing software bugs against feature abilities / inactivity requires changing the code of just a few computers, not all radios in the field. It's nice. The communication protocols and formats associated with many different forms of call order are summarized below in detail. I. Radio transmission, logical ID acquisition order A. CC sends a continuous stream of control messages, which all non-working mobile stations receive. The message is in the following frame format, sending two messages in a 30ms frame. Dot = 32 bits Barker = 16 bits (eg 11-bit barker code and 5-bit dot preamble) Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. When the power of the mobile station is turned on, the point ID message is received from the control line (CC) in the following format. MT-A = 2 bits (eg 11) MT-B = 3 bits (eg 111) MT-C = 4 bits (eg 1110) Delay = 2 bits Line = 5 bits Priority = 3 bits Fixed point = 1 bit Fail soft = 2 bits Point ID = 6 bits BCH code = 12 bits The delay identifies the maximum number of control line slots before the control line responds to inward transmissions. The line identifies the line number for the operating control line. The priority prohibits mobile stations with lower priority from transmitting on the inward control line. The fixed point bit specifies whether the point ID is a fixed (= 0) or adjacent (= 1) ID. C. If desired, the mobile station can, at its discretion, send a login request over the control line in synchronization with the received control line message, if the priority allows. The shape of the frame is as follows. Dot = 152 bits Barker code (repeat 3 times) = 48 bits (including padding) Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The login message is encoded as follows: MT-A = 2 bits MT-B = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits If the mobile station does not have a logical ID, it sends a logical ID request message. The logical ID request message is encoded as follows. MT-A = 2 bits MT-B = 3 bits MT-C = 3 bits Physical ID = 20 bits BCH code = 12 bits D. The control line responds with a logical ID assignment message. II. Radio Caller Order-Radio Call, Group Call A. The control line sends a continuous stream of control messages, which all non-working mobile stations receive. Two messages are sent in 30 ms frames with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. The mobile station that originated the group call sends a group line allocation request on the control line in synchronization with the message received by the control line. The frame format is as follows. Dot = 152 bits Barker (repeated 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The group call request message is encoded as follows: MT-A = 2 bits Communication type (eg voice, data, interconnect or voice secret) = 2 bits Not used = 1 bit Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits C. The control line responds with a pair of two messages for line allocation. The coding is as follows. MT-A code = 2 bits Communication type (eg voice) = 2 bits 1/2 logical ID = 6MSB or LSB group / logic = 1 bit Line = 5 bits Group ID = 12 bits BCH code = 12 bits D. All mobile stations in the called group switch to the assigned operating line and receive a confirmation message. A slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits The confirmation message for the group call is encoded as follows: MT code = 4 bits Count lower than audible range = 2 bits Message / Send relay = 1 bit Group / logical ID = 1 bit Group ID = 12 bits BCH code = 12 bits E. The outgoing mobile station receives the confirmation message and sends a 384-bit dot and then an audio. F. The operating line receives the dot and sends a 2 device key connection / mute release message. MT code = 4 bits Count lower than audible range = 2 bits Message / Send relay = 1 bit Fill = 1 bit Logical ID = 12 bits BCH code = 12 bits The called mobile station receives the mute cancellation message and cancels the mute of the audio. G. A mobile station operating on another operating line receives a line allocation message below the audible range. H. The control line lags behind and sends a line update message to the participating mobile stations. I. The sending mobile station unlocks and sends a non-slot key unlock message. The format of all non-slot messages is: Dot = 384 bits Data block # 3 = 128 bits Data block # 2 = 128 bits Data block # 1 = 128 bits Data block # 0 = 128 bits Data blocks # 3, # 2, # 1 and # 0 are identical except for a 2-bit block count. (Each block is repeated 4 times.) Each has the following format. Dot = 16 bits Barker code = 16 bits Byte 1 = 8 bits Byte 1 (inverted) = 8 bits Byte 1 = 8 bits Byte 2 = 8 bits Byte 2 (inverted) = 8 bits ......... Byte 3 = 8 bits Byte 4 = 8 bits Byte 4 (inverted) = 8 bits Byte 4 = 8 bits The unlock message is encoded as follows. MT code = 4 bits Not used = 2 bits Block count = 2 bits Logical ID = 12 bits BCH code = 12 bits J. The operating line sends 896 to 2,816-bit dots to drop all mobile stations from the line. III. Wireless Call Order-Wireless Calls, Individual Calls A. The control line sends a continuous stream of control messages, which all non-working mobile stations receive. The message is sent in two frames to fit a 30ms frame with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. A mobile station that intends to make an individual call sends an allocation request on the control line in synchronization with the received message on the control line. The frame format is as follows. Dot = 152 bits Barker (repeat 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The individual call request message is encoded as follows: MT-A code = 2 bits Communication type (eg voice) = 2 bits Logical ID (callee) = 12 bits Logical ID (caller) = 12 bits BCH code = 12 bits C. The control line responds with a pair of two messages for line allocation. The coding is as follows. MT-A code = 2 bits Communication type (eg voice) = 2 bits 1/2 logical ID = 6MSB or 6LSB Group / logical ID = 1 bit Line = 5 bits Logical ID = 12 bits BCH code = 12 bits D. Both the calling side (last logical ID) and the called side mobile station switch to the assigned operating line and receive a confirmation message. The slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits The confirmation message for each call is encoded as follows: MT code = 4 bits Count lower than audible range = 2 bits Message / Send relay = 1 bit Group / logical ID = 1 bit Logical ID = 12 bits BCH code = 12 bits E. The calling mobile station receives the confirmation message, sends a 384-bit dot, and then sends an audio. F. The operating line receives the dot and sends a key connection / mute release message for the two devices. MT code = 4 bits Count lower than audible range = 2 bits Message / Send relay = 1 bit Not used = 1 bit Logical ID = 12 bits BCH code = 12 bits The called mobile station receives the mute cancellation message and cancels the mute of the audio. G. Operating mobile stations on other operating lines do not receive line allocation messages below the audible range. H. The control line lags behind and sends a line update message to the participating mobile stations. I. The mobile station unlocks during transmission and sends a non-slot disconnect disconnect message. All non-slot message formats are as follows. Dot = 384 bits Data # 3 = 128 bits Data # 2 = 128 bits Data # 1 = 128 bits Data # 0 = 128 bits The data # 3, # 2, # 1 and # 0 are the same (repeated four times) and all have the following format: Dot = 16 bits Barker = 16 bits Byte 1 = 8 bits Byte 1 (inverted) = 8 bits Byte 1 = 8 bits Byte 2 = 8 bits Byte 2 (inverted) = 8 bits ......... Byte 3 = 8 bits Byte 4 = 8 bits Byte 4 (inverted) = 8 bits Byte 4 = 8 bits The unlock message is encoded as follows. MT code = 4 bits Not used = 2 bits Subcount = 2 bits Logical ID = 12 bits BCH code = 12 bits IV. Radio Call Order-Wireless Calls, Emergency Group Calls A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. Two messages are sent in a 30-millisecond frame with the following format. Dot = 32 bits Barker = 11 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. A mobile station attempting to make an emergency group call sends an allocation request on the control line in synchronization with the received control line message. The frame format is as follows. Dot = 152 bits Barker (repeat 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The urgent group call request message is encoded as follows: MT-A code = 2 bits Communication type = 2 bits State / C = 1 bit Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits C. The control line responds with two messages of line allocation encoded as follows. MT-A code = 2 bits Communication type = 2 bits 1/2 logical ID = 6MSB or LSB Group / logical ID = 1 bit Line = 5 bits Group ID = 12 bits BCH code = 12 bits D. All mobile stations in the called group switch to the assigned operating line and receive a confirmation message. A slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits The confirmation message for the emergency group call is encoded as follows: MT code = 4 bits Lower count due to audible range = 2 bits Message / Send relay = 1 bit Group / logical ID = 1 bit Group ID = 12 bits BCH code = 12 bits E. The calling mobile station receives the confirmation message and sends a 384-bit dot and then an audio. F. The operating line receives the dot and sends a key connection / mute release message for the two devices. MT code = 4 bits Count lower than audible range = 2 bits Message / Send relay = 1 bit 1 bit (not used) = 0 Logical ID = 12 bits BCH code = 12 bits The called mobile station receives the mute cancellation message and cancels the mute of the audio. G. Mobile stations operating on other operating lines receive line allocation messages below the audible range. H. The control line lags behind and sends a line update message to the participating mobile stations. I. The sending mobile station unlocks and sends two non-slot unlock messages. The format of all non-slot messages is: Dot = 384 bits Data # 3 = 128 bits Data # 2 = 128 bits Data # 1 = 128 bits Data # 0 = 128 bits The data # 3, # 2, # 1 and # 0 are the same (repeated 4 times) and all have the following format. Dot = 16 bits Barker = 16 bits Byte 1 = 8 bits Byte 1 (inverted) = 8 bits Byte 1 = 8 bits Byte 2 = 8 bits Byte 2 (inverted) = 8 bits ......... Byte 3 = 8 bits Byte 4 = 8 bits Byte 4 (inverted) = 8 bits Byte 4 = 8 bits The unlock message is encoded as follows. MT code = 4 bits Count lower than audible range = 2 bits Logical ID = 12 bits BCH code = 12 bits V. Radio Call Order-Wireless Call, State Call A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. Two messages are sent in a 30-millisecond frame with the following format. Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. The mobile station that intends to make a status call sends a status request on the control line in synchronization with the message received on the control line. The frame format is as follows. Dot = 152 bits Barker (repeat 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The status request message is encoded as follows. MT-A code = 2 bits MT-B code = 3 bits MT-C code = 3 bits 3 bits (not used) = 000 Autoresponder = 1 bit (eg yes) 4 bits (not used) = 0000 Logical ID = 12 bits BCH code = 12 bits C. The control line responds with a status page message encoded as follows: MT-A code = 2 bits MT-B code = 3 bits MT-C code = 4 bits 2 bits (not used) = 00 Autoresponder = 1 bit (eg yes) State = 4 bits Logical ID = 12 bits BCH code = 12 bits D. The called mobile station sends a control line status message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits MT-C code = 3 bits 3 bits (not used) = 000 Autoresponder = 1 bit (eg yes) State = 4 bits Logical ID = 12 bits BCH code = 12 bits E. The control line responds with a status confirmation message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits MT-C code = 4 bits 2 bits (not used) = 00 Autoresponder = 1 bit (eg yes) State = 4 bits Logical ID = 12 bits BCH code = 12 bits The calling mobile station receives the status message. VI. Wireless Call Order-Wireless Calls, Special Calls A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. Two messages are sent in a 30-millisecond frame with the following format. Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. A mobile station that intends to make a special call sends a request for a special call on the control line in synchronization with the received message on the control line. The frame format is as follows. Dot = 152 bits Barker (repeat 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The special call request message is encoded as follows: MT-A code = 2 bits MT-B code = 3 bits MT-C code = 3 bits 2 bits (not used) = 00 Communication type code = 2 bits (eg interconnect) 1 bit (not used) = 0 Priority code = 3 bits Logical ID = 12 bits BCH code = 12 bits C. The control line responds with a pair of two messages for line allocation. It is coded as follows. MT-A code = 2 bits Communication type code = 2 bits (for example, interconnection) 1/2 logical ID = 6MSB or LSB Group / logic = 1 bit Line = 5 bits Logical ID = 12 bits BCH code = 12 bits D. The mobile station switches to the assigned operating line and receives a confirmation message. A slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits BCH code = 12 bits The confirmation message for the special call is encoded as follows: MT code = 4 bits Subcount = 2 bits Hang time / trunk = 1 bit Group / logical ID = 1 bit Logical ID = 12 bits BCH code = 12 bits E. The calling mobile station receives the confirmation message and sends a special multi-block call message. A message frame (shown below) can have 1 to 16 blocks. Dot = 384 bits Data # 3 block # 1 = 128 bits Data # 2 block # 1 = 128 bits Data # 1 block # 1 = 128 bits Data # 0 block # 1 = 128 bits Data # 3 block # 2 = 96 bits Data # 2 block # 2 = 96 bits ......... Data # 3, # 2, # 1, # 0 are the same in all blocks (repeated 4 times). The data encoding of block # 1 is as follows. Dot = 16 bits Barker = 16 bits Byte 1 = 8 bits Byte 1 (inverted) = 8 bits Byte 1 = 8 bits Byte 2 = 8 bits Byte 2 (inverted) = 8 bits ......... Byte 3 = 8 bits Byte 4 = 8 bits Byte 4 (inverted) = 8 bits Byte 4 = 8 bits Data in blocks after block # 1 do not have a dot or barker code. If a telephone interconnect is required, the data in block # 1 is encoded as follows: Group count = 4 bits Individual count = 4 bits Phone digit count = 4 bits Phone Digit # 1 = 4-bit MSD Phone Digit # 2 = 4 Bits BCH code = 12 bits If no interconnection is required, block # 1 is encoded as follows: Group count = 4 bits Individual count = 4 bits Group / logical ID = 12 bits BCH code = 12 bits Subsequent blocks are encoded with one group ID, one logical ID or five telephone digits as required to fill the count for block # 1. The phone digit is first, then the ID, then the group ID. Digit coding is 1 digit per nibble. (Zero = 1010). The ID coding is as follows. 8 bytes = 10101010 (8 bits) Group / logical ID = 12 bits BCH code = 12 bits F. Sends a special call reception bitmap message for a slotted operating line. The slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits BCH code = 12 bits The special call-receipt bitmap is encoded as follows (using a similar confirmation bitmap is subject to the pending US patent application serial number (applicant copy number 45-MR-496)). MT code = 4 bits Block # 1 bit = 1 bit (eg OK) Block # 2 bit = 1 bit (eg OK) Block # 3 bit = 1 bit (eg 0 = repeat) Block # 4 bits = 1 bit ......... Block # 16 bits = 1 bit BCH code = 12 bits G. The calling mobile station receives the bitmap message and sends a multi-block special call message. A message frame (shown below) can have 1 to 16 blocks. Dot = 384 bits Data # 3 block # 1 = 128 bits Data # 2 block # 1 = 128 bits Data # 1 block # 1 = 128 bits Data # 0 block # 1 = 128 bits Data # 3 block # 2 = 96 bits Data # 2 block # 2 = 96 bits ......... Data # 3, # 2, # 1, # 0 are the same in each block (repeat 4 times). The coding of block # 1 is as follows. Dot = 16 bits Barker = 16 bits Byte 1 = 8 bits Byte 1 (inverted) = 8 bits Byte 1 = 8 bits Byte 2 = 8 bits Byte 2 (inverted) = 8 bits ......... Byte 3 = 8 bits Byte 4 = 8 bits Byte 4 (inverted) = 8 bits Byte 4 = 8 bits The data in blocks after block # 1 does not have a dot or barker code. Only blocks with a bitmap bit of "0" are sent. For example, in step F, block # 3 of step E is the block to be retransmitted first. If no bitmap is received within 100 ms from step E or G, retransmit all blocks. Steps F and G are repeated until all blocks are correctly received (BITMAP = all 1). H. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. The message is sent in two messages in a 30ms frame with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits I. The control line sends a pair of two messages, 0 to 16 of the line allocation, as needed for a special call. The coding for each message is as follows. MT-A code = 2 bits Communication type code = 2 bits 1/2 logical ID = 6MSB or 6LSB Group / logical ID = 1 bit Line = 5 bits Logic = 12 bits BCH code = 12 bits J. All called mobile stations move to the assigned operating line and cancel mute (same as late participation). From this point, the operating line message is the same as a group or individual call. VII. Radio Call Order-Wireless Call, Dynamic Group Reorganization Call A. The control line sends a continuous slitome of control messages, which all inactive mobile stations receive. The message is sent in two messages in a 30ms frame with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. A mobile station that intends to make a dynamic group reorganization call sends a request on the control line in synchronization with the received control line message. The frame format is as follows. Dot = 152 bits Barker (repeat 3 times) = 48 bits Message = 40 bits Message (inverted) = 40 bits Message = 40 bits The dynamic group reorganization request message is encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits C. The control line responds with a dynamic group reorganization message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits D. The mobile station confirms the dynamic group reorganization in the login message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits E. The mobile station can request the cancellation of the dynamic group reorganization with a message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits BCH code = 12 bits F. The control line responds with a dynamic group reorganization cancel message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits G. The mobile station approves the cancellation of the dynamic group reorganization with a login message encoded as follows. MT-A code = 2 bits MT-B code = 3 bits Group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits VIII. Radio call sequence-console call, group call A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. The message is sent to two messages in a 30ms frame with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. The console attempting to make a group call sends a group call message to the downlink. The group call message is encoded as follows. MID = 1 byte (# 0) = 8 bits #Byte = 1 byte (# 1) = 8 bits Source = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT-A code = 2 bits Communication type = 2 bits Group ID = 12 bits Logical ID = 12 bits Parity = 1 byte (# 8) = 8 bits C. The control line responds with a pair of two messages for line allocation. The coding is as follows. MT-A code = 2 bits Communication type = 2 bits 1/2 logical ID = 6MSB or 6LSB Group / logical ID = 1 bit Line = 5 bits Group ID = 12 bits BCH code = 12 bits D. All mobile stations in the called group switch to the assigned operating line and receive a confirmation message. A slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits The confirmation message for the group call is encoded as follows. MT code = 4 bits Count lower than audible range = 2 bits Hang time / relay = 1 bit Group / logical ID = 1 bit Group ID = 12 bits BCH code = 12 bits E. The calling console receives the line allocation from the downlink and switches audio for the identified line. The console message is coded as follows: MID = 1 byte (# 0) = 8 bits #Byte = 1 byte (# 1) = 8 bits S / D = bytes # 2, # 3 = 16 bits Not used = 4 bits MT code = 2 bits Communication type = 2 bits Logical ID = 12 bits Not used = 2 bits GR / L ID = 1 bit Line = 5 bits Group ID = 12 bits Parity = 1 byte (# 8) = 8 bits F. The operating line sends a 2 device key connection / mute release message. MT code = 4 bits Count lower than audible range = 2 bits Hang time / relay = 1 bit 1 bit (not used) = 0 Logical ID = 12 bits BCH code = 12 bits The called mobile station receives the mute cancellation message and cancels the mute of the audio. G. A mobile station operating on another operating line receives a line allocation message below the audible range. H. The control line lags behind and sends a line update message to the participating mobile stations. I. The console sends a key release message encoded as follows: MID = 1 byte (# 0) = 8 bits #Byte = 1 byte = 8 bits Source = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT code = 4 bits Not used = 4 bits Logical ID = 12 bits Parity = bytes # 7 = 8 bits J. The operating line sends 896 to 2,816-bit dots to drop all mobile stations from the line. K. The console receives the unlock message. MID = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source = bytes # 2 and # 3 = 16 bits MT-A / B / C = 9 bytes Drop Cr = 1 bit Not used = 1 bit Line = 5 bits Logical ID = 12 bits Parity = bytes # 8 = 8 bits IX. Wireless call sequence console outgoing, individual calls A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. Two messages are sent in a 30-millisecond frame with the following format. Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. The console that wants to make an individual call sends an individual call message to the downlink. The individual call messages are coded as follows: MID = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT-A code = 2 bits Communication type = 2 bits Logical ID = 12 bits Logical ID = 12 bits Parity = bytes # 8 = 8 bits C. The control line responds with a pair consisting of two messages for line allocation. The coding is as follows. MT-A code = 2 bits Communication type = 2 bits 1/2 logical ID = 6MSB or LSB Group / logical ID = 1 bit Line = 5 bits Logical ID = 12 bits BCH code = 12 bits D. The called mobile station switches to the assigned operating line and receives a confirmation message. The slot-type operating line message is transmitted using the next frame. Dot = 32 bits Barker = 16 bits Message = 32 bits Message (inverted) = 32 bits Message = 32 bits The individual call confirmation message is encoded as follows: MT code = 4 bits Count lower than audible range = 2 bits Hang time / trunk = 1 bit Group / logical ID = 1 bit Logical ID = 12 bits BCH code = 12 bits E. The outgoing console receives a line allocation message from the downlink and switches audio to the specified line. The console message is coded as follows: MID = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT code = 2 bits Communication type code = 2 bits Logical ID = 12 bits Not used = 2 bits GR / L ID = 1 bit Line = 5 bits Logical ID = 12 bits Parity = bytes # 9 = 8 bits F. The operating line sends a connection / mute release message for the two devices. MT code = 4 bits Count lower than audible range = 2 bits Hang time / trunk = 1 bit 1 bit (not used) = 0 Logical ID = 12 bits BCH code = 12 bits The called mobile station receives the mute cancellation message and cancels the mute of the audio. G. Mobile stations operating on other operating lines do not receive line allocation messages below the audible range. H. The control line lags behind and sends a line update message to the participating mobile stations. I. The console sends a key release message encoded as follows: MID = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT code = 4 bytes Not used = 4 bits Logical ID = 12 bits Parity = bytes # 7 = 8 bits J. The operating line sends 896 to 2,816-bit dots to drop all mobile stations from the line. K. The console receives the unlock message. MID = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source = bytes # 2 and # 3 = 16 bits MT-A / B / C = 9 bits Line drop = 1 bit Not used = 1 bit Line = 5 bits Logical ID = 12 bits Parity = bytes # 8 = 8 bits X. Wireless call sequence, console outgoing, A. The control line sends a continuous stream of control messages, which all inactive mobile stations receive. The message is sent in two messages in a 30ms frame with the following format: Dot = 32 bits Barker = 16 bits Message # 1 = 40 bits Message # 1 (inverted) = 40 bits Message # 1 = 40 bits Message # 2 = 40 bits Message # 2 (inverted) = 40 bits Message # 2 = 40 bits B. The console trying to set the patch sends a patch ID assignment message to the downlink. The patch ID assignment message has a variable length depending on the group and individual ID counts. MID = 29 = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source / destination = bytes # 2 and # 3 = 16 bits Not used = 4 bits Group count = 4 bits Individual count = 4 bits Logical ID = 12 bits Not used = 12 bits Logical ID = 12 bits Not used = 12 bits Logical ID = 12 bits Not used = 13 bits Group ID = 11 bits Not used = 13 bits Group ID = 11 bits Not used = 13 bits Patch ID = 11 bits Parity = 8 bits C. Console has a special group IC code (1000 0000 Use 0000) to receive a patch request confirmation from the point controller. MID = 12 = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source / destination = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT-A code = 11 = 2 bits MT-B code = 100 = 3 bits Patch ID = 11 bits Group ID = 11 bits Parity = bytes # 8 = 8 bits D. When the console wants to activate a patch, it sends a patch activation message to the downlink. MID = 27 = bytes # 0 = 8 bits #Byte = byte # 1 = 05 = 8 bits Source / destination = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT code = 4 bits (1110) Not used = 5 bits Patch ID = 11 bits Parity = bytes # 7 = 8 bits E. The control line responds with an aliasing ID assignment message. The group assignment message is encoded. MT-A code = 2 bits (11) MT-B code = 3 bits (110) Aliase group ID = 11 bits Not used = 1 bit Group ID = 11 bits BCH code = 12 bits The group aliasing ID message is repeated in control line background mode and is not confirmed by the mobile station. The individual aliasing ID assignment message is encoded as follows. MT-A code = 2 bits (11) MT-B code = 3 bits (101) Aliase group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits F. All receivers receive the assigned message, but only the mobile station of the individual call approves the message. MT-A code = 2 bits (11) MT-B code = 3 bits (110) Aliase group ID = 11 bits Logical ID = 12 bits BCH code = 12 bits G. The console receives the patch assignment activation message and confirms the patch. There is one message for each allocation. MID = 12 = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source / destination = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT-A code = 2 bits (11) MT-B code = 3 bits (100) Patch ID = 11 bits Group ID = 12 bits Parity = bytes # 8 = 8 bits MID = 13 = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source / Destination = Byte # 2 and Byte # 3 = 16 bits Not used = 4 bits MT-A code = 2 bits (11) MT-B code = 3 bits (101) Patch ID = 11 bits Logical ID = 12 bits Parity = bytes # 8 = 8 bits H. The console makes a patch call by sending a group call message using the patch ID. MID = 24 = bytes # 0 = 8 bits #Byte = byte # 1 = 8 bits Source / destination = bytes # 2 and # 3 = 16 bits Not used = 4 bits MT code = 2 bits (00) Communication type = 2 bits (00) Patch ID = 11 bits Logical ID = 12 bits Parity = bytes # 8 I. The control line sends a group call message. The subsequent steps are the same as the group calls sent from the console. Although only one embodiment of the present invention has been described in detail, one of ordinary skill in the art will appreciate that various modifications can be made to this embodiment while taking advantage of the novel features and advantages of the present invention. Therefore, please be aware that all such modifications are within the scope of the present invention.

[Simple explanation of drawings]

FIG. 1 is an overall explanatory diagram of the trunk wireless relay system of the present invention, FIG. 2 is a simplified block diagram of a central control point (and a satellite receiver point) in the trunk relay system of FIG. 1, FIG. Is a simplified block diagram showing the overall architecture as a point of the main controller with respect to the central control point, Fig. 4 is a simplified block diagram of the line architecture used in each line of the architecture at the central point shown in Fig. 3, No. Figure 5 is an overall simplified block diagram of a technical mobile station / portable radio device used to communicate within the trunk relay system of Figure 1, and Figure 6 is a schematic block diagram of an example as seen from the calling device. A simplified flowchart of a typical call processing sequence, FIG. 7 is a simplified flowchart of the call processing sequence in the called device, FIG. 8 is a diagram showing a trunk line drop order and a typical required block time, and FIG. 9 is a diagram. Overall, a diagram showing call initiation communication and typical timing conditions within this example method, FIG. 10 is used to start and end trunk radio communication individually or as a group in this example method. A graph showing the control communication protocol, FIG. 11 is a simplified flowchart showing a suitable computer program that can be used in the point controller, calling device and called device to achieve the tenth communication protocol.