CA1305524C - Processor-to-processor communications protocol for a public service trunking system - Google Patents

Abstract

ABSTRACT OF TEE DISCLOSURE

A downlink between a communications dispatch console and a digitally trunked radio repeater system site controller efficiently transfers message data between the site controller and the console over a standard 9.2 kilobit per second landline. A downlink trunking card identical in structure to trunking cards used in the preferred embodiment system for RF channel signal processing interfaces the site controller with the landline link. A
similar trunking card on the other side of the landline link interfaces the dispatch console processor with the landline link. Message protocol and format is translated between the site controller and the landline link and between the landline link and the dispatch console. Data buffering at each end of the landline link maximizes data transfer rate over the landline, and in addition, a priority scheme insures that more important messages are transmitted over the downlink before less important messages. Retransmit-until-acknowledged protocol is used to insure reliable message transfer -- and also to permit receiving units along the downlink to slow down transmitting units in order to avoid message traffic blockage.

Description

~3~5~i2~

` 1 45MR-542 PROCESSOR-TO~PROCESSOR COMMUNICATIONS_PROTOCOL
FOR A
PUBLIC SERVICE TRUNKING SYSTEM

CRQSS-REFERENCES TO RELATED APPLICATIONS
This application is related to the followlng commonly assigned Canadian Applications: Canadian AppIication Serial NoO 566,664 of Childress et al, ~iled May 12, 1988, entit:led "Trunked Radio Repeater System"; Canadian Application Serial No. 566,663 of Childress et al, filed May 12, 1988, entitled "Failsoft Architecture for Public Trunking Systemi';
Canadian Application Serial No. 566,660 of Childress, filed ~ay 12, 1988, entitled "Adaptive Limiter/DetectGr Which Changes Time Constant Upon Detection of Dotting pattern"; Canadian Application Serial: No. ~566,662 of Childress et al, filed May 12, 1988, entitled~"Apparatus and Method:for Transmitting Digital Data Over a Radio Communlcations Channel".
This application is also:related to the following commonly-assigned Canadian applications: Canadian Application Serial No. 58~,064 of ~issoway et al, filed October~ 13, 1988, enti~led "Mobile Radio Interface";
Canadian Application Serial No. 580,0g7 of Hall et al, filed October 13, 1988, entitled 7'Radio Trunking ~ault Detection System"; Canadian Application Serial No.

580,094 of Cole et al, filed October 13, 1988 ~3~%~

entitled i'A Method for Infrequent Radio Users to Simply Obtain Emergency Assistance'~.
SPECIFICATION
This invention is generally related to the art of trunked radio repeater systems. The invention more particularly relates to such repeater systems using digital control signals transmitted over a dedicated control channel while also using plural working channels which are assigned temporarily for use by individual mobile radio units.
The trunking of radio repeaters is well known. Early trunking systems used analog control signals while some more recent systems have utilized digital control signals. Control signals have been used on a dedicated control channel and/or on different ones of the working (voice) channels for various different reasons and effects.
non-exhaustive but somewhat representative sampling of publications and patents describing typical prior art trunked rad.io repeaker systems is set forth below:
U.S. Patent No. 3,292,178 - Magnuski (1986) U.S. Patent No. 3,458,664 - Adlhoch et al (1969) U.S. Patent No. 3,571,519 - Tsim~idis (1971) U.S. Patent No. 3,696,210 - Peterson et al (1972) U.S. Patent No. 3,906,166 - Cooper et al (1975) U.S. Patent No. 3,936j616 - DiGianfilippo (1976) U.S. Patent No. 3,970,8C1 - Ross et al (1976) U.S. Patent No. 4,001,693 - Stackhouse et al (1977) U.S. Patent No. 4,010,327 - Kobrinetz et al (1977) U.S. Patent No. 4,012,597 - Lynk, Jr. et al (1977) U.S. Patent No. 4,022,973 - 5tackhouse et al (1977) U.S. Patent No. 4,027,243 - Stackhouse et al (1977) U.S. Patent No. 4,029,901 - Campbell (1977) U.S. Patent No. 4,128,740 - Graziano (1978~
U.S. Patent No. 4,131,849 - Freeburg et al (1978) U.S. Patent No. 4,184,118 - Cannalte et al (1980) ~3~5~

U.S. Patent No. 4,231,114 - Dolikian (1980) U.S. Patent No. 4,309,772 - Kloker et al (1982) U.S. Patent No. 4,312,070 ~ Coombes et al (1982) U.S. Patent No. 4,312,074 - Pautler et al (1982) U.S. Patent No. 4,326,264 - Cohen et al (1982) U.S. Patent No. 4,339,923 - Predina et al (1982) U.S. Patent No. 4,347,625 - Williams (1982) U.S. Patent No. 4,360,927 - Bowen et al (1982) U.S. Patent No. 4,400,585 - Kaman et al (1983) U.S. Patent No. 4,409,687 - Berti et al (1983) U.S. Patent No. 4,430,742 - Milleker et al (1984) U.S. Patent No. 4,430,755 - Nadir et al (1984) U.S. Patent No. 4,433,256 - Dolikian (1984) U.S. Patent No. 4,450,573 - Noble (1984) U.S. Patent No. 4,485,486 - Webb et al (1984) U.S. Patent No. 4,578,815 - Persinotti (1985) Bowen et al is one example of prior art switched channel repeater systems which avoid using a dedicated control channel -- in part by providing a handshake with the repeater site controller from a seized "idle" working channel before communication with a called unit(s) is permitted to proceed.
There are many actual and potential applications for trunk radio repeater systems.
However, one of the more important applications is for public service trunked (PST) systems. For example, a single system of trunked radio repeaters may be advantageously used by an entire metropolitan area to provide efficient radio communications between individual radio units within many different agencies. Each agency may, in turn, achieve efficient communication batween individual units of different fleets or sub-units (e.g., the police department may have a need to provide efficient communications between different unlts of its squad car force, :

. .

~3~S~

different portable units assigned to foot patrolmen, different units of detectives who are narcotics agents, and the like). Sometimes it may be important to communicate simultaneously with predefined groups of units (e.g., all units, all squad cars, all foot patrolmen, etc.). At the same time, other agencies (e.g., the fire department, the transportation department t the water department, the emergency/rescue services, etc.) may be in need of similar communication services. As is well known to those familiar with trunking theory, a relatively small number of radio repeaters can efficiently service all of these needs within a given geographical area if they are trunked (i.e., shared on a "as-needed" basis between all potential units).
The potential a~vantages of trunked radio repeater systems for public services is so well recognized that an organization known as the Association of Public-Safety Communications Officers, Inc. (formerly the Association of Police Communications Officers) (APCO) has developed a set of highly desirable features for such a system commonly known as the l'APCO-16 Requirements." A
complete listing and explanation of such requirements may be found in available publications kr?own to those in the art.
An advantageous trunked ratio repeater system is described in the aforementioned Canadian Application Serial No. 566,664 of Childress et al. That application describes a trunked radio repeater system architecture in which the RF "control shelf" which receives and transmits radio frequency signals for a particular working or control channel is controlled by a microprocessor-based "trunking card" (hereafter '~

., `

~3~

referred to as a "GETC" -- General Electric: Trunking Card) which performs the signal processing functions associated with the control shelf and RF channel. A primary site controller (e.g., a minicomputer) is conn~:ted to various trunking cards, and receives digital signals from and sends digital signals to the various trunking cards. The primary site controller performs the control functions of the system (duriny normal s~stem operations) -- and thus performs tasks such as call. logging, dynamic regrouping, and "patch" coordination as well as other, more route control functions such as assigning channels to new calls.
One or more dispatch consoles also connected to the primary site controller generate ~essages requesting services from the primary site controller and also monitor the status of the entire system via messages sent to it from the site controller.
The dispatcher console(s) is a critical part of the repeater system since it coordinates virtually all communications on the system and is often directly involved in system communications transactions. While mobile uni-ts someti~es call other mobile units to establish mobile unit-to-mobile unit communications, a large portion of the communications traffic handled by the system is between a h~man dispatcher at the console and an individual or group of mobile units~ The dispatcher console is the "nerve center" of the r~peater system and coordinates and monitors system operation. Although some of the advance features provided by the repeater syste~ are performed automatically, other advanced features require direct manual intervention by a dispatcher. Reliable and rapid communication o control signals between the dispatcher console and the a primary site controller i9 therefore of utmo~t importance.

.

3~55~24 The present invention provides a ~eans for communicating siynals between processors in a digitally trunked radio frequency repeater systa~n. More particularly, the present invention provides method and apparatus for communicating signals between a central site controller and an RE channel signal processing module; and also between the site controller and a radio repeater system dispatch~r console via a "downlink".

BRIEF DESCRIPT_N OF T~E_DRAWINGS

These and other features and advantages of the invention will be better and more completely understood by referring to the following detailed description of presently preferred exemplary embodiments in conjunction with the appended sheets of drawings, of which: :
FIGURES 1 and lA are schematic block diagrams of an oYerall trunked radio repeater syst~m 190 of an embodiment o~ the present invention;

FIGURE 2 is a more detailed block diagram of the signal path between the primary site controller and the dispatcher console shown in FIGURE lA; .
: :~
FIGURES 3 and 4 are schematic diagrams of message formats transmitted over the downlink shown in FIGURE 2;
i FIGURES S-6 are schematic flowcharts of exemplary program control ~tepQ performed by the site controller : shown in FI W R~ 2 :to commu~icate signal5 to and receive signals from the trunking cards;

: /. ~

:. :

~3~i2~

EIGURE 7 is a schematic flow chart of exemplary program control steps performed by trunking cards shown in FIGURES 1 and 2 to communicate signals to site controller 410;

FIGURE 8 is a timing diagram showing signal propagation delays over the FIGURE 2 downlink;

FIGURE 9 is an overall schematic flowchart of exemplary program control steps performed by the downlink trunking card and the switch trunking card shown in FIGURE
2 to propagate signals over the downlink; and FIGURES 10-18 are more detailed schematic flowcharts of the exempIary program control steps shown in FIGURE 9.
.~
DETAILED DESC~IPTION OF T9E PRESENTLY PREEERR~D
EXEMPLA~Y EMBODIfflENTS

/

~ ~ /
/
:: /

~,~
:~

S ~

7a Table of Contents . . _ 1.O OYERALL SYSTEM ARC~ITECTURE . . . . . . . . . . . 8 2.0 CENTRAL SITE ARCHITECTURE . . . . . . . . . . . . 10 3.0 INTERFACE BETWEEN TRUNKING CARDS AND SITE
CONTROLLER 410 . . . . . . . . . . . . . . . . . . . 14 3.1 OVERALL STRUCTURE AND OPERATION OE T~E
TRUNKING CARDS . . . . . . . . . . . . . . . . . 14 3.2 STRUCTURE OF SERIAL DATA LINKS BETWEEN SITE
CONTROLL~R 410 AND TRUNKING CARDS . . . . . . . 17 3.3 SERIAL DATA LINK PROTOCOL . . . . . . . . . 19 :: :
; 4.0 ~DOWNLINK ARC~ITECTURE . . . . . . . . . . . . . . 20 .

5.0 TYPES OF DOWNLINK MESSAGES . . . . . . . . . . . 25 5.1 GLOBAL DOWNL~INK MESSAGES . . . . . . . . . . 25 .~
5.1.1 CONTROL CH~NNEL GLOBAL DOWNLINK MESSAGES 26 : 5.1.2 WORKING:CHANNEL GLOBAL DOWNLINK ~ESSAGES 28 .
S.1.3 PATC~ GLOBAL DOWNLINK MESSAGES . . . . . 2~
: 5.2 ADMINISTRATIVE DOWNLINK MESSAGES . . . . . . 29 6.0 DATA TRANSLATION ON THE DOWNLINK . . . . . . . . 30 : 6.1 DATA TRANSLATION OF SITE SOURCED GLOBAL
~: MESSAGES . . . . .:. . . . . . . . . . . . . . . 31 6.2 DATA TRANSLATION OF CONSOLE SOURCED GLOBAL
MESSAGES . . .~. . . . ~ . . . . . . . . . . . . 35 , :

7.0 EXEMPLARY PROGRAM CONTROL STEPS . . . . . . . . . 39 ~: 7.1 SITE CONTROL~ER 410 INTE~ACTION WITH TR~NKING
; ~AR~S . . . . . . . . . . . . . . . . . . . . . 40 :

~ ' , ~3~5S;~:~

7b 45MR-542 7.1.1 Message Transmission On Links 412 . . . 41 7.1.2 Reception by Site Controller 410 of Messages Tr n~mitted by DLTC 450 . . . . . . . 42 7.2 STEPS PEREORMED BY DLTC 450 A~ SWITCH TC 454 43 7.2.1 Transmission of Messages F:rom Site Controller 410 to Switch 457 . . . . . . . . . 46 7.2.2 Transmission Of ~essages From Switch 457 to Site Controller 410 . . . . . . . . . . . . 56 8.0 GENERAL DISCUSSION OF MESSAGE DEFINITIONS AND
FORMATS .......................................... 62 9 . O MESSAGES ON LINKS 41~ BETWEEN SITE CONTROLLER 410 : AND TRUNKING CARDS 400,438,450. . . . . . . . . . . . 62 : 9.1 TY2ES OF MESSAGES COMMUNICATED BETWEEN SITE
CONTROLLER 410 AND THE TRUNKING CA~DS OVER LINKS
~12 . . . . . . . . . . . . . . ~ . . . . . .-. 63 : 9.2 "ADMINISTRATIVE" MESS~GES ON LINKS 412 : ~ ORIGINATED BY SITE C9NTROLLER 410 . . . . . . . 68 9.2.1 GETC SETUP COMMAND ~01 HEX3 . . . . . . 70 9.2.2 GETC BROADCAST COUNT (02 HEX) . . . . . 71 9.2.3 GETC STATUS REQUEST (07 HEX) . . . . . . 72 9.2.4 GETC FAILSOFT MODE (F8 ~EX) . . . . . . 73 9.2.5: GETC TEST MESSAGE (~B HEX) . . . . . . . 74 9.2.6 GETC RESET MESSAGE ~FD HEX~ . . . . . . 7~
9.3 RETR~NSMIT LAST MESSAGE: (FE HEXj . . . . . . 75 : 9.4 ADMINISTRATIVE MESSAGES TRANSMITTED FROM
: TRUNKING C~RDS TO SITE C~NTROL~ER 410 OVER LINKS
41~ . . . . . . . . . . . . . . . . . 76 9.4.:1 ~GXTC SETUP~RESPO~SE (01 ~E~) . . . . .:. 77 9.4.2 GETC BRO M CAST COUNT (02 ~EX~ . . . . . 78 :~ : 9.4.3 GETC STATUS RESPONSE ~07 HEX) . . . . . 79 9.~.4 GETC PRESENT STATE (Fg HEX~ . . . . . . 80 ., .

~3~5~
7c 45MR-542 iii 9.4.5 GETC TEST MESSAG~ (FB HEX) . . . . . . . 80 9.4.6 ~ET~ANSMIT LAST MESSAGE (FE HEX) . . . . 81 9.5 GLOBAL MESSAGES ON LINKS 412 ORIGINATED BY
SITE CONTROLLER 410 . . . . . . . . . . . . . . Bl 9.5.1 OUTBOUND CONTROL CHANNEL SINGLE SLOT
MESSAGE tOD HEX) . . . . . . . . . . . . . . . 82 9.5.2 OUTBOUND CONTROL CHANNEL ASSIGNMENT ~08 HEX) . . . . . . . . . . . . . . . . . . . . . 83 9.5.3 OUTBOUND WO~KING CHANNEL RADIO PROGRAMMIN~
MESSAGE (19 HEX~ . . . . . . . . . . . . . . . 85 9.5.4 OUTBOUND CONTROL CHANNEL CONCATENATED
MESSAGE (OB HEX) . . . . . . . . . . . . . . . 86 9.5.5 OUTBOUND WORKING CHANNEL REPEAT AUDIO
ENABLE/DISABLE (lA HEX) . . . . . . . . . . . 88 9.5.6 OUTBOUND WORKING C~ANNEL DROP MESSAGE (lC
: HEX~ . . . . . . . . . . . . . . . . . . . . . 8~
9.5.7 TRANSMIT FCC STATION IDENTIFICATION (F7 :~ HEX) . . . . . . . . . . . . . . . . . . . . . 89 9.6 GLOBAL MESSAGES ON LINKS 412 TRANSMXTTED BY
TRUNKING CARDS 450 TO SITE CONTROLLER 410 . . . 90 9.6.1~ INBOUND CONTRO~ C~ANNEL MESSAGE (08 HEX~ 90 9.6.2 INBOUND WORKING C~ANNEL MESSAGE (lO HEX) 9i :
}O.O: MES5AGES ON LANDLINE LINK 452 BETWEEN DOWNLINK
T~ KING CARD 450 AND SWITCH TRUNKING CARD 454 . . . 91 10.1 ADMINISTRATIVE MESSAGES CARRIED BY LANDLINE
: LINK 452 BETWEEN DLTC 450 ~ND SWITCH TC 454 . . 94 10.1.1 WORKING C~ANNEL CONFIGURATION MESSAGE . 95 : ; 10.1.2 DOWNLINK CHANNEL CONFIGURATION MESSAGE 96 :~ 10.1.3 CONTROL C~ANNEL CONFIGURATION MESSAGE . 97 10.1.4 ACKNOWLEDOE M$55AGE . . . . . . . . . . 98 10.1.5 NOT ACKNOWLEDGE MESSAGE . . . . . . . . 9g lO.Z GLOBA~ MESS MES ORIGINATED ~Y SITE

~,,~,~", , -` ~3~iS~

7d 45MR-542 iv CONTROLLER 410 WHICH ARE COMM~NICATED OVER
LANDLINE LINK 452 FROM DLTC 450 TO SWITC~ TC 454 100 10.2.1 SINGLE SLOT CONTROL CHAMNEL MESSAGE . 101 10.2.2 TWO-SLOT CONTROL CHANNE~ MESSAGE . . 104 10~2.3 WOR~ING CE~NNEL MESSAGE . . . . . . . 106 10.2.4 PATC~/SIMU-SELECT COLLECTION ACKNOWLEDGE
: MESSAGE . . . . . . . . . . . . . . . . . . 108 10.2.5 PATC~/SIMUL-SELECT ACTIVATE/DEACTIVATE
MESSAGE . . . . . . . . . . . . . . . . . . 110 10.3 CONSOLE ORIGINATED GLOBAL MESSAGES CARRIED

10.3.1 SINGLE SLOT CONTROL CHANNEL MESSAGE . 114 10.3.2 WORKING CHANNEL ~ESSAGE . . . . . . . 116 10.3.3 PATCH/SIMUL-SEEECT CO~LECTION MESSAGE 119 10.3.4 PATCH/SIMUL-SELECT ACTIVATEjDEACTIVATE
MESSAGE . . . . . . . .~ . . . . . . . . . . 124 11.O MESSAGES ON LINK 456 BETW~EN SWITCH 457 AND
~: SWITCH TC 454 . . . .:. . . . . . . . . . . . . . . :126 11.1 ADMINISTRATIVE MESSAGES CARRIED BY ~INK 456 : BETWEEN SWITCH 457 AND SWITCH TRUNKIMG CARD 454 126 11.1.1 WORKINC CH~NNEL CONFI W RATION MESSAGE 126 11.1.2 DOWNL~NK CHANNEL CONFIGURATION MESSAGE 127 11.1.3 CONTROL CHANNEL CONFIGURATION MESSAGE 128 : 11.1.4 ACKNOWLEDGE MESSAGE . . . . . . . . . 130 .5 NOT ACKNOWLED&E (:"NEGATIVE") MESSAGE 131 : ~ 11.1.6: SEND CONFIGURATION MESSAGE . . . . . 132 11.2 LINK 456 GLOBAL MESSAGES ORIGINATED BY
SWITCH 457 (CONSOLE 102) AND TRANSMITTED BY
: : :SWITCH TO SWITC~ TC ~54: . . . . . . . . . . . 133 ~: 11.2.1 GROUP CALL MESSAGE . . . . . . . . . 133 : 11.2.2 INDIVIDUAL~:CALL MESSAGE . . . . . . . 135 11.2.3~ UNKEY MESSAGE . . . . . . ~ . , . . . 137 ' :

`.-, ,:.:

s~

7e 45MR-542 11.2.4ACTIVATE PATCH ID REQUEST ME:SSAGE . . 139 11.2.5DEACTIVATE PATCH ID REQUEST MESSAGE . 141 11.2.6MODIFY PATC~ I~ ASSIGNMENT MESSAGE . 143 11.2.7 EMERGENCY STATUS ALERT MES5AGE . . . 145 11.2.8EMERGENCY C~ANNEL REQUEST MESSAGE . . 147 11.2.9 STATUS PAGE MESSAGE . . . . . . . . . 149 11.2.10 AP RESET MESSAGE . . . . . . . . . . lSl 11.2.11 CANCEL EMERGENCY MESSAGE . . . . . . 153 11.3 LINK 456 GLOBAL MESSAGES ORIGINATED BY SITE

TO SWITCH 457 . . . . . . . . . . . . . . . . 154 11.3.1 CHANNEL ASSIGNMENT MESSAGE . . . . . 156 11.3.2 UNIT KEY MESSAGE . . . . . . . . . . 158 : 11.3.3 UNKEY/CHANNEL DEASSIGNMENT MESSAGE . 160 11.3.4 DEACTIVATE PATC~ ID MESSAGE . . . . . 162 : 11.3.5 ASSIGN GROUP ID TO PATCH ID MESSAGE . 164 : 11.3.6 ASSIGN INDIVIDUAL ID TO PATCH ID MESSAGE 166 11.3.7 SITE ID MESSAGE . . . . . . . . . . . 168 : 11.3.~ CHANNEL UPDATE MESSAGE . . . . . . . 170 11.3:.9 ACTIVATE PATCH ID MESSAGE . . . . . . 172 11.3.10 PATCH COLLECTI~N ACKNOWLEDGE MESSAGE 174 11.:3.`l1 EMERGENCY C~ANNEL UPDATE MESSAGE . . 176 11.3.12 EMERGENCY CHANNEL ASSIGNMENT MESSAGE 178 11.3.13 STATUS MESSAGE . . . . . . . . . . . lBO
11.3.14 SITE CONTROLLER 410 RESET MESSAGE . 182 12.0 APPENVIX I -- GLOSSARY OF MESSAGE EIELD
DEFINITIONS . . . . . . . . . . . . . . . . . . . . 184 `: : :

. ~, . ... .
:

~ ~3~S~29~

1.0 OVERALL SYSTEM ARCHITECTURE

An exemplary trunked radio repeater system 100 in accordance with an embodiment of this invention is generally depicted in ~IGURE 1. System 100 includes at least one (and typically many~ mobile lor portable) radio tran~ceiving stations 15~ and an RF repeater station 175.
Mobile transceiving station 150 communicates via an RF
link and repeater station 175 with other mobile transceiving stations and/or with landbased parties connected to the repeater station by conventional dial~up landlines.
Repeater station 175 includes a site controller 410, individual repeater channel transceivers 177, and a multiplexing telephone interconnection network ("switch", or "MTX") 179. Site controller 410 is pre~erably a mainframe digital computer which oversees the general operation of repeater station 175. In particulart site controller 410 controls the operation of RF transceivers 177 by transmitting digital signals to and receiving digital signals from "trunking cards" ("TC"~ 400 connected between th~ site controller and individual transceivers (although only one transceiver 177 and one trunking card 400 are shown in FIGURE 1, there typically are many such trunking card/transceiver combinations in rep~ater station 175 -- one for each RF channel the repeater station operates on.
: Site controller 410 communicates with one or more dispatch consoles 102 via a "downlink" 103 which includes a "downlinkl' trunking card 450 and a "switch" trunking card 454. The downlink 103 also typically is channeled through switch 179~. Also connected to switch 179 are AVL
(automatic vehicular locating systeml 181 and CAD (computer aided dispatch system) 183. ~ system manager . , .

%~

console/computer station 416 is connected to site controller 410 and to switch 179 to allow a system manager to oversee and control the overall operation of system 100.
A remote receiver 187 a~d associated concentrator/voter 189 may be connected to trunking card ~00 to allow so-caLled "RSSI" signal strength measurements ~o be based on the stronger of the signal level receivled at the ce~tral repeater station site and the signal level received at a remote site -- thereby increasing the quality and reliability of the selected received audio.
An RF link ("RF") connects RF transceivers 177 with mobile transceiving stations 150. ~obile station 150 is capable of transmitting digitized voice or digital data signals (encrypted or unencrypted~ to and receiving such signals from repeater station 175 over the RF link.
In the configuration shown in the upper left-hand portion of FIGURE 1, mobile station 150 includes a mobile RF transceiver 152 connected to a control head 154 via a serial digital bus 153. M~bile transceiver may al50 be connected to a vehicular repeater 156 via the serial bus.
A mobile data terminal interface 1:58 may connect the serial ~us to a mobile data terminal (MDT~ 162. A separate digital voice guard ~odule 164 performs data encryption and decryption on digitized voice and/or digital data signals using the conventional DES algorithm.
In the alternate~mobile radio configuration shown in the lower left-hand corner of FIGURE l, a coupler 166 is used to connect dual control heads 154A, 1~4B to serial bus 153. In this configuration, a mobile data terminal 162 and associated interface 158 m~y be connected directly to serial bus lS3 and~or to bus 153A (on the output of the coupler 166~. Voice guard module 164 is preferably connected to bus 153A when dual control heads 154A, 154B

3L3~

and associated coupler 166 are used.
.As illustrated, individual radio units (mobile or portable radio transceivers) of various groups communicate with one other ~both within and possibly outside o their own groups) via shared radio repeater channels. A dispatch console 102 supervises the operation of repeater system 100. There may be multiple dispatch consoles 102 ~one for ~ach separate fleet of mobile/portable units) and a master or supervisory dispatch console for the entire system if desired.

2.0 CENTRAL SITE ARC~ITECTURE

Referring now more particularly to FIGURE lA, a transmitting antenna 200 and receiving antenna 202 (which may be a common antenna structure) are utilized at ~he central site with conventional signal combining/decombining circuits 204, 206 as will be apparent to those ~killed in the art. Transmitting and receiving RE antenna circuitry 200-206 individually a plurality of duplex RF channel transmit/receive circuits included in a plurality of RF
repeater "stations" 300, 302, 304, 306, etc. (there may typically be twenty such stations). Each station :transmitter and receiver circuitry i5 typically controlled by a dedicated control shelf CS (e.g., a microprocessor-based control circuit) a~ is also ~enerally depi~ted in FIGURE lA. Such control shelf logic circuits associated with each station are, in turn, controlled by trunking cards TC :(further microprocessor-based logic control circuits) 400, 4~2, 404 and 406. The trunking card~ 400-406 communicate with one anoth~r and/or with a primary site control~er 410 via control links 412.
The primary site controller 410 (and optional backup . ~ , ' , :

"` ~3~%~L

controller if desired) may be a commercially available general purpose processor (e.g., PDP 11/73 processor with a 18 MHz-J11 chip set). Although the major "intelligence" and control capabilities for the entire system reside within controller 410, alternate backup or "failsoft" control functions may also be incorporated within the trunking cards 400-406 so as to provide continued trunked repeater service even in the event that controller 410 malfunctions or is otherwise taken out of service.
More detail on such failsoft features may be found in the aforementioned Canadian Application Serial No. 566,663.
Console 102 requests resources from site controller 410 by sending messages to the site controller over downlink 103. In response to console resource requests, site controller 410 allocates the requested resources and notifies the console 102 via downlink 103 messages that the requested resources have been allocated. Hence, site controller 410 may be considered a resource allocator, and console 102 may be considered a ` resource requestor.
For example, console 102 may request a resource in response to the following stimuli: a console push-to-talk button depression (indicating a dispatch operator has requested an RF channel);
"simu-select" activation/deactivation, and "patch"
activation and deactivation (I'simu-select'' and l'patch' allow the console to call any selected collection of -mobile radio transceiver individuals and/or groups by issuing a single call request). Since mobile radio transceivers can also request RF channels independently of console action in the preferred embodiment, RF channel assignment messages may be .

~3~ 24 received by console 102 even though ~he corlsole issued no channel requests (console 102 is able to monitor all mobile radio communications in the preferred embodiment.) An optional telephona interconnect 414 may also be provided to the public switch teLephone network.
Typically, a system manager t~rminal, printer and the like 416 is also provided for overall system management and control ttogether with one or more dispatcher consoles 102). A sp~cial test and alarming facility 418 may also be provided as desired.
A slightly more detailed view of the site architecture for control data communication iR shown in FIGURE 2. Here, the PDP 11/73 controller 410 is seen to communica-te over l9.Z kilobit per second (kbps) RS232 serial lin~s 412(1)-412(N~ with up to 25 trunking control cards TC controlling respective duplex repeater circuits in those individual channels. In the preferred embodi~ent, each link 412 is independent of the other links. Another high ~peed 19.2 kilobit per second bus 420 is used to :communicate with the hardware that supports a downlink 103 to/frQm the switch 457 and dispatch ~onsole 102.
At each controlled repeater channel, the 19.2 kilobit data bus 412 is monitored by an 8031 processor in the trunking card TC associated with that channel. The TC
(trunking card) exercises control over the control shelf CS
and of~it~ associated repeater with audio, signalling and control buses. The trunking cards r~ceive hard-wired inputs providing:~lock synchronization and a "failsoft"
indlcation over a backup serial link ~BSL~ synchronization line 422 (which in the preferred embodiment is actually a high-speed serial data link and a single wire synchronization line). Such a "failsoft" indicat~on indicate~ that normal control by the c~ntral controller 410 , ~5;5~

is not available and that an alternate di~,tri~uted control algorithm should be implemented within each of the trunking card modules TC.
In the preferred embodi~ent, dispatch con~ole is t~pically not located at the location of site controller 410. This is because site controller 410 should be placed very close to the RF control shelves CS -- which are pr~ferably located at a high elevation ~e.g., on the top of the skyscraper or high hill or mountain) so as to maximize the RF coverage and effective radiated power (erp) of the rep~ater transceivers. Console 102, on the other hand, is generally locat2d wh~re it can be conveniently accessed by people responsible for communicating with the mobile units (e.~., at police headquarters, the building in which the county or city government of ~iceS are housed, etc.). Since the dispatch console 102 is generally loca ed some dista~ce away from site controll~r 410, a segment of the downlink communications pa~h 103 between the site controller ~nd the console constitutes a land line or microwave link in the preferred embodiment.
Switch 457 in the preferred embodiment includes ~
conventional telephone swit~h ("MTX") which routes audio and other signal paths between dispatch console lO2, standard TELC0 lines (not shown), and RF control shelves CS. Switch 457 may, for example, route audio between an RF
control shelf CS and another control shelf; between a control shelf and a console lO2 speaker/microphone; or betw~en a control shelf and a telephone line.
Switch 457 performs such audio path routing in a conventional manner in respons~ to digital control messages transmitted on downlink 103. Switch 4S7 includes a main proc~ssor which performs a variety of functions, including handling all downlink 103 communications tasks and passing ~3~

appropriate signals between the console 102 and the downlink 103. Switch 457 in the preferred embodiments supports several dispatch consoles 102, and routes downlink messages to the appropriate console (or to all of the consoles in the case of some downlink messages).

3.1 OVERALL STRUCTURE AND OPERATION OF THE TRUNKING CARDS
Detailed discussions of the structure and operation of RF trunking cards 400-408 and downlink trunking card 450 are found in the following aforementioned Canadian applications: Canadian Application Serial No. 566,664 of Childress et al, entitled "Trunked Radio Repeater System"; and Canadian Application Serial No. 566,663 of Childress et al, entitled "Failsoft architecture for Public Trunking System".
As mentioned previously, trunking cards 400-408 are located at respective associated repeater control shelves CS to provide control channel and working channel processing, while the downlink trunking card ("DLTC") 450 is used in downlink 103 to provide a communications path between the site controller and switch 457. A
further switch trunking card ("SWITCH TC") 454 located at or near switch 457 communicates signals between DLTC 450 and switch 457.
Briefly, all of the RF trunking cards 400-408, DLTC 450 and switch TC 454 are identical in structure in the preferred embodiment -- each being a microprocessor-based , ::

~L3~S~

control module which executes program control software and communicates with site controller 410 via a 19.2Xbps RS-232 serial link ~except switch TC 450 which does not communicate directly with the site contro:Ller 410 and communicates instead with switch 457). Any trunking card TC may operate~as either a RF control channel trunking card, a RF working channel trunking cardj a downlink trunki~g card, or a switch trunking card in the preferred embodiment.
RF control channel trunking cards perform signal processing functions associated with an RF repeater operating on a RF control channel. RF work~ng channel trunking cards perform signal processing functions associated with an RF repeater operating on an RF working channel (or associated with a d~gital voice guard landline link connecting the site with switch 457). Downlink trunking cards and ~witch trunking cards perform signaI
processing functions assocated with downlink 103 ~which communicates messages between switch 457 and site controller 410). ~ ~
Every trunking card in the preerred embodiment stores the program control software it needs to operate as a control channel, working channel, downlink and switch trunking card. Upon power up or reset of system 100, each trunking card at least initially operates as a working channel trunking card in the preferred embodiment. ~he trunking cards:are commande~-to become a control channel or downlink by the~site controller after power-up.
Site controller 410 is aIso capable of dynamically .
:~ reconiguring each tr~nking:card in system 100 to provide ontrol channel~,~wor~ing channel, or downlink chan~el proc~es ing. For e~ample, upon power-up, site controller 410 :trans~its a message to each trunking card 400-408j 450 , ~33 }~

info~ming the respective trunking cards that they are to ex cute the software controlling them to operate as RF
control channel, RF working channel and downlink tr~nking cards, respectively. Each trunking card is enabled/disabled from site operations as well as being '~steered" to the appropriate site contro:Ller (i.e., primary site controller 410, or an ~ptianal backup site controller). To dynamically reconfigure a trunking card, site controller ~lO sends a configuration message to the trunking card positively requesting the trunking card to configure itself (i.e., begin executing the software associated with) a particular function. For example, if the control channel trunking card and/or associated repeater fails, the site controller 410 can command a working channel trunking card to reconfigure itself to become a control channel trunking card.
Site controller 410 periodically sends status messages to the trunking ~ards to determine their ldentities, modes of operation, and which site ccntroller they are steered tG. Site test functions are also performed by the trunking cards in response to messages sent to them by site controller 410.
S~te controller 410 is also capable of individually testing and resetting any trunking card if a major malfunction occurs in system lO0. The test mode allows the trunking card to exercise the site controller erial interface, and the hardware ports of the trunking card --all using a test pattern designated by the site controller. For:d~wnlink trunking card 450, additional diagnostics allow exercising of the modem whi~h connects the tr~1nking card to landline link 452.
During normal operation, the trunking cards pass informational messages to site controller 410 over ~ ~ ~ o~

high-speed serial data links 412, and execute commands received from the site controller over the same links. Site controller 410 performs system control func~ions through downlink trunking card 450 and trunking cards 400-408.
However, the trunking cards are also capable of a backup trunked mode of operation without intervention from any site controller (master or backup) via a backup serial link (see the aforementioned Canadian Application Serial No.
566,663 of Childress et al).
3.2 STRUCTURE OF SERIAL_DATA LINKS BETWEEN SITE
CONTROLLER 410 AND TR~NKING CARDS
Control channel trunking card 400, working channel trunking cards 402-408, and downlink trunking card 450 each communicate with site controller 410 via independent high-speed serial data links 412. The communications path between site controller 410 and any (each) of the trunking cards includes an asynchronous serial RS-232C bus. The message protocol on these serial buses supports control channel, working channel and downlink channel processing using both a fixed length and a variable length message packet. The message protocol also provides an efficient error recovery scheme in the presence oE noise.
Both the trunking cards and the primary site controller 410 support the level conversion necessary for an RS-232C communications device.
The serial link 412 between site controller 410 and each trunking card is full-duplex to support concurrent bidirectional device-to-device communications, and has a transmission speed in both the transmit and the receive directions of ~s~

19.2 kbps. Link 412(dl) between site controller 410 and DLTC 4~0 is identical in structure and operation to any link 412 between the site controller and an RF trunking card 400-408. Data is tran~mitted over links 412 in bytes consisting of one start bit, eight binary data bits, and one stop bit. The eight bit binary data is transmitted with the least significant bit first and the most significant bit last.
FIGURE 3 is a schematic diagram of an exemplary signalling message (byte) format used to communicate messages over links 412.
Link 412 itself is a 3-wire circuit including a transmit data line, a receive data line and a signal ground line. The site controller serial interface corresponding to each link 412 is configured as a data terminal wit~ a 25-pin connector using pins 2, 3 and 7 as the bus transmitted data, bus received data and signal grvund, respectively. The following is a detailed electrical description of each serial data link 412:

RS-232C electrical interface.
Three wire asynchronous comnt~tnication: transmit, receive and signal ground.
Transmit and receive signals are bipolar.
Minimum transmit level i5 *-5 to ~-15 volts.
Maximum output resistance for transmit driver is 300 ohms.
Minimum receiver threshold is +- 3 volts.
Maximum receiver input voItage is ~- 25 volt~.
Receiver input impedance is 3k to 7k ohms.
Maximum cable length i8 25 ~eet at lg.2Kbit/sec d~ta rate.
Maximum 30 V/microse~onds slew rate.
:

:' .. : , .

.

:~L3~

3.3 SERIAI, DATA LINK PROTOCOL

Data is transferred over links 412 at a data rate of 19.2Kbit/sec. The bit time is 52.08 microsecond. On receive, the bit must be sampled with at least a x16 clock with a 15 out of 16 stability hit rate. One start bit is used, and one stop bit is used.
Eight bit binary data is transmitted over the link (see FIGURE 3).
FIGURE 4 is a schematic diagram of the frame format used for communicating data over links 412. The frame start character denotes the start of the specified message block is being transferred. The destination device examines this character to allow decodlng of the following message start character. The frame start character thus delimits the beginning of a new frame and is also used to acquire frame synchronization in a noisy message environment where bit and message framing errors may result. In the preferred embodiment, the frame start character is AA (hex~.
The message start character indicates the type-of message that is being transferred from the 'l~ource device" to the "destination device" (the "source device"
being the one of site controller 410 and the trunking card transmitting message over link ~12, and the "destination device" being the one receiving the message). This character indicates what type of command or response is being generated by the source device.
The frame start character is sufficiently different from any of the employed message start characters in order to aid error detection and correction schemes employed in both site controller 410 and in the trunking cards.
The number of message data bytes varies with the ,.. . - ;.. . - . -~311~5Si;2gL

type of message start byte. Message da~a bytes may contain command information, response information, or data information as will be shown in table 1 shortly.
The checksum byte character provides a check sum indication of the ~ntire message blo~k. Checksum is generated and detected by forming the negation of the exclusive-OR of the message start byte ~d the message data bytes. If the checksum byte received by the destination device is the sa~e as the checksum calculated by the destination device, the destination device generally transmits an acknowledge message alerting the source device that a correct version of the ~essage has been received.
On the other hand, if the checksum byte received by the destination device does not check with calculated checksum, a retransmission of the previous message frame is requested by the destination device (e.g., by sending a "no-acknowledge" message or no acknowledge message at all).
Message bit and message framing errors may occur ~n a noisy communication medium. ~ormally, a reguest for a retransmission of the source's previous message would be invoked by the deætination device upon occurrence of such an error. A source device will retransmit the same frame a maximum of three times in the preferred embodiment.
: :
:

4.0 DOWNLINK ARCEITEC~URE

Referring now to FIGURE 2, in the preferred embodiment, site controller 410 is connected via 19.2 ~bps : link 412(dll to downlink trunking card 450. Downlink trunking card 450 is a microprocessor-based control module which in the preferred embodiment i5 identical in structure :
.

' ''"::: , ' ~3~

.

to trunking cards 400-408 (although the software it executes controls it to perform message handling functions not performed by the RE channel trunking cards). Downlink trunking card 450 is connected to a 9.6 ~bps landline link 452 the other end of which is connected to a so-called "switch trunkin~ card" 4S4. The switch trunking card 4S4 connects to a main processor within switch 457 via a high speed 19.2 kbps link 456. Each of links 420, 452 and ~56 are bidirectional in the preferred embodiment, and each use di~ferent digital signalling protocols.
Because the data transfer rate of the (local high speed) site controller 410-to-downlink trunking card link 412~dl) is greater than the data transfer rate over the SWITCH TC 454-to-downlink trunking card 420 landline link 452, ~he downlink trunking rard,4S0 must buffer messages it receives over link 412~dl) and then retransmit thPm over link 452 as link 452 becomes availabIe. Similarly, because the data transfer rate over (local ~igh speed) link 4S6 (between switch 457 and the switch trunking card 454) is greater than the data transfer rate over the trunking card-to-trunking card landline link 4S2, the switch trunking card 454 must buffer data it receives from the switch beore transmitting it over link 452. The communications protocol used on link 452 must be as efficient as possible to prevent this link from becoming a "bottleneck" for data being transferred between site controller 410 and switch 457.
Downlink trunking card 450 and switch trunking card 4~4 do more than merely buffer control signals in the preferred embodiment, for an entirely diffexent communications protocol and message format are used on each of links 420, 452 and 456.
~ ownlink trunking card 450 and switch trunking card ~5i5~L

454 commu~icate with one another using a format which is virtually identical to the format described in commonly assigned aforementioned Canadian Application Serial No.
566,664 of Childress et al used by control channel trunking card 400 and working channel trunking cards 402-~08 to ccmmunicate via RF channels with mobile units. The message format used on high speed link 412(dl) to communicate between ~ite controller 410 and downlink trunking card 450 is identical in the preferred embodiment to the messa~e format described previously used for communication o~er links 412 between the site controller 410 and trunking card~ 400-408. The message format and communications protocol used on link 456 to communicate between switch trunking ~ard 454 and swit~h 457, on the other hand, is different from the trunking card-to-trunking card communications format and protocols because the main processor within the switch uses entirely different message formats in the preferred embodiment.
Downlink trunkin~ card 450 in the preferred embodiment translat~s between the message protocol of link 412(dl.) and the message protocol o~ link 452 and also compensate~ for the differences in data transfer rates of the two links. The switoh trunking card 454 performs message protocol translation and data rate compensation in order to interfa~e links 452 and 456. T~ese transl~tions are accomplished reliably and efficiently without degrading overall data transfer rate between site controller 410 and ~witch 457. ~
In addition, the downlink 103 between site controller 410 and console 102 in the pr~ferred embodiment may provide message prioritization so that more important messages are assured of being transferred befors less important messages. Message prioritization insures that the "

~ ~3~S5;~

lesser data transfer rate of link 452 cannot degrade overall system response time even under v~ery heavy message loading of downlink 103.
Data is exchanged between switch ~57 and switch trunking card 454 over a l9.2 k~ps console-to-SWITC~ TC
link 456 u~ing a "transmit and wait" for acknowledgement protocol. If no acknowledgement is received within 50 millise~onds, the transmitting unit times out and retransmits the message (giving up after it has transmitted the message three times). Acknowledgements are not sent to the console 102 by the switch trunking card 454 if the switch trunking card receive buffer queue contains more than four messages even though the message from the console 102 is received correctly (this technique being used to prevent messages from "piling up" in the switch trunking card receive buffer).
The messages transmitted on link 456 are framed for transmission as follows:

: T A B L E
Byte Number _ Character l Message ID number : 2 Number of data bytes : : 3,4 Source, destination bytes : : : 5-n Message bytes (variable ~ : length) : : n~l Checksum character : _ .

Administrative messages do not use source and destination bytes. Each byte is transmitted on an .

~3~?~52~

asynchronous basis using one start and one stop bit (10-bit characters) at a 19.2-kbps rate.
Both console-to-SWITCH TC link 4S6 and the site controller-to-downlink trunking card link 412(dl) have data transmission rates which exceed that of t:he landline link 452 Moreover, acknowledgement messages must be transmitted over the landline link 452 in addition to the other messages~ Buffers are provided within downlink trunking card 450 and switch trunking card 454 to smooth the flow of messages and to maximize data transfer rate over landline link 452. If the buffers containing messages being transmitted from console 102 to site controller 410 become nearly full, the flow of messages from the console 102 to the site controller can be slowed by delaying acknowledgement by switch trunking card 454 of messages received from the console 102.
~ To reduce the chance that urgent console messages : become "stuck" in the switch trunking card buffer and are :not rapidly communicated to site controller 410, the switch : trunking card 454 may transmit messages it receives from console 102 in the following predetermined priority:

(1) Retransmission packets (first) (2) Acknowledgement messages (second) : (3) Control channel messages (third~ -(4) Working channel messages (fourth) ~: :(5) Patch messages (fifth) (63 Administrati~e messages (last).
:
Overflow of messages produced by site controller 410 is:prevented when the downlink trunking card 450 receive buffer becomes full by delaying message acknowledgements returned from the downlink trunking card to the site :

`, , , , .' , ", ', ~ .
. ':' `' ~ ' :
'' ` ' : .

~3~S~9~

controller. Packets requiring retransmission and acknowledgament messages are always tranr,mitt~d over landline link 452 ~efore other messages in the buffer.
FIGURE 8 is a schematic diagram of estimated transmission delay over the downlink 103 in the case of a simple group call with no activity on the downlink before the message is sent. If all dispatchers should simultaneously request a call, the downl~nk would deliver the requests to the site controller at the rate of one re~uest every 15 milliseconds. Thus, the site controller 410 26 millisecond processing time in the preferred embodiment become~ the limiting delay, and the downlink 103 is capable of deliveriny messages to site controller 410 more rapidly than the site controller is capable of processing them.

5.0 TYPES_OF DOWNLINK MESSAGES

Messages communicated on downlink 103 can be classified into two main types: (1) "global" messages, and (~) "administrative" mes~ages.

5.1 GLOBAL D~WNLIN~ MESSAGES

Global messages are messages which originate at switch 457 and are intended to be received by site controller 410, or are originated at the site controll~r for int~nded receipt by the switch. That is, all global messages prop3gate along the entire downlink 103 and are u~ed to con~ey in~ormation between the site controller 410 and the switch 457. When either DLTC 450 or switch TC 454 receives a global mes5age, it passes the message along (after translating same as will be explained) down the ~L3~5~;24 downlink 103 for eventual receipt by either site controller 410 or switch 179.
Examples of "global" mess~ges inclucle m~s ag~s from the console requesting the site controller to assign a channel and call an individual or group of mobile radio transceivers; and messages from the site controller informing the console that a channel has unkeyed.
There are three types of global messages in the preferred embodiment: working channel m~ssages, control channel messages, and patch messag~s. As will become apparent, there is a direct relationship between control channel and working channel downlink messages and the messages that are transmitted on the control and working RF
channels. "Patch" global messages have no corresponding RF
message equivalent, and ~re use~ to define and control special "patch" groups (allowing, for example, a console operator to temporarily define a collection of individual and/or groups of mobile transceivers as members of a "patch" group so that the entire patch group can be called using a single console call co~and).
, 5.1.1 CONTROL C~NNEL GLOBAL DOWNLINK MESSAGES

: Downlink control channel me~sages correspond to signals which ar~ to be (or have been) transmitted over the RF control channel by an RF channel trunking card.
In the preferred embodiment, mobile units which are : :not actually engaged i~ active communication8 on 8 working channel monitor the control channel and await instructions. To access a working chann~l, a mobile unit transmit a general request on the system i~bound control .

: .

~3~

channel, and site controller 410 responds by transmitting a channel assignment message on the outbound control channel via control channel repeater trunking card 400 (this channel assignment message instructing the mobile unit to retune to the assigned working ~hannel). Similarly, if a dispatcher at the console 102 wishes to contact a sp~cific mobile unit, he or she inputs a channel request message which in the preferred embodiment is hand~ed ~y site controller 410 in a manner which is very similar to the way the site controller handles mobile-originated channel requests.
Console-originated downlink messages which involve control channel activity are classi~ied as "control channel" downlink messages, and similarly, site controller-originated m~ssages ~hich invol~e both the control channel and:the console are also categorized as "control channel" messages. Such downlink control channel messages include, for example, messages originated by console 102 requesting a gruup of mobile units or an individual mobile unit to retune to a working channel, and mess~ges originated by site controller 410 informing.the console o a succ2ssful working channeL assignment to a mobile unit or group, or indicating a mobile unit request for communications with a dispatcher, and messages informing the console of a change of status of an ongoing working channel assignment (e.g., channel unkey, or change of worki~g channel freguency). For example, the "site id"
message may be categorized as a glvbal control channel message because the RF control channel trunking card 400 controls its a~sociated RF repeater to transmit a 6imilar messa~ over the RF control channel in the preferred embodiment.

.

'~ .

, ~3~S~4 5.1.2 WORKING CHANNEL GLOBAL DOw~lLINK MESSAGES

DownlinX working channel type messages relate directly to the activity of a working channel. A worlcing channeL global message is typically communicated from the site controller 410 to switch 179 corresponding to each working channel message the site controller causes to be transmitt~d on an RF working channel in order to continuously update the switch (and the console) with working channel status. An example of a global working channel message is the unkey message originated by a mobile unit 150 on a working channel.

.
5.1.3 PATCH GLOBAL DOWNLINK MESSAGES

System 100 in the preferred embodiment includes a "patch" facility which allows a dispatcher to flexibly:
organize individuals and groups o~ mobile units into temporary ~roups called "patches." Mobile units are already preprogramm~d in the preferred embodiment to respon~ to predetermined individual and group :: :identification codes transmitted over the control channel.
Eor example, the mobile tra~sceiver installed onboard a police detective' 5 unmarked car may respond to an individual unit identification code corresponding to all homicide mobile units; to another group identification code corr~ponding to all police units; and to an individual call identification code corresponding to that specific unit.
: Sometimes, however, it may be necessary to call all '' . '.

, ~3~5~2~

homicide detectives, all police units within a specific squad, and certain individual c~ime investigation units all at the same time without calling all poli~e units. The preferred embodiment permits a dispatc~er-to speci~y a temporary "patch identification" corresponding to whatever collection of group and/or individual mobile units are desired to ~e included in the call. Once this "patch :
identification" has been specified, the dispatcher can call all units within the specified collection by depressing a single patch transmit button on console 102. Primary site controller 410 then automatically controls the control channel trunking card 400 to transmit the appropriate individual and group call messages over the control channel, direc ing all mobile units within the prespecified "pat~h" collection to tune to a free working channel. The downlink supports certain patch commands which allow console 102 to create, modify and deactivate such special patches.

5.2 ADMINISTRATIVE DOWNLINK MESS~GES

. Administrative downlink messages are messages which do not propagate the entire length of downlink 103 between site controllsr 410 and switch 457. These administrative messages ar~ "overhead" messages used:to keep downlink 103 operating~pruperly, and do not carry useful in~ormation between the site controller and the swit~h 4S7.
Administrative messages are used, for example, to insuire about ~he status~of the downlink and also to ac~nowledge correct receipt of downlink mesgages.
For e~ample, some administrative mes~ages originate at one o~ trunking cards 450 and ~S4 and are intendecl to be received by the other trunking card. Other administrative .

~3~5~2~

messages are generated by site controller 410 and are i~tended to be received by DLTC 450 and/or switch TC 454, but not by switch 457. Still other administrative messages are generated by switch 457 and are intended to be received by switch TC 454 and/or DLTC 450, but not by site controller 410.
Examples of administrative messages are acknowledgement messages transmitted by DLTC 450 to site controller 410 acknowledging correct receipt of a data byte previously transmitted by the site controller; and messages transmitted by the site controller to the DLTC and to switch TC 454 causing those trunking cards to "configure"
themselves in the operational modes required for them to support downlink ~ommunications.
,..
6.0 DA~A TRANSL~TION ON T~E DOWNLINK

The protocols used on links 420, 452 and 456 are all different from one another in the preferred embodiment.
For ex~mple, data on the site controller-to-downlink trunk~ng channel link 412(dl) is trans~itted least-significant-byte and least-significant-bit irst. On ~he landline link 452, the data is transmitted mo~t-significant-byte and: most-siginficant-bit first. On the link 456 between the switch trunki~g card:452 and switch 457, the mo~t-significant-byte is transmitted first, but each byte is transmitted with its least-significant-bit first.
Downlink trunking card 450 in the preferred ~ I
embodiment translates between the data format of link 412(dl) and the data format of link 452. Likewi~e, the switch trunking card 454 translates be~.ween the data format of link 452 and the data format of link 4S6. These .. ,. ~ , ~3~ 2~

translations are relatively transparent. For example, many such translations can be performed by storing received data in a buffer memory in the order it i~ received, and then reading the stored data in a different order. Other translations (e.g., those performed by switch TC 454 between link 456 and landline link 452) require mapping between "MID" operational codes tused by switch 457 and console 102) to corresponding "GETC" operational codes (used by downlink TC 450,:site controller 410, and RF
trunking cards 400-408).
The following tables 3-10 show field-by-field translations along the downlink 103 for various types of global messages. Field definitions are defined in the Appendix I, and the corresponding message formats re defined in the following discus~ion.

6.1 DATA TRANSLATION OF SITE SOURCED GLOBAL M~SSAGES

There are three types of slte sourced global messages: single slot control channel messages, two slot Control channel messages and working channel messages. For each type of message, there is a table below showing how the types, bits and nibbles are moved between links 420, 452 and 456.

:
:

L36~52~
4sr~lR-s42 T A B L E 2.

C:ONTROL C~NE:L ONE-SLOT ME:SSAGE:

SITE: CONTE~OLLER ~10 ~ -> CONSOLE 10:!

Link 412 ~ dl ) Liz~k 452I.inlc 456 B~rte Site Me~;3;aqe Modem IMessac:~e Con~;ole Me2~saqe~
O STB BKl MID

2OCl, OC2 GID SD1 3OC3, OC4 PKT SD2 4OC5, 06 OCl, OC2, O, OCl 5OC7, O OC3, OC4~ OC2, OC3 G CHK OC5, 0C6 OC4, 0C5 7 STB OC7, BCl OC6, OC7 8 GID BC2 CH~C
9OC1, OC2 OC1, OC2 MID
10OC3, OC4 OC3, 0C:6 TLY
11OC5,OC6 OC5,OC6 SDl 12OC7, O OC7, BKl SD2 13 C~K BC2 O,OCl 14 OC2, OC3 ~: ~ 15 OC4 , OC5 16 OC6, 0C7 17 : CEI~

N OTE: BXx, BC2, MID, GID, TLY, SDx CHK, PKT, STB
: FIELDS ARE 13YTE WIDE.
OCx FIELDS ARE NIBBLE W}DE.
TWO SITE MESSAGES CAN BE PAC~CED INTO ONE MODEM MESSAGE.
ONE MODli:M MESSAGE CAN BE: UNPACKED INTO TWO CONSOLE MESSAGES.

.

~3~5~24 4 5MR- 5 4 2 T A _B L E 3.

~O~ING CIIAN~L MESSAGE.

SIll~: CONTROLLER 410 ~ > COtaSOl.E 102 I.ink 412 ( dl ) Link 452 Link 456 B~,rte Site l~les~3aqes Modem Messaqe t::on~ole Mes~a~s 2 OW1, OW2 GID SDl 3 OW3,0W4 P~CT SD2 : 4 OW5, 0 OWl, OW2 O, OWl CHK OW3, 0W4 OW2, 0W3 6 STB OW5, BCl OW4, OWS
,~

~; ~ 8 : OWl, OW2:~ OWl, OW2 ~IID
9 OW3, 0W4 OW3, 0W4 ~ TLY
OW5, 0 OW5, BCl SDl ~: ~ 11 CHK BC2 SD2 12 O, ~
13 OW2, 0W3 ~: : 14 OW4, 0W5 ~, ~ CHK

NOTE: BKx, BC2, MID, GID, TLY, SDx CHK, PKT, STB FIELDS
: ARE~: BYTE~ WIDE ~
. ~ ~: OWx FIEI,DS ARE~: NIBBLE: WIDE .
TWO SITE MESSAGES CAN BE PAC~OED IN~O ONE MODEM MESSP~t:E.
ONE MODEM MESSAGE C~N BE :UNPP~C~OED INTO TWO CONSOLE: MIESSAGES.

-, ~
'~ .
:~

.,: .. , :. : .

~3~

T A B L _ 4.

l~O-SLOT CO~aTROL CEi~EL ~:SSAGE

SITE CONTROLIER 410 ~ --> COPlSOLE 102 Link 412 It dl ~ Lin3c 452 Link 456 Btye 5ite Messac~es Modem Message C~nBOle_Me8s~ges 0 STB BKl MID

2 OCA,OCB GID SDl 3 0CC, OCD P~CT SD2 4 OCE,OCF OCA, OCB O,OCA
S OCG, 0C~ 0CC, OCD l:)CB, 0CC
6 OC I, O OCE, O~::F OCD, OCE
7 CHK OCG, OCH OCE ~ OCG
8 : OCI,BCl OCEI,OCI ~:
: 9 BC2 CEIK
__ _ _ ~ NOTE: ~BK~, BC2, MID, :;ID, TLY, SDx CHK, PKT, STB FIELDS
: ~ ARE B~YTE WIDE.
OCx :FIELDS ARE NIBBLE WIDE. ~:
ONE CONS0LE MESSAGE CAN BE PAC}OED INTO ONE MODEM MESSAGE.
EACH MODEM MESSAGE IS UNPACECED INTO ONE SITE MESSAGE.

:: : : :

.

T A B L E 5.

A(~ 7ATE/DEACTIVATE ME:S5A~

S ITE CONl~OLLER 410 ~ > CONSOLE 102 Link 412~dl) Link 452 Link 456 B~rte Site Mes!3age Modem Messaae Con~ole Me~saqe O STB BKl MID

2 PSS, RSVE GID SDl 3 0, GRP PKT SD2 4 GRP PSS, RSVD PSS, RSVD
CHK O, GRP O,GRP
~: 6 GRP GRP
: 7 CH~C CHK

lNOTE: BKx, ~lID, GID, TLY, SDx CH~C, PKT STB FIELDS ARE
BYTE WIDE.
PSS FIE:LD I S ONE BIT WIDE .
RSVD EIELD IS SEV}5N BITS WIDE.
GE~P F.IELD IS ELEVEN BITS WIDE. ,-ONE CONSOLE MESSA~E IS PAC}{ED INTO ONLY ONE MODh'M MESSRGE., EACH MODEM MESSAGE ~ IS UNPACKED INTO ONLY ONE SITE MESSAGE.

6~.2;~DATA_TRANSL~TION OF CONSOLE SOURCED GLOBAL MESSAGES

The following tables list the data translations performed on global messayes originating at console 102 witc:h 4S7 ) .

': : : :
: : :

. ... ~.. .~

~3U5~ 4 A B L E 6.

CONTROL C~A~NEL ONE-SLOT ~355~G13 CONSOLE 102 ~ > SI~E CONTROLLER 410 Link 456 Lin~ 452Link 4~2(dl~
; Byte Console Me~sa~e~ ~vd~m Mes~aqe Site Me~saqes O MID BKl STB
; 1 TLY BK2 GID
2 SDl GID ICl,IC2 3 SD2 PKT IC3,IC4 ; 4 O,ICl ICl,IC2 IC5,IC6 IC2,IC3 IC3,IC4 IC7,0 6 IC4,IC5 ~IC5,IC6 CHK
7 IC6,IC7 IC7,BCl STB

9 MID ICl,IC2 ~ ICl,IC2 TLY IC3,IC6 IC3,IC4 ~: 11 SDl IC5,IC6 IC5,IC6.
12~ SD2 IC7,BCl IC7,0 13 O,ICl BC2 C~K
14 IC2,IC3 lS ~ IC4,IC5 16 IC6,IC7 :
~: 17 C~K

~: : NOTE: :BRx, BC2, MID, GID, TLY, SDx, STB, CHK, P~T
; : FIELDS ARE B~TE WID~.: :
x FIELDS ARE~NIBBLE WIDE.
TWO CONSOLE MESSAGE5 C~N BE PACKED INTO ONE MODEM MESSAGE.
ONE MODEM MESSAGE CAN BE UNPACKED INTO ~WO SITE MESSAGES.

~.

~ 3C~SS2~L 4 5MR- 5 4 2 T A B_ L E 7 HORKING C~NNEL MESSAGE

CONSOLE 102 ~ > Slll~ C:ONTROLLEE~ 410 Link 456Lir~ 452 Link 412 ~ dl By~e Console Messa~es Modem Messa~e Si~e Me~saqes O MID BKl STB

2 SDl GID WC1, WC2 3 SD2 PKT WC3, WC4 4 0, WC1 WCl, WC2 WC5, O
S WC2, WC3WC3, WC4 CHK
6 WC4, WC5WC5, ~Cl STB

: 8 MID WCl,WC2 : WC1,WC2 g TLY WC3, W(::4 WC3, WC4 ~ SDl WC5,BCl WC5, O
11 ~ SD2 BC2 CHK
12 O, WCl `
, ~ 13 WC2,WC3 14 WC4,WC5 1~ CHEC

Nl~ BKx, BC2, MID, GID, ~LY, SDx, CHK, PKT, STB
FIELDS ARE: E~YTE WIDE.
WCx FIELDS ARE ~NIBBLE WIDE.
: ~ TWO CONSOLE MESSAGES CAN BE PACKED INTO ONE MODEM MESSAC:E.
ONE~ MODEU MESSAGE C~N 8E UNPACK~ INTO TWO SITE MESSAGES

::

, : . . : :

, s~

T A B L E 8.
PATCE~ COr.LE~IO~J MESSAG~
CONSOLE 102 -~ 5ITE CONTROLLER 41t) Link 456 Link 452 .. Link 412 ( dl ) B~te Console Me~saqe Modem Messa~es_ Site Messaaes O MID BKl STB

2 SD1 GID CNT,HDR,SPK
3 SD2 CNT, HDR, SPKO, GRP
4 O, GCT O, GRP GRP
ICT, LID C;RP ICT, O
6 LID ICT,BCl CEIK
7 0, GRP BC2 STB
:~ 8 GRP 0, LID GID
- ~ ~ 9 O,GRP LII;) O,LID
GRP O,BCl LID
11 O, GRP BC2 O
12 GRE' C~IK
13 CHK BKl STB

:
GID O j GRP
` ~ 16 CNT,E~I)R, SPKGRP
17 O, GRP
~ la ~ GRP CHK
; 19 ~ O,BCl 2 0 _ : : BC2 NOTE:: BKx, BC2, ~ MID, GID, TLY, SDx CHK, PKT, STB
~FIEI,D5 ~E BYTE WIDE.
GCT, ICT, SPK FIELI)S ARE NIBBLE WIVE.
LID FIELD ~S TWELVE~ BITS WIDE.
~: : GRP FIELD IS~ ELEVhN BITS WIDE.
CNT FIELD: IS THREE: BITS WIDE.
~ ~ ~ HDR FIEI,D: IS ONE BIT WIDE.:
- : ~ ONE CONSOLE MESSAGE CAN BE PAC~ED INTO ONE OR MORE MOI:~EEI
MESSAGES .
EACH MODEM ME:SSAGE IS UNPACKED INTO ONE OR MORE SITE
MESSAGE5 .

' . ~

.
, '' ' ,~ ' ' ~3~i52~

T A B L E 9.

ACTIVATE~DEACTIVATE MESSAGE
CONSOLE 102 ~ --> SITE CONTROLLER 410 Link 4~6 Link 45Z Link 412(d~
Byte Console ~essaqe _ Modem Me~aqe Site ~es~a~
0 MID BKl STB

2 SDl GID PSS,RSVD
3 SD2 PKT O,GRP
4 PSS,RSVD PSS,RSVD GRP
O,GRP O,GRP CHK

7 C~K CHK
. .

N~TE:BKx, MID, GID, T~Y, SDx CHK, PKT, STB FIELDS ARE
BYTE WIDE. :
PSS FIELD IS ONE BIT WIDE.
RSVD FIELD IS SEV~N BITS WIDE.
GRP FIELD IS ELEVEN BITS WIDE.
ONE CONSOLE MESSAGE IS PACKED INTO ONLY ONE MODEM MESSAGE.
ALL laOpEll MESS~4GES ~QR A PATC~I ARE PACKED INTO ONE SITE ~IESSA&E.

7.0 EXEffloeLARY PROG~AM CONTROL STEPS

The following describes exemplary program control steps peror~ed hy site controller 410, RF trunking cards 400-408, DLTC 450, swit~h TC 45~ and switch 457 to communicate messages over downlink 103 ~et*een the ~its control}er and console 102 and b~tw~en the site controller and the RF channe} trunking cards.~

1 3g)5~i29L 4 5MR- 5 4 2 7.1 SITE CONTROLLER 410 IN~ERA~rION WI~L~ TRUNKING CA~DS

The following describes the manner in which the site controller 410 interacts with each of the various trunking cards.
Upon power up, site controller 410 transits a message to the trunking cards informing the trunkillg card that they are to execute the appropriate software (e.g., control channel, working channel, or downlink software). In configuring the downlink trunking card 450, the site controller informs the trunking card how many active channels there are on system 100, and also direct the downlink trunking card to steer its communications to the backup site controller if necessary.
The primary site controller 410 periodically sends status requests to downlink trunking card 450 to determine it.s identity, its mode of operation, and which si~e controller it is steered to.
Primary site controller 410 occasionally transmits a broa~cast message count to downlink trunking card 450 in order to communicate the number of broadcast messages sent from the site controller to the downlink trunking card.
Every trunking card in system 100 is responsible for keeplng track of current system status information independently, and~the broadcast message count helps to determine whether the YariOUS trunking cards have been accurately updated with current system status. The broadcast message count is incremented after every received broadcast-type message.
Whenever a bit or frame error oc~urs on link ~12(dl), site controller 410: can request downlink trunking card 450 to retransmit the last message by simply not acknowledg~ng rece1pt of the me~sage. Site controller 410 ~ 3~SS24 4SMR-542 .

is also capable of individuall~ tes~ing a~d resetting the downlink trunking 450 if a major malfunction occurs in ~ystem lOO. The test mode allows downlink trunking card 450 to exercise its modem (which connects it to link 452) the site controller serial interface, and the hardware ports of the trunking card -- all using a test pattern designated by the site controller.
Outbound downlink channel communications are handled by site controller 410 with the downlink trunking card 450 actin~ as a buffering device. On the receive side, status responses are sent to site controller 410 by downlink trunking card 450 to enable the site controller to determine whether the downlink trunking card is operating correctly. Inbound downlink channel messages from the dispatch console 102 are bufferPd by the downlink trunking card 450 and sent to the site controller. Messages are transferred over link 412~dl) in a framed format. Each charaeter that is transmitted or received over link 412(dl) includes the 10-bit RS-232C serial data packet stream shown in FIGURES 3 and 4~(and described in detail above).
If downlink trunking card 450 has requested three su~sequent retransmissions from site controller 410 after site controller has transmitted the synchronization s~guence, the downlink trunking card enters the failsoft mode of operation. Site controller 410 transmits the ynchronization seguence whenever it has to request the downlink tru~king;card to retransmit a frame more than twice~

7.1.1 Me~ a~ Trar~mlssion On Links 412 , , , .
" ~ . ,;,, ~ ~. . .
.

: " ~ '': ' ' ~3~

FIGURE 5 is a flow chart of exemplary program control steps (states) per*ormed by site controller 410 to transmit a message frame over link 412 to a trunking card.
Site controller 410 first transmits synchronization characters (block 504). The site controller 410 then transmits a frame start character (block 506), the message start character (block 508), and a variable number of message data bytes (block 510). Following the message data, site controller 410 transmits the checksum character (block 51~) and waits for the next frame which needs to be transmitted. If a checksum error is detected by the trunking card, the message is never acknowledged and the site controller 410 retransmits the message.
FIGURE 6 shows the steps performed by the trunking cards to transmit messages to site controller 410 over links 412. These steps are virtually identical to the steps per~ormed by the site controller to transmit messages (see FI&URE 5).

7.1.2 Reception by Site Controller 410 of M~ssaqes Transmitted by DLTC 450 FIGURE 7 is a flow chart of exemplary program control steps performed by site controller 410 t~ receive messages transmitted to it over link 412(dl) by a trunking card. Site controller 410 waits for a frame character indicating the start of a new message frame (hex '7AA" ~ in the pre~erred embodiment (decision block 522). When such a frame character is received, site controller 410 looks for a message ID Dyte (decision block 524), then a variable ~3~5~

number of data bytes (the n~tmber of bytes is specified in the start character) (decision block 526~, and then the checksum byte indicating the end of the message (decision block 52~). Once the checksum byte has been received, site controller 410 calculates checksum based on the received message characters and compares the calculated checksum with the received checksum to determine whether they correspond.
If received and calculated checksum correspond, a "good".message has been received and site controller 410 begins to process the message (block 530). On the other hand, if the tests performed by any of decision blocks 524-530 fail, site controller 410 gives up, logs an error, and waits for the next frame start character (block 522).

7.2 STEPS PERFORMED BY DLTC 450 AND SWITC~ TC 454 FIGURE 9 is a schematic flow chart of exemplary program control steps performed by system lOO to communicate data over the downlink. The sequence of operations shown on the left-hand side of FIGURE 9 communicate a message from site controller 410 to console 102 via Iink 4l2(dl), downlink trunking card 450, landline link:452, switch trunking card 454, and link 456. The steps shown on the right-hand ~ide of FI WRE 9 are used in thç preferred embodiment to communicate a message from console lO2 over the downlink 103 to site controller 410.
The ~teps shown in the upper half of the FIGURE 9 flow chart are performed by downlink trunking card 4SO, and the steps shown on the lower half of the figure are performed by the switch trunking card 454.
When site controller 410 generates a message and transmits it to downlink trunking card 450 over link . . . : ~ . . .

' ~3~i5;~

412(dl), the downlink trunking card first executes a receive logic routine (block 602) to actually receive the message. Next, downlink trunking card 450 executes a message processing routine (block 604) to analyze the received message and determine if the m~essage is in the proper form. In particular, block 604 tests whether the received message is an administrative message which must be responded to by the downlink trunking card, or whether it is a message intended to be passed on down the downlink to console 102. If the message is an administrative message requiring a response, the downlink trunking card generates the response and places it in a transmit buffer (block 606) for communication back to the site controller (block 608).
If the message received from the site controller is a "good" message and is to be communicated to switch trunking card 454, the message is placed in a transmit buffer (block 610) and is transmitted over the landline link 452 by block 612. Switch trunking card 454 executes block 614 to receive the data packet transmitted over link 452, and determine whether the received message is in correct form and was received with no errors. If the received message is a "good"
message, block 614 places an acknowledgment message into the switch trunking card transmit buffer priority queue (block 616). Switch trunking card 454 then processes the received message (block 618).
If the received message is an administrative message requiring a response from switch trunking card 454, the trunking card places an administrative message response into its transmit priority queue (block 616). On the other hand, if the received message is intended to be sent to console 102, switch trunking card 454 places the message in an internal receive buffer (block 620) and passes the , .

: .

~3~

message on to console 102 via link 456 (block 622).
In response to a messago recei~ed by switch trunking card 454 via link 456 from console 102, the switch trunking card executes a receive logic routine ~block 624) a~d acknowledges the r~ceived message if appropriate (e.g., by placing a received acknowledgement messaga in its buffer (block 620)). If the message is an administrative message whiçh requires the switch trunking card 454 to perform some diagnostic routine, the diagnostic routine (or ~ther processing) is executed (block 626). For example, console 102 may reguest switch trunking card 454 to transmit its configuration, which the trunking card does by placing configuration information into its buffer (block 620). If, on the other hand, the received message is to be passed on to site controller 410, switch trunking card 454 places the received message in its priority queue ~block 616~ in a position determined by the type of the message (as described previouslyj. switch trunking card 454 executes block 628 to remove messages from the priority queue and transmit them over landline link 4~2 to downlink trunking card 450.
. When downlink trunking card 450 receives a console originated message over landline link 452, it performs a receive logic routine (bloc~ 630) to guarantee that a "good" message has been received and causes the receipt to be acknowledged by placing an acknowledge message in its transmit buffer (block 610), Downlink trunking card 450 then proces6es the received message (block 632), and if the message is an administrativa-type message, transmits a response back to switch trunking card 454 (block 612). If the received messaye is intanded for site controller 410, downlink trunking card 4~0 places the message in its buffer (block 606) and passes it on to the site controller via .
;

~3 ~2 link 412(dl) (block 608).

7.2.1 Tra~smission of Messaqes From Site Co.nt_oller 410 to S~itch 4S7 FIGURE 10 is a more detailed flow chart of FI~URE 9 block 602. The routine shown in FIGURE 10 is performed by downlink trunking card 450 to receive and acquire a message transmitted to it over link 412~dl) by site controller 410.
Downlink trunking card 450 first determines if it has received a start character (since in the preferred embodiment, start characters are used to indicate the beginnings of message frames transmitted over link 412(dl)) (block 650). If a start character has not yet been received, DLTC 450 waits for a start character. Once a start character is received, DLTC 450 determines whether the "GETC" code is valid (i.e., tests whether the received message is a valid message) (block 652). If the received GETC code is invalid, an error is tabulated, (this tabulated error being used later to inform the site controller or console 102 about the behavior of the downlink). If the GETC code is valid, DLTC 450 determines from the code how many additional bytes of data are expect~d to be received, and then ac~uires the data bytes transmitted following the ~ETC code, and count~ the number of character~ to determine when the message has ended ~block 658~. If t~e maximum time delay expires be~ore ~he required number of characters have been received, DLTC 450 tabulate~ an error and waits for the n~xt message. On the other hand, if the entire message is received before the , .. . ' ~ . .

:~3~2~

maximum delay expires, the DLTC calculates checksum based on the rec~ived characters and compares 1he calculated checksum with the contents of the received checksum byte (block 6623. If calculated checksum and received checksum do not correspond, a transmission error has occurred, the entire received message is discarded, and an error is tabulated . If the checksum check determin~s, on the other hand, that the message was received correctly, the message is processed by the "good message processor" block 604, and the DLTC 450 awaits receipt of the next message (decision block 650).
If the test of decision block 662 reveals the received message is good, the ~essage is processed by messaye processing block 604 -- a detailed flow chart of which is shown in FIGURE ll. Blocks 675-68S decode the "GETC code" in the received message to determine what kind of message has been recei~ed. Some messages reguire an immediate response from the DLTC 450, while others are to be transmitted by the DLTC over link 452. If the GETC code is a Ol (as tested for by block 675), the site controller 410 has requested DLTC 450 to configure itself (e.g., upon initial application of power to system lO0 or upon syste~
reset). Decision block 687 tests whether bits 7 and 6 of the message are both set. If these bits are set, the command~is ignored (since the downlink trunking card has already previou ly configure itself for downlink operation, and would not be exeouting the FIGURE 9 routine in the first place unless it had already so configured itself). I ~he values of bits b7, b6 are not bo~h set in the newly-received me~sage, site con~roller ~lO i9 requesting the downlink trunking 450 to configure itself as some other kind of trunking card, and the configuratio~
process is executsd to implement that change (block 689).

,.. . .
.
': . ~ . ' .

, ' . ' . ~:

,' ' ~ 3~5~4 45MR-542 4~

Block 577 determines whether the GETC code of the newly-received message is that of a control channel 2-slot message. If this type of message has been received, the downlink trunking card must prepare the message for transmission to the switch trunking card 454 over link 4S2. Downlink trunking card 450 computes a conventional BC~ error checking fieid (block 691). Although the me~sages on link 412(dl) are pr~tected by checksum error checking, the more powerful BCH error checking and correction algorithm is used to protect data transmitted over landline link 452 in order to reduce the number of messages that need to be retransmitted over the landline link.
The downlink trunking card 450 then searches its tran~mit first-in-first-out buff~r 610 for the last 1-slot control channel message put into the buffer (block 693).
Downlink trunking card 450 transmits data over landline link 452 in packets, each packet containing at least one message and preferably two messages. The packets are long enough to contain to independent control channel l-slot messayes, or two working channel me~sages. In the pref~erred embodiment, each packet contains the same type of message. For example, one packet may contain two l-slot control channel messages, and another packet may contain two working channel messages but no packet may contain a control channel message and a working channel message. In the preferred embodiment, two messages are placed into the same packet Block 693 searches the downlink trunking card t~ansmit buffer to locate:the last packet placed into the buf~er which contains a control channel message, and decision block 695 determines whether the second message slot of that message packet is full. If the second message 810t is not full, ~he newly-received control challnel ; ' .

.

~3~

message is stored in the second slot (block 697). If the second slot i5 full, a new message packet is created, the new message is assigned a packet number (block 699) and the second slot of this new packet is set to indicate that the packet can accept another control channel message (block 701). In the preferred embodiment, each packet to be transmitted is assigned a packet number (simply an arbitrary number generated sequentially to uniquely designate packets and make it possible for receipt of individual packets to be acknowledged). Once a packet has been created by blocks 699, 701, the packet is stored in a first-in-first-out buffer (block 610 shown in FIGURE 9) at block 702 to await transmission over link 452 by FIGURE 9 block 612.
If block 679 determines the received message is a working channel message, blocks 703-713 (which are very similar to blocks 691-701) are executed to prepare the working channel packet for transmission, and the pac~et is stored on the FIFO transmit buffer ~block 702).
If the newly-received message is a control channel 2-slot message (as determined by hlock 681), it will fill an entire packet. The BCH error checking field is calculated for it (block 715), and a packet number is assigned to it (block 717~ the 2-slot message packet is then placed in the transmit buffer (block 702).
If decision block 683 determines the newly-received message is a test message, decision block 719 tests whether a modem test has been requested. If the site controller 410 has requested a modem test, a modem test routine ~not ~hownj causes the modemto generate dotting. Otherwise, the message is ignored.
If the GETC code of the newly-reçeived message indicates that the message is a status request me~sage (as .

.

~3~5~

tested for by block 685), decision block 721 determines what type of status information (present state, setup request, broadcast count or activity reg~test) has been requested. An activity request (indicated by bits bl and bO each being set) causes the downlink trunking card 4SO to transmit a message. All other combinations of these bits cause the downlink trunking card 450 to transmit specific status information back to site controller 410 (block 723).
First-i~-first-out buffer 610 shown in EIGURE 9 is implemented in a conventional manner in the preferred en~odiment. That is, this buffer is simply an area of the internal memory of downlink trunking card 450 which acts as a message queue in which the first message3 stored into the gueue are the first messages to be removed from the queue.
All retransmitted packets and acknowledge messages are transmitted by block 610 before any packets generated by block 604 are transmitted.
Once messages are placed onto this FIFO buffer, they are transmitted by the transmit logic routine 612 shown in detail in the FIGURE 12 flow chart. This transmit logic routine 612 actually transmits messages over landline link 452 and also keeps track of which already-transmitted -messages have not been acknowledged by switch trunking card 454 and must be re ransmitted.
;~ Block 730 attempts to remove the "oldest" message on the downlink trunking card transmit ~u~fer. If the transmit bufer is empty, downlink trunki~g card 450 transmits four bytes of dotting pattern (alternating binary valued bits, i.e., 1 0 1 0 1 0) (block 732). If there i5 a message to be transmitted, on the othar hand, DhTC 450 transmits the word synchronization Barker code character (block 734), the GETC code corresponding to the packet (bloc~ 736), and then determines whether a packet or a , , . :

;

':

~3~ 45MR-542 message is being sent (decision block 73~). If a packet (rather than an acknowledgement or other type of administrative message) is to be transmitted, the packet number is sent first tblock 740), followe;d by the contents of the first message slot and corresponding BC~ error checking code (blocks 742, 744), followed by the contents of the second message slot and its corresponding BC~ code (block 746, 748) (decision block 745 determines whether any message is actually contained in the second slot -- blocks 702, 744 transmit the contents of the first slot regardless of whether there is a message in the second slot). If the data being transmitted is a message rather than a packet, the message is transmitted (block 7503 along with a corresponding checksum code ~block 752) (since in the preferred embodiment only data ~ackets and not messages are protected by the BCH code).
The downLink trunking card 450 then stores the message in a message acknowledae queue (block 7~41 and checks whether any messa~es in the acknowledge message queue have been acknowledged (by checking the contents of a received acknowledgement message queue and determining if the packet number field of any acknowledge message received~
from switch TC 454 matches the packet number field of any message in:the acknowledge gueue). All messages which have ~been acknowledged are removed from the acknowledge message gueue (block 756). DLTC 4~0 then determines whether any message has been i~ the acknowledge message queue for more than 30 milliseconds (this test can be performed, for example, hy storing a real time along with every message stored in the acknowledge message gueue, this real time corre~pondlng to the time the me sa~e is stored in the queue:-- and comparing the real time field of each stored messa~e w1th the current real time) (decision block 758).

` ` ' ~`' : . ' 1 3~S~24 45MR-542~

If any message goes unacknowledged for more than 30 milliseconds, it is retransmitted by the DLTC unless it has already been retransmitted three times. A retransmit counter associated with each entry in the acknowledge queue which is older than 30 milliseconds is incremented (block 760), and all incremented retr~nsmit counters are compared with the value o~ 3 Idecision block 762). The downlink trunking card 450 "gives up" on any message that has already been retransmitted three times and has gone unacknowledged again, and simply stores an error code (block 764) for later inquiry by site controller 410. On the other hand, a message which has gone unacknowledged or more than 30 milliseconds which has not yet been retransmitted three times i~ removed from th~ acknowledged message queue (block 764) and retransmitted ~y blocks 734-748.
FIGURE 13 is a detailed schematic diagram of the received logic routine 614 executed by the switch trunking card 454 to receive data packets and messages transmitted to it over landline link 452. Decision block 775 looks for an incoming Barker code (word sync pattern~ to determine when an incoming message is present on link 45Z. When Barker code arrives, the switch trunking card 454 determines whether the GETC code in the received packet is valid (decision block 777), and then looks for a packet number (decision block 779). If no packet number is included in the r~ceived data, a message rather than a packet has been received, the message is stored (decision blo~k 781), and the checksum of the received message is checked (decision block 783). If the checksum calculated by switch trunking card 454 corresponds with the checksum field o~ the received message, the received message is assumed to have been received with no errors and is further ~3`~SS~:~

processed by good message processing block 618. If a checksum error is detected, the rec~ived message is discarded (block 7853 and an error is logged (block 787).
If the received data does have a packet number, switch trunking card 454 determi~es whether this packet has already been acknowledged (decision blo~k 787~. In the preferred embodiment, DLTC 450 retransmits the same packet number with any message it retransmits. Sometimes, the switch trunking card 454 correctly receives a packet and transmits an acknowledgement, but the downlink trunking card 450 fails to receive the acknowledgement and therefore retransmits the same packet again. Decision block 787 tests for this condition so as not to waste time on processing messages already acknowledged and processed, and generates another acknowledqement message for the received packet (block 789) and transmit~ this a~knowledge message over link 452 to downlink trunking card 450.
If the received packet hzs not already been correctly received, the messages it contains are temporarily stored ~block 791, 797), and the BCH error checXing codes they contain ase analyzed in a conventional fashion (decision blocks 793, 7991. If the BCH algorithms .
indicate the packet has been received correctly, the received messages are further processed by FIGURE 9 block 618. If some of ~he messages have been received incorrectly, however, the entire packet is discarded (block 785) and the message is not acknowledged to force the downlink trunking card 450 to retransmit the messaye. All : packet~ and all mes~a~es which have been correctly received cause the downlink trunking card 450 to tabulate a messaye count (bl~ck 801~, and transmit an acknowled~e message to the downlink trunking card (block 789).
"Good" me~sages processed by received logic routine .,,,, :, 3L3~

614 are passed on to the "good mes~age processing" routine (FIGURE 9 block 618~ a detailed schematic flow chart of which is shown in FIGURE 14. Routine 618 determines the type of the newly received message by testing the GETC code the message contains (blocks 825-835~. If the received me~sage is an acknowledge message (determined by block a~5 ) ~ it is further process:ed by transmit logic block 628 (block 837).
If the received messa~e is a 2-slot control channel message (indicated by GETC code = 08, block 827), switch trunking card 454 translates the received GETC code into a MID code understandable by console 102 (which in this case, MID = GETC = 0~) (block 839), and the switch trunking card begins to set up the message to be passed along to the console 102 by reservin~ seven bytes in a temporary storage buffer to contain the receivëd message Sblock 841).
If the received GETC code - OD (indicating a l-slot control channel message), switch trunking card 454 must analyze the remainder of the message to determine what sort of l-slot control channel message has been received and set the MID code to the appropriate code corresponding to the message (MID = 9 for unit key message, MID = 10 for unkey/channel D assignment message, MID = 12 for assign group ID~to patch ID message, MID = 13 for assign individual ID to patch ID message, MID = 14 fo~ site ID
message, or MID = 15 for channel update message). The number of data bytes reserved for any control channel lot message is six (block 845).
If the rece1ved GETC code = 19 (indicating a working channel message), the switch trunking card 454 sets the MID
code to 11 (working channel message~ (block 847), and reserves five data bytes for:the working channel message (block 849).

. .

~ 3~S~4 45MR-542 For control channel and working channel messages, the switch trunking card 454 thsn "builds" the ~essage by adding source and destination codes ~block 851~, inserting the message itself (block 8S3), calculating a checksum check ~block a5s ) ~ and storing the message so "built" into the switch trunking card transmit FIF0 buffer ~see FIGURE 9 block 620).
If the received GETC code = FB (test message), the response (a request of the message) is simply stored in the priority gueue 616 the switch trunking card uses to contain messages to be transmitted back to downlink trunking card 450. If the received GETC code = 07 (status request message), switch trunking card 454 tests whether the reguested status information is for downlink activity (decision block 861). If downlink activity information has been requested, the~information is stored in priority queue 616 for communication bac~ to site controller 410.
FIGURE 9 block 618 stores messages into the switch trunking card 454 FIF0 buffer 620 which must be communicated to console 102. The FIGURE 9 block 622 tran=mit logic routine (shown in detail in the FIGURE 15 flow chart~ removes ~essages from this buffer and transmits' them o~er link 456 to console 102. Such messages are removed from the FIF0 buffer (block 875), and transmitted over the console-to-SWITCH TC link 456 (blocks 877-885).
Routine 622 then determines whether messages it has passed on to console 102 have been acknow~edged (decision block ~: , 7). A message that has gone unacknowledged for more ~han ~ 50 milliseconds ~as tested for ~y decision block 889) is : retran~mitted unless it has ~lready been transmitted three times, at which time the ~witch trunking card 454 "gives : up" and lo~s an error (blocks 891-895).
If console 102 receives more messages than it can ,...................................................................... .

~L3~ 4 handle at a given time from switch trunki.n~ card 454, it stops acknowledging receipt messages sent: to it -- forcing the switch trunking ca~d to wait 50 milliseconds and then retransmit the message. In this way, console 102 is capable of slowing down the transfer rate on the downlink to give itself enough time to process received messages.

7.2.2 Transmission Of Messaqes From Switch 4S7 to Site Controller 410 Console 102 is also capable, of course, of initiating its own message~ and causing those messages to be transferred via switch 457 and downlink 103 to site ~ontroller 4l0. Once console 102 has constructed a message,:it transmits that message to switch trunking card 454 via switch 457 and console-to SWITCH TC link 456 .
FIGURE 9 block 624 accumulates console messages and acknowledges them -- and if necessary, slows down the transfer of console messages to th downlink to accommodate the lower data transfer rate of landline link 452. A
detailed flow chart of the received logic routine 624 is shown in FIGURE 16 .
The switch trunking card 454 looks fvr a start character (block 902) indicating the beginning of a new message, and then determines whether the MID code contained in the message i8 valid (decision block 904). If the MID
code is invalid, an error is tabulated (block 906) and the switch trunking card waits for the next message. If the MID code is valid, switch trunking card 454 determines from the code how many characters foLlowing the code it should expect, and sets a maximum delay period in accordance with , .

-~3~ 45riR-s42 this number of characters (this maximum clelay pexiod being ~ maximum time period ~y the end of which the switch trunking card should have receiv~d the entire message) (block 908). If the required number of characters has not been received by the time the delay expires (decision blo~ks 910, 9123, the received message is ignored and an error is logged (block 906). If all of the characters of the message have been received before the delay is over, a checksum check (decision block 914) is performed to determine whether the newly-received message is error free. If the received message has a checksum error, an error is logged (block 906~ and the message is ignored. If the received message is error free, a message counter is incremented to indicate the message has been received (block 916) and the message is sent to FIGURE 9 block 626 for "good message processing". Meanwhile, switch trunking card 454 determines how many messages are stored in priority queue 616 (block 618), and if more than four m~ssages are stored there, delays 15 milliseconds (block 920) before acknowledging the received message (block 922). Received messages are acknowledged by storing corresponding acknowledgement m~ssages in the FIF0 buffer managed by EIGURE 9 block 620 (block 922). FIGURES
17A-17B are together a detailed flow chart of the "good message processing" routine (FIGURE 9, block 626) performed by switch trunking card~454 to process messa~es received from console 102. Block 626 also mana~es a priority queue (used to order the messages sent over the downlink to site controller 410). As mentioned previously, one of ~he ways the preferred embodiment compensates for the lower ~ata tr nsfer rate of landline link 452 is to prioritize messages so that more important messages are transferred before less important ones.

Switch trunking card 454 under con.trol of the message processing routine 626 first determines the type of message to be transferred by testing the MID code associated with the message (blocXs 925-933). An acknowledge messagie (MID = 04) is processed by simply passing the acknowledge message to transmit logic routine 622 (blocks 925, 93~). Control channel individual and group call messages (MID - 24 or MID = 25) are processed by calculating BCH error checking/correction field (block 937), and placing the message into the second slot of a packet already in the gueue containing a control channel message or (if one existsl (blocks 939, 941, 943). If no control packets with free second slots are already on the priority queue, the switch trunki.ng card 454 sets up a new packet with a GETC code = 08 (1-slot control channel) (block 945~, a packet number (block 947), and a blank second slot Sblock 949), and then stores the new packet on the priority gueue (block 951). Finally, a counter whi~h keeps track of the number of entries on the priority queue waiting to ~e transmitted is incremented (hlock 953) and the switch trunking card waits for the next message to be processed.
If the MID code of the newly-received message indicates that the message is a working channel message (as tested for by block 929),:blocks 955-967 are performed to calculate~BCH error checking information, place the working channel messa~e in the second slot of a working channel data packet ~if one exist:s), and forming a new working channel data packet if necessary. Block 969 stor~s the new working channel data packet o~ the priority queue after the Last working channel packet (the oldest working channel data packet bein~ stored on the queue so that it is trans~itted only after all control channel working packets .~, . .., -j 5~

and acknowledge packets have been transmitted~.
If the new message is a patch message ~as indicated by decision block 931), the switch trunking card 454 must transmit a packet which is relatively long compared to the other packets it transmits over the downlink. Patch messages may be up to 16 packets long in the preferred embodiment, and these packets are transmitted only when there are no acknowledge message, control charnel message and workin~ channel message packet~ on the priority queue (therefore, a control channel packet which is formed after half of a patch message has been transmitted will be transmitted before the rest of the patch message). ~n the preferred embodiment, patch messages are relatively long because~they specify the identifications o several ~up to ten) different individual and/or group mobile units as being included in the patch. To process a patch message, a counter M is set to~O (block 971) and switch trunking card 454 then calculates the number N of packets needed to store the patch message (block 973). The patch message is then "built" by first setting the message GETC code to 15 (block 975) and then assigning a packet number which is encoded to indicate the packet numher of a patch message as well as a .
unique packet number used to distinguish that packet from others (block 977). Two BCH ields are calculated to protect the patch message from errors (block 979), and the completed packet is stored in the~ priority queue after the last patch message in the queue (which in turn is after the last working channel m~ssage) (block 981). The ~ueue counter:i~ in~remented~after each patch packet 1S ~tored in the priority queue (block 983), and the ~alue of counter M
is also changed to keep track of the number of patch packets in the patch message (block 985). Control then loops bacX to block ~75, the loop being exited when all of ~3al~

the packets in the patch message h~ve bee!n formed ~as tested for by decision block 987~.
The steps performed by the switch trunking card 454 to remove packets from the priority queue.and transmit them via landline link 452 to downlink tr~l~king card 450 are virtually identical to the steps performed by downlink trunking card 450 to transmit packets to the switch trunking card (see FIGURE 12). Likewise, the steps in FIGURE 9 block 630 performed by downlink trunking card 450 to receive packets transmitted to it over link 452 by switch trunking card 454 are virtually identical to the steps performed by the switch trunking card to receive packets transmitted to it by the downlink trunking card (see FIGURE 13).
FIGURE 18 is a flow chart of e~emplary controI steps performed by the downlink trunking card 450 to process messages received from the switch trunking c~rd 454 (see bLock 632 of FIGURE 9). The downlink trunking card 45~
first determines from the G~TC code o the received message what sort of message has been recei~ed (blocks 1002-1010).
If an~acknowledge message has been received (as tested ~or by block 1002), block 632 instructs block 612 to transmit an acknowledge message (block 1012). If a control message has been received ~as tested for by block 1004), checksum information is calculated (block 1014), a frame character is added to the front of the message ~block 1016) and the message is placed in the downlink-to-site controller FIF0 buffer ~see FIGURE 9 block 606) (block 1018~. Blocks 1014-1018 re also performed for received working channel mes~ages (a tested for by block 1006~. If a ~ulti-packet patch message has been received ~as tested for by block 1008), the downlink trunking card 450 tests whether the entire patch mecsage has been received before any part of . ~

, ' .

~3~

the message is transferred over link 422 to site controller 410. The entire patch message is acq~lired first (by block 1022~, and then blocks 1014-1018 are executed to calculate checksum, prefix a frame character and store the entire patch message into the FIF0 buffer. Note that working channel, control channel, acknowledgement and administrative messages may arrive after only a part of a patch message has been received, so that routine 632 keeps track of partially-received patch messages while processing other types of packets.
If an administrative message (e.g., test message or status message) arrives (as tested for by decision block 1010), routine 632 simply stores the message in the buffer for communication to site controller 410.
The logic routine performed by downlink trunking card 450 to transfer messa~es from the FI5URE 9 block 606 buffer and site controller 410 is straight forward, being guite similar to the routine performed by switch trunking card 454 to transmit messages over link 456 to console 102 see FIGURE 15).
A method and an architecture for communicating digita~ message signals between a communication dispatch console 102 and a RF repeater system site controller has been described. This method and archite~ture permits messages to be efficiently transferred over a landline comm~nications link which has a lower data transfer rate than other higher-speed communication paths in the downlink without seriously degrading overall tranqfer rate.
~ranslation between protocols and prioritization of messages are accomplished without significantly degrading overall transfer rate -- so that the limiting delay in the downlink is the processing speed of the site controller rather than downlink transf~r rate.

8.0 GENERAL DISCUSSION OF MESSAGE DEFINITIONS AND FORM~TS

A detailed description of the the ~essages and associated formats existing on each of the links ~20, 452 and 456 making up downlink 103 will now be present~d.
First, the messages and associated formats existing on link 412(dl) between site controller 410 and trunking cards 400-408, 450 wilI be discu~sed.
Following will be a discussion of the messages and associated formats existing on the landline link 452 between downlink trunking card 450 and switch trunking card 454.
Finally, a discussion of the messag~s and associated message formats e~isting on link 456 between switch TC 454 and switch 457 will be presented.
The discussions of the messages existing on the links will be divided into discussions of administrative , messages and global:messages. Global messages are :discussed in an order accordlns to the unit~originating the ~message. For example, global messages existing on a particula~ li~k which were originated by site controller 410 will be discussed before global messages originated by switch 457.
~: : :

9~.0 k~55A OE S~ON LINKS 412~BETWE~N SITE CO~TRoLLER 410 AND T~UN~ING CARDS 400-408,450 :

`~: : :: :
: Messages on the high-speed data links 412 between site controller 410 and trunking car~s can be~ classified in two types: those originated by the site controller, and ; those~originated by the trunking cards.

:
, ~:
, :. , ~ .. ..

~ `

: ' :
.

~3~5~

9.1 TYPES OF MESSAGES COM~JNICATE:D BETWEEN SITE CONTROLLE:R
410 AND l~E TRUN~ING C~RDS ~YER LINKS 412 The term "global message~ has no application for messa~es communicated between site controller 410 and RF
channel trunking cards 400-408, since such messages are not "passed on" to switch 457 in the sense that site controller 410 sends "global messages" to DLTC 450 which the DLTC then passes onto switch TC 454 and s~itch 457. However, in another sense, all messages transmitted between the site controller 410 and RF trunking cards 400-408 which request or confirm allocation of system resources may be termed "global messages. 7~ "' As mentioned previously, most global messages carried on downlink 103 correspond to messages carried on a link 412 between site controller 410 and an RE trunking card 400-408. For example, when site controller 410 transmits a working channel assignment message to a working channel trunking card 40~-408, it also transmits a global working channel assignment message over downlink 103 to infor~ the console 102 that a working channel has been assigned and to cause switch 457 to route the audio paths needed to connect the assigned working channel control shelf CS to the console (and perhaps also to a dial-up telephone line).
The following is a detailed discussion o~ messages communicated~between the site controller 410.and the trunking cards over links 412.
As the same messages and messa~e formats are used by the preferred embodiment site controller ~10 to communicate with DLTC 450 and with the RF channel trunking cards 400-408, the f~llowing discussion also fully describes the signalling which occurs between site controller 410 and .
~' ' 3~5;5i24L 4 5MR 5 4 2 DLl`C 450 over link 412 (DL).
Messages communicated between site controller 410 arld trunking cards 400-408, 450 in the preferred embodiment are set forth in the table belou:

T B L E ~0.
Gh PST_Site l~l~ssaqes sourcc Site Controller Hessage Message Mess~ge Description ACU I 81 6 ACU Status Message eo 1 ACU Re~et Conunand ACU 0 81 1 ACU Status Request 82 13 ACU Set Alarm Masks 85 ~ ACU Set Relay St:at~
GETC I S0 2 Downlink Patch Acti~rate 51 4 Downlink Patch rolleetio~
GE:TC I 53 2 Downlink Simselect ~ct~ate GETC I 54 4 Do~mlink Simselect Collec GhTC I SX 99 Re~erved for Down Li~3c 52 4 Patch Collection Blocks 55 4 Simulslct Collection Blck SX 99 ResenJed for Dowrllin3c 01 3 Getc Setup Respon~e 02 -1 GETC Bro~dcast Cour~t GE:TC I 07 1 GETC Status R~sponse GET~ I 08 4 CC Message 3 WC Messasle G~C I 13 8 ~C Mes~age with AVL i~fo GETC I 16 12 WC Special Call Me~age GETC I 19 99 WC Radio }?rogrammi~g M~g E'B 2 GETC Test Me~sage GE:TC I EE 1 Retransmit Last M~sa~e GETC 0 01 1 GETC Setup Command :
.. . . .~ . .

i ~ ~
~3~2~ 45~ 542 G~ PST Site ~ssaqes Source Site Controller Hessage ~e~s~ge Hessage DescriptiQn ~

GETC o 02 1 GETC Broadcast Count GETC o 07 1 GET'C Status Request GETC o 08 6 Channel Assi~nment GETC o OA 1 GETC co~versation limits ~ETC O 08 8 CC Concatenat~d Message GETC o OC 4 GETC Site ID Mes~age GETC o OD 4 CC Single Slot Message GETC o 19 3 Radio Programming Messa~e GETC o lA 1 WC Repeat Audio En/Disa~l G~TC o lC 1 WC Drop Message GETC o F7 12 FCC Morse Code Identifier GETC O F8 1 GO TO Failsoft Command GETC o ~8 2 GETC Test Message GETC O FD 1 GETC Reset Message GETC O FE 1 Retransmit Last Message L~C I 61 2 LIC Status Response LIC I 6A 2 Ring Detected on Landline LIC I 6B 2 Ring Terminated Landline LIC ~ 00 2 Reset of Host Controller LIC 3 01 2 Status Poll of LIC
LIC O 02 2 Setup Tone Dial Line LIC : ~ 03 2 Setup PuIse Dial Line LIC O 04 2 Put Line Off ~ook LIC o 05 2 Put Line On Hook LIC O 06 2 ~ Di~connect All Line/Rptr ~IC Q 07 2 Disconnect LineJRDtr LIC O 08 2 Connect Llne/Rptr LIC O 09 2 Pul3e Dial Digit LIC o OC ~ Enabl~ LIS Module~
LIC o OD 2 Disable Landline , .

~3~5~

G~ PST Site ~essaqes Sour~eSite Controller llessage Message Hessage Description IN!OUT ID L~ngth _ _ LIC O OE 2 Enable Landline LIC O OE 2 Enable Group of Landlines LIC O lE 2 Reset LIC Modu:Le PMU I Bl 3 PMU Status Message PMU I B4 3 PMU Channel Power Raading PMU O BO O PMU Reset PMU 0. Bl O PMU Status Poll PMU O B2 3 PMU Channel Mask PMU O B3 3 PMU Channel Threshold Pgm PMU O B4 1 PMU Channel Power Reguest PMU O B6 3 PMU On Channel Message RIC I 41 2 RIC Status Response RIC I 45 : 2 DTMF Digit from Mobile RIC I 4B 2 D~MF Digit from Landline : RIC I 4C 2 Dial Tone from Landlin~
RIC O 00 2 Reset of Host Controller ::
RIC O ~Ol 2 Status Poll of RIC
: RIC O 02 2 Enable Repeater Audio RIC ~ 03 2 Enable Repeater Interconn RIC O 04 2 Detect DTMF from Landline RIC O 06 2 Generate Test Tone Patter RIC O :07 ~ Z Generate Tone to Mobile RICO : 08 2 Generate DTMF to Mobile .
RI~ 0 09 2 Generate Dial To Mobile RIC O OD 2 Generate Tone To Landline RIC O OE 2 Generate DTMF To Landline : RIC O OE 2 Generate Dial To Landline RIC O lO 2 Tone to Mobile & Landline RIC :0 ll 2 DTMF to Mobile ~ Landline RIC O 12 2 Dial to Mobile & Landline ,~, ,. :

~3~

G~ PST Sit~ ~essaqes Sour~e Site Controller Message Message Message Descriptio~
IN~OUT ID Len~th RIC O 13 2 Repeat with DTMF Regen RIC O lE 2 Reset RIC Module SMAN I 00 0 Messag~ Acknowledge SMAN I 20 0 System Manager Logoff SMAN I 22 13 System Manager Login SMAN I 23 8 Logical ID Record (all~
SMAN I. 24 6 Group ID Record (all) SMAN I 25 1 Request for Alarm Status SMAN I 27 7 Clock Time/Date SMAN I 28 1 Monitor On/Of SMAN I 29 1 Activity Download On/Off SMAN I 2A 0 Site Configuration Reques SMAN I: 2F 5 Site RF Reconfiguration SMAN I 30 2 Interconnect Line Database SMAN I 31 8 Logical ID Record ~inc) SMAN I 328: Group ID Record (inc) SMAN I 3317 Interconnect Rotary D~ta SMAN 1 347~ Intercon Toll Call Restr SMAN I 351 ACU Relay Mask :SMAN ~ 3612 ACU Alarm Masks SMAN I ~ ~ FFO; Message Negative Acknowledge ~SMAN 0 20 ~ O System Manager Logoff SMAN~ O ~00 ~ O Messag- ~Ac~nowledge S~AN; O 22 13 Site Login SMAN O 23 : O Logical Databas~ Request SMAN O 24 O Group Database Reguest SMAN O 25: ~ 9 Alarm/Status Record SMAN O 27 ~ O Request for Time/Date SMAN O 28 19 Monitor Record ~:
SM~N O 29 16 Activity Record ,,,~, . . .

~3~

6a ~ PST Site ~essaq~s Source Site Controller Message Message Heslsage Description IN/OUT_ ID_ Lenqth SMAN 0 2A 14 Site Configuration SMAN 0 30 0 Re~uest for Intercon Line SMAN O 33 0 Request for Intercon Rotr SMAN O 34 0 Request for Intercon Toll T'JI 91 2 TU Status Response TU I 94 12 CC Monitor Results TU I 94 1 CC has Fai led TU I 96 1 Test Call Results TU I 9X 1 RF Test Results TU 0 07 0~ TU Status Poll TTJO 08 6 Monitor Control Channel TU O OB 0 Send CC ~onitor Results :-: ~U O OE O Stop Monitorin~ CC
TU O 10 0 Perform Test Call :~ TU~ 0 13 0 Send T~st Call Re~ults : TU O 20 2 Perform RF Test TU O 23 0 Send RF Test Results TU 0 25 0 Stop RF Test TU ~ FD O TU Reset Command TU O FE O Retransmit Last Command ~: :

~; :9.2 "ADMINISTRATIVE" MæSSAGES ON LINKST4~2 ORIGINATED BY
SITE CONTROLL~R~10 T~e ~ite ontroller 410 sends commands and poll : requests to the trunking cards in order to perform overall managem~nt of sys~em 100. The types of admini~trativ*
messages transf0rred from site controller 410 to t~le trunking Gards include resynchronization characters, setup .--~~
~3~

commands, poll commands, downlink communications, and test functions.
The following are descriptions of administrative messages transmitted by site controller 410 over link 412(dl) to the trunking cards.
. . _ /
/

/
/
; /
/
: : : / :

/:

: ~ :

;;2~

9.2.1 GETC SETUP COMMAND (01 HEX) To: Trunking card From: Site Controller 410 The trunking card is configured as a control channel, working channel, or downlink trunking card at power up or reset using this message.
One message data byte is used to confiyure or reconfigure the trunking card.

The message data byte bit definition is given below:
b7 b6 = O O disable the GETC from any functional channel processing O 1 enable the GETC for control channel processing :
: 1 1 enable the GETC for downlink ~channel processing b5 = O steer the GETC to the master site controller 1 steer the GETC to the backup site controller :: : :
b4 b3 b2 bl bO channel number of the GETC
at the pst site .
` ~

3~ i2~

45~1R-542 , 9.2.2 GETC BROADCAST COUNT (02 HEX) To: Trunking card From: Site controller 410 The site controller 410 transmits to the trunking card the current broadcast count number. This is used by the trunking card to determine if a channel assignment or update message has been missed. If one has been missed, the trunking card will transmit its latest broadcast count number back to the site controller 410 indicating a missed assignment.
The message data byte contains the following:
b7 b6 b5 b4 b3 b2 bl bO -~ broadcast count, module 256 At power up or reset, the trunking card awaits the broadcast message~count from the site controller 410 before reporting any missed assignments.
'' ' ,: ,~ :

~3~55;~

45MR~542 9.2.3 GETC STATUS_REQUEST 107 HEXj To: Trunking card From: Site controller 410 The site controller 410 requests the status of the trunking card to monitor its activity. The items that are monitored include the present state of the trunking card (as determined by the internal state table), setup or configuration, the trunking card broadcast count, and the trunking card's-present activity (e.g., present type of communication).
The message data byte contains which status ~al~e the GETC will return to the site controller ~10.
b7 b6 bS b4 b3 b2 = O O O O O O
bl bO = O 0 present state O 1 setup request ~ ~ 1 0 broadcast count ;~ :1 1 activity request :::
~: /

: /
~ ~ ' ;
, ' ~ ' ~3~;;SZgL

.

9.2.4 GETC FAILSOFT MODE (F8 EEX) To: Trunking card From- Site controller 410 The site controller 410 instructs the trunking card to go to the failsoft mode of operation pending further communications.
The message data byte is encoded as follows:
b7 b6 b5 b4 b3 b2 bl bO = O 1 0 1 0 1 0 1 (55 HEX) ; /
/

: : /

:
~ ~ /
~; ~

:: ~

~3~ 2~

9.2.5 GETC TEST M~SSAGE_(FB HEX~

To: Trunking card From: Site controller 410 The site controller 410 sets the tr~nking card into a test mode of operation. Before the site controller 410 transmits this command, the trunking card is put ~nto the disabled mode of operation via the setup command. The tests that are performed include modem check, a site controller 410 serial test, and a hardware port value check. In the modem test for DLTC 450, a continuous data byte value is transmitted over ~he downlinX path. In the modem test for an RF trunking card, a continuous data byte is transmitted over the air. In the site controller 410 serial test, a continuous byte is sent over the RS-232C bus to the site controller 410. In the hardware port test, the speciied port on the:trunking card is loaded with the given message in byte 2.
The two message bytes are encoded as follows:
Byte 1 ~
b7 b6 bS b4 - hardware port location b3 = 0 no hardware port test 1 hardware port test enabled b~ ~ 0 no site controller 410 : 1 serial test enabled : bl = 0 no modem test 1 modem test enabled : bO = 0 no RF modem te~t 1 ~ RF modem test enabIed : Byte 2 -- 8 bit binary data used in the specified test.

., , : .
' .
.

~3~

7~ 45MR~542 9.2.6 GETC RESET MESSAGE (FD HEX) To: Trunking card From: Site controller 410 The site controller 410 instructs the trunking card to reset.
The message data byte is encoded as follows:
b7 b6 b5 = 0 0 0 b4 b3 b2 bl bO = trunking card identification (e.g., channel number) ., .
. :
; ~ 9.3 RETRANSMIT LAST MESSAGE (FE HEX) The site controller instructs the trunking card to retransmit its last message. ~his occurs during bit.errors ; and message framing errors.
.
The messaye data byte is encoded as follows:

b7 b6 b5 =~0 0 0 b4 b3 b2 bl ~O -- GETC channel number (identification) In the downlink 103, site controller 410 administrative-type messages generally psss rom the site ~3~

controller 410 to downlink trunking card 450, and from the downlink trunking card on to the switch trunking card 454. The acknowledge message is used only between the downlink trunkiny card 450 and the switch trunking card 454 on the 9.2 kbps llnk 456.

9.4 ADMINISTRATIVE MESSAGES TRANSMITTh`D FROM TRUNKING

A detailed description of each of the administrat.ive" messages transmitted by the trunking cards to site controller 410 over links 412 in the preferred embodiment appears below.

- /

/... . _ _ . _ ~3~

9.4.1 GETC SETUP RESPONSE ~Ol HEXl To: Site Controller 450 From: Trunking card The trunking card .~ends its setup or configuration : back to the site controller 450 in response to a status re~uest command originated by the site controller 450.
The message data bytes are encoded as follows:
. Byte 1 ----b7 b6 = O O trunking card disabled from any functional channel processing (abnormal) O l trunking card performing control : channel functions : l O trunking card performing control : ~ channel function~
:~ ~: ; :
: 1 1 trunking card performing downlink : functions b5 = O GETC steared to the ma~ter site controller l GETC steered to the backup site controller :~ : b4 b3 b2 bl bO the identification number of the : trunking card read from a five bit 3IP switch setting : b7 and b6 are identical as provided by the GETC
~e~up ~ommand from the site controller.
b5 may~not be identical because once steered to the : : alte~nate slte controller, the GETC may not ~ind a~tive communications pre~ent in which case:it would ~teer to the :~ :: ac~e ite controller.~:
: Byte 2 ~ : low order ~ bits forming the 14 ~it FCC frequency code --~3~iiS2~

these bits are read from the DIP
switch on the GETC
Byte 3 ---- high order 6 bits forming the 14 bit FCC frequency code (embedded in the low order bits of message #3) these bits are read from the DIP
switch on the GETC

9.4.2 GETC BROADCAST COUNT (02 HEX) To: Site Controller 410 From: Trunking card The trunking card transmits to the site controller its current broadcast count number.
This message is sent in response tv a status request from the site controller 410 asking for the broadcast count - or whenever the next site controller 410 generated broadcast count message does not check with the trunking card broadcast count.
At power up or reset, the trunking card awaits the : : broadcast count message from the site controller 410 and sets its broadcast count to that value.
: ~The message data byte contains the broadcast count number, modulo 256.

, ~ :

.

, ~ .

.
~ ' -~, ; ,; . . , ^`~`` ~31~5~

9.4.3 GETC STATUS RESPONSF.I07 HEX~

To: Site Controller 410 From: Trunking card The trunking card sends its present activity :response back to the site controller 410 as reguested by the site cQntroller 410 in a status request message.
The present activity includes RF carrier indicating, on-air indicator, first power up or reset status and type of ongoing communication.
The message data byte contains the following bit designations:
: b7 = 0 subsequent poll ater re~et : 1 first poll after reset b6 = O ~AM area ok ~: 1 RAM area error b5 = :0 no transmit ongoing : 1 transmit ongoing ` b4 = O no carrier being received 1 carrier b*ing received 3 = O no emergency 1 emergency call b2 = O ~tandard call 1 special call bl, bO = 0 0 voice communication : O 1 DVG communication 1 0 data communication : 1 1 interconnect communication :: ~

;: :

~3~ i2~

9.4.4 GETC PRESENT STATE (F9 HEX) To: Site Controller 410 From: Trunking card The trunking card returns the present state to the site controller 410 upon request. The present state indicates the present trunking card activity.
The message byte is encoded to give the trunking card present state (O - 255).

9.4.5 GETC TEST MESSAGE (FB HEX~

: To: Site Controller 410 ~From: Trunking card The trunking card responds to the site controller 410:with the hardware port ~est configuration. This message is sent~periodically~:in the trunking card test mode o operation. The trunking ~ard reports the status of the : onboard input latches or buffers. A total of 8 hardware : registers are reported.
: The two~message bytes are encoded as follows:
Byte 1 -- :
;~ b7:b6 b5 b4 b3 = O O O O O
b2 bl bO -- hardware port number : Byte 2 --:~ : : 8 bit value ~ontained in the hardware port specified in byte #l .

~ ,. .

.

~3~5524 9 . 4 . 6 RETRANSMIT LAST MESSA5~ ( FE HEX ) The trunking card instructs the site controller 410 to retransmit its last message. This occurs during bit errors and message framing errors.
The message data byte ~ s encoded as follows:
b7 b6 b5 = O O O
b4 b3 b'~ bl bO ---- channel number ~; 9 . S G~OBAL ~D3SSAG2~:S ON LINRS 412 ORIGINATED E~Y SIll~:

. ~: The following presents more detailed descripti:ons of some of the site controller to trunking card global :: messages.

: ; : :

::
~, ~,~ :
.

..

.

. ~

3~3~i5~

9.5.1 OUTBOUND CONTROL CHANNEL SINGLE SLOT MESSAGE (OD
HEX) -To: Trunking cardFrom: Site Controller 410 The site controller sends a single slot message to the control channel GETC. This ~essage includes channel updates~ dynamic regroups, alias I.D.'s, status acknowledges, time mark, unit keyed/unkeyed/enable/disable, site I.D., and system operational mode.
The message data bytes are encoded as follows:
Byte 1 ~
: : b3 b2 ~1 bO = O O O O
least significant nibble of the radio message in the upper nibble Byte 2 ---- next byte of radio message ~ :
Byte 3 ~ next byte of radio message Byte 4 ~ most significant byte of radio . message -- .

: ~ : : ' / ' ~:: : :
,~' :~ : :: :

: . : ,,~

~: : "~
.

`:
, : , :

, . ~: . ' . .

~3~iSZ~

9.5.2 OUTBOUND C_ TROL CH~NNEL A5SIGNMENT (08 HEX~

To: Trunking card From: Site Controller 410 The site controller 410 sends a channel assiqnment to the:trunking card. The outbound control channel assignment is composed of the 2-8 bit radio information field, a 4 bit field indicating originator of assignment, an 8 bit working channel setup and 1/2 logical ID and the hang time. The site controller 410 is also capable of dynamically reconfiguring the the working channels for a different: communications mode (voice, DVG, data, or interconnect). `

The message data bytes are encoded as foIlows:
. Byte 1 ~
b3 = O radio originated call 1 console 102 originatad call .~
b2 bl bO = O O O
least significant nibble of radio message i~ the upper nibble Byte 2 ---- next byte of radio message Byte 3 ---- ~next byte o radio message Byte 4 ---- most significant byte of radio message ~: : Byte 5 ---- hang time byte b7 b6 bS b4 b3 ~b2 bl bO -- O to 255 seconds : Byte 6 ~ working channel setup byte and 1/2 ~: logical ID
~, :
~:

. . , . ~ .

: - :

.
.

~3~?5~2~

b7 = O standard working channel handshake special call working channel handshake b6 = O no repeat of inbound working channel messages 1 repeat of inbound working channel messages 5 b4 b3 b2 bl bO -- 1/2 logical ID for the second message in a 2-slot outbound message :

.

~3~3?S~2~

9.5.3 UTBOUND WORKING CHANNEL RADIO PROGRAMMING MESSAGE
(19 HEXL

To: Trunking card - From: Site Controller 410 The site controller 410 instructs a working channel trunking card to buffer the data to be sent to the mobile radio unit.
The message data byte length is variable and is encoded as follows:
Byte 1 ---- packet number ( O through 2S5, module 256 ) Byte 2 ~ packet size in bytes (O through 255~
: Byte 3 ---- first byte in packet Byte 4 ~ second byte in packet :~:
~; .
~ Byte N = last byte in packet ::
~: :: ;:

:: :

::

.. ~ ~' ' . . .

-~L3~?~;;5~9~

9.5.4 ~ ATENATED MESSAGE ~OB
HEX) The site controller 410 transmits a concatenated message to the trunking card. The concatenated message is a 2-sl~tted message to the mobile radio units. The site controller 410 provides mobiles with site status information, dynamic regroup prsconfiguration plans, ID
assignments, and programming channel assignments.
The site controller passes 8 message bytes of information to the trunking card. These message data bytes are encoded as follows:
Byte 1 ----b3 b2 bl bO = O O O O
first radio slot, least significant nibble of radio message in the upper nibble Byte 2 ---:- irst radio slot, next type of radio message Byte 3 ~ first radio slot, next byte of radio message : Byte 4 ---- first radio slot, most significant byte of radio message :~ Byte S ----b3 b2 bl bO = O O O O
: second radio slotj least : significant nibble of radio message ln the upper nibble Byte 6 -~ econd radio slot, next byte of : radio mes~age -: Byte 7 ---- second radio slot, next byte of Byte radio message .

:, . ~ '; .' : . . ' '' '. : , ' , ' . `.
' ;52~

Byte 8 ---- second radio slot, most significant byte of radio message ,`: /

/
~ /
,~ /

~ / :

_ _ _ _ :: :

.
, ,~ ~ . ' ' ~ ' , ~ ~3~5~

9.5.5 OUTBOUND WORKING CH~NNEL RE~EAT AUDIO ENABLE/DISABLE
(lA HEX) The site controller 410 instr-lcts the trunking card working channel to enable or di~able the repeat audio path of the mobile communication. This is used to quickly disable inactive users.
The messaye data byte is encoded as follows:
: b7 = O disable repeat audio path ~;~; 1 enable.repeat audio path , b6 b5 = O O
b4 b3 b2 bl bO - GETC number of specifie~ .
channel :: :
: 9.5.6~0UTBOUND WORKING CHANNEL DROP MESSAGE (lC HEX) : : : : : : :
The site controller 410 instructs the working : channel to abruptly terminate all communications activity.
The mes~saqe data byte are encoded as follow~:
, :
b7 bÇ b5 - O O O
b4 b3 b2 bl:bO -- G~TC (working chann~l) number ~ .
~ .

.

.

..
.
.

~3~55;2~

9.5.7 TRANSMIT ECC STATION IDENTIFICATION ~F7 HEX~

The site controller instructs the trunking card working channel to transmit the FCC station identification Morse code over the RF airways. The FCC ID is padded with bytes of OO to a length of 12 bytes.
The format of the message data bytes are as follows:

Byte 1 ---- message data byte count Byta 2 ---- first data byte of FCC code Byte 12 ---- last data byte of FCC code /

/

/

: /

:: : :
; :

~3~ 2~
,, ~

9.6 GLOBAL MESSAGES ON LINKS 412 ~RANSMITTED BY TRU~KI~
C~RDS 450 TO SITE CON~ROLL_ 410 Below are detailed descriptions of exemplary formats for each of the "global" messages sent by the trunking cards to site controller 410 over links 412.

9.6.1 1NBOIJND CONTROL CHANNEL MESSAGE (08 HEX) To: Site Controller 410 From: Trunking card The trunking card sends a radio control channel message to the site controller 410. The inbound control channel messaye is composed of the actual 28 bit radio data with a 4 bit header. The 4 bît header is comprise~ of ~eros.
The trunking card passes 4 bytes of information to the site controller. T~e message data bytes are encoded as follow3:
8yte 1 ~-b3 b2 bl bO = 0 0 0 0 least significant nibble of message in the upper nibble Byte 2 -- next byte of radio message Byte 3 -- next byte of radio message Byte 4 -- most significant byte of radio message .,,,,, ~ , - , . .

'' : ' ' ~3f~SZ~

9.6.2 INBOUND WORKING CHANNEL MESSAGE (10 HEX~

To: Site Controller 410 From: Trunking card The trun~ing card transmits the standard inbound working channel message without mobile AVL information to the site controller 410. The messa~es that are passed to the site controller 410 include the key, unkey, drop channel, null message, and radio dotting message.
The trunking card passes 3 bytes of message information to the site controller 410. These bytes are encoded as follows:
Byte 1 --b3 b2 bl = O O O
bO = O normal message or channel drop message 1 channel drop occurred without radio arriving on the specified workin~
channel to complete the standard initial ~handshaking of dotting least significant nibble or radio message in the upper nibble ; Byte 2 -- next byte of radio message :~ Byte 3 -- most significant byte of radio : . ~message 10.0 MESSAGES ON L~NDLINE ~INK 452 BETW~EN DO~NLIN~ TRUNKING

.

The interface between the DLTC 450 and the switch TC
454 is a standard landline serial link 452 terminating at each end in standard wiring and standard connectors. All site audio wiring enters the dispatch center through a standard telephone block. The telephone lines are run between the DLTC 450 and switch TC 454 (each channel is provided with its own cable). Standard connectors are used at each end of the telephone cable. Link 452 is operated in the full duplex mode, with message transmission occurring in both directions at any given time.
Exclusive-OR BCH checksums are used to insure data integrity.
The transmission bit rate on landline link 452 is 9.6 kbps as determined by the downlink trunking card 450.
Messages are transmitted over link 452 in packets, each packet containing one or two messages. Data is exchanged by packets over link 452 using an automatic retransmission unless acknowledge protocol 00 meaning that the transmitting trunking card will retransmit a data packet (up to three times in the preferred embodiment) until the receiving trunking card sends an acknowledgement message indicating it has correctly received the packet.
The receiving trunking card may acknowledge correct receipt of a packet by transmitting an acknowledgement message to the transmitting trunking card, this acknowledgement message specifying message type and packet number. If the received packet contains an administrative message requiring a response by the receiving trunking card, acknowledgement is made by transmitting the requested response. If no acknowledgement is received within three message times after the last byte of the packet has been ~3~

transmitted, the packet is a~ltomatically retransmitted (up to a maximum of three times).
Packet frames may be transmitted without interruption, with açknowledgement messac3es being interspersed between other packets as they occur. LinX 452 is synchronous, so that dotting is transmitted if the transmit buffer is empty.
The frame format for data packets transmitted over link 452 is as follows:

T A B L E 11.
Byte Number Character -1,2 Barker code 3 GETC code start byte 4 packet number (if needed) : 5,n ~essage blocks (1 or 2) n+l checksum (if requiredj :~ /
/

,, ~L3~552~

10.1 ADMINISTRATIVE MESSAGES CARRIED BY LANDLIN~ LINX
452 BETWEEN DLTC 450 AND SWITCa TC 454 Administrative messages are used to transfer global messages, keep byte and message synchronization, and pass administrative status information between the DLTC 450 and switch TC 454. The link is used in the full duplex mode, with message transmission occurring in both directions at any given time. Exclusive-OR checksums are used to insure data integrity. An "acknowledge" or any other administrative message forces message and byte synchronization. The DLTC responds to send configuration messages with a downlink, working or control channel administrative message.
~ t l~ ~v ",,~ , ~` ~; The 4~or~m~ are exemplary a~ministrative message ormats carried by landline link 452 between DLTC 450 and : switch TC 454.

:
:
''~ /

/

"
,-.
,~
/ , , ~3~5~i;2~

~5 10.1.1 WORKING CHANNEL C0NFIGURATION MESSAGE

MESSAGE TYPE: Administrative MESSAGE NUMBER: 87 OVERALL LENGT~: 6 bytes WHEN SENT: Transmitted only by the DLTC 450 in response t~
receiving a working channel command from the site controller 410.
SOURCE: DLTC 450 ORIGINAL SOURCE: Site controller 410 DESTINATION: switch 457 FINAL DESTINATION: switch 457 : `
; ~ ORgING_C~ANNEL MESSAGE FORMAT
- ~ :
Byte ~ Bit # De~cription :: 7 6 5 4 3 2 ~1 0 :
0 0 1 0 1 0 I 1 1 BK1 Barker byte 57 : 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 ;~ 2~: 0 0 0 0 Q 0 0 1 GID message id=87 3 0 0~ 1 0 0 1 0 1 PKT packet number of this message.
~; 4 0 0 0 0 0 0 0 0 Not used : 5 0 1 1 0 0 0 0 1 CHK exclu~ive or : : check~um .

~L3~55;~

g6 10.1.2 DOWMLINK C~ANNEL CONFIGURATION MES';AGE

MESSAGE IYPE: Administrative MESSAGE NUMBER: 88 OVERALL LENGTa: 6 bytes WHEN SENT: Transmitted only by the DLTC 450 in response to receiving a downlink channel command from the site controller.
SOURCE: DLTC 450 ORIGINAL SOURCE: Site controller 410 DESTINATION: Switch 457 FINAL DESTINATION: Switch 457 DOWNL_NK C~NNEL MESSAGE EORMAT
:
~ ~ Bvte ~ Bit ~ Description : 7 6 5 4 3 2 1 0 .
0 0 1 0 1 0 1 1 1 BKl Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 2: 0 1 0 1 1 0 0 0 GID message id=88 3 ~ O O 1 0 0 1 0 1 PKT packet number : of this message.
0 0 0 0 0~ 0 0 Not us~d 0 0 1 1 1 0 0 1 C~K exclusive or checksum :

" , . . .
:
:

~3~5i;52~

10.1.3 CONTROL CH~NNEL CONFIGURATION MESSAGE

MESSAGE TYPE: Administr21tive MESSAGE NUMBER: 89 OVERALL LENGTH: 6 by~es WHEN SENT: Transmitted only by the DLTC 450 in response to receiving a controL channel command from the site controller 410.
SOURCE: DLTC 450 ORIGINAL SOURCE: site controller 410 DESTINATION: Switch 457 FINAL DESTINATION: Switch 457 ':
~: CONTROL ~HANNEL ~ESSAGE FORMAT
. ~
B~te #_ Bit # De~cription 7 _6 5 4 3 2 1 0 0 0 1 0 1 0 1 1 1 BKl Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 2 0 1 0 1 1 0 0 GID message id=89 3 0 0 1 0 0 1 0 1 PKT packet number -: : of this me~sa~e.
4 0 0 0 0 0 0 0 0 Not used 0 0 1 1 1 0 0 0 CHK exclusive or ~hecksum :
;

, ~s~z~

10.1. 4 ACKNOWLEDGE MESSAGE

MESSAGE TYYE Administrative MESSAGE NUMBER: gO
C)VERALL LENGT~I: 6 bytes ; W~EN SENT: Transmi tted by either DLTC 450 or switch 457 in response to correctly receiving a ~lobal message.
SOURCE: Switch 4S7 or DLTC 4SO
ORIGINAL SOURCE: Switch 457 or DLTC 450 DESTINATION: DLTC 450 or switch 457 FINAL DESTINATION: DLTC 450 or switch 457 .':
ACKNOWL~GE ~:SSAI:;E FORMAT
B~rte~ ~ ~ Bit # Description 7 ~ 6 5 4 3 2 1 O
~: :: 0 0 10 1 0 1 1 1 BK1 Barker byte 57 1 0 0~ O 1 0 0 1 0 BK2 Barker byte li!
2 O 1O 1 1 O 1 O GID message id=90 :
3 ~ O O1 O O 1 O 1 PKT packet number of this messag~.
: 4 O OO O 1 0 0 1 PKT packet num~er of acknowledged global message.
O O1 1 0 0 1 1 (~K exclusive or chec:ksum ~3~

10.1.5 NOT ACKNOWLEDGE MESSAGE

MESSAGE TYPE: Administrative OVERALL LENGT~: 6 bytes - ~HEN SENT: Transmitted ~y either in response to incorrect:ly receiving a global message.
SOURCE: Switch 457 or DLTC 450 ORIGINAL SOURCE: Switch 457 or DLTC 450 DESTINATION: DLTC 450 or switch 457 :.
NOT ACYNOhLEDGY ~ESSA~ FORMAT
: Bvte # Bit # Descri~tion - .

O O 1 O 1 O l 1 l BKl Barker byte 57 1 O O O 1 O O 1 O BK2 Bar~er byte 12 2 O 1 O 1 l O 1 1 GID message id=91 : 3 O O 1 0 0 1 O 1 PKT packet number : of this mess~ge.
~, - 4 O O O O 1 0 0 1 PKT pa~ket number of acknowledged global message.
O O 1 1 O O 1 O C~K exclusive or ~hecksum ~3~2~

10.2 GLOBAL MESSAGES ORIGINATED BY SITE CONTROLLER 410 W~IC~
AR~ ~OMMUNIGATED O~ER LANDLINE LIN~ 452 FROM DLTC 4 O TO
SWITC~ TC ~54 Landline link 452 carries global messages between DLTC 4SO and switch TC 454 on one leq of their journey traversing downlink 103 between site controller 420 and switch 457. These global messages are divided into two categories: console requests issued by switch 457 to the site controller 410; and site controller commands. The site controller commands may be responses to console resource requests, or responses to mobile resource requests. The DLTC 450 and switch TC 454 do not directly recognizs the content of the global messages that they are transferring in the preferred embodiment.
The switch main processor may reguest the site -controller to provide a RF channel in xesponse to a console 102 push to talk (PTT) command. The switch 457 may also request the RF channel to be released followin~ a console unkey command. Eor patch or "simul-select" operation, a patch id is required from the site contro}ler before a RF
chan~el request may be made. Deactivating a patch or "simul-select" requires that the patch id be deactivated also.
Since the site controller mana~es the RF channels during normal system operations, all channel assignments and deassi~n~ents are made through the site controller 410. Mobile, portable and console channel reguests are all honored. Any channel assiqnment or deassi~nment qenerate~
a message to the di patch center throu~h the downlink. The site controller 410 also a~signs a patch id for patch and ~3~ 4 simul-select op~ration. These assignments and deassignments of patch id also generate messages to the dispatch center via the downlink.

The following is a dascription o:E the repertoire of exemplary global messages transmitted by DLTC 450 over landline link 452 to switch TC 454 in response to global messages received by the DLTC from site controller 410:

10.2.1 SINGLE SLOT CONTROL CHANNEL MESSAGE

MESSAGE TYPE: .Global MESSAGE NUMBER: 13 OVERALL LENGT~: 14 bytes WHEN SENT: Issued by the site controller to the dispatch ~ center when control : information is requested or required b~ the dispatch center SOURCE: DLTC 450 GRIGINAL SOURCE: site controller 410 DESTINATION: Switch TC 454 FINAL DESTINATION: Console 102 or other : control node on switch 457 STNGLE SL~T CONTROL C~ANNEL FORMAT
Byte # _ Bit~ Description 7 6 5 4 3: 2 1 0 O O 1 0 1 0 1 1 1 BKl Barker byte 57 ~3~

SINGLE SLOT CON~ROL C~AUM~L FORMAT
Byte $ Bit~ _ _ Descri~tion _ _ _ 7 6 5 4 3 ~ 1 0 lO O O l O O 1 0 BK2 Barker byte lZ
20 0 0 0 l 1 0 1 ~ID message id=13 30 0 l O O l O l PKT packet n~mber . of this message 4 0 0 0 0 OCl 28 bit message extracted from the site controller 410 message ~most significant nibble) l O O l OC2 most significant nibble 50 1 l O OC3 next significant nibble 1 1 0 0 OC4 next ~ significant nibble ; ~O l l O OC5 next : significant nibble 0 0 0 0 OC6 next ;: significant nibble ` ~ 7: O 1 1 0 OC7 least : significant nibble : ~ ~0 0 0 0 BCl most : significant BCH
nibble - 80 l l O O O O O BC2 least signifîcant BCH byte ~: : ` : :
:~: : 9~ O O O OCl 28 bit message : extracted from the site controller 410 message ~most : significant nibble) 1 0 0 1 OC2 next significant nibble 0 l l O OC3 next significant nibble :
~ .

- ~3~2~

SINGL~ SLOT CONTROL C~ANNEL FO~M~T
BYte # _ __ _ Bit# _ DescriPtion _ 7 6_ 5 4 3 2 1 _0 1 1 0 0 OC4 next significant nibble 11 0 1 1 0 OC5 next significant nibble 0 0 0 0 OC6 ne~t - significant nibble 12 . 0 1 1 0 OC7 least significant n:ibble 0 0 0 0 BC1 most significant BCH
nibble 13 0 1 1 0 0 0 0 0 BC2 least significant BCH byte NOTE: CONTROL CHANNEL OUTBOUND
/

/

~ /
~: ~
.~

.

~L3~5~

10.2.2 TWO-SLOT CONTROL C~ANNEL MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 8 OVERALL LENGTH: 10 bytes WHEN SENT: Issued by the site controller when any channel a~signment is issued. This includes standard and emergency channel assignments.
SOURCE: DLTC 450 ORIGINAL SOURCE: site controller 410 DESTINATION: `Switch TC 454 FINAL DESTINATION: .. Con~ole 102 or other control node on switch .457 - TWO-SLOT CONTROL CaANN~L MESSAGE

O O 1 O 1 0 1 1 1 BKl Barker byte 57 : 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 : 2 0 0 O O 1 0 0~ 0 GID message id=08 ; 3 O O 1 0 0 1 0 1 PKT packet number o ~hi~ me age 4 0 O O O ~ OCA 36 bit message extracted from a concatenated control channel message : 1 0 0 1 OCB next signi~icant nibble s~

T~O-SL3T C NTROL C~UNNEL MESSAGE
BYte # Bit ~ DescriPtio~

O 1 1 O OCC next significant nibble 1 1 O O OCD next significant nibble 6 O 1 1 O OCE next significant nibble O O O O OCF next significant nibble 7 O 1 1 O OCG next significant nibble O O O O OCH next 5i gnificant nibble : ~ 8 O 1 1 O O~I least ~ significant nibble : O O` O O BCl most significant BCM
nibble 9 O 1 1 O O O O O BC2 least ~ significant BCH byte ; ~ ~ NOTE: 2-SLOT CONTROL CEANNEL OUTBOUND
': ,: , , -~ : ' ~

:

:
.~
' : ~ ~

~ .

;,,, ~ , . , . .

~3~5~

10.2.3 WORKING CHANNEL MESSAGE

MESSAGE TYPE: ~lobal MESSAGE NUMBE~: 16 OVERALL LENGTH: 16 bytes WHEN SENT: Issued by the site controller when any working channel me~sage is issued.
This includes all working channel messages SOURCE: DLTC 450 ORIGINAL SOURCE: site controller 410 DESTINATION: Switch TC 454 FINAL DESTINATION: Console 102 or other : ~ control node on switch 457 , WORKING Ca~NNEL FO~MAT
Brte # _ Bit # Description : 7 6 5 4 ~3 Z 1 0 O 0 1 0 1 0 1 1 1 BKl Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 2 O O 0 1 0 0 0 0 GID message id=16 ~ : 3 O O; 1 0 0 1 0 1 PKT packet number - of this message 4 . O O O O ` OW1 20 bit me~sa~e e~trac~ed from ths site controller 410 working channel : mes~age ~most significant nibble) 1 0 0 1 OW2 most , ~3~

WQRXING CEIANNEL FOE~ MA~r Byte # Bit # l)escription significant nibble 0 1 1 0 OW3 n~xt significant nibble 1 0 0 OW4 next significant nibble 6 0 1 1 0 OW5 least significant nibble 0 0 0 0 BC1 most significant BCH
nibble 7 0 1 1 0 0 0 0 0 BC2 least significant ~CH byte :~ 8 0 0 0 0 : OW1 20 bit message extracted from the global message Imost signiicant nibble) 1 0 0 1 OW2 n~xt significant nibble 9 0 1 1 0 OW3 ~ext significant nibble ~; 1 1 0 0 OW4 next significant nibble 0 1 1 0 OW5 least significant nibble Q 0 0 0 BC1 most : signifisant BCH
nibble 11 0 1 1 0 0 0 0 0 BC2 least significant BCH byte NC~ ALL WORKING CHANNEL MESSAGES.

.

.

., ,;
. j ,, : ~ .,, .' ' :, ~

~3~i5Z~

10.2.4 PATCH/SIMU-SELECT C~OLLECTION ACKNOWLEDGE MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 82/85 OVERALL LENGTH: 8 bytes WHEN SENT: Transmitted by a DLTC 450 when it receives a modem GID of 82 (patch collection ack) or 85 (simul-select collection ack). Both modem messages are converted into a single console message. The protocol conversion is identical for both GIDs.
.
SOURCE: DLTC 450 :~: ORIGINAL SOURCE: site controller 410 ~ ~ DESTINATION: Switch TC 454 : .: :
: FINAL DESTINATION: Console 102 or other control node on switch 457 .

:
:.:: ': _~
~ : ~ :

~3~

COLI~:CTION ACKNGWLEDGE_rss~Gr FOR~T
B~vte ~ _ ____ Bit # _ __ ___ _ De~3cri~tis7n O O 1 0 1 O 1 1 1 BK1 Barker byte O O 0 1 0 0 1 0 BK2 Barker byte 2 O 1 0 1 0 0 1 0 GID message id=82 patch or 2 O 1 O 1 O 1 0 1 GID message id=85 semsel 3 0 0 l 0 0 0 0 0 PKT packet number of thi s message 4 0 - PSS set if patch message () O O Not used 1 0 Reserved o Reserved 0 0 O 1 1 GRP patch id :~ : 6 0 0 0 1 GRP patch id MAK modify ack=1 0 0 0 Not used 7 O 1 1 0 0 O 0 0 CHK checksum ~ ~ -. . .
:.

:.
.
: :

~3~5~

10.2.5 PATC~/SIMUL-SELECT ACTIVATE/DEACTIVATE MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBERS: 80/83 : OVERALL LENGTH: 8 bytes WHEN S~NT: Transmitted by a DLTC 450 upon receiving a similar : . message from the site controller 410. These messages spawn messages to the dispatch center consoles 102. The dispatch center GETC receives a patch activate/deactivate message GID 80 or simul-select : ~ activate/deactivate message ~; GID which spawn console , ~ messages:
patch/simul-select activate (MID 16) and : patch/simul-select deactivate ~MID 11).
SOURCE: DLTC 450 ORIGINAL SOURCE: site controller 410 DESTINATION: Switch TC 454 : FINAL DESTINATION: Console 102 or other ~ ~ ~ : control node on switch 457 :~ :

:: ~ : : : :

:
.

~3~

PA~/5IMUL-SELECT ACTIVA~ACTIVATE
~:SSAGE EORMAT
Bvte # _ it ~ DescriDtion 0 0 1 0 1 0 1 1 1 BK1 Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 2 0 1 0 1 0 0 0 0 GID message id=80 patch or 2 0 1 0 1 0 0 1 1 GID messag~ id=83 simsel 3 0 0 0 1 1 1 1 1 PKT packet number of this me-sage 4 0 P5S set if patch 1 ACT set if : activation 0 0 Not used : ~ 1 1 1 1 Reserved : 5 o Reserved 1 ~ 1 0 0 0 0 GRP group id 60 1 1 0 GRP group id : 0 0 0 0 Not used 70 1 1 1 1 0 1 1~ CHK checksum 10. 3 CONSOLE C)RIt-~Il~TED tX.OBAL MESS_GES CARRIED BY_LA~LIN~
4S2 E ROM SW~TCEI T;:~ 454 TO DLTC ~50 : ~ : The switch ~S7 is capable of generating global me~sag~s which are communicated by downlink 103 to site : controller ~10. The e switch-~enerated global messages in the preferred embodiment are derived from comma~ds issued by a~ operator of consoIe 102. When switch TC 454 receives , . , ' ,:

- ~3~S~

a global message from switch 457, the switch TC simply passes the message along (after translat:ion and other modificatio~) over landline link 452 to DLTC 450. DLTC
450, in turn, passes the message to site controller 410 for processing.
All console ~switch) initiated global messages in the preferred emhodiment are either "resource request" or "status" messages. When a console PTT button is depressed and a RF channel is required, a group call or individual call message is sent over the downlink 103 to the site controller. Both of these messages are resource request (RF channel re~uest) messages.
As an example of one common scenario, suppose an RF
channel is assigned and a con~ersation has started between a console operator and a mobile radio transceiver. When the console operator "unkeys" his microphone, a console (switch) originated global unkey message is sent to the site controller in response to the console unkey. The global unkey message is communicated by downlink 103 from switch 457 to site controller 410 and is processed by the sita controlLer.
A console unkey command may or may not generate a channel deassignment from the site controller 410. If the system is configured for transmission trunking, a channel deassignment (from the site controller~ will immediately follow any unkey. However, if the system is message trunked, a hold ("hang") time is established so that channels are not dropped immediately after an unkey. ~en a channel is open and available, the key message will suffice in notifying the site controller of the console's 102 intention to use the channel.
As another example, for multiple group operation, a patch id is assigned to each patch and simul-select button ~SS2~ -on the console 102. When a patch id is generated or modified in the console 102, a console-originated global "modify patch" message is sent from switch 457 to site controller 410 over downlink 103. Th patch id and group and individual collection information contained in thi6 "modify patch" message is stored ~t the site controller.
Multiple group calls are activated and deactivated throu~h messages to the site controller. These messages are requests for use of a patch id. The site controller must check the system configuration before approving the p~tch id usage.
The following describes in detail the types of console initiated messages carried by landline link 452 from switch TC 454 to DLTC 450. Each of these landline messages obviously corresponds to a console initiated global message carried by link 456 between switch 457 and switch TC 454. ~ 7~

' ` /:

/
/
~ ,~
~ ~ /

:

... ..
, .
' . .
',' , '' : ~

~L3~5~;2~

10. 3 .1 SINGLE SLOT CONTROL CHANNEL MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 08 OVERALL LENGTH: 14 bytes WHEN SENT: Transmi tted by swi tch 457 when it receive~ a global message with a message id of 24, 25, 30, 31 or 34 SOURCE: switch TC 454 ORIGINAL SOURCE: Console lU2 or other : control node on switch 457 DESTINATION: : DLTC 450 FINAL DESTINATION: site controller 410 :: ~ CONTROL CHANNEL
IN130UND MT-A: 00 :

SINGLE SLQT CONTROL CE~ANNEL FORMAT
~ BYte # _ ___ Bit ~t . De~cription _ : ~ 7 6 5 4 3 2 1 0 ~: : : O O 1 0 1 0 1 1 1 13Kl Barker byte 57 ~; 1 0 0 0 1 0 0 1 0 B~C2 Barker byte 12 ~: :
2 0 0 0 0 1 0 0 0 GID message id=08 3 0 0 1 0 0 1 0 1 PKT packe~ nun ber of thi s message ~L3~

SINGLE SLOT CONTRO~ CHANNEL_FO~MAT
B~te ~ Bit_# Description _ _ 7 6 S 4 ~ 2 _1 _0 0 0 O O ICl 28 bit message extracted from the global message ~most significant nibble) 1 0 0 1 IC2 next significant nibble 0 1 1 0 IC3 next significant nibble 1 1 0 0 IC4 ne~ct significant nibble 6 0 1 1 0 IC5 next . significant nibbl~
O O O O IC6 next significant nibble :~ 70 1 1 0 IC7 least si~nificant nibble O O O O E~Cl Tnost significan~ BCH
~ nibble -` 8 0 1 1 0 0 0 0 0 BC2 least : significant BCH byte~
9 0 O O O ICl 28 bit message :: extracted from the global message 1 0 0 1 IC2 next significant nibble 0 1 1 0 IC3 n~xt ~: : signiicant - ~ nibble 1 1 0 0 IC4 next significant nibble 11 0 1 1 0 IC5 next : significant nibble .
~ ~ O O O O IC6 next ., " . ~ , .
. . , ~
.
', , ' :' ' j,, s~

SINGLE SLOT CONrROL C~ANNEL FORMAT
Byte ~ Bit ~ Descr ption __ 7 _6 5 4 3_ 2 _1 0 significant nibble 12 0 1 1 0 IC7 least significant nibble O O O O BC~l most significant BCH
nibble 13 0 1 1 0 0 0 0 0 BC2 least significant BCH byte ~; `' 10.3.2 WORKING C~ANNEL MESSAGE

MESSAGE TYPE: Global - ~ MESSAGE NUMBER: 16 OVERALL LENGTH: 12 bytes WHEN SENT: Transmitted by switch 457 when it recei~es a global message with a message id of 27, 28 or 33 SOURCE: : switch TC 454 ORIGINAL SOURCE: Console 102 or other : control node on switch 457 DESTINATION: DLTC 45~
: ~ FINAL DESTIMATION: site controller 410 ~ :
`:

, i" , , .

.
, i~3~

WORKING C~ANNEL FORMAT
Byte # _ _ Bit # _ Oescriptio~ _ __ 0 0 1 0 1 0 1 1 1 BK1 Barker byte 57 : 1 0 0 0 1 0 0 1 0 BK2 8arker byte 12 . 2 0 0 0 1 0 0 0 0 GID message id=16 3 0 0 1 0 0 1 0 1 PKT packet number of this message 4 0 0 0 0 IWl 20 bit message extracted from the global message (~ost signiicant nibble~
1 0 0 ~1 IW2 most significant ~: - nibble ; 5 0 1 1 0 IW3 next si~nificant nibble 1 1 0 0 IW4 ne~t significant ~ : nib~Le : 6 0 1 :I 0 IW5 least significant nibbl~
0 O O O BCl most si~nificant.
; ~ BCH nibble ~: :7 0 1 1 0 0 0 0 0 BC2 least significant BCH byte 8~ ~ 0 0 0~ 0 IWl 20 bit message : extract~d from the global me~sage ~most ~ : : : sisnificant nibble : : 1 :0 0 1 I~2 most significant : nibble 9 O 1 1 0 IW3 next igniicant nibble 1 1 0 0 IW4 next significant slibble : .

. .
... .
.

: . .
, ~3~

WORKING CHANNEL FORMAT

Byte # Bit # _ Description o 1 1 0 IW5 least significant nibble 0 0 0 0 BC1 most significant BCH nibble 11 0 1 1 0 0 0 0 0 BC2 least significant BCH byte ---- --- -- . ...

/
' ~
/ .

:~3~5~i2~

llg 10.3.3 PATC~/SIMUL-SELECT COLLECTION MESSAGE
.
MESSAGE TYPE: Global MESSAGE NUMBE~: 81 j84 OVERALL LENGTH: 12 bytes WHEN SENT: Transmitted by switch 457 when it receives a console message id of 29 The received message spawns into one of two sets of messages based on whether the message is a patch or simul-qelect message. The modem GIDs for the simul-select messages are 84 and 85, while the GIDs for the patch messages are 81 and a2. Two GIDs are required: one GID is used as a header message which transfers the~qroup count and individual count associated with the .~ collection. The other GID
: : is used to transfer the groups and individuals in the collection.
SOURCE: switch TC 454 ~: ORIGINAL SOURCE: Consola 102 ;:~; : DESTINA~ION: DLTC:450 ~ INAL DESTINATION: ; site controller 410 ~ : ~
,::: : : .

~ .
,.

, , . . ' '.
.
.
: ' ' ', ' :
,:
',, . ' ,. ' , ' ' ' ::

~3~ i2~L

COLLEGTION MESSAGE_L@~ __ R~T~
Byte ~ Bit # De~cription ~. ~

O O 1 0 l O 1 1 l BKl Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Bark~r byte 12 2 O 1 0 l 0 0 0 1 GID message id=81 patch or 2 . O 1 0 l 0 1 0 0 GID message id=84 simsel 3 0 0 l CNT count of the number of data messages which follow the header message 1 - HD~ header field=l - signifies that this message is the header message :~ 1 0 l 0 SPK least si~nificant nibble of the packet count 4 0 1 1 0 GCT group count 0 PSS set if patch message 1 1 1 GRP patch id 0 1 1 0 0 0 1 1 GRP patch id .
: 6 0 0 0 1 ICT indi~idual ~ ~ : - count : : 1 1 0 0 BCl most significant BCH
nibble 7 0 1 l 0 0 0 0 0 BC2 least significant BCH byte : 8 0 0 0 0 Not used l 0 0 l LID first logical id in collec~ion or ~irst group id if , ... .

, , ~3~5~2~

COLLECTION MESSAGE (HEADER FORMAT!

Byte ~ Bit # Description 7 6 5 4 3 2 l 0 there is no logical id 9 0 1 1 0 1 1 0 0 LID logical id or group id 0 0 0 0 Not used 0 0 0 0 BCl most significant BCH nibble 11 0 1 1 0 0 0 0 0 BC2 least significant BCH byte ~: ` /

/
/

~ /
, ~ : ~ : : /

~: /

, ~

:
:
, , ,,, , ~ . , , , ~ , ~s~

COLLECTION MESSAOE (DATA FO~ ~ Tl Byte # Bit ~ Description 7 6 5 4 3 2 l 0 _ _ , _ _ O O 1 O l O 1 1 l BKl Parker byte 57 1 O O O 1 O O 1 O BK2 Barker byte 12 2 O 1 O l O O l O GID message id=82 patch or 2 O l O l O l O 1 GID message id=85 simsel 3 O O O CNT count of the number of data messages which follow O ~DR header field=O
signifies that this message is not a header message but a data message 1 O l O SPK least significant nibble of the packet count ` 4 O O O O Not used l O O 1 GRP first group id in collection .
O l 1 O l 1 O 0 ~RP group id 6 Q O O O Not used 1 1 0 O BCl most significant BCH
nibble 7 O 1 l O O O O O BC2 least significan~ BCH byte a O O O O not used 1 0 0 1 GRP second group id or null code 1010 if there are no more : groups in the ~ collection 9 O 1 1 0 1 1 O O GRP group id or ~3~;2~

COLLECTION MESSAGE (DATA FORMAT) Byte # Bit # Description 7 6 5 _4 3 2 1 0 null code 10101010 0 0 0 0 not used O O O O BC1 most significant BCH
nibble 11 0 1 1 0 0 0 0 0 BC2 least signi~icant BCH
: byte NOTE: PATCH/SIMUL-SELECT COLLECTION MESSAGES.

,: /
/

`; : : :
.
~ : /
: ; /

''":""' " ' ' :
.
, ~L3~

12~

10.3.4 PATCH/SIMUL-SELECT ACTIVATE~DEACTIVATE MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBE~S: 80/83 OV~RALL LENGT~: 8 bytes WHEN SENT: Transmitted by a switch 457 when it receiv~s a global message with a message id of 27 (activate patch/simsel) or 28 (deactivate patch/simsel).
Due to the site controller 410 requirements, these messages are transformed into two modem messages ~ with a GID of 80 (patch -~ activate/deactivate) or ~3 : (simsel activate/deactivate). The format of both massayes is : th~ same.
:
SOURCE: switch TC 454 ORIGINAL SOURCE: Console 102 or other control node on switch 457 DESTINATION: DLTC 450 FINAL DESTINATION: site controller 410 : ~ :

~:: :
:
': :
~ ~ :

~3~

PATC~SIMUL-SELECT ACTIVATE~DEAC~TIV~TE
MESSAGE FORMAT
Byte ~ _ Bit ~ _ De~cri~tion _ 7 6 5 ~ 3 2 1 0 0 0 1 0 1 0 1 1 1 ~K1 Barker byte 57 1 0 0 0 1 0 0 1 0 BK2 Barker byte 12 2 0 1 0 1 0 0 0 0 GID message id=80 patch or 2 . 0 1 0 1 0 0 1 1 GID message id=83 simsel 3 0 0 0 1 1 1 1 1 PKT packet number of this message ; 4 0 PSS set if patch 1 . ACT set if -- acti~ation 0 0 - Not used 1 1 ~1 0 Reserved 0 0 0 0: 0 Reser~ed : 1 0 0 GRP group id : 6 0 1 1 0 1 1 0 0 GRP group id ; 7 0 1 1 1 1 0 1 1 CHK checksum '~: :
' : :

,~

, .. .. . .

- ~3CP~

11.O MESS~GES ON LINK 456 BETWEEM SWITC~ 457 AND SWITC~ TC

.
Both global and local messagec are transmitted over the high-speed link 456 between switch trunking card 454 and switch 457. The following describes messages transmitted o~er that link 456.

11.1 ADMINISTRATIVE MESSAGES CARRIED Y NK 4S6 BETWEEN
SWITC~ 457 AND S~ITC~ RUN~ING CARD 454 The foLlowing are detailed descriptions of individual administrative messages communicated between switch TC 454 and switch 457 in the preferred embodiment:

11.1.1 WORKING CHANNEL CONFIGURATION MESSAGE
:: :
MESSAGE TYPE: Administrative MESSAGE NUMBER: O1 OVERALL LENGTH: 3 bytes WHEN SENT: Transmitted only by the Switch TC 454 in response to receiving a send configuration message from the~switch 457.
: SOURCE: Switch TC 454 ORIGINAL SOURCE: Switch TC 454 : DESTINATION:: Switch 457 FINAL DESTINATION: Switch 457 , ...

~3~;2~
45MR~542 ~ y~E ~ORMAT
B~,rte # Bit # Desc:ription O O O O O O 0 1 MID Message id=01 0 Not used 0 0 0 0 0 0 0 0 TLY data bytes to follow 2 0 0 0 0 0 0 0 1 CH~ checksum .

11. 1. 2 DOWNLINK C~EL CON~IGURATION MESSAGE:

~IESSAGE TYPE: Admini strative MESSAGE NUMBER: 02 S OVERALL LENGTE~: 3 bytes :~ ~ WEIEN SENT: Transmitted only by the Switch TC 454 in response to receiving a send .
configuration message from the switch 457.
SOURCE: Switch TC 454 GENERAL SOUROE: Switch TC 454 DESTINATION: : : Switch 457 FINAL DESTINATION: Switch 457 ~: :
:::
:: ::
;`

~3~

DOW~INK ~ANNEL ME:SSAGE FORMAT
ES~te ~ Bit # Dess~ription O O O O O O 1 0 MID Message id=02 Not used 0 0 0 0 0 0 0 0 TLY data bytes to follow 2 0 0 0 0 0 0 1 0 CHK checksum _ 11.1.3 CONTROL CHANNEL CONFIGU~ATION MESSAG~
:~ .
MESSAGE TYPE: Administrative OVERALL LEN5TH: 3 bytes WHEN SENT: Transmitted only by the Switch TC 454 in response to receiving a send .
coniguration message from the switch.
SOURCE: : Switch TC 454 : : ~ORIGINAL SOUROE: Switch TC 454 DESTINATION: ; Switch 457 EINAL DESTI~ATION: Switch 457 ~:
;~: :: :

, , , , ,.:

~' ~3~SiZ~

45~1R-542 C)NTROL CYIAN~L MESSAGE FOR~AT
Byte # Bit # _ _De~cription __ 7 6 5 4 _ 3 2 1 0 O O () O O O 1 1 MID Message id=03 0 Nok used 0 0 0 0 0 0 0 0 TLY date bytes to follow 2 0 0 0 0 0 0 1 1 CEIK checksum /

., /
, . ~ /

"' ~: : /

~, : /
~ ~ /

.
.
.

; ' ~L3~

11.1.4 ACKNOWLEDGE MESSAGE

MESSAGE TYPE: Admi~istrative MESSAGE NUMBER: 04 OVERALL LENGT~I: 3 hyte 5 WHEN SENT: Transmitted by the Switch TC 4S4 or Switch 457 after receivin~ a glo~al message with a correct checksum.
SOURCE: Switch 457 or Switch TC 454 ORIGINAL SOURCE: Switch 457 or Switch TC 454 DESTINATION: Switch TC 454 or Switch 457 FINAL DESTINATION: Switch TC 454 or Switch 457 ACKNOWL~ SAGE FORMAT
BVt~ # _ _ _ _Bit ~ escription : 7 6 5 _4 3 2 1 0 0 0 0 0 0 1 0 0 MID Mess~ge id=04 O Not used 1 0 0 0 0 0 0 0 0 TLY data bytes to . follow 2 0 0 0 0 0 1 0 0 CHK checksum ' ''' ': , .

~3~

ll.l.S NOT ~ SSAGE

MESSAGE TYPE: Adm-ni~trative MESSAGE NUMBER: 05 OVERALL LENGTH: 3 bytes W~EN SENT: Transmitted by the Switch TC 454 or Switch 457 after receiving a global message with an incorrect checksum. Receipt of this message requires that the last message be retransmitted.
:~ SOURCE: Switch 457 or Switch TC 454 ORICINAL SOURCE: Switch 457 or Switch TC 454 .~ DESTINATION: Switch TC 454 or Switch 457 : FINAL DESTINATION: Switch TC 454 or Switc~ 457 NOT ACRNO~ErLE~"NEGATIVF") MESSAGE E RMAT
B~te # _ Bit # Description 7 ~ 5 4 3 ~ 1 0 O O O O O O O 1 MID Message id=05 O Not used O O O O O O O O TLY data bytes to follow :~:
~ :2~ 0 0 0 O O 1 0 1 C~K checks~m ~ ~ :

:
"

.

~3~S52~

11.1.6 SEND CONFIGURATION MESSAGE

MESSAGE TYPE: AdministratiYe MESSAGE NUMBER: 06 OVERALL LENGTH: 3 bytes T Transmitted ~y Switch 457 WHEN SEN : at a five second rats to establish the configuration of the Switch TC 454 and to maintain byte and message synchronization.
SOURCE: Switch 457 ORIGINAL SOURCE: Switch 4S7 DESTINATION: Switch TC
FINAL DESTINATION: Switch T~

: SEND CONF ~ TION ME55A OE EORMAT
Byte ~ BLt # _ Description _ 7 6 ~ 4 3 2 1 0 0 0 0 1 :1 0 MID Message id=06 : 0 ~ R Retransmit (0 or 1) 0: 0 ~0 ~0 ~0 :0 0 0 TLY data bytes to ` 2 0 0 00 0 1 1 0 C~K checksum ':

:
': ;. ~ .

~ ~ :

~3~S~

11.2 LINK 456 GLOBAL MESSAGES ORIGINATED BY SWITC~_457 fCONSOLE 102) AND TRANSMITTED BY SWITCH TO SWITCH TC 454 The following are exemplary format:.and definitions of global messayes originated by switch 457 and transmitted by switch 457 over link 456 to switch trunking card 454.

11.2.1 GROUP CALL MESSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBER: 24 OVERALL LENGTH: 9 bytes GETC CODE:~ 08 WHEN SENT: Transmitted by the : ~ console 102 to request.a RF
channel path to a group of ~: field units (mobile or portable. This message is : generated by any console PTT key for a group, whether or not a RF channel assignment already exists for that group.
SOURCE: Switch 457 ORIGINAL SOUROE: Console 102 or other control node on Switch 457 ~:: DESTINATION: ~: Switch TC 454 ,` FINAL DESTINATION: Site Controller 410 CONTROr~ CHANNEL
INBOUND MT-A: ~ 00 ~3(~55Z4 GROUP CALL MESSAGE FORMAT
B~te # Bit # DescriDtion 0 0 0 1 1 0 0 0 MID Message id=24 0 R retransmit =0 for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow, exclusive of c~ecksum 2 0 0 0 0 0 0 0 0 SDl source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 4 0 0 0 0 Not used 0 0 Reserved 0 0 TAG clear voice=00 0 Reserved 0 0 1 0 0 1 0 GRP group id=123 upper seven bytes 6 0 0 1 1 GRP group id-123 lower nibble 0 0 0 0 LID source ~d=003 upper nibble 7 0 0 0 0 0 0 1 1 LID source id=003 lower byte 8 0 0 1 1 1 1 1 1 CHK checksum ~L3~iZ~

.

11.2.2 INDIVIDUAL CALL MESSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBER: 25 GETC CODE: 08 : OVERALL LENGTH: 9 bytes W~EN SENT: Transmitted by the console 102 to request a RF
channel path to an individual field unit (mobile or portable). This message is generated by a ~: console PTT key for an ~; individual destination . whether or not a RF channel : already exists.
i~, SOURCE: Switch 457 ORIGINAL SOURCE: Console 102 DESTINATION: DLTC *SO
CONTROL CHANNEL
INBOUND MT-A:. : lO
FINAL DESTINATION: Site Controller 410 , ~

,.. . .

~3~

INDIVIDUAI. CAI.L PSESSAGE FO~iAT
Byte ~ _ Bit ~ Descri~ion 7 6 5 ~ 3 2 1 0 o 0 0 1 1 0 0 1 MID Message id=25 R retransmit=0 for first transm:ission : 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum .2 0 0 0 0 0 0 0 0 5Dl source de~tination byte 1 : ~3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 4 0 0 . Not used 1 0 Res~rved 0 0 TAG clear voice=00 0 0 0 0 0 0 1 0 LID destination id=023 upper seven bits 6 0 0 1 1 LID destination id least significant nibble 0 0 0 0 LID source id=003 upper nibble :~ ~
7: : 0 0: 0 0 0 0 1 1 LID source id-003 lower byte 8 0 0 ~ 0 0 1 1 0 CHK checksum ~: :
.

'~ ' ', "
.: :
' 11.2.3 UNKEY MESSAGE

: MESSAGE TYPE: Global, working channel MESSAGE NUMBER: 26 GETC CODE: 10 OVERALL LENGTH: 8 bytes WHEN SENT: Transmitted by the console 102 to inforrn the site controller 410 of a console unkey (this ~nessage may or may not drop the channel assigned).
SOURCE: Switch 457 ORIGINAL SOURCE: Console 102 ~:: DESTINATION: DLTC 450 FINAL DESTINATION: Site Controller 41 ~NBOUND WORKING
~::: CHANNEL MT-A: 0011 ~`: :: :

: ,, _,~
: ~ :

~, :
.~ .

, .

~3~

~EY MESS~E FORM~T
B~te~ ~Descri~ti~n 7 6 5 _ 4 3__2 1 0 : O O O 1 1 0 1 0 MID Message id=26 R retransmit=O or ~irst transmission 0 0 0 0 0 1 0 1 TLY 5 data bytes to follow exclusive of checksum 2 O O O O O O O O SDl source des ination byte 1 3 0 0 0 0 0 0 0 0 SD2 source : : destination byte 2 :
0 0 O O Not used . O 1 1 Reserved ~; 5 O O O O Reserv~d ; O O O O LID audio source id upper nibble 6 O ~0 0 0 Q ~ O 1 1 :LID audio source id lower byte : 7 0 : 0 0 1 1 1 1 1 CHK checksum :~ :
:: ?

`:

~ 3~S;~

11.2.4 ACTIVATE PATC~ ID REOUEST~MESSAGE

MESSAGE TYPE: Global, working channel MESSAGE NUMBER: 27 GETC CODE: 10 - OVERALL LENGTH: 8 bytes WHEN SENT: Transmitted by the console 102 when a patch or simul-select is set up.
This message requests that the patch id be activated, the mobiles and individuals be notified of the activa~ion of the patch id, ~and requests that the console 102 be allowed to : activate the patch id. The patch id has already been defined to the site controller 410 by another message.
SOURCE: Switch 457 ORIGINAL SOURCE: Console 102 DESTINATION: DLTC 450 FINAL DESTINATION: Site Controller 410 WORKING CHANNEL
: INBOUND MT-A: 1110 ~5~

1~0 ACTIV~TE PATC~ ID RE~UEST MESSAGE FORMAT
~yte # _ Bit # Description - 7 6 5 4 3 _2 1 0 0 0 0 1 1 0 1 1 MID Message id=27 0 R retransmit=0 for first trans~ission .1 0 0 0 0 0 1 0 1 TLY 5 data bytes to follow exclusive of ch~cksum .2 0 0 0 0 0 0 0 0 SDl source destination byte 1 - 3 0 0 0 0 0 0 0 0 SD2 source -~ destination byte 2 4 0 0 0 0 Not used 1 1 I 0 Reserved 0 0 0 0 0 Reserved 1 0 0 GRP patch id=480 most significant : : nibble G 1 0 0 0 0 0 0 0 0 GRP patch id Ieast : significant byte 7 1 0 0 1 0 1 0 O CHK checksum . . ~
''~ ,'~

.; .
' :i~3~

11.2.5 DEACTIVATE PATCH ID REQUEST MESS~GE

MESSAG~ TypE: Global, working channel MESSAGE NUMBER: 28 GETC CODE: 10 OVERALL LENGT~: 8 bytes WHEN SENT: Transmitted by the console 102 when a patch or simul-select is removed from the front panel (deactivated) or i~ the patch or simul-select : memory contents are cleared.
50URCE: Switch 457 ORIGINAL SOURCE: Console 102 ~: :
- DESTINATION: : DLTC 450 FINAL DESTINATION: Site Controller 410 WORKING~CHANNEL
INBOUND MT-A: 1111 : : /

~' : /
: ~ :

~ .

' ~ .

:

~L3~

1~2 DEACTIVATE PATC~ ID RE;QUEST MESSAGE FORMAT
B~fte $ Bit # _ Des~:ription 7 6 5 ~4 3 2 1 0 O O O 1 1 l O O MID Message id=28 O R Re~ransmit = O
for first transmi ssion 1 0 0 0 0 0 1 0 1 TLY 5 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SDl source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 ~: 4 : 0 0 0 0 Not used 1 1 1 1 Reserved ~ 5 0 0 0 0 0 ResPrved :~ ~ 1 0 0 : GRP patch id=480 : ~ : most significant ;: nibble ~:
6 1 0 0 0 0 0 0 0 GRP patch id least ; significant byte ~: ; 7 ~ 1 0 0 1 0 0 1 0 CHK checksum :
:
~ : :

.. . ~................................. .

, ' ' ' :.
',. . .

~3~S2~

. 1~3 11.2.6 MODIFY_PATC~ ID ASSIGNMENT MES AGE

MESSAGE TYPE: Global, patch MESSAGE NUMBER: 29 GETC CODE: lS
OVERALL LENGTH: 8 bytes minimum, 40 bytes maximum WHEN SENT: Transmitted by a console 102 when a patch or simul-select memory is modified or cleared. This message is used to tell the site controller 410 which : groups and individuals are associated with a patch - id. B~tween O and 16 : entities ~groups or individuals) may be grouped together in any combin~tio~
(groups or individuals).
The last entity is the patch id for the grouping.
SOURCE: : Switch 457 ORIGINAL SOURCE: Console 102 or other control node on Switch 457 DESTINATION: DLTC 45G
EINAL DESTINATION: Site Controller 410 . : :
~' ~

' ,.

.
''' ~3~5~2~

~ODIEY PATC~ ID RE0UEST MESSAG~ EORMAT
Byte~# ~ _ Bit ~ _ DescriDtion 7 6 5 ~ 3 2 1 0 0 0 0 1 1 1 0 1 MID Message id=2~
0 R retransmit=0 for first transmission 1 0 0 0 0 1 0 1 1 TLY 11 data bytes to follow e~clusive of checksum 2 0 0 0 0 0 0 0 0 SDl source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 4 0 PSS following patch id is a simsel 0 0 0 Not used 0 0 1 0 GCT group count 50 0 0 1 ICT in ividual count 0 0 0 0 LID first individual id=234 60 0 1 1 0 1 0 0 LID least significant byte : 7 0 0 0 0 0 Not used 0 1 1 GRP first group id=345 8 0 1 0 0 0 1 0 1 GRP first group : least significant byte g Q 0 0 0 0 ~ot used 1 0 0 GRP second group id-456 0 } 0 1 0 1 1 0 GRP second group least significant byte 11 0 0 0 0 0 Not used 1 0 0 GRP patch id=480 ' ~3~5~ii2~

Byte ~ Bit # De~cription 7 6 5 _4 3 2 _1 0 most byte 12 1 0 0 0 0 0 0 0 GRP patch id least significant byte 13 1 0 1 0 0 0 0 0 CHK checksum NOTE: SPECIAL CALL WORKING CHANNEL SIGNALLING MESSAGE.

11.2.7 EMERGENCY STATUS ALERT ME_SAGE

~: MESSAGE:TYPE: Global, control channel MESSAGE NUMBER: 30 OVERALL LENGTH: ~9 bytes W~EN SENT: Used by the console 102 to : declare an emergency to a group. This message is ~: used to tell the site controller 410 which group is to be placed into emergency status. The specified group's communications take on the :~ ~ : highest priority available on the system.
SOURCE: . Switch 457 :~ : ORIGINAL SOURCE: Console 102 DESTINATION: DLTC 450 FINAL DESTINATION: Site Controller 410 CONTROL CH~NNEL
INBOUND MT-A: 01 .

~3~

EMERGENCY ST~TUS ALERT ~E:SSAGE FORMAT
Byte # _ Bit # De~cription 7 6 5 4 3 2 1 ~ ~
0 0 0 1 1 1 1 0 MID Message id=30 0 R retransmit=0 for irst transmis ion 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SDl source desti~ation byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 .: 4 0 0 0 0 ~ No~ used~; O 1 Reserved ~;~ 0 0 TAG clear voice : 5 1 S/C status/call bit=l O 0 1 0 0 1 0 GRP group id=123 (in the emergency~
6 O O 1 1 GRP least significant byte ~ : 0 0 0 0 LID individual~
:~ id=234 (declaringemergency) ; 7 : 0 0 1 1 0 1 0 0 LID least ;:~ : significant byte :
~ 8 1 0 0 0 1 0 1 0 CHK checksum :
- - - .

; ~

' ' , ' ' ' ~ :, '' ' '' ~ ' ' ' . : ' ` ' -' , . ' ~

' ' ' ~ , :: ' .
" '.,' ~3~ z9~

. 147 11.2.8 EMERGENCY CHAN~EL ~3~ ESSAGE

MESSAGE T~PE: Global, control channel MESSAGE NUMBER: 31 OVERALL LENGTH: 9 bytes WHEN SENT: Used by the console 102 to request a channel from the site controller 410 for a voice transmission. This message is used when a dispatcher hits a PTT and the group he i 9 trying to communicate with is in an ongoing emergency.
SOURCE: Switch 457 ORIGINAL SOURCE: Console 102 DESTI~ATION: DLTC 450 FINAL DESTINATION: Site Controller 410 CONTROL CH~NNEL: :
:: INBOUND MT~A 01 ~ , :
':~`: ~
-.

: :: :: :

:
:: :

, .
.
.

52~

14~

~MER~ENCY_C~ANNEL RE~UE5T_PESSAGE FORM~T
Byte # Bit # r _ De~crlpti~n 0 0 0 1 1 1 1 1 MID Message id=31 0 R retransmit=0 for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SD1 source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source de tination byte 2 4 0 0 0 0 Not used O 1 Reserved 0 0 TAG clear voice 0 S/C status/call ~:: bit=0 0 0 1 0 0 1 0 GRP group id=123 (in the emergency) 6 0 0 1 1 GRP least significant byte : 0 0 0 0 LID individual ~
id-234 (re~uesting a channel) 7 0 0 1 1 0 1 0 0 LID least ;~ significant byte `; 8 0 0 0 0 1 0 1 1 CHK checksum " ~
.
:

. . , ~ . .
: :

:' ' , ' ~ - ' :

-~3~SS~

11.2.9 STATUS PAGE MESSAGE

MESSAGE TYPE: Global, control channel MESSAG~ NUMBER 32 OVERALL LENGTH: 9 bytes WREN SENT: Used by the consol~ 102 to inquire as to a ~nit's present status. The radio in the field will be interrogated by the site controller 410 and the unit's status shall be contained in a status message to the console 102.
SOURCE: Switch 457 ORIGINAL SOU~CE: Console 102 DESTINATION: DLTC 450 ~:~ FINAL DESTINATION: Site Controller 410 CONTROL CHANNEL
: : INBOUND MT-A: 11 MT-B: 111 :: :
~ MT-C: 001 ~ ~ .
~::: : :
:: :
:

.. .. .
: . ':

~L3~

STATUS PAGE ME,SSAGE EO~MAT
Byte # Bit # Description : 7 6 5 4 3 2 1 0 0 0 1 0 0 0 0 0 MID message id=32 0 R retransmit=0 for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SDl source de~tination by~e 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 4 0 0 0 0 ~ Not used 1 1 1 1: Reserved .~ : 5~ 1 0 0 1 Reserved 0 0 0 Not used 1 ATM automa~ic bit=1 : 6 0 0 0 0 Not used 0 0 0 0 LID indiYidual id-234 (unit to be interrogated) : 7 0 0 1 1 0 1 0 0 LID least significant byte 8 ; 1 0 0 0 1 1 0 0 CHK cbecksum , ::
.
:

:

,,,, . ~ .
. . .

' ' `:, ' - , ~, ' :~

; ~

~3~ 2~

11.2.10 AP_RESET MESSAGE

MESSACE TYPE: Global MESSAGE NUMBER: 33 OYERALL LENGTH: 9 bytes WHEN SENT: Used by the switch 457 to inform the site controller 410 that the main processor has just come out of a reset state. The site controller 410 must also clear all temporary buffers and bring its databases to ; a power up state.
SOURCE: Switch 457 ORIGINAL SOURCE: Console 102 DESTINATION : DLTC 450 ~FINAL DESTINATION: Site Controller 410 :

~: :

. , , ' ' .:

,'~' ' ~L 3~

B~te ~ _ Bit ~ e cription 7 6 ~ 4 3 2 O O 1 0 0 0 0 1 MID Message id=33 O R retransmit=O for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SDl souree dest~nation byte 2 3 0 O O O O O O 0 5~2 source destination byte 2.
4 0 0 0 0 0 0 0 0 Not used 0 0 O O O O O O Not used 6 0 0 0 0 0 O O O Not used :: 7 O O O O O O O O Not used ' : ~ 8 O O 1 Q O ~1 1 1 C~K checksum : : . . .. /

,~

.` ~ ~ : : ~ / ;

, ' . .', ~ ' '' "" '"' "' , , ~3~

11.2.11 CANCEL EMERGENCY M~SSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBER: 34 OVERA~L LENGTH: 9 bytes WHEN SENT: Transmitted by a console 102 (or other control node connected to the switch 457) to the site, directing the site to cancel an emergency which is in progress. This message is identical to the group call message, except for a ; change in one blt.
: SOURCE: - Switch 457 ORIGINAL SOURCE: Console 102 or other control node on Switch 457 DESTINATION: DLTC 450 FINAL DESTINATION: Site Controller 410 CONTROL CHANNEL
INBOUND MT-A: 00 ~

:
' :
' ~
; ~: ~ : :~ : :

.

:' ~ '' ;
, ~ .

.~

~fp~r~D

C~NCEL EMERGENCY MESSAGE FOR~AT
Byte # _ Bit # _ De~criPtiOn 0 0 1 0 0 0 1 0 MID Message id=34 0 R retransmit~5 for : first transmissio~
1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 0 0 0 0 0 0 0 0 SD1 source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 : 4 0 0 0 0 Not used 0 0 Reserved 0 0 TAG clear voice=00 . ~ ..
1 . ECL emergency cancel=1 , ~ 0 0 1 0 0 1 0 GRP group id=123 upper seven bits ` 5 0 0 1 1 GRP group id=123 lower nibble ` ~ 0 0 0 0 ~ID console id=003 upper nibble 7 0 0 0 0 0 0 1 1 LID console id=003 : : lower byte 8 1 0 0 0 0 1 0 1 CHK checksum 11.3 LIN~ 456 GLOBAL MES~AOE S QRIGINATED BY SIT~ CONTROLLER
410 AND TRANSMITTED FROM SWITC~ TC 454 TO SWITC~ 45?

Messages from the site controller are responses to resource request~ genera~ed by either a console 102 or a :~.
-:~

~3~ 2~

field unit (mobile, portable). The site controller assigns and deassigns RF channels, manages patch ids and relays all keys and unkeys regardless of source.
Also, for multiple group calls, a patch id is used to represent a collection of groups. Patch id control and assignment is done at the site controllerO For mobile or console multiple group calls, the patch id is set up ahead of a PTT and permission to use the patch id is issued hy the site controller.
The following describes global messages transmitted by switch TC 454 to switch 457 over link 456 in response to global messages originated by site controller 410 and received by switch TC 454 over link 452.

/

': /

/

~ . ^

, ~3~

; ~ .
11.3.1 CHANNEL ASSIGNMENT MESSAGE

~; MESSAGE TYPE: Global, Control Channel MESSAGE NUMBER: 8 GETC CODE: 08 OVERALL LEN~Tff lO bytes WHEN SENT: Issued by the site controller in response to either a field unit PTT or console PTT. This message is the response to the ~ GROUP CA1L or INVIVIDUAL
`~; CALL messages.
~ SOURCE: DLTC 450 : ~ ORIGINAL SOURCE: Site Controller 410 : DESTINATION: Switch 457 FINAL DESTINATION: Either rlqUeSr bgOadcaSt to ~"~ all consoles 102 (in the case:of a mobile group callS
CONTROL CHANNEL
OUTBOUND MT-A: 00 : ~::

-, ~' ~ ' .
, ~3~ ;Z4 C~ANNEL ASSI ~
BYte ~_ Bit ~ Descri~ption 7 6 5 4 3_ 2 _1 O
O O O O 1 O O O MID Message id-8 R retransmit=O for first transmission 1 O O O O O 1 1 1 TLY 7 data bytes to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 O O O O O O O O SD2 source destination byte 2 O Not used O O Reserved . O O TAG clear voice=OO -O O O l O O 1 O LID source id=123 6 O O 1 1 LID least significant nibble O O Not used O L/G ~roup id O CHN channeL=3, most . significant bit ~: 7 O O 1 1 CHN c~annel=3, least significant nibble O Not used O 1 O GRP destination group id=234 8: O O 1 1 O ~1 O O GRP destination group least significant byte 9 0 0~ 1 0 1 0 1 1 CHK checksum ~OTE: 2-SLOT MESSAGE COMPRESSED.

:
., ~ .

, .
: , , : , "

2~

.

~ 11.3.2 UNIT KEY MESSAGE

:
MESSA~E TYPE: Global, cont~ol channel MESSAGE NUMBER: 9 GETC CODE: OD
OVERALL LENGTH: 9 bytes : WHEN SENT: Issued by the site controller in response to either a ~ield unit PTT or console PTT. This message is used when a channel is assigned but inactive ~i.e., no ongoing conversation).
:~ SOURCE: DLTC 450 ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 ~ -FINAL DESTINATION: Broadcast to all consoles ' ~

, .
, . .
~ .
" ~

~ . ~, ., ': ' ~3~ 2~

DN~T ~ ~SArr FORMAT
Byte # Bit ~ Ce~9~-e~9~ ~
7 6 5 4 _3 2 1 O
O O O O l O O 1 MID Message id=9 O R retransmit=O for first transmission 1 O O O O O l 1 O TLY 6 data bytes to ~ollow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 O O O O O O O O SD2 source destination byke 4 O O O O Not u~ed 1- 1 1 1 Reserved :; S 1 0 0 1 0 0 O Reserved : O CHN channel=6 : 6 O 1 1 0 CHN channel=6 ~ O O O 1 LID ~ource id=123 :~ 7 O O 1 O O O 1 1 LID least significant byte 8 1 1 O l O O 1 O: CHK checksum NOTE: CONTROL CHANNEL OUTBOUND MT-A: ll, MT-B: 111, MT-C: 0010.

.~

., .

. ':' ' ~ ':

~, , , ' ,, : ~

: ' . ' - ~3~. S~2~

11.3.3 UNKEY/CHANNEL DEASSIGNMENT MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 10 GETC CODE: OD
O~ERALL LENGTH: 9 bytes WHEN SENT: Issued by the site controller in response to releasing of PTT by either a field unit or a console 102. This message may be issued twice: Once to inform the switch 457 of an ~ unkey only ~mesRage ; trunking), and another line to inform the system of a dropped channel (trans~ission trunking~
SOURCE: DLTC 450 :~ ORIGINAL SOURCE: Site Controller 410 :~ : DESTINATION: Switch 457 : FINAL DESTINATION: Broadcast to a~l consoles :
:

`:
:
~ :
:: :
:: :

;

' ~ ; ':
: :

:

~3~5~;2~L
~ 5~-542 uNxEy~s~ANNEL-~asslGNMEN~~ e~ Rr~T
Byte ~ _ 8it ~ ~De~cription 7 6 5___4 3 2 1 0 o O O O 1 0 l O MID message id=O
o R retransmit-O for first transmi ssion 8 0 0 0 0 1 1 0 TLY 6 data bytes to follow excl~sive of checksum 2 O O O O O O O O SDl source destination byte 1 3 0 O O O O O O O SD2 source destination byte 2 4 0 O O O Not used l l 1 l Reserved 1 0 0 1 1 0 Reserved 1 ~DP drop channel=l O CHN channel-6 6 0 1 1 0 CXN channel=6 O O O O LID source id=012 most significant byte 7 0 0 0 10 0 1 0 LID least ~ significant byte :~ ~ 8 l l l O l 1 0 1 CHK checksum NOTE: CONTROL CaANNEL OUTBOUND MT-A: 11, MT-B: 111, : MT-C- 0011.

.~ :

~3~S~

45MR-5ds2 11.3.4 DEACTIVATE PATCH ID MESSAGE
;~
MESSAGE TYPE: Global, working channel MESSAGE NUM~ER: 11 GETC CODE: 19 OVERALL ~ENGT~I: 8 bytes ~IEN SENT: Issued by the site controller in response to a termination o a multiple group configuration.
Issuad when a console 102 dissolves either a patch or a simul-select multiple group designation, or when a mobile dissolves a patch.
; SOURCE: DLTC:450 : ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 FINAL DESTINATION: Console 102 : ~ :

. .

~3~Z~

DE CTIV~ PATCH ID ~:5SAGE FORMAT
B yte # Bit # Description _ _ 7 6 5 4 3 _ 2 O O O O 1 0 1 1 MID message id=l R retransmit=O for first trans~ission 0 0 0 0 0 1 0 1 TLY 5 data bytes to follow exclusive of checksum 2 O O O O O O O O SD1 source destination byte 1 3 0 O O O O O O O SD2 source destination byte 2 4 O PSS foIlowing patch Notis a simse1 id 1 1 1 1 Reserved : 5 O O O O O Reserved O O 1 GRP patch id-123 ~;~ 6 O O 1 O O O 1 1 GRP patch id-123 least significant byte 7 O O 1 0 O O 1 1 CHK chècksum : NO~E: WORKING CHANNEL SLOTTED OUTBOUND MESSAGE MT; 1111.

:

: :

:

": ' ' .:. .. .
. .

~3~

:~ 11.3.5 ASSIGN GROUP ID TO PATCH ID MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 12 GETC CODE: 00 OVERALL LENGTH: 9 bytes WHEN SENT: Transmitted by a site controLler when a patch or simul-select modification ha- been approved. This message is used to inform console 102 which groups are assigned to a patch id. The assignmentS will be issued one message at a time~ If this message is received, the patch id specified in the message is ~ ~ automatically activated-.
:: SO~RCE: : DLTC 450 ORIGINAL SOURCE: Sit~ Controller 410 : DESTINATION~ Switch 457 ~ ~ FINAL DESTINATION: Console 102 : : :: ~

~ ~

,~: :
' , , ... .

~3~

Byte # Bit ~ Description 7 6 _5 4 3 2 1 O
O O O O 1 1 O O MID messa~e id=12 O R retransmit=O or first transmission 1 O O O O O 1 1 O TLY 6 data bytes - to follow exclusive of checksum 2 O O O O O O O O SD1 source destination byte 1 3 O O O O O O O O SD2 source destination byte 2 4 0 O O O Not used ; 1 1- 1 O Reserved o R~served ~ O 1 1 O 1 O O GRP patch id=34S.
;~ ~ most significant byte 6 O 1 O 1 GRP patch id least : significant nibble O Reserved : ~ 1 O O GRP group`id=456 most significant : i nib~le 7 O 1 O 1 O 1 1 O GRP group id least significant byte :~ 8 O O 1 1 O O 1 O C~K checksum - . . . .
NO~E: CONTROL CHANNEL OUTBOUND MT-A: 11, MT B: 100.

~' ..
'-".
, :~L3~s~

11.3.6 ASSIGN INDIVIDUAL ID TO PATCH IO MESSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBER: 13 .GETC CODE: OD
OVERALL ~ENGTH: 9 bytes WHEN SENT: Transmitted by a site controlIer when a patch or simul-select modification has been approved. This message is used to inform the console 10~ which individuals are assigned to a patch id. The : .. assi~nments will be issued one message at a time. If this message is received, -~ the patch id specified in ~ the message is : automatically activated.
: SOURCE: DLTC 450 ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 ;: EINAL DESTINATION: Console 102 :
:
~_ .

,~

~ 3~

45MR~542 SSIGN INDIVIDUAL ID TO PATC~ ID MESSAOE FORM~T
Byte # Bit # _ _ _ D~scription O O O O 1 1 O 1 MID message id-13 o R retransmit=O for first transmission 1 O O O O O 1 1 O TLY 6 data bytes : to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 O O O O 0 0 O 0 SD2 source destination byte 2 - 4 0 O O O Not used 1 1 1 O Reserved 1 Reserved O 1 1 O 1 O O GRP patch id=345 ~ most significant byte : 6 O } O 1 GRP patch id least :: siqnificant nibble :~ O 1 O 1 LID group id-5~7 most significant nibble : : 7 O 1 O 1 O 1 1 1 LID group id least significant byte 8 1 O 1 1 O O 1 1 CHK ch cksum NOTE: CONTROL CHANNE~ OUTBOUND MT-A: 11, MT-B: 141.
~ .

: ~ :

, :

,. : ... ,, ~ .
. .
, ~3~;5~:~

11.3.7 SITE ID MESSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBE~: lg GETC CODE: OD
OVERALL LENGTH: 9 bytes : WHEN SENT: Notifies the console 102 of the site status and failsoft information.
Location of the control channel is also transmitted.
: SOURCE: DLTC 450 :` ORIGINAL SOURCE: Site Controller 41 DESTINATION: :~ Switch 457 FINAL:DESTINATION: Requesting console 102 ~: ~:

...

.
" ~ '' ' ~3~

SITE ID MESSAGE FORMAl' Byte # Bit ~ Description O O O O 1 1 1 0 MID message id=14 o R retransmit=O for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 O O O O O O O O SD1 source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 : 4 0 0 0 0 Not used 1 1 1 1 Reserved : 5 1 1 1 1 0 . Rese~ved O O DLY delay=O
O CHN control channel=6 6 0 1 1 0 CHN control channel=6 : O O O Reserved - 1 HMS inormation about this site=1 7 0 0 FST failqoft-O
normal operation O O O O O 1 SID ~ite id=l : 8 1 0 0 1 0 1 1 1 CHK checksum ~OTE: CONTROL CHANNEL OUTBOUND MT-A: 11, MT-B: 111, MT-C: 1110.

':

~. ;

,., ~ .

~ 3~55~ 4 45MR-542 11.3.8 CHANNEL UPDATE MESSAGE

MESSAGE TYPE: Global, control channel MESSAGE NUMBER: 15 GETC CODE: OD
OVERALL LENGTH: 9 bytes ~HEN SENT: Transmitted by a site controller while a channel is in use. Specifies the group or individual using the channel and whether the channel is supporting a o'igital or analog : transmission.
: SOURCE: DLTC 450 ~:~ ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 :
FINAL DESTINATION: Console 102 ;:' ~:~ :: : ~

:

~. , :

13~5~2~ 45~1R-542 Ca~NNEL UPDATE ~ESSAGE FOE~T
Bvte ~ _ _ Bit # _ Description _ O O O O 1 1 1 1 MID message id=15 o R retransmit=O for first transmission 1 O O O O O 1 1 O TLY 6 data bytes to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 0 O O O O O O O SD2 source destination byte 1 4 0 O O O . Not used 1 1 1 1 Reserved : 5 1 O O O O Reserved ~ 1 STG clear voice=O
-: O L/G group id O CHN chan~el=6 6 O 1 1 0 CHN ch~nnel-6 O Not used O 1 O GRP group id=234 ~ost ~ignificant nibble 7O O 1 1 O 1 O O GRP group id least significant byte 81 1 O 1 O 1 O O CHK check~um .
NOTE: CONTROL CHANNEL OUTBOUND MT-A: 11, MT-B: 111, MT-C: 0000.

~- ~''', ', ~' ~' ' . , '' .
~, ~. ~

~ 45MR-542 11.3.9 ACTIVATE PATCH ID MESSAGE

MESSAGE TYPE: Global MESSAG~ NUMBER: 16 OVERALL LENGTH: 8 bytes ~HEN SENT: Transmitted by a site controller after a patch id has been activated. This message is used for both patch and simul-select applications.
SOURCE: DLTC 4~0 ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 EINAL DESTINATION: Console 102 /
/

~: /
; ~: /

~:

~ 3~S524 45MR-542 ACTIVAT~ PATC~ ID MESSAGE FORM~T

BYte # Bit # De~cription O O O 1 O O O O MID message id=16 O R retransmit=O for . first transmission 1 O O O O O 1 O 1 TLY 5 data bytes : to follow exclusive of checksum : 2 O O O O O O O O SDl source destination byte 1 3 O O O O O O O O SD2 source destination byte 2 : 4 O PSS follo~ing ~ ` patch id is a simsel :~ id O O O Not used 1 1 1 1 Reserved :
~; 5 O Reserved '.
O 1 1 O 1 O O GRP patch id=345 ~:: 6O 1 O 1 GRP patch id least : ~ significant nibble 1 Reserved ~; O O O Not u ed 7 ~ O 1 1 1 O 1 1 O C~K checksum ~ : NOTE: MODELED:AETER WORKING CHANMEL MESSAGE llll.

:` :
i . , :
: : :
':
:
' ~. . . ..

-. . :, : :
.

~3~55Z4 45MR-542 11.3.10 PATCH COLLECTION ACKNOWhEDGE MESSA~E

MESSAGE TYPE: Global : MESSAGE NUMBER: 17 OVERALL LENGTH: 9 byt*s WHEN SENT: Transmitted by a site controller after a modify patch collection message has been received. This message is used for both patch and simul-select applications and is the global acknowledge for the modify message.
, :
~ SOURCE: DLTC 450 `~: : ORIGINAL SOURCE: Site Controller 410 :
: :: DESTINATION:: Switch 457 FINAL DESTINATION: ~ ~Console 102 ~ :

~: : , ~
: :

, ~ : : :

:.:
. ~ : ~ ~: :

:~ :

.

.
,, .. . ~ ' ' .

' .
, 3C~;2~ 45rlR~542 PATC~ COLLECTION ACKN ~LEDGE ME';SAGE O~MAT
- By~e ~ _ _ Bit # Description 7 ~ 5 4 3 2 1 O
O O O 1 0 O 0 1 MID message id=17 O R retransmit=O for first tran~mission 1 O O O O O 1 0 1 TSY 5 data types to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 0 0 0 0 0 0 0 0 SD2 source destination byte 2 ~:~ 4 O PSS following patch id is a simsel id O O O Not used 1 1 1 0 Reserved 0 Reserved 0 1 1 0 1 0 O GRP patch id=345 6 0 1 0 1 GRP patch id 1 MAK modify ack=l 0 0 0 Nor used 7 1 1 0 1 0 1 1 1 C~X checXsum NOTE: ~MODELED AFTER WORKING CHANNEL MESSAGE 1111.

: ~
.

, , , '' ,,; ~ :

~3~5~ii29L

11.3.11 EMERGENCY CHANNEL UPDATE MESSAGE

MESSAGE TYPE: Global MESSAGE NUMB}3R: 18 OVERALL LENGTH: 9 bytes - WHEN SENT: Once a radio unit has declared an emerg~ncy, the site controller 410 shall send this message to the dispatch center. The dispatch center uses this inform~tion to display the emergency information on the consoles 102.
SOURCE: DLTC 450 ORIGINAL SOURCE: Site Controller 410 DESTINATION: Switch 457 FINAL DESTINATION: Console 102 , ~ .
/

~: : ~

~. . ;.

.

31 3~;S~

EMERGENCY C8hNNEL ~
B~te ~ _ _ Bit # _ Destination O O O 1 0 0 1 0 MID Message id=lB
O R retransmit=O for first transmission 1 0 0 0 0 O 1 1 0 TLY 5 data bytes to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 0 O O O O O O O SD2 source destination byte 2 g O O O O Not used 1 1 1 1 Reserved 1 0 1 1 0 Reserved O STG clear voice O L/G group/uni~ ~lag O CHN channel field ms bit : 6 0 0 1 0 CHN channel=3 O O O O GRP group id or LID logical id 7 0 O O O O O O O GRP group id or LID group id :~: 8 1 0 0 1 1 0 1 1 C~K check;um : NOTE: CONTROL CHANNEL OUTBOUND: MT-A: 11, MT-R: ill, ~ M5-C: 0110.

;:
~ .

. ; , :. ., : . :
, .
.

~3~

17~

11.3.12 EMERGENCY CHANNEL ASSIGNMENT MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 19 OVERALL LENGTH 10 bytes W~EN SENT: This message is the response to an emergency channel request message.
Upon receipt of this message, the dispatch center shall route the audio path to the appropriate consoles 102 and display the logical id -: which will be transmitting the audio.
: SOURCE: ~ DLTC 450 ORIGINAL SOURCE: Site Controller 410 DESTINATION: : Switch 457 ~` FINAL DESTINATION: Console 102 ____ _ :- /

.

.
' -1~5~ 45~1R-542 1~9 EMERGENCY CaANNEL ASS~IGN~ENT MESSAGE FO~MAT
~yte ~ Bit ~ _____e~scri~tion O O O 1 O O 1 1 MXD Messaye id=19 R retransmit~O for first tr~nsmission 1 O O O O O 1 1 1 TLY 7 data byt~s to follow exclusive of checksum : 2 O O O O O O O O SD1 source destination byte 1 3 O O O O O O O O SD2 source destination byte 2 4 O O O O Not used O 1 Reserved O O TAG clear voice=OO
S O O 1 1 O O 1 O LID source id - 123 6 O O 1 I LID least significan~ nibble O O Not used O L/G group id O CHN channel=3 most significant bit 7 : O O 1 1 CHN channel=3 least significant nibble : O Not used O 1 0 GRP destination ; group id=234 8 O O 1 1 O 1 0 0 GRP destination group least significant byte : ~ 9~ O 0 1 1 O: 1 O O C~K check~um : : NOTE: CONTROL C ~ : Ol) TWO-SLOT MESSAGE COMPRESSED.

.
, `
.
' ` ' :,` .. ~ ~ , ' .

-. :

~ 3~5~4 45MR-542 11.3.13 STATUS MESSAGE

MESSAGE TYPE: Global MESSAGE NUMBER: 20 OVERALL LENGTH 9 bytes WHEN SENT: This mes~age is relayed from a radio unit to the dispatch center through the site controller 410. It may be transmitted by a radio either in response to an in~uiry, or at the request of the raclio operator .
SOUR~E: DLTC 450 ORIGINAL SOURCE- Radio via site controller DESTINATION: . Switch 457 FINAL DESTINATION: Console/Computer Aided ~: ~ Dispatch System : : /

D~
~,.
/:

, ~ 3~55~4 45MR-542 STATUS MESSAGE FO~MAT
Byte # _ _Bit # Descriptio~
7 6 5 4 3 Z l O
O O O 1 0 1 0 0 MID Messa~e id=20 O R retran~mit=O for first transmission 1 0 0 0 0 0 1 1 0 TLY 6 data bytes to follow exclusive of checksum 2 O O O O O O O O SDl source destination byte 1 3 O O O O O O O O SD2 source destination byte 2 ~: 4 0 0 0 0 Not used 1 1 1 1 Reserved `
1 0 1 0 Reserved - O O O Not used l ATM ~utomatic response-1 6 0 0 0 1 STS status code=l O O O 1: LID loglcal id 7 0 0 l O O 0 1 1 LID logical id : 8 l O 0 0 1 1 1 0 CHK checksum NOTE:: CONTROL CHANNEL INBOUND: MT-A 1~, MT-B: 111, MT-C: 010.

.-: ~:
~, ' .`, :~: :
:
, ~, :
., ~' i,.. .. -: ~ , ,, .. ' . , : ' ~3~5524 45MR-542 11.3.14 SITE CONTROLLER 410 RESET MESSAG:E

MESSAGE TYPE: Global status message MESSAGE NUMBER: 21 OVERA~L LENGTH: 9 bytes WHEN SENT: When a site controller 410 comes out of reset tfor any reason), it will issue this message to the dispatch center so that both sets of operational databases can be cleared.
SOURCE: DLTC 4SO
ORI~,INAL SOURCE: àite Controller 41 DESTINATION: Switch 457 FINAL DESTINATION: Main processor (console) : :: :

/

,..
~, /

.

~ 3~5S24 45MR-542 lB3 SITE CONTROLLER 410 ~ESET MESSAGE ~ORMAT
BYte # __ Bit ~ _ Description 7 6 5 4 3 2 l O
O O O l O l 0 l M~D Message icl=21 ; O R ratransmit-O for first transmission 1 O O O O O } 1 O TLY 6 data bytes to follow exclusive o~ checksum 2 O O O O O O O O SDl source destination byte l 3 O 0 O O O O O O SD2 source destination byte 2 ~: 4 O O O O O O O. O Not used ,:
O 0 O O O O O O Not used : 6 O~ O O O O O O O Not used :
; : 7 O O O O O O O O Not used :
8 O 0 O 1 O O 1 l CH~ checksum NOTE: MODELED AFTER WORKING C~NNEL MESSAGE 1111.
hil the~present invention has been described with wha~ is presently considered to be the most practical and preferred embodiments, it~is to be understood ~hat the appended claims are not to be limited to the disclosed embodiments hut on the contrary, are intended to cover all modifications, ~ariations and/or equivalent arrangements which retain any novel features and advantages of this invention.

, . ~ . .

~3~5~;2~
45MR~542 12.0 APPENDIX I -- GLOSSARY OF MESSAGE FIELD DEFINITIONS
.

The following glossary of field definitions correspond to the field names set forth above in the detailed message formats.

MESSAGE FIELD DEFINITIONS
Field Ranae Description (hex) ACT 0-1 One bit field used to indicate whether a patch~simsel id is being activated (=1) or deactivated (O=) ATM 0-1 Automatic bit field used to : indicate that the responding unit automatically relays its status to the console 102.
BKl 57 First Barker byte, alw~ys a 57 : hex : BK2 12 Second Barker byte, always a 12 hex : .
BMP OO-EF Bit map used for multiple group calls. Each bit represents an entity which was specified in the set up of the ~ ~ ~ call.
: C~K OO-FF "ExcIusive Or" checksum of all :`~ bytes in a:message.
: CHN OO-lF Five bit field which specifies ~he hardware channel on which a calI will be routed. Each :~ : channel is connected to a ~ repeater.
: 00 Reserved 01-18 ~epeater/channel numbsrs 1 to 24 l9-lB ~ Reserved ~C Call pending ~' ~a3~
4sr~lR-s42 MESSAGE FIELD DEFINITIONS
Field (hex) D~cript~on lD Call gueued lE System busy, c~ll not queued lE Call denied CNT 0-7 Count of the number of patch messages to follow header message -DLY 0-3 Delay associated with time between channel request to channel allocation 00 2 slots - 60 msec 01 3 slots - 90 msec 5 slots - 150 msec 11 8 slots - 240 msec ECL 0-l One bit field used to command the site to cancel the declared emergency =1 FST 0-3 Two bit failsoft code 00 Normal operation OI Limi~ed trunkiny Conventional operation 11 Reserved GCT O-F Indicates number of groups ~; . following in this message.
GID OO-FF Unique GETC message id :~ : GRP 000~7FF Eleven bit group id used to :~ speci~y a collection of mobiles HDP 0-1 Hold channel = O, drop channel=l :: HDR 0-l Elag whic~ identifies a patch message as a header message HMS 0-1 Home site i~formation =1, adjacent ~ite information =0.
IC1 O-F Most significant nibble of an inbound single slot control channel message ~ -3L3~

MESSAGE FIELD DEE:tNITIONS

( hex ) IC2 O-F Second signif.icant nibble ( inbound sin~:lle 510t control channel m~ssa~g~ ) 3 O-F Third significant nibble ( inbound sincJle slot control channel messaS~e) IC4 O-F Fourth significant nibble ( inbound single slot control channel message) IC5 O-F Fifth significant nibble (inbound single slot control channel message) IC6 O-F Sixth significant nibble ( inbound single slot control channel message ) IC7 O-F Least significant nibble bound single slot control chanrlel mes~3a~e ) ICT O-F Indicates nunLber of individuals following in this messaqe.
I~l O-F Most si~nificant nibble of a~
inbound worlcing channe1 message IW2 O-F Second significant nibble (inbound working channel message ) I~3 O-F Third significant nibble ~inbound working channel message) IW4 Q F L~ast significant nibble ( inbound workinçr channel mes~ag~ ) IW5 O-F Least significarlt nibble ( inbound working channel messaqe ) L~G 0-1 Following id ~ s ~ither a group L/G--O, or a unit L/G=l ;

.
., ~5MR-542 la7 MESSAGE FIELD DEFINITIONS
Fi~ld (hex) t~

LID OOO-FFF Twelve bit logical id used to uni~lely specify a source or destination of audio MAK O-l Acknowledge to a modify patch assignment message-l MID OO-FF Unique console message id OC1 O-F Most significant nibble of an outbound single s}ot control channel message OC2 O-F Second significant nibble (outbound single slot control channel message) OC3 O-F Third significant nibble (outbound single slot control channel message) OC4 O-F Fourth significant nibble (outbound single slot control channel message) OCS O-F Fifth significant nibble ~outbound single slot control channel message) OC6 O-F Sixth significant nibble (outbound single slot control channe1 message) : OC7 O-F Least significant nibble : (outbound single 510~ control channel message) OCA O-F Most significant nibble of an : ~ outbound 2-slot control channel : message .
: OCB O-F Second significant nibble (outbound 2 slot control channel message ) ,,,,~ ~

~3~

1~8 MESSAGE FIELD D~FINITIONS
Eield Ranqe ~

OCC O-F Second significant nibble (outbound 2 slot control channel message) OCD O-F Eourth significant nibble ~outbound 2-slot control channel message ) OCE O-F Fifth significant nibble (outbound 2-slot control channel message) OCF 0-F Sixth significant nibble (outbound 7-slot con~rol channel message) OCG 0-F Seventh significant ni~ble ~outbound 2-slot control channel message) OCH O-F Eighth significant nib~le (outbound ~-slot control channel message) OCI :~ O-F Least significant nibble (outbound single slot control channel message) OWl O-F Most significant nibble of an ou:tbound working channel message OW2 O-F Second significant nibble (outbound working channel message) OW3 O-F Third significant nibble : (outbound working channel - message) OW4 O-F Fourth slgnificant nibble :(outbound working channel message) OW5 O-F Least significant nibble (outbound working channel .

, .. .

~IL3~?5;~

MESSAGE FIELD DEFINITIONS
Field _Ranqe_ DescriPtior (hex) ~ message) ; PID OO-lF Five bit physical id used in conjunction with . source/destination field PKD OO-FF Eight bit packet number which is - unique, and incremented after every message is passed. If the receiver skips a packet .number, a NACK i 5 sent to the . transmitting GETC.
PSS O-l One bit field used to indicate whether the ollowing group id ~: is a patch (-l) or simsel t=1 id .~
R O-l Retransmit=l if message is repeated .;
S/C O-l Status/Call=l if message:is a status message.
SDl,SD2 TB~ Sourcejdestinatio~ code : :: used with multiple switch ~ 457/multiple site messages.
: :SID 00-3F :Site identification number i: :
: SPK O-F Four bit least significant ~: : nibble of packet number used in : ~ ~ a patch message STB OO-FF ~ : Eight bit start byte used ~ exclusively in site~GETC
-~ communications ~: ~ STG O-l One bit short tag fleld used in status messages :: O Clear Voi;ce Transmi~sion 1 Digital transmi sion (Voice ~: Guard or digital data ) :
TAG 0-4 Two bit field identiias type of : transmission 00 Clear voice .~ .

....

.

5~i2~

1~0 MESSAGl; FIELD DEFINITIONS
Field Ranae _ Description ( hex j Ol Voice suard Data 11 Reserved TLY OO-FF Eight bit field used to specify the -number of bytes following the message id exclusive of the checksum byte : /
/

~ /

/
: : : ~
: : : ~
: :. / :

/

: : /

:

, ~:

- ,: ~ ' ' ' .
: . , , ,,. :

Claims (36)

1. In a digitally trunked radio frequency repeater system of the type including plural RF repeater transceivers communicating via radio frequency channels with mobile radio transceivers, said repeater transceivers being controlled by a site controller which communicates control information with a dispatch console over a downlink, a method of operating said system comprising:
communicating digital control signals between said repeater RF transceivers and said mobile radio transceivers via said radio frequency channels using a synchronous serial communications protocol; and communicating digital control signals between said site controller and said dispatch console over a telephone line data link using said same synchronous serial communications protocol.

2. In a digitally trunked radio frequency repeater system of the type including plural RF repeater transceivers communicating via radio frequency channels with mobile radio transceivers, said repeater transceivers being controlled by a site controller which communicates control information with a dispatch console over a downlink, an improvement comprising:
means for communicating digital control signals between said repeater RF transceivers and said mobile radio transceivers via said radio frequency channels using a synchronous serial communications protocol; and means for communicating digital control signals between said site controller and said dispatch console over a telephone line data link using said same synchronous serial communications protocol.

3. In a digitally trunked radio frequency repeater system, a method of communicating digital control siynals between an RF repeater site controller and a telephone switch over a digital signal downlink, said method including:
(1) communicating distinct first and second site controller messages between said site controller and a downlink trunking card module over a high-speed data link connecting said site controller to said downlink trunking card module;
(2) communicating distinct first and second console messages between said switch and a switch trunking card module over a further high-speed data link connecting said switch trunking card module to said switch; and (3) communicating single messages corresponding to said first and second console message and single messages corresponding to said first and second site controller messages between said downlink trunking card module and said switch trunking card module over a lower speed landline communications link.

4. A digitally trunked radio freguency repeater system of the type which communicates over radio freguency channels with mobile radio transceivers under the control of a dispatch console, said system comprising:
plural RF xepeater transceiver means for communicating via said radio frequency channels with said mobile radio transceivers, said plural repeater transceiver means each including an RF trunking card associated therewith;
downlink means for communicating control signals between said dispatch console and a site controller means, said downlink means including a downlink trunking card;
a switch trunking card associated with said dispatch console;
site controller means connected to said plural RF trunking cards and to said downlink trunking card for controlling said trunking cards;

first serial data link means connected between said site controller means and said downlink trunking card for communicating digital signals in a first protocol between said site controller means and said downlink trunking card;
said downlink trunking card including means for translating said digital between said first protocol and a second protocol different from said first protocol;
second serial data link means connected between said downlink trunking card and said switch trunking card for communicating said digital signals in said second protocol between said downlink trunking card and said switch trunking card;
said switch trunking card including means for translating digital signals between said second protocol and a third protocol different from said second protocol;
and third serial data link means connected between said switch trunking card and said dispatch console for communicating said third protocol digital signals between said switch trunking card and said dispatch console.

5. A system as in claim 4 wherein at least one of said first, second and third serial data link means includes means for transmitting/receiving digital signals in the following protocol;
a frame start character having a value of "AA"
hex;
a message identification byte which specifies an operational code and a number N of data bytes to follow said identification byte;
a variable number N of message data bytes following said identification byte said variable number being dependent on the value of said identification byte;
and a further byte indicating the end of message and also specifying error checking/correction information.

6. A system as in claim 4 wherein:
said plural repeater transceiver means each include means for communicating digital encoded radio frequency signals with said mobile radio transceivers via said radio frequency channels using a synchronous serial communications protocol substantially identical to said second protocol.

7. A system as in claim 4 wherein:
said first serial data link means includes means for communicating distinct first and second site controller messages to said downlink trunking card;
said third serial data link means includes means for communicating distinct first and second console messages with said dispatch console; and said downlink trunking card and said switch trunking card include means for communicating single messages corresponding to said first and second console messages and single messages corresponding to said first and second site controller messages therebetween over said second serial data link means.

8. A system as in claim 4 wherein:
said first serial data link means includes means for transmitting distinct first and second site controller messages from said site controller means to said downlink trunking card;
said downlink trunking card includes means for packing said first and second messages into a single message;
said second link means includes means for transmitting said single message to said switch trunking card;
said switch trunking card includes means for unpacking said single message into distinct first and second control messages corresponding to said first and second site controller messages; and said third serial data link means includes means for transmitting said first and second console messages to said dispatch console.

9. A system as in claim 4 wherein:
said third serial data link means includes means for transmitting distinct first and second console messages over said switch trunking card;
said switch trunking card includes means for packing said first and second messages into a single message; and said second serial data link means includes means for transmitting said single message from said switch trunking card module to said downlink trunking card;
said downlink trunking card includes means for unpacking said single message into distinct first and second site controller messages corresponding to said first and second console messages; and said first serial data link means includes means for transmitting said first and second site controller messages to said site controller means.

10. A system as in claim 4 wherein:
said first serial data link means includes means for transmitting and receiving messages between said site controller means and said downlink trunking card module in a first format including:
(a1) start frame byte, (a2) operational code byte, (a3) a variable number N of data bytes, and (a4) a checksum byte, said downlink trunking card includes means for converting said messagas transmitted over said first serial data link between said first format and the following second format:

(b1) Barker code bytes, (b2) said operational code byte, (b3) a packet begin character, (b4) said variable number N of data bytes, and (b5) at least one checksum byte different from said first-mentioned checksum byte;
said second serial data link means includes means for transmitting and receiving messages in said first format between said downlink trunking card and said switch trunking card;
said switch trunking card includes means for converting messages between said second format and the following third format;
(d1) a MID code corresponding to said operational code byte, (d2) a TLY byte specifying the number of data bytes to follow, (d3) source and destination bytes indicating the source and destination of said message, (d4) said variable number N of data bytes, and (d5) a further checksum byte different from said first-mentioned and second-mentioned checksum bytes; and said third serial data link means includes means for transmitting and receiving messages in said third format.

11. In a trunked radio repeater system having an architecture of a site controller communicating with RF
repeater means and a downlink trunking card module, said RF
repeater means and downlink trunking card module each having control functions and being capable of communicating with each other independently of the site controller, a method of communicating digital signals over a downlink between said site controller located at an RF repeater site and a processor located remotely from said site, said RF repeater site including a plurality of said RF repeater means for communicating digital control signals with mobile radio units over RF channels using a predefined digital signaling protocol, said method comprising the steps of:
(1) communicating digital signals in a first predefined protocol between said site controller and said downlink trunking card module over a first serial data link;
(2) translating said first protocol digital signals between said first protocol and a second predefined protocol with said downlink trunking card module;
(3) communicating said digital signals in said second protocol between said downlink trunking card module and a switch trunking card module located remotely from said site over a second serial data link;
(4) translating said second protocol digital signals between said second protocol and a third predefined protocol with said switch trunking card module; and (5) communicating said third protocol digital signals between said switch trunking card module and said processor over a third serial data link, wherein said first and second protocols are different from one another, and said second protocol is substantially identical to the signalling protocol used to communicate digital control signals between said repeater means and said module radio units over said RF channels.

12. A method as in claim 11 wherein:
said communicating step (1) includes transmitting digital data signals over said first data link at a rate of about 19.2 kbps using said first protocol;
said communicating step (5) includes transmitting digital data signals over said third data link at a rate of about 19.2 kbps using said third protocol; and said communicating step (3) includes transmitting digital data signals over said second data link at a rate of about 9.6 kbps using said second protocol.

13. A method as in claim 11 wherein:
said communicating step (3) includes transmitting data over said second data link at a first data transfer rate; and said communicating steps (1) and (5) include transmitting data over said first and third data links, respectively, at data transfer rates which are substantially greater than said first data transfer rate.

14. A method as in claim 11 further including the steps of:
performing said steps (1) - (5) in sequence to communicate global messages between said controller and said processor; and performing only said steps (1) and (2) to communicate administrative messages between said controller and said downlink trunking card module.

15. In a trunked radio repeater system, a method of communicating digital signal messages between a site controller and a trunking card comprising:
(1) transmitting a frame start character having a value of "AA" hex;
(2) transmitting a message identification byte which specifies an operational code and a number N of data bytes to follow said identification byte;
(3) transmitting a variable number N of message data bytes following said identification byte, said variable number being dependent on the value of said identification byte; and (4) transmitting a further byte indicating the end of message and also specifying error checking/correction information.

16. A method as in claim 15 further including:
(5) waiting for receipt of an acknowledgement - l99 - 45MR-542 message responsive to the message transmitted by said steps (1) - (4);
(6) repeating said steps (1) - (4) if said acknowledgement message is not received after a time period has elapsed and said steps (1) - (4) have not already been repeated twice to retransmit the same message; and (7) transmitting a synchronization sequence if said acknowledgement message is not received after said time period has elapsed and said steps (1) - (4) have already been repeated to retransmit the same message twice.

17. A method as in claim 15 wherein each of said steps (1) - (4) includes transmitting a start bit, eight binary digital data bits, and a stop bit.

18. A method as in claim 15 wherein each of said steps (1) - (4) includes:
(a) transmitting a start bit;
(b) transmitting eight binary data bits with least significant bit first and most significant bit last;
and (c) transmitting a stop bit.

19. A method as in claim 15 wherein said steps (1) - (4) each transmit digital signals at a nominal rate of 19.2 kilobits per second with a nominal bit time of 52.08 microseconds.

20. A method as in claim 15 wherein:
said method further includes, generating the exclusive-OR value of said message identification byte transmitted by said transmitting step (2) and said message data bytes transmitted by said transmitting step (3), and negating said generated exclusive-ORed value;
and said transmitting step (4) includes transmitting said negated value as said byte containing error checking/correction information

21. In a trunked radio repeater system of the type including a site controller including at least one trunking card means for controlling the operation of a radio frequency repeater, a method of communicating digital signal messages between said trunking card means, comprising:
(1) receiving a frame start character having a value of "AA" hex;
(2) receiving a message identification byte which identifies an operational code and a number N of data bytes to follow said identification byte;
(3) receiving a variable number N of message data bytes following said identification byte, said variable number being dependent on the value of said identification byte; and 4 ) receiving a further byte indicating the end of message and also specifying error checking/correction information.

22. A method as in claim 21 wherein each of said receiving steps includes sampling an incoming digital data stream at a rate of at least sixteen times the nominal bit rate of said stream.

23. A method as in claim 21 wherein said receiving step (1) includes acquiring frame synchronization in response to said frame start character.

24. A method as in claim 11 further including:
calculating a checksum value responsive to said bytes received by said receiving steps (2) and (3);
comparing said calculated checksum value with the value of said further byte received by said receiving step (4) ; and if said comparison reveals said calculated and received checksum values match, transmitting an acknowledge message.

25. A method of communicating digital signals between an RF repeater site controller and a telephone switch over a digital signal downlink, said method including:
(1) transmitting distinct first and second site controller me sages from said site controller over a high-speed data link connecting said site controller to a downlink trunking card module;
(2) packing said first and second massages into a single message at said downlink trunking card module;
(3) transmitting said single message from said downlink trunking card module to a switch trunking card module over a lower speed landline communications link;
(4) unpacking said single message into distinct first and second console messages corresponding to said first and second site controller messages at said switch trunking card module; and (5) transmitting said first and second console messages to said switch over a further high-speed data link connecting said switch trunking card module to said switch.

26. A method of communicating digital signals between an RF repeater site controller and a telephone switch over a digital signal downlink, said method including:
(1) transmitting distinct first and second console messages from said switch over a high-speed data link connecting said switch to a switch trunking card module;
(2) packing said first and second messages into a single message at said switch trunking card module;
(3) transmitting said single message from said switch trunking card module to a downlink trunking card module over a lower speed landline communications link;

(4) unpacking said single message into distinct first and second site controller messages corresponding to said first and second console messages at said downlink trunking card module; and (5) transmitting said first and second site controller messages to said site controller over a further high-speed data link connecting said downlink trunking card module to said site controller.

27. A system for communicating digital signals between an RF repeater site controller and a telephone switching network over a digital signal downlink including:
a first high-speed data link connecting said site connecting to a downlink trunking card means;
a landline communications link connecting said downlink trunking card means to a switch trunking card means;
a second high-speed data link connecting said switch trunking card means to said telephone switching network;
said site controller including means for transmitting distinct first and second site controller messages from said site controller to said downlink trunking card means over said first high-speed data link;
said downlink trunking card means for packing said first and second messages into a single message and for transmitting said single message to said switch trunking card means over said landline communications link;
said switch trunking card means for unpacking said single message into distinct first and second console messages corresponding to said first and second site controller messages and for transmitting said first and second console messages to said telephone switching network over said second-speed data link.

28. A system for communicating digital signals between an RF repeater site controller and a telephone switching network over a digital signal downlink including:
a first high-speed data link connecting said site controller to a downlink trunking card means;
a landline communications link connecting said downlink trunking card means to a switch trunking card means;
a second high-speed data link connecting said switch trunking card means to said telephone switching network;
said telephone switching network including means for transmitting distinct first and second console messages to said switch trunking card means over said second high-speed data link;
said switch trunking card means for packing said first and second console messages into a single message and for transmitting said single message to said downlink trunking card means over said landline communications link;
said downlink trunking card means for unpacking said single message into distinct first and second site controller messages corresponding to said first and second console messages and for transmitting said first and second site controller messages to said site controller over said first high-speed data link.

29. A method of communicating digital signals between an RF repeater site controller and a telephone switching network over a downlink digital signal data link, said method comprising the steps of:
(A) transmitting messages from said site controller to a downlink trunking card module in the following format:
(a1) start frame byte, (a2) operational code byte, (a3) a variable number N of data bytes, and (a4) a checksum byte;
(B) converting, at said downlink trunking card module 450, said messages transmitted by said transmitting step (A) into the following format:
(b1) Barker code bytes, (b2) said operational code byte, (b3) a packet begin character, (b4) said variable number N of data bytes, and (b5) at least one checksum byte different from said first-mentioned checksum byte;
(C) transmitting said message converted by said converting step (B) from said downlink trunking card module to a switch trunking card module;
(D) converting, at said switch trunking card module, said message transmitting said transmitting step (C) into the following format;
(d1) a MID code corresponding to said operational code byte, (d2) a TLY byte specifying the number of data bytes to follow, (d3) source and destination bytes indicating the source and destination of said message, (d4) said variable number N of data bytes, and (d5) a further checksum byte different from said first-mentioned and second-mentioned checksum bytes; and (E) transmitting said data converted by said converting step (D) to said switch.

30. A method of communicating digital signals between an RF repeater site controller and a telephone switching network over a downlink digital signal data link, said method comprising the steps of:
(A) receiving messages from said site controller with a downlink trunking card module in the following - 205 - 45Mr-542 format:
(a1) start frame byte, (a2) operational code byte, (a3) a variable number N of data bytes, and (a4) a checksum byte;
(B) converting, at said downlink trunking card module, said messages received by said receiving step (A) into the following format:
(b1) Barker code bytes, (b2) said operational code byte, (b3) a packet begin character, (b4) said variable number N of data bytes, and (b5) at least one checksum byte different from said first-mentioned checksum byte; and (C) transmitting said message converted by said converting step (B) from said downlink trunking card module to a switch trunking card module.

31. A method of communicating digital signals between an RF repeater site controller and a telephone switching network over a downlink digital signal data link, said method comprising the steps of:
(A) receiving a message wit a switch trunking card module in the following format:
(a1) Barker code bytes, (a2) said operational code byte, (a3) a packet begin character, (a4) said variable number N of data bytes, and (a5) at least one checksum byte; and (B) converting, at said switch trunking card module, said message received by said receiving: step (A) into the following format:
(b1) a MID code oorresponding to said operational code byte, (b2) a TLY byte specifying the number of data bytes to follow, (b3) source and destination bytes indicating the source and destination of said message, (b4) said variable number N of data bytes, and (b5) a further checksum byte different from said first mentioned and second-mentioned checksum bytes; and (C) transmitting said data converted by said converting step (B) to said switch.

32. A method of communicating digital signals between an RF repeater site controller and a telephone switching network over a downlink digital signal data link, said method comprising the steps of:
(A) transmitting messages from said site controller to a node on said downlink in the following format;
(a1) start frame byte, (a2) operational code byte, (a3) a variable number N of data bytes, and (a4) a checksum byte;
(B) converting, at said downlink node, said message transmitted by said transmitting step (A) into the following format:
(b1) a MID code corresponding to said operational code byte, (b2) a TLY byte specifying the number of data bytes to follow, (b3) source and destination bytes indicating the source and destination of said message, (b4) said variable number N of data bytes, and (b5) a further checksum byte different from said first-mentioned and second-mentioned checksum bytes; and (C) transmitting said data converted by said converting step (B) to said switch.

33. In a digitally trunked radio frequency communications system, an arrangement for prioritizing digital messages for communication between a dispatch console and a site controller, said arrangement including:
means for receiving control channel messages, working channel messages, patch messages, and administrative messages from said dispatch console;
buffer means connected to said receiving means for temporarily storing said received messages:
communication link means connected to said buffer means for transmitting messages contained in said buffer means to said site controller; and processing means, operatively connected to said buffer means and said communication link means, for prioritizing the transmission of messages temporarily stored by said buffer means so that:
(a) all stored control channel messages are transmitted before any stored working channel, patch or administrative message, (b) all stored working channel messages are transmitted before any stored patch and administrative message, and (c) all stored patch messages are transmitted before any stored administrative message.

34. In a digitally trunked radio communications system of the type including a dispatch console for transmitting digital control messages to and receiving digital control messages from a site controller, an improvement comprising:
buffer means for storing plural messages intended for said dispatch console;
communications link means connected between said buffer means and said dispatch console for communicating digital control messages between said buffer means and said dispatch console;
message transmitting means operatively connected to said buffer means and said communications link means for reading messages from said buffer means and transmitting said read messages to said dispatch console over said communications link means;
means connected to said message transmitting means and to said communications link means for controlling said transmitting means to retransmit previously transmitted messages in the absence of receipt of an acknowledgement message transmitted by said dispatch console;
message receiving means within said dispatch console connected to said communications link means for receiving said transmitted messages; and acknowledgement means operatively connected to said message receiving means for transmitting acknowledgement messages in response to said received messages, said acknowledgement means including means for controlling the effective rate of transmission of said message transmission means by selectively inhibiting transmission of acknowledgement messages in response to received messages.

35. A method as in claim 11 further including the steps of:
performing said steps (1) - (5) in sequence to communicate global messages between said controller and said processor; and performing only said steps (4) and (5) to communicate administrative messages between said processor and said switch trunking card module.

36. In a trunked radio repeater system having an architecture of a site controller communicating with RF
repeater means and a downlink trunking card module, said RF repeater means and downlink trunking card module each having control functions and being capable of communicating with each other independently of the site controller, a method of communicating digital signals over a downlink between said site controller located at an RF
repeater site and a processor located remotely from said site, said RF repeater site including a plurality of RF
repeater means for communicating digital control signals with mobile radio units over RF channels using a predefined digital signalling protocol, said method comprising the steps of:
(1) communicating digital signals in a first predefined protocol between said site controller and said downlink trunking card module over a first serial data link;
(2) translating said first protocol digital signals between said first protocol and a second predefined protocol with said downlink trunking card module;
(3) communicating said digital signals in said second protocol between said downlink trunking card module and a switch located remotely from said site over a second serial data link;
(4) translating said second protocol digital signals between said second protocol and a third predefined protocol with said switch; and (5) communicating said third protocol digital signals between said switch and said processor over a third serial data link, wherein said first and second protocols are different from one another, and said second protocol is substantially identical to the signalling protocol used to communicate digital control signals between said repeater means and said mobile radio units over said RF channels.