U.S. patent number 5,392,278 [Application Number 07/658,844] was granted by the patent office on 1995-02-21 for distributed multisite system architecture.
This patent grant is currently assigned to Ericsson GE Mobile Communications Inc.. Invention is credited to Charles P. Brame, Philip C. Gulliford, Wim A. Imron, James L. Teel.
United States Patent |
5,392,278 |
Teel , et al. |
February 21, 1995 |
Distributed multisite system architecture
Abstract
A multisite network switch for a series of RF digital trunked
radio transceivers and dispatcher consoles. Each transceiver covers
a certain site area. The switch establishes audio communications
between different sites and various dispatcher consoles. The
multisite switch has a distributed architecture in which each node
of the switch is supported by a microprocessor controlled card.
Each node interfaces with a site, dispatcher console, system
manager or other system component.
Inventors: |
Teel; James L. (Goode, VA),
Gulliford; Philip C. (Forest, VA), Brame; Charles P.
(Forest, VA), Imron; Wim A. (Forest, VA) |
Assignee: |
Ericsson GE Mobile Communications
Inc. (Lynchburg, VA)
|
Family
ID: |
46247656 |
Appl.
No.: |
07/658,844 |
Filed: |
February 22, 1991 |
Related U.S. Patent Documents
|
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
Issue Date |
|
|
573977 |
Aug 28, 1990 |
|
|
|
|
Current U.S.
Class: |
370/312;
370/341 |
Current CPC
Class: |
H04W
84/08 (20130101); H04W 4/10 (20130101); H04W
76/45 (20180201) |
Current International
Class: |
H04Q
7/28 (20060101); H04J 003/16 (); H04Q 011/08 () |
Field of
Search: |
;370/67,85.1,85.9,85.7,85.11,94.1,95.1,95.3 ;455/56.1,33.1,33.4
;379/58,59,63 |
References Cited
[Referenced By]
U.S. Patent Documents
Foreign Patent Documents
|
|
|
|
|
|
|
2075799A |
|
Nov 1981 |
|
GB |
|
WO91/16797 |
|
Oct 1991 |
|
WO |
|
Other References
Motorola CENTRACOM Series II Control Center Systems, Field
Maintenance Manual, Jun. 5, 1985..
|
Primary Examiner: Marcelo; Melvin
Attorney, Agent or Firm: Nixon & Vanderhye
Parent Case Text
RELATED APPLICATIONS
This application is a continuation-in-part of application Ser. No.
07/573,977, entitled "Distributed Multisite Coordination System"
filed on Aug. 28, 1990, in the name of James L. Teel, Jr., now
abandoned.
This application is related to the following copending commonly
assigned U.S. patent applications.
Application Ser. No. 07/532,164, filed Jun. 5, 1990, entitled
"Fail-Soft Architecture for Public Trunking System", now U.S. Pat.
No. 5,175,866.
Application Ser. No. 07/658,843, filed Feb. 22, 1991, entitled
"Dynamic Address Allocation Within RF Trunking Multisite Switch",
now U.S. Pat. No. 5,276,442.
Application Ser. No. 07/658,640, filed Feb. 22, 1991, entitled
Message "Bus Slot Update/Idle Control In RF Trunking Multisite
Switch", now U.S. Pat. No. 5,253,253.
Application Ser. No. 07/658,798 filed Feb. 22, 1991, entitled
"Controller Architecture" for RF Trunking Distributed Multisite
Switch, now U.S. Pat. No. 5,239,538.
Application Ser. No. 07/658,637, filed Feb. 22, 1991, entitled
"Protocol Between Console and RF Trunking Switch", now U.S. Pat.
No. 5,200,954.
Application Ser. No. 07/658,636, filed Feb. 22, 1991, entitled
"Audio Routing With A Trunked Radio Frequency Multisite
Switch".
The disclosure of each of these related copending applications is
incorporated by reference.
Claims
What is claimed is:
1. A local area network for a radio frequency multicasting system
including a multisite switch comprising:
a first microprocessor controlled node coupled through a first data
link and to a first trunked audio link to a first transmitter;
a second microprocessor controlled node coupled through a second
data link and to a second trunked audio link to a second
transmitter, where said second transmitter is in a separate site
than is said first transmitter;
an audio bus including a plurality of slots conveying audio
communications between said transmitters, said audio bus being
operatively connected to the first and second microprocessor
controlled nodes, said nodes controlling slot assignments for said
communications.
2. A local area network as in claim 1 further comprising a third
microprocessor controlled node coupled to a dispatcher console
through a third data link and a third trunked audio link.
3. A local area network as in claim 2 wherein said microprocessor
controlled nodes are structurally substantially identical.
4. A local area network as in claim 3 wherein said microprocessor
controlled nodes are structurally interchangeable.
5. A local area network as in claim 1 wherein said first and second
nodes have a dynamic addressing means for assigning unique
addresses to said nodes by each node selecting its own unique
address.
6. A local area network for a radio frequency multicasting system
including a multisite switch comprising:
a first microprocessor controlled node coupled through a first data
link and to a first trunked audio link to a first transmitter;
a second microprocessor controlled node coupled through a second
data link and to a second trunked audio link to a second
transmitter, where said second transmitter is in a separate site
than is said first transmitter;
an audio bus operatively connected to the first and second
microprocessor controlled nodes, said bus including a plurality of
slots conveying audio communications between said transmitters,
said nodes controlling slot assignments for said communications;
and
a message bus operatively coupled to said first and second nodes,
said nodes repeatedly sending status messages on the message bus
slot,
whereby said nodes maintain a bus/slot bit map representative of
the status of each audio slot and a redundant message discard means
for discarding slot status messages redundant to a previously
received slot status message.
7. A local area network for a radio frequency multicasting system
providing communications between mobile user units and groups of
user units, said system including a multisite switch
comprising:
a first microprocessor controlled node coupled through a first data
link and to a first trunked audio link to a first transmitter;
a second microprocessor controlled node coupled through a second
data link and to a second trunked audio link to a second
transmitter, where said second transmitter is in a separate site
than is said first transmitter;
an audio bus operatively connected to the first and second
microprocessor controlled nodes, said bus including a plurality of
slots conveying audio communications between said transmitters,
said nodes controlling slot assignments for said communications and
the microprocessor controlled nodes include databases for unit and
group counts,
said unit and group counts are indicative of mobile user units and
user units assigned to a particular group in a broadcast area for a
transmitter coupled to a respective node.
8. In a radio frequency multicasting system of the type having a
central switch controlled by a local area network of nodes each
having one or more microprocessor supported audio cards connected
to a slotted audio bus within the switch, a controller card coupled
to said audio cards and to a message bus within said switch, and
plurality of radio frequency site controllers each coupled to an
individual switch node, a method of establishing audio
communications between said site controllers and through said
switch comprising the steps of:
receiving a channel assignment at a first node of the switch from a
first site controller;
generating an audio slot assignment message in said first node and
placing the slot assignment message on the message bus;
upon receipt of the slot assignment message from the bus, a second
node sending a channel request to a second site controller
operatively coupled to said second node;
sending a second channel assignment to the second node from the
second site controller and
sending audio signals from the first site controller to the second
site controller over the assigned audio slot on the switch.
9. A local area network for a radio frequency multicasting system
including a multisite switch comprising:
a first microprocessor controlled node coupled through a first data
link and to a first trunked audio link to a first transmitter;
a second microprocessor controlled node coupled through a second
data link and to a second trunked audio link to a second
transmitter, where said second transmitter is in a separate site
than is said first transmitter;
an audio bus operatively coupled to the first and second
microprocessor controlled nodes, said bus including a plurality of
slots conveying audio communications between said transmitters,
said nodes controlling slot assignments for said communications and
said nodes store databases of user groups, wherein each of said
user groups identifying individual units in said system assigned to
each group.
10. A local area network for a radio frequency multicasting system
including a multisite switch comprising:
a first microprocessor controlled node coupled through a first data
link and to a first trunked audio link to a first transmitter;
a second microprocessor controlled node coupled through a second
data link and to a second trunked audio link to a second
transmitter, where said second transmitter is in a separate site
than is said first transmitter;
an audio bus operatively coupled to the first and second
microprocessor controlled nodes, said bus including a plurality of
slots conveying audio communications between said transmitters,
said nodes controlling slot assignments for said communications and
said nodes store databases identifying mobile units within the area
covered by the transmitter coupled to the respective node.
11. A local area network for a radio frequency multicasting system
including a multisite switch comprising:
a first processor controlled node coupled through a first data link
and to a first trunked audio link to a first transmitter;
a second processor controlled node coupled through a second data
link and to a second trunked audio link to a second transmitter,
where said second transmitter is in a separate site than is said
first transmitter;
an audio bus operatively coupled to the first and second processor
controlled nodes, said bus including a plurality of slots conveying
audio communications between said transmitters, said nodes
controlling slot assignments for said communications.
Description
FIELD OF THE INVENTION
This invention relates to radio frequency (RF) signal transmission
systems. In particular, the invention relates to a distributed
network of trunked radio transmission systems in which command and
audio signals from one system are switched through a distributed
network to another transmission system.
BACKGROUND AND SUMMARY OF THE INVENTION
Multiple-site RF transmission systems broadcast signals from more
than one base station. This allows radio communications to cover a
larger area than is possible with a single base station.
The present invention relates to a network of several single site
trunked radio systems. An example of a single site transceiver
system is disclosed in commonly-assigned U.S. Pat. No. 4,905,302,
entitled "Trunked Radio Repeater System" and U.S. Pat. No.
4,903,321 entitled "Radio Trunking Fault Detection System" which
are incorporated by reference. Digital trunked radio transceivers
capable of handling communications between numerous mobile units
and dispatcher consoles in a single area are known.
It is generally impractical for a single VHF/UHF RF repeater
transmitting site to effectively serve a large geographical area.
The broadcast area of a single site is limited by several factors.
The effective radiated power of the antenna is subject to legal and
practical limits. In addition, natural and man-made topographical
features, such as mountains and buildings, block signals from
certain locations.
Multiple transmitting sites are necessary to provide RF
communications to all locations within a given locality. Multiple
transmitters may be needed to cover a rural community covering many
square miles or a city having many buildings. FIG. 1 is a schematic
diagram of a simplified multiple-site system having three radio
repeater (transmitting) central sites S1, S2, and S3 providing
communications to geographic areas A1, A2, and A3, respectively.
Mobile or portable transceivers within area A1 receive signals
transmitted by site S1, transceivers within area A2 receive signals
transmitted by site S2, and transceivers within area A3 receive
signals transmitted by site S3. Each site has a site controller
that acts as a central point for communications in the site. To
enable communications from one area to another, a switch networks
the radio systems together to establish audio slots connecting one
site controller to another. Thus, a caller in one area can
communicate with someone in another area.
One known method to link several individual trunked systems is
simulcasting. Simulcast systems broadcast the same signal at the
same time from several base stations. A receiver in area A2 can
listen to a signal that originated in area A1 because all of the
site transceivers, including at S2, broadcast the same signal.
There are difficulties when signals are broadcast simultaneously
from several overlapping transceivers. In the areas where the
signals overlap, signals from different transmitters interfere to
create null regions and signals combine to generate undesirable
audible signals which are received by the callee. Despite these
problems, successful simulcast systems are operational and have
overcome the problems inherent with simultaneous signal
transmission. However, the present invention does not employ
simulcast.
The present invention is directed to a multisite RF trunked
repeater system. As with simulcast, mulitsite allows a caller in
one area (e.g. A1) to communicate with a callee in another area
(e.g. A2). Unlike simulcast, multicast does not broadcast signals
simultaneously from several transmitters on a single channel into
all areas. Multicast broadcasts signals only into those areas where
the intended callee(s) is located. Moreover, in a multicast
network, each site assigns a specific channel to a call
independently of the channel assignments made by other sites. Thus,
a single call may be broadcast from several site transmitters each
operating on a different frequency.
In multisite, the site controller (S1) receives a call from a
mobile radio in A1 requesting a channel to communicate with a
specific callee. A caller requests a channel simply by pressing the
push-to-talk (PTT) button on his microphone. This informs the site
controller that a channel is requested. The PTT signal is
transmitted to the unit on a control channel that is continuously
monitored by the site controller. The site controller assigns a
channel to the call and instructs the caller's radio unit to switch
from the control channel to the channel assigned to the call. This
assigned channel is applicable only within the area covered by the
site.
In addition, the site controller sends the channel assignment to
the multisite network switch. The switch assigns an internal audio
slot to the call. The switch also sends a channel request to all
other site controllers or to only those site controllers having a
designated callee within their area. Upon receiving a channel
request, these secondary site controllers assign a channel to the
call. Again, each secondary channel is operative only in the area
covered by the secondary site controller. The secondary site
controller(s) also sends the channel assignment back up to the
multisite switch. The caller can then communicate with a unit or
group in an other area via the multisite switch. The call is
initially transmitted to the primary site controller, routed
through the assigned audio slot in the switch and retransmitted by
the secondary sites on various assigned channels in those other
areas.
When the caller ends the call, the primary site controller
deactivates the assigned channel for that site and notifies the
network switch that the call is terminated. There may be a brief
"hang time" after the end of the call during which the channel
remains assigned. During this hang time, the call can be rekeyed
without going through the channel assignment procedure.
When the call is dropped, the network switch sends an end of call
command to the secondary site controllers. A call is terminated in
a similar format and operation as the slot assignment. Instead of
establishing an audio route between sites and through the switch,
the end of call command causes the assigned channels to be
released.
In addition to providing communications between mobile radio units
in different areas, the multisite network switch provides
communications between dispatchers and mobile radio units. The
dispatcher consoles are connected to the network switch in the same
manner as are the site controllers. A dispatcher console can issue
a channel call request through the network switch to a site
controller in another area to call a mobile unit or to another
dispatcher console to call a dispatcher in another area.
In addition to all of the features that the mobile units have, each
dispatcher console has the ability to participate in any call in
its area or to its assigned groups. Thus, when a call comes through
the network switch from another area to a mobile radio, the network
switch informs the dispatcher console of the call in addition to
notifying the site controller. The dispatcher can listen in or
participate in the call to the mobile radio.
The network switch is also capable of handling calls to groups of
mobile units and/or dispatcher consoles. The wide area switch
manages group calls and monitors the network to ensure that the
site controllers for all of the callees in the group assign a
channel to the group call. If a channel is not assigned, the wide
area switch advises the caller that the wide area call cannot be
formed as requested. The caller then has the option of re-keying
the call so as to reach those areas having assigned channels.
The multisite switch maintains site and track masks in its
databases to identify and locate each unit and group in the entire
radio system covered by the multisite switch. A site mask is
maintained for each radio unit in the system and each group of
units. A track mask is also maintained for each user and group in
the system. The site masks are static and are stored in a system
manager for the system. The site mask must be uploaded from the
system manager to appropriate nodes in the switch when a call is
initially placed. The track mask is dynamic and is continuously
updated by log-ins and call activity from the units in the various
sites.
In the preferred embodiment, each mask is a 16-bit field. Each bit
corresponds to a particular site. A one (1) bit signifies that this
site should be involved in calls to the group or individual
associated with the mask. A group can have multiple bits set in its
site and track masks because there may be group members spread over
several sites. An individual may have multiple bits set in his site
mask but only one bit set in his track mask. An individual can be
in only one site at a time. Accordingly, the track mask should only
have one bit set at a time. By use of these masks, the multisite
switch can determine which sites should participate in a call and
which sites have certain units and group members. Using this
information, the switch can route audio to the appropriate
sites.
There are many advantages that multisite has over simulcast.
Multisite avoids the difficulties associated with transmitting
simultaneously several RF signals on the same channel. The
complicated RF electronics and timing circuitry needed to overcome
the problems that arise from overlapping signals that are required
for simulcast are not needed in a multisite system. Multisite
avoids the problems of overlapping signals by having each area
assign a different channel for any one call. Moreover, there is no
need for simultaneous calls in multisite as there is in simulcast.
Furthermore, multisite signals need be broadcast only in those
areas having a party participating in the call. Whereas, simulcast
broadcasts calls over all areas regardless of whether there is
anyone listing to the call in every area.
The present invention relates to a multisite switch having a
distributed architecture. The logical functions of the switch are
shared by various microprocessor operated nodes distributed
throughout the switch. The nodes share the computational workload
of the switch. Each node is connected to a site controller,
dispatcher console, the system manager or other component of the
overall radio system. The nodes coupled to site controllers are
referred to as Master II Interface Modules (MIMs) and the nodes
coupled to dispatcher consoles are referred to as Console Interface
Modules (CIMs).
Each node of a multisite network switch is supported by a switch
controller card operated by microprocessors. All of the cards have
substantially the same hardware and are interchangeable. The MIM
and CIM cards have identical hardware. There is one card for each
site controller and each dispatcher console coupled to the switch.
Each card acts as a gateway into the network for its site
controller or dispatcher console.
The multisite switch does not completely fail if one card breaks
down. Wide area communications, i.e. calls between site areas,
continue despite the failure of a node. If a card fails, then the
gateway to the network is closed only for its site controller or
dispatcher console. Failure of a node prevents wide area
communications only with respect to the site or console connected
to the failed node. Mobile units in the area serviced by the failed
card will not be able to call a unit in another area or receive
calls from another area.
Local communications within an area are not disabled by the failure
in the multisite switch. A site controller is not disabled by a
failure of its associated node in the multisite switch. In
particular, the failure of a MIM does not disable the site
controller to which the MIM is connected. The site controller
continues to operate and local communications within the area are
unaffected by a failure in the multisite switch.
The ability to continue wide area calls after a node in the switch
has failed provides several advantages to a distributed
architecture switch over a central architecture switch. In a
central architecture, a central processing unit (CPU) governs the
operation of the switch. If this CPU fails, then the entire switch
fails. Wide area communications are completely shut down by the
failure of a multisite switch having a central architecture. As
already stated, wide area communications are not completely shut
down by a failure in a switch having a distributed
architecture.
Distributed network multisite systems have a much faster data
transfer rate than comparable central architecture multisite
systems. Central computers process information serially. All
communications passing through the switch must be serially
processed by the central computer. The central computer slows
communications because of its serial operation. Distributed network
systems achieve parallel processing by sharing the computational
task between several processors. Distributed networks are generally
significantly faster than central computers.
Distributed network multisite systems are generally less expensive
than multisite systems having a central computer. The hardware
needed for a distributed network is a series of microprocessor
controlled cards that handle communications between the multisite
switch and the site central controllers, dispatcher consoles and
various other users of the network. The cost of a series of cards
is typically much less than that of a central computer. Moreover, a
distributed network switch can be expanded simply by adding cards.
To expand the capacity of a central computer requires purchasing a
larger central computer.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an illustration of three site radio system networked
together by a multisite switch;
FIG. 2 is a schematic of the architecture for a distributed network
multisite;
FIG. 3 is a block diagram of the switch controller card;
FIG. 4 is a message flow diagram for a primary radio push-to-talk
(PTT) signal;
FIG. 5 is a flow chart for a primary radio PTT from a primary
site;
FIG. 6 is a flow diagram for messages issued by the MOM in response
to a primary radio PTT;
FIG. 7 is a flow chart for the MOM when receiving a primary radio
PTT;
FIG. 8 is a message flow diagram showing a secondary site capturing
a channel request from a primary site;
FIG. 9 is a flow chart showing a secondary site capturing a channel
request from a primary site;
FIG. 10 is a flow chart showing the additional steps followed in
capturing a channel request with confirmation;
FIG. 11 is a flow chart that continues from FIG. 5 and shows
processing steps for confirmation of calls;
FIG. 12 is a message diagram of a primary radio unkeying/dropping a
call;
FIG. 13 is a flow chart of the primary radio unkeying/dropping a
call;
FIG. 14 is a message diagram showing a secondary site receiving an
unkey and/or message drop signal;
FIG. 15 is a flow chart showing a secondary site receiving an
unkey/message drop signal;
FIG. 16 is a message diagram showing a secondary site releasing a
channel;
FIG. 17 is flow chart showing a secondary site releasing a
channel;
FIG. 18 is a flow chart showing a confirmed call override by a
primary site; and
FIG. 19 is a flow chart showing radio login message processing by
primary and secondary sites.
DETAILED DESCRIPTION OF THE DRAWINGS
An exemplary trunked radio repeater system in accordance with the
invention is generally depicted in FIG. 1. Individual remote units
communicate with each other through shared radio repeaters that are
part of the trunked repeater system 100. The system is composed of
several sites 102. Each site includes a site transceiver that
broadcasts signals over a certain area and a site controller. For
example, site S1 broadcasts over area A1. The remote units can
communicate with units within their own area or with units in other
areas. The remote units also communicate with the dispatcher
console for each site.
Each site is controlled by a site controller. The site controller
controls much of the data and audio traffic in its area. The site
controller is described in more detail in the application and
patents previously mentioned. For purposes here, the site
controller communicates with the multisite switch 200. The
multisite switch handles communications between sites.
Communications between sites are conducted through the multisite
switch 200 shown in FIG. 2. The multisite switch communicates with
each of the site controllers 201 in every site and the dispatcher
consoles 202. There are both data and audio communication lines
between the multisite switch and each site controller and
dispatcher console.
The primary responsibility of the multisite switch is to establish
and remove audio connections among the audio channels connected to
it. The multisite switch comprises a local area network of nodes.
As shown in FIG. 2, the nodes are labelled corresponding to whether
they interface with a site controller, dispatcher console or other
system component. For example, MIMs 203 are nodes in the switch
that interface with site controllers and CIMs 204 are nodes that
interface with dispatcher consoles. There are other nodes such as a
Monitor Module (MOM) 205, a Recorder Interface Module (RIM) 206,
Conventional Interface Module (CVIM) 207 and Switch Interconnect
Module (SWIM) 208.
The MOM 205 is the interface for the system manager and the MOM PC
(personal computer). The system manager updates the databases in
all of the nodes. The MOM maintains certain centralized databases
including databases for smart calls and confirmed calls. Smart
calls relate to the operation of the dispatcher console. A call is
"smart" if the call has been selected, i.e., being listened to by
the dispatcher via a select speaker in the console. If the call is
not selected by at least one console, then a flashing indicator
light appears on certain consoles. Thus, several dispatchers can
readily see which calls are not being monitored by at least one
dispatcher.
A confirmed call is one for which the audio channel and slot
assignments must be confirmed before the caller begins talking. The
system manager sets which calls are to be confirmed and provides
this information to the site controllers. The channel assignment
for the originating call from the primary site controller instructs
the multisite switch that the call is to be confirmed. The MOM
receives a message that a confirmed call is requested and then
tells the primary MIM which secondary MIMs must confirm the call by
sending a site mask to the primary MIM. The site mask identifies
each secondary MIM to participate in the confirmed call.
The RIM 206 interfaces recorders to the switch. Recorders are
assigned to record calls for various groups or units. The CVIM 207
functions much the same as a MIM but is indirectly coupled to
telephone lines and standard base stations whereas the MIMs are
coupled to site controllers for digital trunked radio systems. The
conventional interface adapter (CIA) 212 is merely an interface
between the CVIM and the telephone lines and base stations.
Similarly, the SWIM interfaces the switch with telephone lines.
Each node in the multisite switch is supported by a microprocessor
controlled communications card. All of the cards for the MIMs,
CIMs, CVIM, MOM, RIM and SWIM have the same hardware and are
interchangeable. The cards are said to have different personalities
to indicate that they are assigned to, for example, a site
controller or a dispatcher console (dispatch position). Each card
can be easily configured to be a MIM, CIM, etc., by setting a few
switches on the card. Thus, the cards are truly
interchangeable.
The nodes of the switch are each connected to a digital message bus
209 and a digital audio bus 210. The message bus 209 is shown in
FIG. 2 as a message network using an Intel 80C152 Global Serial
Channel (GSC) microprocessor. The message network is a high speed
data bus that resides in the GSC microprocessor.
The audio bus 210, in the present embodiment, comprises 32 time
division multiplexed buses. Each bus contains 32 slots that each
carry a single audio channel. A maximum of 1024 audio slots may be
routed through the switch (32 buses.times.32 slots). The audio
slots are assigned by the MOM to specific nodes, e.g., MIMs and
CIMs, when the switch is enabled.
As part of the switch start up procedure, the nodes connect their
assigned bus/slots to the node's external channel inputs. For
example, a MIM will couple each channel from the site controller to
a separate audio bus/slot. Once the bus/slot is linked to the
channel, the bus/slot receives the output from the channel through
the host node. Of course, the channel has no intelligible signal
until it is assigned to a call by the site controller. Although a
bus/slot is linked to a site channel for purposes of transmission,
no other node is listening to that bus/slot until the host node
sends a slot assignment message throughout the switch notifying the
other nodes that a call has been assigned to that bus/slot.
FIG. 3 shows a block diagram of one of the cards 300. This diagram
is applicable to all of the nodes of the switch except for the
conventional interface adapter (CIA). Thus, the hardware for the
MIM, CVIM, MOM, SMIM, RIM and CIM is a switch controller card. Each
card includes a communications controller 301, a dual port
random-access-memory (RAM) chip (302) and an interface processor
303.
The communications controller 301 is a message router. It routes
messages between the control message bus 209, the serial port
leading outside of the switch 304, the message bus and the
interface processor 303 through the dual port RAM 302. In the
present embodiment, the communications controller is an Intel
80C152 microprocessor. The communications controller is coupled to
the message bus 209. This controller places messages onto the bus
and receives messages from the message bus. Messages received from
the site controller over the serial port are translated into a
format usable by the multisite switch. The communications
controller also translates switch messages into a format that the
site controller understands.
The interface processor 303 performs substantially all of the
logical functions for the card. In effect, the interface processor
is the intelligence for the card. The interface processor, in this
embodiment, is an Intel 80C186 microprocessor. The interface
processor acts as a switch for the audio network and assigns slots
to active audio channels through the parallel audio control port
306.
Each call through the switch is patched to a slot on the audio bus.
When the call is terminated, the call is terminated and the slot is
made available for assignment to another call. The interface
processor for each MIM assigns slots, connects audio slots to the
site controller or dispatcher console to establish a communications
link, and terminates calls. Since all MIMs and CIMs perform these
functions, they must continually inform each other and the other
nodes of their slot assignments. Accordingly, the MIMs and CIMs
send messages regarding slot assignments, slot updates and slot
idles over the message network 209 to other nodes.
The communications controller 301 for each node initially processes
all of the messages on the message network. Slot assignments are
forwarded to the interface processor through the dual port RAM.
Redundant slot update/slot idle messages are not forwarded to the
interface processor by its communications controller. Messages
regarding slot updates or idle slot control are processed by the
communications controller by referring to a bit map located in the
RAM storage 302. Update messages are sent periodically by a primary
MIM to confirm to the other nodes the active status of a slot. When
a primary MIM terminates a call it sends a slot idle message to the
other nodes. The primary MIM also periodically sends update idle
messages until the slot is reassigned to another call.
The slot bit map in the dual-port-RAM 302 identifies the status of
each audio slot on all 32 buses. The bit map is updated by slot
assignment messages, slot idle messages and slot updates that are
sent on the message bus. Slot assignment messages inform all nodes
of the bus and slot number hosting the call. A more complete
disclosure of the slot bit map and slot status messages is
contained in Application Ser. No. 07/658,640 entitled Message "Bus
Slot Update/Idle Control In RF Trunking Multisite Switch"
identified above.
The MIM is coupled to the site controller through a standard serial
land line (e.g. a telephone line). The MIM receives digital command
signals from the site controller through a down link line such as
is described in commonly assigned U.S. Pat. No. 4,835,731, entitled
"Processor-To-Processor Communications Protocol For A Public
Service Trunking System" and is incorporated by reference.
Each MIM maintains databases that identify the units within its
site and the groups that correspond to active calls. These
databases are set up by the system manager 211 and sent to all of
the switch nodes. The unit database identifies each unit in the
wide area system. For each MIM, some of the units will be in its
assigned site area and others will be outside of its area. The MIM
keeps track of which units are in its area.
TABLE A shows the format of each unit database entry. Each entry is
three bytes long in the present embodiment.
TABLE A ______________________________________ UNIT DATABASE
______________________________________ Wide Area/Track/Force/"on
this site" Bits Current Group
______________________________________
The wide area bit is set to designate that the unit is to
participate in multisite and be capable of communicating from one
site to another via the multisite switch. The track bit designates
whether the unit is to be tracked by the multisite switch as the
unit moves from one site to another. Tracking is discussed in
greater detail with respect to the login procedure. When the force
bit is set for a unit on a particular site, then that site's MIM
will assign a channel to broadcast from this unit. If the force bit
is not set, then a channel will be assigned to a call from the unit
only if there is a callee in the MIM's area. Accordingly, if a
receiving MIM sees that there are no callees in its area, then the
MIM will not request a channel for the call. The "on this site"
bits indicate whether the unit is in the area covered by the site.
Finally, the current group bits identify the group currently
selected by the unit.
Each unit may be capable of participating in several different
groups and the unit operator selects the desired group at any
particular time. Whenever a call comes in for the selected group,
then the unit will receive the call.
The MIMs also maintain a database of the groups. A group is a
collection of units that communicate together on a single call. For
example, there may be a group for the fire department that allows
all of the fire trucks to listen to the central dispatcher or the
fire chief. The dispatcher dials this group into his console to
broadcast messages to all fire trucks. Similarly, groups can be
established of rescue stations, police units assigned to a
particular precinct, and many other combinations of users of the
public service radio system.
The format for each group on the MIM database is shown in TABLE
B.
TABLE B ______________________________________ GROUP DATABASE
______________________________________ Wide Area/Track/Force
______________________________________
There is one byte allocated for each group entry in the database.
The wide area bit designates whether the group is to participate in
multisite. Groups that are physically confined to one site need not
be able to participate in multisite and, thus, the wide area bit
will not be set for those groups. The track bit designates whether
members of the group being called are to be tracked from one site
area to another. The force bit determines whether calls for this
group are to be broadcast to a specific area regardless of where
the units are. If the force bit is not set, then a channel will be
assigned for group calls only in those areas having at least one
active group member.
The MIMs also maintain a group count database. The group count
database indicates the number of group members in the MIM's site
area. The system manager sets up a group count database for each
node. Each MIM records the number of group members in its area for
each group. Group members are counted when they enter or leave the
area and when they select a group.
As discussed below, when a unit enters a new area, a login message
is sent from its new site controller to the corresponding MIM
identifying the unit and its current group. The MIM receiving the
login signal through its serial port, i.e. from the site
controller, increments the count for the unit's group. Similarly,
when a unit leaves an area, the corresponding MIM logs the unit out
of its group count database by decrementing the count of the unit's
current group. In addition, when a unit changes groups, it sends a
group login message that causes the MIM for its area to increment
the count for the newly selected group and decrement the count of
the old group.
The unit databases are continually updated by each MIM. The
databases are also updated from time to time by the system manager
operator. The unit databases on each MIM contain the same
information with the exception of the "on this site" bits. These
bits are set only if the corresponding unit is in the area serviced
by the MIM and are, thus, unique to each MIM. With the exception of
the "on this site" bits, the unit databases are set by the system
manager.
The "on this site" bits in the unit are set and reset during the
login procedure followed by each radio unit as it moves from one
site area to another. Each site broadcasts a control channel
throughout the area covered by the site. Every radio unit in the
area is locked onto this control channel. When a unit leaves an
area and loses reception of the control channel, the radio scans
for another control channel. The scanner will lock onto the control
channel being broadcast in the area that the unit has moved into.
When the unit locks onto this other control channel, the unit
transmits a login signal to the site controller which in turn sends
the login signal to its MIM. The login identifies the unit and its
current group. The MIM receives the login signal and then switches
the "on this site" bits for the database entries for that unit. In
addition, the MIM places a signal on the message bus identifying
the unit that logged into that site. All of the other MIMs monitor
the message bus and check whether the message identifies a unit
previously in their areas. The one MIM that had the unit, reads the
login unit from the message bus and logs the unit out by resetting
the "on this site" bits for its unit entry in the unit
database.
There are several commands used by the multisite switch for
activating a call from a remote radio unit and from a dispatcher
console, for confirming receipt of the call request, and for
terminating the call. Message diagrams, flow charts and state
diagrams for these commands are presented in FIGS. 4 to 21.
The MIM communicates with the site controllers using the message
format and protocol of the site controller. Descriptions of the
commands employed by the site controller are contained in the
commonly assigned patents and co-pending applications referred to
elsewhere in this specification. In particular, U.S. Pat. No.
4,835,731, previously cited, sets forth many commands for a public
service trunking system.
As shown in FIG. 4, a MIM 401 receives a radio originated channel
assignment 403 from its corresponding site controller. This signal
indicates that a remote unit in the area assigned to the MIM wants
to call another unit or a group and its site controller has already
assigned a channel to the call for its area. All channel
assignments are sent to the multisite switch. The MIM assigned to
the caller is the primary MIM and all MIMs assigned to callees are
secondary MIMs. This channel assignment is received by the
communications controller 301 in the MIM as are all communications
from outside of the multisite switch.
The MIM responds to the radio originated channel assignment by
sending two messages on the message bus for the multisite switch. A
slot assignment message 405 is sent to all switch components
identifying the slot on the audio bus that is assigned to the call.
A group count message 406 is sent to the MOM only if the count
transitions from 0 to 1.
Upon receipt of the slot assignment message, each CIM 204 looks
through its database to determine if the callee is programmed at
the console. If the callee is programmed, the CIM informs its
corresponding dispatcher console of the call and connects the audio
slot for the call to the dispatcher console 202. Thus, the
dispatcher console can monitor all calls that involve groups or
units that have been programmed by the dispatcher.
As shown in the flow chart of FIG. 5, upon receipt of a radio
originated call from the site controller, step #501, the primary
MIM confirms that the channel number is valid in step #502. An
error condition is signaled if the number is not valid. If the
number is valid, then in step #503 the MIM tracks the unit making
the call by setting the "on this site" bit for the unit in its unit
database. In step #504 the MIM checks whether a group call is being
made. If the call is to a group, then the count for that group is
indexed to update the group count in step #505. If the count
transitions to or from zero, then the group count is sent to the
MOM in step #506. The MOM maintains a group count database that
indicates which nodes (MIMs and CIMs) correspond to active group
members. After handling the group count, the site channel database
is updated to reflect the new channel assignment in step #507. The
MIM keeps track of all slot assignments made by the MIM.
The MIM translates the channel assignment as sent by the site
controller into a slot assignment for use within the multisite
switch. In step #508, the slot assignment is broadcast to all other
switch components. The primary MIM logs the channel as active so
that it will be serviced by the MIM's background updating task. The
principal updating task is to send slot update messages to the
other nodes. If the call is a confirmed call, then the primary MIM
proceeds from step #509, to the steps discussed below with respect
to FIG. 11.
As shown in FIGS. 6 and 7, the MOM 205 sets up group calls and
informs CIMs of smart calls. The MOM tracks which calls have been
"selected" by a dispatcher console, and, thus, are being broadcast
over the console's select speaker. In step #701, the MOM receives
each slot assignment. If a call is "selected," then the MOM
notifies the CIMs that it is a smart call (601) in steps #702 and
#703. In step #704, the MOM checks whether the call is a group
confirmed call. If it is, then the MOM sends a confirmation site
mask to the primary MIM in step #705. The confirmation site mask
identifies each node that is to participate in the call and enables
the primary MIM to track receipt of all the confirmation messages
from the secondary MIMs.
Upon receipt of a group count 407 from a MIM, step #706, the MOM
first checks whether the group is forced on the MIM in step #707.
If the group is forced, then each MIM will automatically request a
channel for the group call and the MOM does not need to do
anything. If the group is not forced, then in step #708 the MOM
checks if the group count is zero and, if so, clears the group bit
for that site in step #709. If the count is zero, then there are no
units from the group in the area corresponding to the MIM and the
MOM clears the group's bit for that MIM in the confirmation site
mask stored in the MOM. If the group count is not equal to zero,
then the group bit is set for that MIM in step #710. The MOM
maintains this group count database for use with confirmed
calls.
As is shown in FIGS. 8 to 10, the secondary MIMs 801 receive to a
slot assignment 405 and a slot update from a primary MIM in step
#901. In step #902, each MIM checks its databases to determine
whether the callee is listed as being in its area. If the callee is
not in its area, then the node does nothing. If there is a callee
in its area, the MIM is designated as a secondary site. The MIM
sets the slot bit (or clears the bit if the slot assignment says
the channel is dropped or unkeyed) on the bit map maintained in the
RAM 302 to stop subsequent updates from being sent to the interface
processor 303 on the card, step #902. In step #904, secondary site
MIMs check whether the call is already logged in as being pending.
If so, then the MIM does nothing in response to the update or slot
assignment message. If the call is not logged in, then it is
determined active pending in step #905. Active pending status means
that the call is awaiting a channel assignment from the secondary
site.
In step #906 and 907, the secondary MIM generates a secondary
originated channel request (CR) and transmits it to its
corresponding site controller. The MIM marks the call as being "up"
on its site in step #908. When the site controller responds in step
1001 with a channel assignment (CA) by means of a secondary
originated channel assignment from the site, the secondary MIM
confirms in step #1002 that the channel assignment corresponds to
an active pending call. If there is no active pending call, then an
error condition is reported by the MIM.
Assuming the channel assignment matches a pending call, then the
secondary MIM checks that its channel summing capacity has not been
reached in step #1003. If the channel assignment would exceed
capacity, then an error condition is reported and the corresponding
call is removed from the active list in steps #1004 and #1005. If
the capacity has not been reached, then, in step #1006, the channel
assignment is added to the channel sum list maintained by the
secondary MIM. The MIM then routes the audio slot from the primary
MIM to the secondary site in step #1007. In addition, the MIM
notifies its site controller that the call is now active (step
#1008) and removes the call from the active pending list. If the
call requires confirmation, then the secondary MIM sends a
confirmation message via the message bus to the primary site in
step #1009 before removing the call from the active pending
list.
As shown in FIG. 11, the primary MIM receives confirmation messages
from the secondary MIMs for calls designated as confirmed calls in
step #1101. Before receiving these confirmation messages, the
primary MIM determines whether the call is to a group or to an
individual unit in step #1102. Group calls require the primary site
to receive a confirmation site mask from the MOM in step #1103. The
primary site stores the site mask in memory in step #1104, and
waits for confirmation messages from the secondary MIMs. Upon
receiving each secondary MIM's confirmation message, the primary
MIM checks whether the message is the last one to be received by
using the site mask in step #1105. For calls to an individual unit,
there will be only one confirmation message to be received. For
group calls, the number of confirmation messages to be received is
the number of secondary sites involved in the call. Upon receipt of
the last confirmation message, the primary MIM transmits to the
caller through the site controller that the call has been confirmed
by all callees in step #1106.
As shown in FIGS. 12 and 13, the caller terminates a call by
unkeying the PTT in his mobile radio. The site controller transmits
an unkey or drop signal 1201 to the primary MIM. A drop signal
terminates a call and causes the assigned audio slot to be idled.
Unkeying for many calls, such as transmission trunked calls, also
immediately generates a drop signal. For some calls, such as
message trunking, there is a brief "hang time" between an unkey
signal and a drop signal. The unkey signal by itself does not cause
the site controller to deactivate a channel or a MIM to idle a
slot. If there is a hang time between the unkey signal and drop
signal, then during the hang time the audio communication line
between the caller and callee(s) is maintained even though the
caller is not transmitting. If the caller rekeys the call during
this hang time, then he can immediately begin talking on the
existing communication line. If the hang time expires before the
call is rekeyed, then a drop signal is sent to terminate the
channel assignments and slots.
In step #1202, the primary MIM confirms that the unkeyed channel is
listed as being valid in its databases. Assuming that the channel
is valid, the primary MIM updates its site channel database to
verify the call termination. The primary MIM also sends an idle
slot assignment message 1204 to the other nodes of the multisite
switch informing them that the channel has been dropped.
Additionally, if the call was confirmed, then the primary MIM
removes the confirmed call signal from its site channel database in
step #1205. Upon receipt of the idle slot assignment from the
primary MIM, the CIMs notify their respective dispatcher consoles
of the call termination in step #1206.
As shown in FIGS. 14 and 15, when they receive a slot assignment
message indicating an unkey or channel drop, the MIM checks the bit
for that slot in the slot bit map in RAM 302 in step #1501. If the
bit indicates the slot is up, then in step #1502 the bit is reset
to indicate that the audio slot is idle. If the MIM had the call
logged into its site, step #1503, such as when a callee was in the
site, then this secondary MIM generates and transmits a secondary
originated unkey signal to its site controller in steps #1504 and
#1505. The secondary MIM checks whether the unit that unkeyed is
the last unit participating in the call in step #1510. If it is the
last unit, then the secondary MIM removes the call from its list of
active site channels.
As shown in FIGS. 16 and 17, a callee can release itself from a
call by sending a secondary originated unkey/drop signal 1601. Upon
receiving an unkey/drop signal from its site controller, a
secondary MIM checks if all of the units in its site participating
in the call have been released from the call. In steps #1602 and
#1603, the MIM checks whether the secondary unkey drop signal
corresponds to each of the summed entities on the MIM's channel sum
list and, if so, whether the callee is the last callee in the
summed entity list. When the last callee is released, then the
secondary MIM disengages its secondary site from the audio slot
assigned by the primary MIM in step #1603. The secondary MIM also
removes the callee from its channel sum list in step #1605. When
the sum count equals zero in step #1606, there are no more callees
assigned to the secondary MIM for that call. Accordingly, in step
1607, the secondary MIM signals the site controller to remove the
call from the active list for that site.
As is shown in FIG. 18, a caller making a confirmed call can
institute the call even if all of the callees do not respond with
confirmation of the call. Confirmed calls are those that require
confirmation from all of the callees before the call can be placed.
However, the callee may desire to make the call even if not all of
the callees respond to the call. Accordingly, the caller can
override the normal operation of the confirmed call by rekeying his
microphone. The rekeyed PTT signal will instruct the multisite
switch to route the call through even though not all of the callees
have confirmed that they are listening to the call.
In step #1801, the primary MIM receives the rekeyed PTT signaling
that the confirmed call is to be overridden. In step #1802, the MIM
returns a signal to its site controller acknowledging that the
confirmed call is being established, albeit without all of the
intended callees.
As shown in FIG. 19, the message sequence for the radio login is
the same for primary and secondary MIMs. As previously discussed, a
radio unit sends a login message to the site controller for the
area when it enters a new area. This login message is conveyed to
the MIM assigned to that new site in step #1901. In step #1902, the
MIM checks whether the login message came through the serial port
from the site controller or over the message bus from another MIM.
Upon receiving a login message from the site, i.e., through the
serial port of the communications controller in the switch
controller card, the MIM sends the login through the message bus to
all other MIMs in step #1903. In addition, the MIM updates its unit
and group databases to identify the new unit. The MIM also
increments its group count and unit databases in step #1904. If the
group count transitions from zero in step #1905, then the MOM is
notified that the MIM now has a unit assigned to the group.
The other MIMs that receive the login message from the message bus
of the switch, check whether the unit was logged into its site
area. The MIM that has the unit logged into its site deletes the
unit from its unit databases. In step #1906, the MIM also
decrements its group count for the group that the unit was
assigned. If the unit was the last unit from the group to leave
that site area, then the MIM notifies the MOM that the group count
is zero for its site in step #1905.
The following section contains the formats and contents of the
messages processed (transmitted and received) in the multisite
switch in the preferred embodiment. The two external links to the
multisite switch are to RF site controllers and to dispatcher
consoles.
The downlink from a site controller is a 19.2 Kbs/s asynchronous
serial link The link from a dispatcher console is normally a 19.2
Kbs/s serial link.
Console--CIM Message Interface
This section defines the message interface between the dispatcher
console and the console interface module (CIM) in the multisite
switch. These messages use a sliding window protocol and link
recovery techniques discussed below.
System Access
Operator Login
This message identifies the console operator to the switch.
______________________________________ Console sends : LOGIN (63) #
Bytes Field Function (1) message.sub.-- id LOGIN (1)
operator.sub.-- priority priority of console operator (2)
operator.sub.-- id id of console operator (1) privilege.sub.--
level privilege level of console operator (1=operator,
2=supervisor) Switch returns : CALL.sub.-- STAT (101) # Bytes Field
Function (1) message.sub.-- id CALL.sub.-- STAT (1) msg.sub.--
group LOGIN (1) msg.sub.-- sub.sub.-- group N/A (1)** call.sub.--
variant N/A (2) callee.id operator id (1) callee.type UNIT (3)
caller N/A (1) status 0 - Success (1) host console number Operator
Logout ______________________________________
This message informs the switch that the operator is logging off of
the console.
______________________________________ Console sends : LOGOFF (64)
# Bytes Field Function (1) message.sub.-- id LOGOFF Switch returns
: CALL.sub.-- STAT (101) # Bytes Field Function (1) message.sub.--
id CALL.sub.-- STAT (1) msg.sub.-- group LOGOFF (1) msg.sub.--
sub.sub.-- group N/A (1)** call.sub.-- variant N/A (3) callee N/A
(3) caller N/A (1) status 0 - Success (1) host N/A
______________________________________
Module Functions
Module Programming
These messages allow the dispatcher to program a module to an
entity (group, individual, conventional, phone line, etc.) selected
from a list of system entities.
______________________________________ Add Module Console sends :
ADD-MODULE (58) # Bytes Field Function (1) message.sub.-- id
ADD.sub.-- MODULE (2) callee.id id of entity programmed (1)
callee.type type of entity programmed (1) module.sub.-- volume
current module volume (1) channel audio channel number assigned to
module Switch returns : CALL.sub.-- STAT (101) # Bytes Field
Function (1) message.sub.-- id CALL.sub.-- STAT (1) msg.sub.--
group ADD.sub.-- MODULE (1) msg.sub.-- sub-group module volume
(1)** call.sub.-- variant Audio channel number (7 bits) assigned to
module from above ICom Active bit (3) callee from above (3) caller
N/A (1) status 0 - Success 1 - Error (1) host console number Delete
Module Console sends : DELETE.sub.-- MODULE (59) # Bytes Field
Function (1) message.sub.-- id DELETE.sub.-- MODULE (2) callee.id
id of entity programmed (1) callee.type type of entity programmed
Switch returns : CALL.sub.-- STAT (101) # Bytes Field Function (1)
message.sub.-- id CALL.sub.-- STAT (1) msg.sub.-- group
DELETE.sub.-- MODULE (1) msg.sub.-- sub.sub.-- group N/A (1)**
call.sub.-- variant N/A (3) callee from above (3) caller N/A (1)
status 0 - Success (1) host console number Modify Module Console
sends : MODIFY.sub.-- MODULE (62) # Bytes Field Function (1)
message.sub.-- id MODIFY.sub.-- MODULE (2) callee.sub.-- delete.id
id of entity to delete (1) callee.sub.-- delete.type type of entity
to delete (2) callee.sub.-- add.id id of entity to add (1)
callee.sub.-- add.type type of entity to add (1) module.sub.--
volume current module volume (1) channel audio channel number
assigned to module Switch returns : CALL.sub.-- STAT (101) # Bytes
Field Function (1) message.sub.-- id CALL.sub.-- STAT (1)
msg.sub.-- group MODIFY.sub.-- MODULE (1) msg.sub.-- sub.sub.--
group module volume (1)** call.sub.-- variant audio channel number
(7 bits) assigned to module from above ICom Active bit (3) callee
added callee (3) caller deleted callee (1) status 0 - Success 1 -
Error (1) host console number
______________________________________
Module Volume and Mute
This message provides volume/mute control of audio levels on the
channel assigned (select, unselect, etc.) to a programmed
entity.
__________________________________________________________________________
Console sends : MODULE.sub.-- VOLUME (61) MUTE.sub.-- MODULE (68) #
Bytes Field Function (1) message.sub.-- id MODULE.sub.--
VOLUME/MUTE.sub.-- MODULE (2) callee.id id of entity programmed (1)
callee.type type of entity programmed (1) module.sub.-- volume
current module volume Switch returns : CALL.sub.-- STAT (101) #
Bytes Field Function (1) message.sub.-- id CALL.sub.-- STAT (1)
msg.sub.-- group MODULE.sub.-- VOLUME/MUTE.sub.-- MODULE (1)
msg.sub.-- sub.sub.-- group module volume (1)** call.sub.-- variant
N/A (3) callee from above (3) caller N/A (1) status 0 - Success 1 -
Error (1) host console number
__________________________________________________________________________
Module Select/Unselect
This message causes audio for the programmed entity, e.g., mobile
unit or dispatcher, to be routed to the channel specified.
Currently, the message contains the select state of the entity, and
the switch infers the channel number.
______________________________________ Console sends :
SELECT.sub.-- MODULE (60) # Bytes Field Function (1) message.sub.--
id SELECT.sub.-- MODULE (2) callee.id id of entity programmed (1)
callee.type type of entity programmed (1) channel audio channel
number assigned to module Switch returns : CALL.sub.-- STAT (101) #
Bytes Field Function (1) message.sub.-- id CALL.sub.-- STAT (1)
msg.sub.-- group SELECT.sub.-- MODULE (1) msg.sub.-- sub.sub.--
group N/A (1)** call.sub.-- variant audio channel number assigned
to module from above (3) callee from above (3) caller N/A (1)
status 0 - Success 1 - Error (1) host console number
______________________________________
Transmit Functions
Module Transmit
This message allows the console dispatcher to transmit to any
entity that has been programmed into a module.
______________________________________ Console sends : MESSAGE
GROUP NUMBER (see Switch - Site Messages) # Bytes Field Function
(1) msg.sub.-- group message group number (1) msg.sub.-- sub.sub.--
group message sub.sub.-- group number (1)** call.sub.-- variant
call qualifier flags (2) callee.id id of entity programmed (1)
callee.type type of entity programmed (2) caller.id id of console
operator (1) caller.type UNIT (1) operator.sub.-- priority console
operator priority (1) node.sub.-- id CIM's node id in switch
(filled in by CIM) (4) site.sub.-- Mask site participating in call
(non Wide Area call only) Switch returns : CALL.sub.-- STAT (101) #
Bytes Field Function (1) message.sub.-- id CALL.sub.-- STAT (1)
msg.sub.-- group (A) from above (B) PREEMPT DIRECTIVE (C) from
table in switch-site messages (1) msg.sub.-- sub.sub.-- group (A/B)
from above (C) from table in switch site messages (1)** call.sub.--
variant call qualifier flags (3) callee from above (3) caller from
above (1) status (B/C) 0 - Success (A) 1 - Error (1) host (B/C)
site number (A) console number
______________________________________ NOTE : The switch returns
the same message format for both console originated an mobile
originated calls.
Module Unkey
This message terminates the operator's transmission to an
entity.
______________________________________ Console sends :
CONSOLE.sub.-- UNKEY (11) # Bytes Field Function (1) msg.sub.--
group CONSOLE.sub.-- UNKEY (1) msg.sub.-- sub.sub.-- group
UNKEY.sub.-- ID (1) (1)** call.sub.-- variant call qualifier flags
(2) callee.id id of entity programmed (1) callee.type type of
entity programmed (2) caller.id id of console operator (1)
caller.type UNIT (4) site-mask site participating in call (non Wide
Area call only) Switch returns : CALL.sub.-- STAT (101) # Bytes
Field Function (1) message.sub.-- id CALL.sub.-- STAT (1)
msg.sub.-- group from table in switch site messages (1) msg.sub.--
sub.sub.-- group from table in switch site messages (1)**
call.sub.-- variant call qualifier flags (3) callee from above (3)
caller from above (1) status 0 - Success (1) host console number
______________________________________
The switch returns the same message format for both console
originated and mobile originated calls.
Patch/Simulselect Activation
These messages allow the console dispatcher to activate a
simulselect or patch call. A simulselect allows the operator to
transmit simultaneously to up to 16 entities, while a patch allows
the operator to effectively combine up to 16 entities into a
temporary group.
Console sends: PATCH.sub.-- HEADER (103) or SIMUL.sub.-- HEADER
(104)
______________________________________ # Bytes Field Function (1)
message.sub.-- id PATCH.sub.-- HEADER or SIMUL.sub.-- HEADER (2)
said System Assigned Id (4) callee.sub.-- type.sub.-- cnt[ ] count
for each callee type involved (2) caller.id id of console operator
(1) caller.type UNIT (1) node.sub.-- id CIM's node id in switch
(filled in by CIM) (4) site.sub.-- mask sites to be involved
(filled in by MOM) Followed by : PATCH.sub.-- COLLECTION (107) or
SIMUL.sub.-- COLLECTION (108) # Bytes Field Fnction (1)
message.sub.-- id PATCH.sub.-- COLLECTION or SIMUL.sub.--
COLLECTION (2) said System Assigned Id (10) id.sub.-- list[5] list
of ids involved (4) site.sub.-- mask sites to be involved (filled
in by MOM) ______________________________________
until all ids are sent.
______________________________________ Followed by : PATCH.sub.--
ACTIVATE (111) or SIMUL.sub.-- ACTIVATE (113) # Bytes Field
Function ______________________________________ (1) message.sub.--
id PATCH.sub.-- ACTIVATE or SIMUL.sub.-- ACTIVATE (2) said System
Assigned Id (4) site.sub.-- mask sites to be involved (filled in by
MOM) ______________________________________
Switch returns:
To all consoles on activation error: CALL.sub.-- STAT (101)
______________________________________ # Bytes Field Function
______________________________________ (1) message.sub.-- id
CALL.sub.-- STAT (1) msg.sub.-- group PATCH.sub.-- ACTIVATE or
SIMUL.sub.-- ACTIVATE (1) msg.sub.-- sub.sub.-- group N/A (1)**
call.sub.-- variant N/A (2) callee.id SAID from above (1)
callee.type GROUP (3) caller caller from above (1) status 1 - Error
(1) host site number ______________________________________
To all consoles on activation success:
______________________________________ PATCH.sub.-- ACTIVE (101) or
SIMUL.sub.-- ACTIVE (106) # Bytes Field Function
______________________________________ (1) message.sub.-- id
PATCH.sub.-- ACTIVE or SIMUL.sub.-- ACTIVE (2) said System Assigned
Id (4) callee.sub.-- type.sub.-- cnt[ ] count for each callee type
involved (2) caller.id id of console operator (1) caller.type UNIT
(1) node.sub.-- id initiating CIM's node id in switch (4)
site.sub.-- mask sites involved (filled in by MOM)
______________________________________
Followed by:
______________________________________ PATCH.sub.-- COLLECTED (109)
or SIMUL.sub.-- COLLECTED (110) # Bytes Field Function
______________________________________ (1) message.sub.-- id
PATCH.sub.-- COLLECTED or SIMUL.sub.-- COLLECTED (2) said System
Assigned Id (10) id.sub.-- list[5] list of ids involved (4)
site.sub.-- mask sites involved (filled in by MOM)
______________________________________
until all ids are sent.
Patch/Simulselect Removal
This message allows the console dispatcher to terminate an active
patch or simulselect.
______________________________________ Console sends : PATCH.sub.--
DEACTIVATE (112) or SIMUL.sub.-- DEACTIVATE (114) # Bytes Field
Function ______________________________________ (1) message.sub.--
id PATCH.sub.-- DEACTIVATE or SIMUL.sub.-- DEACTIVATE (2) said SAID
of Active Patch or Simulselect (4) site.sub.-- mask sites involved
(filled in by MOM) ______________________________________
Switch returns: To all consoles on removal success:
______________________________________ PATCH.sub.-- INACTIVE (115)
or SIMUL.sub.-- INACTIVE (116) # Bytes Field Function
______________________________________ (1) message.sub.-- id
PATCH.sub.-- INACTIVE or SIMUL.sub.-- INACTIVE (2) said System
Assigned Id (4) site.sub.-- mask sites involved (filled in by MOM)
______________________________________
Miscellaneous Functions
Console Cross Mute
This message allows the console dispatcher to mute/unmute another
console's transmit audio to prevent audio feedback.
______________________________________ Console sends : CROSS.sub.--
MUTE (67) # Bytes Field Function (1) message.sub.-- id CROSS.sub.--
MUTE (1) console.sub.-- number CIM number of console affected (1)
state 0 - uncross mute 1 - cross mute Switch returns : CALL.sub.--
STAT (101) # Bytes Field Function (1) message.sub.-- id CALL.sub.--
STAT (1) msg.sub.-- group CROSS.sub.-- MUTE (1) msg.sub.--
sub.sub.-- group N/A (1)** call.sub.-- variant state (2) callee.id
console number (1) callee.type N/A (3) caller N/A (1) status 0 -
Success 1 - Error (1) host console number
______________________________________
Console All Mute
This message allows the console dispatcher to mute/unmute all
unselect audio.
______________________________________ Console sends : ALL.sub.--
MUTE (57) # Bytes Field Function (1) message.sub.-- id ALL.sub.--
MUTE (1) all.sub.-- mute.sub.-- volume All Mute volume level (1)
state 0 - inactive All Mute 1 - active All Mute Switch returns :
CALL.sub.-- STAT (101) # Bytes Field Function (1) message.sub.-- id
CALL.sub.-- STAT (1) msg.sub.-- group ALL.sub.-- MUTE (1)
msg.sub.-- sub.sub.-- group N/A (1)** call.sub.-- variant state (3)
callee N/A (3) caller N/A (1) status 0 - Success (1) host console
number ______________________________________
Console Intercom
This message allows the console dispatcher to communicate with
another.
______________________________________ Console sends : ICOM.sub.--
INITIATE (69) initiate ICom connection ICOM.sub.-- ACTIVE (70)
active ICom connection ICOM.sub.-- BUSY (71) busy console
ICOM.sub.-- RELEASE (72) release ICom connection ICOM.sub.-- HOLD
(73) (un)hold ICom connection ICOM.sub.-- TX (74) transmit to
console ICOM.sub.-- UNKEY (75) terminate transmission to console #
Bytes Field Function (1) message.sub.-- id from above (2)
source.sub.-- operator id operator id of sending console (2)
target.sub.-- operator id operator id of receiving console (1)
state 0 - unhold ICom 1 - hold ICom applicable to ICOM.sub.-- HOLD
only (2) bus.sub.-- slot bus slot for audio con applicable to
ICOM.sub.-- TX and ICOM.sub.-- UNKEY only filled in by CIM Switch
returns : CALL.sub.-- STAT (101) # Bytes Field Function (1)
message.sub.-- id CALL.sub.-- STAT (1) msg.sub.-- group from above
(1) msg.sub.-- sub.sub.-- group N/A (1)** call.sub.-- variant state
(ICOM.sub.-- HOLD only) N/A otherwise (2) callee.id target operator
id (1) callee.type UNIT (2) caller.id source operator id (1)
caller.type UNIT (1) status 0 - Success 1 - Error (1) host console
number ______________________________________
Console--CIM Link Protocol
The data link protocol between the console and CIM utilizes a
sliding window technique. The implementation of the sliding window
uses a 4-bit window value, which implies that the maximum number of
outstanding data messages at any one time (receiver or transmitter)
can be 16. The Tanenbaum's Computer Networks, pages 148-164,
provides more information on the sliding window protocol.
The general message format is shown below.
______________________________________ SB Sync Byte (AA) MTNB
Message type/Number of bytes DMID Data Message identifier MSG :
Message bytes MSG S/A Sequence/ACK field (sending/receiving
sequence CC Checksum/CRC field
______________________________________
Sync Byte
This field identifies the start of a data frame.
Message Type/Number of Bytes
This field is used to indicate the type of the message and the
number of bytes in the message.
The message type field is located in the high order two bits of the
byte. The values of this field are listed below.
______________________________________ DATA Data ID 01 ACK
Acknowledgement 02 NAK Negative ACK 03
______________________________________
An ACK message is sent by the receiver when a message is correctly
received (i.e, the checksum/CRC is correct). A NAK message is sent
when the checksum/CRC is incorrect.
The number of bytes field comprise the remaining 6 bits of the
byte. This field includes the DMID, MSG * n, S/A and CC fields
described above.
Data Message Identifier
The data message id field is used to distinguish specific messages
for processing by the receiver. The message types and subtypes used
are listed in the CONSOLE--CIM MESSAGE INTERFACE section above.
Sequence/ACK Field
The sequence/ACK field is a single byte with the sequence and the
ACK numbers occupying 4 bits each. The sequence number is the
current packet number that is sent by the transmitter. The ACK
field is the last correct packet received. This field functions as
an acknowledgement for all packets up to and including the last
correct packet referenced in the ACK field. Thus, for flow control
the receiver may "freeze" the last correct packet number in the ACK
field so that the transmitter is held off from sending any further
messages until the receiver is ready.
The sequence/ACK field allows full duplex data transmission between
the Console and the CIM. The starting values for the sequence and
ACK fields are, SEQ=0, ACK=F (hex).
Checksum/CRC
This field is filled by the transmitter with a value such that the
sum of all bytes in the message (adding with carry, excluding the
sync byte and checksum), is equal to the checksum received. This
field could also be filled with a CRC code if necessary.
An example of the console-CIM link protocol follows.
Assume the following:
The transmitter is sending a data message with sequence
number=4,
The last received correct packet number=2, The message is a "poll"
from the Console to the CIM ##STR1## The CIM responds with and ACK:
##STR2##
Console--CIM Link Error Recovery
These messages are used by the console/CIM to determine the
integrity of the data link, and to reinitialize in the event of a
failure.
Serial Poll
Link failure detection on the Console-CIM link is performed by
periodic polling by both devices. The polls will be sent by the
Console or the CIM as shown below. ##STR3##
The serial poll message is listed below. If the link fails, then an
ACK in response to the POLL message from the Console or the CIM
will not be responded to. Five ACK timeout periods will be allowed.
An ACK timeout period will nominally be set to 100 milliseconds in
the preferred embodiment.
If after five such timeouts, the response to a poll is not
received, the console and/or the CIM will begin sending a link
reinitialize message (see SERIAL INIT MESSAGE).
______________________________________ Console/CIM sends :
SERIAL.sub.-- MSG (123) # Bytes Field Function (1) message.sub.--
id SERIAL.sub.-- MSG (1) message.sub.-- sub.sub.-- id SERIAL.sub.--
POLL CIM/Console returns : ACK Data Frame
______________________________________
Serial Init
If the console-CIM link is broken, a Serial Init Message is sent
upon link restoration. This message causes the sliding window
parameters in both devices to be set to starting values (SEQ=0,
ACK=F and timeouts cleared). All outstanding messages in the CIM
and the console will be cleared from their respective data buffers.
Thus, a link reinitialize will result in the loss of any
outstanding messages.
______________________________________ Console/CIM sends :
SERIAL.sub.-- MSG (123) # Bytes Field Function (1) message.sub.--
id SERIAL.sub.-- MSG (1) message.sub.-- sub.sub.-- id SERIAL.sub.--
INIT CIM/Console returns : ACK Data Frame
______________________________________
Switch Reset
In the event that the CIM goes through a reset during normal
operation of the Console-CIM link, it will send a reset message to
the dispatcher console. This message contains starting values for
the SEQ and ACK numbers, and thus, may be out of the expected
sequence at the console. However, the console will recognize the
message and will in turn send a link reinitialization message to
the CIM. This exchange will reset the protocol parameters in both
the devices to the starting value.
______________________________________ CIM sends: SERIAL.sub.-- MSG
(123) # Bytes Field Function (1) message.sub.-- id SERIAL.sub.--
MSG (1) message.sub.-- sub.sub.-- id SWITCH.sub.-- RESET.sub.-- MSG
Console returns : ACK Data Frame
______________________________________
Switch--Site Messages
Upon receipt of a message from the RF site controller, the
multisite switch's MIM connected to the site performs a translation
of the message into system primitives. These primitives are used
for call processing within the switch. Messages sent from the
switch to the site controller are retranslated from primitives into
a site recognizable format. The content of a system primitive
follows.
______________________________________ CHAN-PRIM (143) (contained
in message when sent on GSC only) # Bytes Field Function
______________________________________ (1) msg.sub.-- group message
group number (1) msg.sub.-- sub.sub.-- group message sub group
number (2) site.sub.-- channel site and channel in use Low byte =
site number High byte = channel number (3) callee entity receiving
call (1) call.sub.-- variant call qualifier flags (3) caller entity
initiating call ______________________________________
Outbound (to site controller) Messages
The following is a list of outbound switch-generated messages to
the site. The msg.sub.-- group and msg.sub.-- sub.sub.-- group
fields correspond to the same fields used in the various messages
defined above.
______________________________________ Msg Group Msg Sub Group Name
______________________________________ Call Requests 1 1 Group Call
2 Emergency Group Call 3 VG Group Call 4 Emergency VG Group Call 5
Cancel Emergency Special Calls 4 1 Clear Voice 2 Interconnect 3
Voice Guard 4 Voice Guard & Interconnect Individual Call
Responses 5 1 Acknowledge ICall Receipt 2 Answer ICall 3 Terminate
ICall Individual Call II Requests 6 1 Clear Voice 2 Voice Guard
Data Call Requests 7 1 Data Group Call 2 Data Individual Call
System All-Call Requests 8 1 Clear Voice 2 Voice Guard Individual
Call Requests 9 1 Clear Voice Forced Select 2 Clear Voice Optional
Select 3 Voice Guard Forced Select 4 Voice Guard Optional Select
Error Message Class 10 1 Group Setting Error 11 1 Console Unkey
Inbound (from site) Messages Call Assignments 21 1 Clear Voice
Group 2 Emergency Clear Voice Group 3 Voice Guard Group 4 Emergency
Voice Guard Group 5 Individual Call II Clear Voice 6 Individual
Call II Voice Guard Data Call Assignments 7 Data Individual Call 8
Data Group Call Special Call Assignments 9 Clear Voice Group 10
Interconnect Group 11 Voice Guard Group 12 Interconnect Voice Guard
Group 13 Clear Voice Individual 14 Interconnect Individual 15 Voice
Guard Individual 16 Interconnect Voice Guard Individual Individual
Call Assignments 17 Individual Call I Clear Voice 18 Individual
Call I Voice Guard System All-Call Assignments 19 Clear Voice
Message Trunked 20 Clear Voice Transmission Trunked 21 Clear Voice
Update Message Trunked 22 Clear Voice Update Transmission Trunked
23 Voice Guard Message Trunked 24 Voice Guard Transmission Trunked
25 Voice Guard Update Message Trunked 26 Voice Guard Update
Transmission Trunked 22 1 Channel Unkey 23 1 Channel Drop System
Message Class 24 1 System Assigned Id 2 Convert To Callee 3 Call
Queued 4 System Busy 5 Call Denied Status Request / Message
Acknowledge 25 1 Status Response 2 Inbound Message Acknowledge 3
Status Request 4 Radio Login
______________________________________
Switch Internal Messages
The multisite switch internal messages are described in the
following section. The messages are generated in response to
console or site controller originated actions. These messages are
sent from the source switch nodes to destination nodes via the GSC
message bus. Thus, all messages described in this section are
generated and processed within the multisite switch.
Slot Assignment/Update
A slot assignment message is broadcast to all nodes in the switch
by an originator node upon assignment or release of an audio bus
slot by that node. While the bus slot remains active, a slot update
message is broadcast at an interval based upon current message bus
loading. This serves to include latecomer nodes into a call that is
already in progress.
______________________________________ node sends: SLOT.sub.--
ASSGN (102) for call activation SLOT.sub.-- UPDATE (124) for active
call update # Bytes Field Function
______________________________________ (1) message.sub.-- id
SLOT.sub.-- ASSGN/SLOT.sub.-- UPDATE (2) bus.sub.-- slot Audio Bus
& Slot number Low byte = Bus number High byte = Slot number (1)
host entity that call is on (site #, console #, etc.) (1)
msg.sub.-- group Message group number (1) msg.sub.-- sub.sub.--
group Message sub group number (1) call.sub.-- variant call
qualifier flags (3) callee entity receiving the call (3) caller
entity initiating the call
______________________________________
The message group and sub group numbers refer to those listed in
SWITCH--SITE MESSAGES. The call qualifier flags in the call.sub.--
variant field are used on a per call basis to tag any special
features of the call. Thus, this field will vary with the type of
call initiated. The bus and slot numbers will indicate which of the
32 busses and 32 slots are to be accessed for the active/terminated
call's audio signal.
Slot Idle
Once a call on a bus slot has terminated, the originating node
broadcasts to all nodes a slot idle message. Like the slot update,
the broadcast interval is based upon current GSC loading. In the
event that a receiving node missed the initial release message
(slot assignment), the slot idle message enables the node to tear
down the call.
______________________________________ node sends: SLOT.sub.-- IDLE
(125) # Bytes Field Function ______________________________________
(1) message.sub.-- id SLOT.sub.-- IDLE (2) bus.sub.-- slot Audio
Bus & Slot number Low byte = Bus number High byte = Slot number
(1) host entity that call is on (site #, console #, etc.) (1)
msg.sub.-- group Message group number (1) msg.sub.-- sub.sub.--
group Message sub group number (1) call.sub.-- variant call
qualifier flags (3) callee entity receiving the call (3) caller
entity initiating the call
______________________________________
Call Status
This message is used to return an error condition to a requesting
CIM. The error conditions include: lack of priority to PTT; console
preempt; patch or simulselect denial at the site, and system
message from the site.
______________________________________ node sends: CALL.sub.-- STAT
(101) # Bytes Field Function ______________________________________
(1) message.sub.-- id CALL.sub.-- STAT (1) msg.sub.-- group message
group number (1) msg.sub.-- sub.sub.-- group message sub group
number (1)** call.sub.-- variant call qualifier flags (3) callee
entity receiving call (3) caller entity initiating call (1) status
0 - Successful 1 - Error (1) host initiating host (console, site,
etc.) ______________________________________
Node Poll
To provide a pseudo real time update of the number of nodes in the
switch and their assigned device type and number, the MOM sends a
node poll message. This message is sent at a predetermined
interval, and can address a range of nodes.
______________________________________ MOM sends: NODE.sub.-- POLL
(131) # Bytes Field Function ______________________________________
(1) message.sub.-- id NODE.sub.-- POLL (1) low.sub.-- addr low
address in GSC address range (1) high.sub.-- addr high address in
GSC address range ______________________________________
Node Active
Upon receipt of a node poll from the MOM, a node determines if its
address lies within the range specified in the poll. If so, the
node responds to the MOM with a node active message.
______________________________________ node sends: NODE.sub.--
ACTIVE (130) # Bytes Field Function
______________________________________ (1) message.sub.-- id
NODE.sub.-- ACTIVE (1) node.sub.-- id responding node id (1) type
device type (MIM, CIM,etc.) (1) assignment numeric assignment (site
1, console 2, etc.) (1) node.sub.-- errors boolean indicating node
errors (TRUE = errors have occurred; FALSE = no errors)
______________________________________
Status Request
To provide a pseudo real time update of status data for a specific
node in the switch, the MOM sends the node a status request at
approximately 1 second intervals. This process is activated when
the MOM PC operator elects to monitor a node in his or her
switch.
______________________________________ MOM sends: STATUS.sub.--
RQST (132) # Bytes Field Function
______________________________________ (1) message.sub.-- id
STATUS.sub.-- RQST ______________________________________
Status Response
Upon receipt of a status request message from the MOM, the node
responds with a status response. This message contains information
pertaining to various exception conditions that may have
occurred.
______________________________________ node sends: STATUS.sub.--
RESP (133) # Bytes Field Function
______________________________________ (1) message.sub.-- id
STATUS.sub.-- RESP (1) node.sub.-- id responding node id (1) type
device type (2) c152.sub.-- serial.sub.-- ovfl communications
controller serial port buffer overflow count (2) c152.sub.--
gsc.sub.-- ovfl communications controller GSC message bus buffer
overflow count (2) c152.sub.-- to.sub.-- c186.sub.-- ovfl
communications controller to interface processor buffer overflow
count (2) c186.sub.-- serial.sub.-- ovfl interface processor serial
port buffer overflow count (2) c186.sub.-- gsc.sub.-- ovfl
interface processor GSC message bus buffer overflow count (2)
c186.sub.-- to.sub.-- c152.sub.-- ovfl interface processor to
communications controller buffer overflow count (2) gsc.sub.--
rx.sub.-- error GSC message bus receive error count (2) gsc.sub.--
tx.sub.-- error GSC message bus transmit error count
______________________________________
Clear Status Errors
The MOM PC operator has the option of clearing the status errors
for any node in the switch. When this is done, the MOM sends a
clear status errors message to this node, commanding it to clear
its error counters.
______________________________________ MOM sends: CLEAR.sub.--
STATUS.sub.-- ERRORS (144) # Bytes Field Function
______________________________________ (1) message.sub.-- id
CLEAR.sub.-- STATUS.sub.-- ERRORS
______________________________________
CIM Select Request
The MOM is responsible for the database used to implement smart
call in the switch. This database contains a list of entities
selected at each console. To determine the select status of each
console, the MOM sends a CIM select request to the CIM connected to
the console.
MOM sends: CIM.sub.-- SELECT.sub.-- RQST (134)
______________________________________ MOM sends: CIM.sub.--
SELECT.sub.-- RQST (134) # Bytes Field Function
______________________________________ (1) message.sub.-- id
CIM.sub.-- SELECT.sub.-- RQST
______________________________________
CIM Select Response
Upon receipt of a CIM select request message from the MOM, the node
responds with a CIM select response for each entity selected at the
CIM's console. The CIM also sends a CIM select response when the
select status of a programmed entity is changed by the console
operator.
______________________________________ CIM sends: CIM.sub.--
SELECT.sub.-- RESP (135) # Bytes Field Function
______________________________________ (1) message.sub.-- id
CIM.sub.-- SELECT.sub.-- RESP (1) console.sub.-- number console
number responding (3) callee programmed entity (1) bit.sub.-- mask
bit identifying select status (see MODULE.sub.-- SELECT bit in
C.sub.-- CIM.H) ______________________________________
Smart Call
When a radio originated channel assignment is received by a MIM, it
broadcasts a slot assignment to all nodes in the switch. Upon
receipt of the slot assignment, the MOM determines if the callee is
selected at any console connected to the switch. If so, the MOM
sends a smart call message to all CIMs. This message affects the
state of the "CALL" indicator at the console. If the entity is
selected at any console, the indicator is constant. Otherwise, it
flashes.
The MOM also sends a smart call message when the select count of a
programmed entity transitions from 0 to 1, or vice versa. This
could occur when the entity is selected/unselected at a
console.
______________________________________ MOM sends: SMART.sub.--
CALL.sub.-- ID (137) # Bytes Field Function
______________________________________ (1) message.sub.-- id
SMART.sub.-- CALL.sub.-- ID (3) callee programmed entity (1)
call.sub.-- variant smart call state (see SMART.sub.-- CALL bit in
S.sub.-- TYPE.H) ______________________________________
Missed Channel Assignment/Drop
The MIM device type contains logic to detect missed channel
assignment and drops on the site downlink. When this occurs, it
sends a missed channel assignment/drop message to the MOM. The MOM
records this information as part of the status data for the
node.
______________________________________ MIM sends: MISSED.sub.-- CA
(138) MISSED.sub.-- CD (139) # Bytes Field Function
______________________________________ (1) message.sub.-- id
MISSED.sub.-- CA/MISSED.sub.-- CD (1) node.sub.-- id node id of MIM
(1) site site number assigned (1) channel channel number involved
______________________________________
Device Slot Allocation
The MOM PC operator is responsible for the number of audio bus
slots allocated to each node in the switch. This allocation is
stored in EEPROM on the MOM Controller. When a node requiring bus
slots resets (MIM or CIM), the MOM sends a device slot allocation
message to it. This informs the node of the audio bus slots it has
been allocated.
______________________________________ MOM sends: DEVICE.sub.--
SLOT.sub.-- ALLOCATION (141) # Bytes Field Function
______________________________________ (1) message.sub.-- id
DEVICE.sub.-- SLOT.sub.-- ALLOCATION (2) bus.sub.-- slot starting
audio bus/slot Low byte = Bus number High byte = Slot number (1)
slot.sub.-- count number of slots allocated
______________________________________
The algorithm used to allocate bus slots executes in bus major
form. For example, if the starting bus number =0, starting slot
number=0, and the number of slots allocated=4, the bus/slot pairs
allocated would be: 0,0 1,0 2,0 3,0. This method minimizes the
impact on a node upon loss of an audio bus.
Patch/Simulselect Update Request
When a console operator logs into the connected CIM, the CIM sends
a patch/simulselect update request to the MOM. This message prompts
the MOM to respond with all active patch and simulselect
information. This response is in the form of the messages described
in patch/simulselect activation.
______________________________________ CIM sends: PAT.sub.--
SIM.sub.-- UPDATE.sub.-- REQ (142) # Bytes Field Function
______________________________________ (1) message.sub.-- id
PAT.sub.-- SIM.sub.-- UPDATE.sub.-- REQ (1) node.sub.-- id node id
of CIM ______________________________________
System Time
At one minute intervals, the MOM broadcasts the system time to all
nodes in the switch via a system time message. This enables all
nodes (and consoles) to synchronize their clocks to the PC
connected to the MOM controller.
______________________________________ MOM sends: SYSTEM.sub.--
TIME (146) # Bytes Field Function
______________________________________ (1) message.sub.-- id
SYSTEM.sub.-- TIME (2) year current year (1989-2099) (1) month
current month (1-12) (1) day current day (1-31) (1) hour current
hour (0-23) (1) minute current minute (0-59) (1) second current
second (0-59) ______________________________________
Audio Channel Configuration
The MOM PC provides the operator with the ability to configure
various audio parameters for each node in the switch. The MOM
controller sends the node this information in the form of an audio
channel configuration message. For a list of configuration options,
see S.sub.-- AUDIO.H
______________________________________ MOM sends: AUDIO.sub.--
CHAN.sub.-- CONFIG.sub.-- MSG (158) # Bytes Field Function
______________________________________ (1) message.sub.-- id
AUDIO.sub.-- CHAN.sub.-- CONFIG.sub.-- MSG (1) msg.sub.--
sub.sub.-- group configuration option (1) channel channel to
configure (1) level TX/RX gain (1) node.sub.-- id node id of
receiving device ______________________________________
Dynamic Node Addressing Messages
These messages are used to perform dynamic node addressing during
switch or node power up. See Appendix B for a detailed description
of dynamic node addressing.
______________________________________ Address Request node sends:
ADDR.sub.-- RQST (119) # Bytes Field Function (1) message.sub.-- id
ADDR.sub.-- RQST (1) node.sub.-- id potential node id Address
Denial node sends: ADDR.sub.-- DENIAL (120) # Bytes Field Function
(1) message.sub.-- id ADDR.sub.-- DENIAL (1) node.sub.-- id
conflicting node id Initialization Complete node sends: INIT.sub.--
COMP (121) # Bytes Field Function (1) message.sub.-- id INIT.sub.--
COMP ______________________________________
Node Priority Definition
This message is used to inform primary nodes of their secondary
node address and secondary nodes of their primary address. The
message is initiated from the MOM.
______________________________________ MOM sends: NODE.sub.--
PRIORITY (159) # Bytes Field Function
______________________________________ (1) message.sub.-- id
NODE.sub.-- PRIORITY (1) prim.sub.-- node primary node address (1)
sec.sub.-- node secondary node address
______________________________________
Console User Profile Data
The following sequence of messages is used to inform each console
of their user profile shift data.
Console User Profile Identification
This message is used to inform the console of its 8 character ASCII
name and 16 bit unit id. The message is initiated from the MOM.
______________________________________ MOM sends: CONSOLE.sub.--
USER.sub.-- PROFILE.sub.-- ID (160) # Bytes Field Function
______________________________________ (1) console console number
(1 - MAX.sub.-- CONSOLES) (8) name 8 character console name (2)
unit.sub.-- id 16 bit unit id
______________________________________
Console User Profile Shift Data
This message is used to inform the console of its shift specific
data. Three shifts are supported. The message is initiated from the
MOM.
______________________________________ MOM sends: CONSOLE.sub.--
USER.sub.-- PROFILE.sub.-- SHIFT (161) # Bytes Field Function
______________________________________ (1) message.sub.-- id
CONSOLE.sub.-- USER.sub.-- PROFILE.sub.-- SHIFT (1) console console
number (1 - MAX.sub.-- CONSOLES) (1) shift shift number (1 - 3) (1)
priority console priority (1) privilege console privilege (1)
def.sub.-- unsel.sub.-- vol default unselect speaker volume (1)
non.sub.-- mon.sub.-- emerg.sub.-- vol non-monitored emergency
volume (1) mute.sub.-- vol mute volume (1) all.sub.-- mute.sub.--
delay all mute delay (1) label.sub.-- delay label delay (1)
screen.sub.-- blank.sub.-- timeout screen blank timeout in minutes
(CRT only) (2) bit.sub.-- mask bit mask (see S.sub.-- SYS.H) (8)
name 8 character console name (2) unit.sub.-- id 16 bit unit id
______________________________________
Console User Profile Return Status
This message is used to inform the MOM if the Console User Profile
Data was received correctly. The message is initiated from the
console.
______________________________________ Console sends:
CONSOLE.sub.-- USER.sub.-- PROFILE.sub.-- STATUS (162) # Bytes
Field Function ______________________________________ (1)
message.sub.-- id CONSOLE.sub.- USER.sub.- PROFILE.sub.-- STATUS
(1) console console number (1 - MAX.sub.-- CONSOLES) (1) status
status (1 - success, 0 - failure)
______________________________________
Nonvolitale RAM Cleared
This message is used to inform the MOM of any occurrance of
nonvolatile memory being cleared in any of the switch nodes.
______________________________________ node sends: NOVRAM.sub.--
CLEARED (163) # Bytes Field Function
______________________________________ (1) message.sub.-- id
NOVRAM.sub.-- CLEARED (1) device.sub.-- type device type (CIM, MIM,
MOM, etc.) (1) device.sub.-- assgn device assigned (CIM 1, MIM 2,
etc.) (1) cause cause for clearing (2) info information field
______________________________________
Switch Download Request/System Manager Data
This group of messages is used to distribute System Manager data
throughout the system (CIMs, MIMs, MOM) for purposes of multisite
operation and console programming operations.
Switch Download Request
This message is used to request System Manager data. The message is
initiated from a MIM or CIM.
______________________________________ node sends: SW.sub.--
UNIT.sub.-- ALL.sub.-- REQ (147) SW.sub.-- UNIT.sub.-- UPD.sub.--
REQ (148) SW.sub.-- GROUP.sub.-- ALL.sub.-- REQ (149) SW.sub.--
GROUP.sub.-- UPD.sub.-- REQ (150) SW.sub.-- SITE.sub.-- REQ (151)
#Bytes Field Function ______________________________________ (1)
message.sub.-- id specific request (1) device.sub.-- type device
type (CIM, MIM) device.sub.-- assgn device assigned (CIM 1, MIM 2,
etc.) node.sub.-- id node id of device
______________________________________
System Manager Unit Record
This message is the unit (radio) data record as reported from the
System Manager. The ALL id indicates a full database download from
the System Manager, while the UPD indicates a download of only the
modified records since the last download. The message is
transmitted from the MOM to each CIM and MIM in the system.
______________________________________ MOM sends: SM.sub.--
UNIT.sub.-- ALL (224) SM.sub.-- UNIT.sub.-- UPD (226) # Bytes Field
Function ______________________________________ (1) message.sub.--
id SM.sub.- UNIT.sub.- ALL/SM.sub.- UNIT.sub.- UPD (2) unit.sub.--
id unit id (4) forced.sub.-- site.sub.-- mask sites on which unit
must communicate (1) bit.sub.-- mask wide area/track/console bits
(1) home.sub.-- site unit's home site number (1.sup. -- MAX.sub.--
SITES) home.sub.-- group unit's home group (1 - MAX.sub.-- GROUPS)
(8) unit.sub.-- name 8 character unit alias
______________________________________
System Manager Group Record
This message is the group (agency/fleet/subfleet) data record as
reported from the System Manager. The ALL id indicates a full
database download from the System Manager, while the UPD indicates
a download of only the modified records since the last download.
The message is transmitted from the MOM to each CIM and MIM in the
system.
__________________________________________________________________________
MOM sends: SM.sub.-- GROUP.sub.-- ALL (225) SW.sub.-- GROUP.sub.--
UPD (227) # Bytes Field Function
__________________________________________________________________________
(1) message.sub.-- id SM.sub.-- GROUP.sub.-- ALL/SM.sub.--
GROUP.sub.-- UPD (2) group.sub.-- id group id (4) forced.sub.--
site.sub.-- mask sites on which group must communicate (1)
bit.sub.-- mask wide area/track bits (1) group.sub.-- type group
type (A/F/S) (8) group.sub.-- name 8 character group alias
__________________________________________________________________________
System Manager Site Record
This message is the site data record as reported from the System
Manager. It identifies the alias given to each site configured in
the system. The message is transmitted from the MOM to each CIM in
the system.
______________________________________ MOM sends: SM.sub.--
SITE.sub.-- DB (93) # Bytes Field Function
______________________________________ (1) message.sub.-- id
SM.sub.-- SITE.sub.-- DB (1) site.sub.-- id site number (8)
site.sub.-- name 8 character site alias
______________________________________
Conventional Control Messages
The following data structure preceeds all conventional control
messages throughout the switch. Each message has one of two message
id's, shown below, followed by a message sub id defining the actual
message itself. This message format allows nodes in the system
receiving the message, but not needing the message, to filter
through without having to switch on each individual message sub
id.
__________________________________________________________________________
Node sends: CONV.sub.-- MSG.sub.-- TYPE (155) CONV.sub.--
MSG.sub.-- RESP (156) # Bytes Field Function
__________________________________________________________________________
(1) message.sub.-- id CONV.sub.-- MSG.sub.-- TYPE or CONV.sub.--
MSG.sub.-- RESP (1) msg.sub.-- sub.sub.-- id message sub id (1)
site initiating / receiving site (1) node.sub.-- id initiating /
receiving node id
__________________________________________________________________________
Conventional Base Station Control
This data structure is used to control the base station from the
console dispatchers point of view. All messages are initiated from
a console and are responded to from the Conventional Interface (CI)
board.
______________________________________ The conventional base
station console sends msg.sub.-- sub.sub.-- id: REMOTE.sub.--
ENABLE (1) REMOTE.sub.-- DISABLE (2) REPEAT.sub.-- ENABLE (3)
REPEAT.sub.-- DISABLE (4) CG.sub.-- ENABLE (5) CG.sub.-- DISABLE
(6) CG.sub.-- MON.sub.-- LATCH (7) CG.sub.-- MON.sub.-- PTT (8)
SCAN.sub.-- ENABLE (9) SCAN.sub.-- DISABLE (10) SIM.sub.--
MON.sub.-- ENABLE (11) SIM.sub.-- MON.sub.-- DISABLE (12)
SET.sub.-- RX.sub.-- FREQ.sub.-- 1 (13) SET.sub.-- RX.sub.--
FREQ.sub.-- 2 (14) SET.sub.-- RX.sub.-- FREQ.sub.-- 3 (15)
SET.sub.-- RX.sub.-- FREQ.sub.-- 4 (16) SET.sub.-- TX.sub.--
FREQ.sub.-- 1 (17) SET.sub.-- TX.sub.-- FREQ.sub.-- 2 (18)
SET.sub.-- TX.sub.-- FREQ.sub.-- 3 (19) SET.sub.-- TX.sub.--
FREQ.sub.-- 4 (20) ICOMM.sub. -- TX (22) # Bytes Field Function (1)
chn channel (1-32) (1) status status The CVIM responds with
msg.sub.-- sub.sub.-- id: REMOTE.sub.-- ENABLE (1) REMOTE.sub.--
DISABLE (2) REPEAT.sub.-- ENABLE (3) REPEAT.sub.-- DISABLE (4)
CG.sub.-- ENABLE (5) CG.sub.-- DISABLE (6) CG.sub.-- MON.sub.--
LATCH (7) CG.sub.-- MON.sub.-- PTT (8) SCAN.sub.-- ENABLE (9)
SCAN.sub.-- DISABLE (10) SIM.sub.-- MON.sub.-- ENABLE (11)
SIM.sub.-- MON.sub.-- DISABLE (12) SET.sub.-- RX.sub.-- FREQ.sub.--
1 (13) SET.sub.-- RX.sub.-- FREQ.sub.-- 2 (14) SET.sub.-- RX.sub.--
FREQ.sub.-- 3 (15) SET.sub.-- RX.sub.-- FREQ.sub.-- 4 (16)
SET.sub.-- TX.sub.-- FREQ.sub.-- 1 (17) SET.sub.-- TX.sub.--
FREQ.sub.-- 2 (18) SET.sub.-- TX.sub. -- FREQ.sub.-- 3 (19)
SET.sub.-- TX.sub.-- FREQ.sub.-- 4 (20) ICOMM.sub.-- TX (22) #
Bytes Field Function (1) chn channel (1-32) (1) status return
status of command ______________________________________
Conventional EE Pot Control
This message is used to adjust the transmit/receive gains on the
Conventional (CI) board.
______________________________________ MOM sends msg.sub.--
sub.sub.-- id: INCREMENT.sub.-- EE.sub.-- POT (33) DECREMENT.sub.--
EE.sub.-- POT (34) SET.sub.-- EE.sub.-- POT (35) WRITE.sub.--
EE.sub.-- POT (36) # Bytes Field Function (1) chn EE Pot channel to
adjust (1) tx.sub.-- rx transmit / receive Pot (1) count amount to
adjust MOM receives msg.sub.-- sub.sub.-- id: INCREMENT.sub.--
EE.sub.-- POT (33) DECREMENT.sub.-- EE.sub.-- POT (34) SET.sub.--
EE.sub.-- POT (35) WRITE.sub.-- EE.sub.-- POT (36) # Bytes Field
Function (1) chn EE Pot channel adjusted (1) tx.sub.-- rx transmit
/ receive Pot (1) count new EE Pot level
______________________________________
Conventional CI EE Pot Levels
This message is initiated from the CI board and is used to report
the EE Pot levels at startup.
______________________________________ CI sends: CI.sub.--
EE.sub.-- POT.sub.-- LEVEL (37) # Bytes Field Function
______________________________________ (1) chn channel (1-32) (1)
tx.sub.-- rx transmit / receive Pot (4) ee.sub.-- levels levels for
4 channels beginning with chn
______________________________________
Conventional Controller Interface (CCI) Configuration/Status
This following messages are used to determine the status of the CCI
card. The MOM PC sends the CCI its conventional site number and the
CCI reports to the MOM when it's reset.
______________________________________ MOM sends: CCI.sub.-- CONFIG
(38) # Bytes Field Function ______________________________________
(1) conv.sub.-- site conventional site # (1-2) CCI sends:
CCI.sub.-- RESET (39) (1) conv.sub.-- site conventional site #
reset CI Configuration ______________________________________
This message is used to configure each individual CI channel.
______________________________________ MOM sends: CI.sub.-- CONFIG
(40) # Bytes Field Function ______________________________________
(1) chn channel to configure (1) config configuration 2/4 wire
tone/DC coupled/noncoupled E&M signaling
______________________________________
Conventional Initialization Messages
The following data structure preceeds all conventional
initialization messages throughout the switch. Each message has a
message id of CONV.sub.-- INIT.sub.-- MSG. This message format
allows nodes in the system receiving the message, but not needing
the message, to filter through without having to switch on each
individual message sub id.
______________________________________ Node sends: CONV.sub.--
INIT.sub.-- MSG (157) # Bytes Field Function
______________________________________ (1) message.sub.-- id
CONV.sub.-- MSG.sub.-- TYPE or CONV.sub.-- MSG.sub.-- RESP (1)
command program command (1) conv.sub.-- site receiving conventional
site (1) node.sub.-- id initiating node id (1) chn channel to
program ______________________________________
Conventional DC Program Control
This message is used to program a Conventional Interface (CI) card
for a DC base station. The message is initiated by the MOM and
transmitted to the CI card.
______________________________________ MOM sends: CONV.sub.--
INIT.sub.-- MSG (157) # Bytes Field Function
______________________________________ (7) dc.sub.-- level DC
levels: -11mA -6mA -2.5mA 0mA +2.5mA +6mA +11mA
______________________________________
Conventional Tone Program Control
This message is used to program a CI card for a tone base station.
The message is initiated by the MOM and transmitted to the CI
card.
______________________________________ MOM sends: CONV.sub.--
INIT.sub.-- MSG (157) # Bytes Field Function
______________________________________ (11) tone.sub.-- frq Tone
frequencies: 1050 Hz 1150 Hz 1250 Hz 1350 Hz 1450 Hz 1550 Hz 1650
Hz 1750 Hz 1850 Hz 1950 Hz 2050 Hz
______________________________________
Interprocessor Messages
GSC Traffic Update Message
The communications controller sends the interface processor a GSC
Traffic Update message at 30 ms intervals. A low pass filter is
applied to this data to produce an average load figure for the
traffic on the message bus. This figure is then compared to a
threshold constant. If the average traffic volume is above the
threshold, then the node does not execute its slot updating message
generation tasks. If the traffic volume is below the threshold, the
node's update process is invoked.
______________________________________ GSC.sub.-- TRAFFIC.sub.--
UPDATE (127) # Bytes Field Function
______________________________________ (1) message.sub.-- id
GSC.sub.-- TRAFFIC.sub.-- UPDATE (1) msg.sub.-- count count of GSC
messages (2) byte.sub.-- count count of GSC bytes
______________________________________
Buffer Overflow Message
The communications controller sends the interface processor a
buffer overflow message at 0.8 second intervals. The interface
processor records this overflow data in RAM, and provides it to the
MOM upon receipt of a status request.
______________________________________ BUFFER.sub.-- OVERFLOW (128)
# Bytes Field Function ______________________________________ (1)
message.sub.-- id C152.sub.-- BUFFER.sub.-- OVERFLOW (2)
serial.sub.-- ovfl C152 serial port buffer overflow count (2)
gsc.sub.-- ovfl C152 GSC buffer overflow count (2) to.sub.--
186.sub.-- ovfl C152 to C186 buffer overflow count
______________________________________
GSC Error Count Message
The communications controller sends the interface processor a GSC
message bus error count message at 0.8 second intervals. The
interface processor records this message bus error data in RAM, and
provides it to the MOM upon receipt of a status request.
______________________________________ GSC.sub.-- ERROR.sub.--
COUNT (129) # Bytes Field Function
______________________________________ (1) message.sub.-- id
GSC.sub.-- ERROR.sub.-- COUNT (2) gsc.sub.-- rx.sub.-- error GSC
receive error count (2) gsc.sub.-- tx.sub.-- error GSC transmit
error count ______________________________________
Serial/Interprocessor Message
This message allows the communications controller to originate its
own messages and receive serial messages. The communications
controller generates a message and places it in the dual-port RAM
buffer packet for serial transmit or the packet for interprocessor
messages. Upon receipt of a SERIAL.sub.-- INTER.sub.-- PROC
message, the interface processor simply routes the message back to
the serial transmit or interprocessor buffer in the dual port RAM
for the communications controller. This procedure enables the
communications controller to handle low-level protocol within the
normal message routing.
______________________________________ SERIAL.sub.-- INTER.sub.--
PROC (126) # Bytes Field Function
______________________________________ (1) message.sub.-- id
SERIAL.sub.-- INTER.sub.-- PROC (n) variable length message
______________________________________
GSC/Interprocessor Message
As with the serial/interprocessor message, the GSC/interprocessor
message provides the communications controller with a method of
routing messages to and from its GSC transmit and interprocessor
buffers via the interface processor.
______________________________________ GSC.sub.-- INTER.sub.-- PROC
(118) # Bytes Field Function ______________________________________
(1) message.sub.-- id GSC.sub.-- INTER.sub.-- PROC (n) variable
length message ______________________________________
Interprocessor Message Transactions
The following message types are used by the communications
controller and the interface processor to communicate with each
other. Interprocessor messages are labeled to indicate the source
of the message.
The message type byte is communicated to the receiving processor or
controller by writing to reserved locations in the dual-port RAM as
is described above. Using the memory map for the interface
processor, the location 02FFE is written to by the communications
controller for a transfer to the processor. Similarly, the
interface processor writes to location 02FFC in the dual-port RAM
for transfers in to the communications controller. The format of
the message type byte is shown below. ##STR4##
The two flags R1, R0 are not currently used and are reserved for an
as of yet undefined function. The six remaining bits are used for
the message type byte. Table B contains a list of system message
types.
TABLE B ______________________________________ Type Byte Function
______________________________________ 00 Serial I/O (data to/from
a site, console, etc.). 01 Global Serial Channel I/O. Enables nodes
to communicate with one another. 02 Interprocessor I/O. Enables the
two processors on a Controller Card to communicate with one
another. ______________________________________
While the invention has been described in connection with what is
presently considered to be the most practical and preferred
embodiment, it is to be understood that the invention is not to be
limited to the disclosed embodiment. On the contrary, the invention
is intended to cover various modifications and equivalent
arrangements included within the spirit and scope of the appended
claims.
* * * * *