Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
~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~%~
2 45MR-542
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~
3 45MR-542
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~
4 45MR-542
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~
4521R 542
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
45MR-542
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~
45MR-542
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 ~
45MR-542
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
BY LANDLINE 452 FROM SWITCH TC 454 TO DLTC 450 111
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
CONTROLLER 410 AND TRANSMITTED FROM SWITCH TC 454
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~
8 45MR-542
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
. , .
%~
45MR-542
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~
45MR-542
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
11 45MR-542
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
45MR-542
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~
45MR-542
13
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~
14 45MR-542
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).
3O0 INTERFACE BETWEEN TRUNKING CARDS AND SITE CONTROLLER 410
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~
45MR-542
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 }~
45MR-542
16
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~
17 45MR-542
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~
45MR-542
18
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~
45MR-542
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
45MR-542
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~
45MR-542
21
.
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
45MR-542
22
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;~
45MR-542
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~
45MR-542
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~
45MR-542
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
45MR-542
26
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~
45MR-542
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
45MR-542
28
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~
45MR-542
29
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~
45MR-542
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~
45MR-542
31
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
GID BK2 TLY
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
33
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
O STB BK1 MID
GID BK2 TLY
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
,~
7 GID BC2 CHK
~; ~ 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.
-
, ~
'~ .
:~
.,: .. ,
:. : .
45MR-542
~3~
34
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
GID BK2 TLY
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.
:: : : :
.
24 4 5MR- 5 4
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
G I D BK2 TLY
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
45MR-542
36
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
8 CHK BC2 GID
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
37
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
TLY BK2 G I D
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
7 CHK BC2 GID
: 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~
45MR-542
38
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
TLY BK2 5ID
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
14 BD2 GID
:
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~
45MR-542
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
1 TLY BK2 GID
2 SDl GID PSS,RSVD
3 SD2 PKT O,GRP
4 PSS,RSVD PSS,RSVD GRP
O,GRP O,GRP CHK
6 GRP GRP
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
41
.
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~
45MR-541
42
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~
45MR-542
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;~
44 45MR-542
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~
45MR-542
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
45MR-542
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~
45MR 542
47
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~
45MR-542
49
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~
45MR-542
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
51
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~:~
45MR-542
53
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~
45MR-542
54
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
45MR-542
56
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.
4 45MR-542
58
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~
45MR-542
59
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~
45MR-542
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~
45MR-542
61
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.
5S24 45MR-542
62
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~
45MR-542
63
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
64
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~
45MR-542
66
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~
45MR-542
67
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~
4 5MR- 5 4 2
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~
69 45MR-542
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~
45MR-542
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
,
71
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
72
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
45MR-542
73
.
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~
74
45MR-542
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~
76 45MR 542
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
CARDS TO SITE CONTROLLER 410 OVER LINKS 412
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~
77 45MR-542
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~
45MR-542
78
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~
45MR-542
79
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~
45MR-542
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
45MR-542
81
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~:
CONTROLLER 410
. ~: The following presents more detailed descripti:ons of
some of the site controller to trunking card global
:: messages.
: ; : :
::
~, ~,~ :
.
..
.
. ~
3~3~i5~
45MR-542
82
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~
45MR-542
83
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~
84 45MR-542
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~
45MR-542
8S
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~
45MR-542
86
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~
87 45MR-542
Byte 8 ---- second radio slot, most
significant byte of radio message
,`: /
/
~ /
,~ /
~ / :
_ _ _ _
:: :
.
,
,~ ~ . ' ' ~ ' ,
~ ~3~5~
45MR-542
88
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~
45MR-542
B9
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~
,, ~
45MR-542
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~
45MR-542
91
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
.
45M4-542
92
CARD 450 AND SWITCH TRUNKING CARD 454
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~
45MR-542
93
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~
45MR-542
94
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~
45MR-542
~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;~
45MR-542
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~
45MR-542
97
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~
45MR-542
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~
45MR-542
99
10.1.5 NOT ACKNOWLEDGE MESSAGE
MESSAGE TYPE: Administrative
MESSAGE NUMBER 91
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
- .
7 6 S 4 3 2 1 O
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~
45MR-542
100
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
101 45MR-542
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~
102 45MR-542
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~
103 45MR-542
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~
104 45MR-542
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
7 6 5 4 3 2 1 0
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~
45MR-542
105
T~O-SL3T C NTROL C~UNNEL MESSAGE
BYte # Bit ~ DescriPtio~
7 6 5 4 3 2 1 O
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~
106 45MR-542
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~
45MR-542
107
WQRXING CEIANNEL FOE~ MA~r
Byte # Bit # l)escription
7 6 5 4 3 2 1 0
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~
45MR-542
108
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~
45MR-542
109
COLI~:CTION ACKNGWLEDGE_rss~Gr FOR~T
B~vte ~ _ ____ Bit # _ __ ___ _ De~3cri~tis7n
7 6 5 4 3 2 1 0
O O 1 0 1 O 1 1 1 BK1 Barker byte
57
O O 0 1 0 0 1 0 BK2 Barker byte
12
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~
45MR-542
110
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~
45MR-542
111
PA~/5IMUL-SELECT ACTIVA~ACTIVATE
~:SSAGE EORMAT
Bvte # _ it ~ DescriDtion
7 6 5 4 3 2 1 0
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~
45MR-542
112
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~ -
45MR-542
113
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~
45MR-542
114
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~
45MR-542
115
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~
45MR-542
116
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~
45MR-542
117
WORKING C~ANNEL FORMAT
Byte # _ _ Bit # _ Oescriptio~ _ __
7 6 5 4 3 2 1 0
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~
118 45MR-542
WORKING CHANNEL FORMAT
Byte # Bit # _ Description
7 6 5 4 3 2 1 0
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~
45MR-542
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
45MR-542
120
COLLEGTION MESSAGE_L@~ __ R~T~
Byte ~ Bit # De~cription
~. ~
7 6 5 4 3 2 1 0
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~
121 45MR-542
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~
45MR-542
122
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~
123
45MR-542
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~
45MR-542
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~
45MR-542
125
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~
45MR-542
126
11.O MESS~GES ON LINK 456 BETWEEM SWITC~ 457 AND SWITC~ TC
454
.
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
127
~ y~E ~ORMAT
B~,rte # Bit # Desc:ription
7 6 5 4 3 2 1 0
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~
45MR-542
128
DOW~INK ~ANNEL ME:SSAGE FORMAT
ES~te ~ Bit # Dess~ription
7 6 5 4 3 2
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
MESSAGE NUMBER 03
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
129
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~
45MR-542
130
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~
45MR-542
131
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~
45MR-542
132
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~
45MR-542
133
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
45MR-542
134
GROUP CALL MESSAGE FORMAT
B~te # Bit # DescriDtion
7 6 5 4 3 2 1 0
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~
45MR-542
135
.
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~
45MR-542
136
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
~: :
.
'~ ' ', "
.: :
'
4 45MR-542
137
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~
45MR-542
138
~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;~
45MR-542
139
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~
45MR-542
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~
45MR-542
141
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~
45MR-542
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~
4SMR-542
. 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~
144 45MR-542
~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~
45MR-542
145
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~
45MR-542
146
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~
45MR 542
. 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~
45MR-542
14~
~MER~ENCY_C~ANNEL RE~UE5T_PESSAGE FORM~T
Byte # Bit # r _ De~crlpti~n
7 6 5 4 3 2 1 0
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~
45MR-542
149
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~
45MR-542
150
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~
45MR 542
151
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~
152
45MR-542
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~
45MR-542
153
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
154
45MR-542
C~NCEL EMERGENCY MESSAGE FOR~AT
Byte # _ Bit # _ De~criPtiOn
7 6 5 4 3 2 1 0
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~
155 45MR-542
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~
45MR-542
156
; ~ .
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
45MR-542
157
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~
45MR-542
158
.
~ 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
102
' ~
, .
,
. .
~ .
" ~
~ . ~, .,
': '
~3~ 2~
45MR-542
159
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~
45MR-542
160
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
102
:
:
`:
:
~ :
:: :
:: :
;
' ~ ; ':
: :
:
~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
162
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~
4SMR-542
163
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~
45MR-542
164
:~ 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~
45MR-542
165
ASSI5N GROUP ID TO PATCH ID MESSAGE FORMAT
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~
45MR-542
166
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
167
SSIGN INDIVIDUAL ID TO PATC~ ID MESSAOE FORM~T
Byte # Bit # _ _ _ D~scription
7 6 5 4 3 2 1 O
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~:~
45MR-542
168
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~
45MR-542
169
SITE ID MESSAGE FORMAl'
Byte # Bit ~ Description
7 6 5 4 3 2 1 0
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
170
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
171
Ca~NNEL UPDATE ~ESSAGE FOE~T
Bvte ~ _ _ Bit # _ Description _
7 6 5 4 3 2 1 O
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
172
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
173
ACTIVAT~ PATC~ ID MESSAGE FORM~T
BYte # Bit # De~cription
7 6 5 4 3 2 1 O
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
174
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
175
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
45MR-542
176
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~
45MR-542
177
EMERGENCY C8hNNEL ~
B~te ~ _ _ Bit # _ Destination
7 6 5 4 3 2 1 0
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~
45MR-542
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
7 6 5 4 3 2 1 O
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
180
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
410
DESTINATION: . Switch 457
FINAL DESTINATION: Console/Computer Aided
~: ~ Dispatch System
: : /
D~
~,.
/:
,
~ 3~55~4 45MR-542
181
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
182
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
184
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
185
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~
186 4 5MR-54
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~
45MR-542
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;~
45MR-542
189
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~
45MR-542
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
: /
/
~ /
/
: : : ~
: : : ~
: :. / :
/
: : /
:
, ~:
- ,: ~ ' '
'
.
: . , , ,,. :
