CA1304132C - Fail-soft architecture for public trunking system - Google Patents

Fail-soft architecture for public trunking system

Info

Publication number
CA1304132C
CA1304132C CA000566663A CA566663A CA1304132C CA 1304132 C CA1304132 C CA 1304132C CA 000566663 A CA000566663 A CA 000566663A CA 566663 A CA566663 A CA 566663A CA 1304132 C CA1304132 C CA 1304132C
Authority
CA
Canada
Prior art keywords
trunking
channel
working
control
site controller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
CA000566663A
Other languages
French (fr)
Inventor
Jeffrey Scott Childress
Houston Howard Hughes, Iii
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
General Electric Co
Original Assignee
General Electric Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Electric Co filed Critical General Electric Co
Application granted granted Critical
Publication of CA1304132C publication Critical patent/CA1304132C/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04Large scale networks; Deep hierarchical networks
    • H04W84/08Trunked mobile radio systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Radio Relay Systems (AREA)
  • Selective Calling Equipment (AREA)

Abstract

FAIL-SOFT ARCHITECTURE FOR PUBLIC TRUNKING SYSTEM

ABSTRACT OF THE DISCLOSURE

A site architecture for a trunked radio frequency communications system provides better fault tolerance capabilities than are available from architectures including redundant hardware. During normal system operations, a primary site controller performs most or all system control functions while signal processing functions are performed in a distributed manner by trunking cards associated with individual repeater channel receivers and transmitters. In the event the site controller fails, the trunking cards also begin performing trunking and other control functions. The trunking cards cease attempting to communicate with the failed site controller, and begin communicating directly with one another via a high speed backup serial link. Through the distributed processing routines performed by the various trunking cards and interaction between the trunking cards over the backup serial link, trunking and other capabilities are maintained even though the primary site controller has failed (although advanced features such as call logging and the like are lost). Because trunking capability is maintained, failure of the primary site controller has little or no effect on ongoing communications and is virtually transparent to mobile unit operators.

Description

~3~

FAIL-SOFT ARCHITECTURE FOR
PUBLIC TRUNXING SYSTE~

S P E C I F I C A T I O N
This invention is generally directed to the art of trun~ed radio repeater ystem~. It is more particularly directed to a radio frequency repeater site architecture with a "fail soft" feature which provides trunking ~nd other communications capability de~pite failure of major component~ of the architecture (e.g., the primary ~ite controller).
Radio repeater trunking (~ime eharing of a single repeater conununications channel among many u8erS ) i8 well-known. Early ~r~nkinç~ 8y8tem5 used analog control signal3 while some more recent system~
have utilized digital control signal3. Control ~ignals have been utilized on a dedicated control channel and/or on diferent one~ of ~e working channels for various different rea50nS and effects.
A non-exhaustive but somewhat repre3en~ative ~sampling of publication~ and patents describinq typical prior art trunked radio repeater ~y~tem~ i~ idantified ~elow:

U.S. Patent ~o. 3,292,178, Magnuski (1966) U.S. Patent No. 3,458,6S4, Adlhoch et al ~1969) U~Sn Patent No. 3,571,519, Tsimbidis ~1971) U.S. Patent No. 3,696,210, Peter~on et al (1972) U.S. Patent No. 3,906,166, Cooper et al (1975) U.S. Patent No. 3,936,616, DiGianfilippo (1976) U.S. Patent No. 3,970,801, Ro~ et al (1976) U.S. Patent No. 4,001,6g3, Stackhouse et al (1977) U.S. Patent No. 4,010,327, Kobrin~tz et al ~19773 U.S. Patent No. 4,012,597, Lynk, Jr. et al (1977~
U.S. Patent No. 4,022,973, Stackhou~e et al (1977) U~S. Patent No. ~,027t2'43, Stac~hou~e et al ~1977) U.S. Patent No. 4,029,901, Campbell (lg77) U.S. Patent No. 4,128,740, Graziano (1978) U.S. Patent No. 4,131,849, Freeburg ~t al (1978) U.S. Patent No. 4,184,118, Cannalte et al (1980) U.S. Patent No. 4,231,114, Doli~ian (1~80) U.S. Patent No. 4,309,772, Kloker ek al (1~82) U.S. Patent No. 4,312,070, Coombe~ et al (1982) U.S. Patent No. 4,312,074, Pautler et al (1982 U.S. Patent No. 4,~26,264, Cohen et al ~1982~
UOS. Patent No. 4,339,823, Predina et at (1982) U.S. Patent No. 4,347,625, Williams (1982) U.S. Patent No. 4,360,927, Bowen et al (1~82~
U.S. Patent No. 4,~00,585, Kamen et al (1982) U.S. Patent No. 4,409,687, Berti et al (1983) U~S. Pat~nt No. 4,430,742, Milleker et aL (1984 U.S. Patent No. 4,430,755, Nadir et al (1984 U.S. Patent No. 4,433,256, Dolikian (1984) U.S. Patent No. 4,450,573, Noble (1984) U.S. Patent No. 4,485,~86, Webb et al (1984) U.S. Patent ~o. 4,578,815, Persinotti ~1985) The Bow~n et al 8y8tem iS a~ example of prior art ~witched channel repeater ~ystems which avoid u~ing a dedicated control channel ~ part by providing a handshake with the repeater site controller on a seized "idle" working channel before communication wi~h the called unit(s) ls permitted to proceed.
Th~re are many actual and potential applications for trunked radio repeater systems.
However, one of the more important applications i~
for public ~ervice trunked (PST) ~ystems. For example, one metropolitan area may advantageously utilize a ~ingle system of trunked radio repeaters to provide efficient radio communications between individual radio units within many different agencies. Each agency may, in tuxn, achieve efficient communication between individual unit3 o different fleets or sub-units (e.g., the police department may have a need to provide efficient communication~ between different unit~ of its squad car force, different units of detectives or narcotics a~ents and the like). Sometimes it may be important to communicate simultaneously to predefined groups o uni~ (e.g., all units, all of the squa~ cars, all of the foot patrolmen, etc.). At the same time, other agencies (e.g., the fire departme~t, the transportation department, the water department, the emergency/rescue services, atc.~ may be in need of similar communication services. As is well-known to those familiar with trunking theory, a relatively ~L3Q~: L32 small number of radio repeaters can efficiently service all of these needs within a given geographic area if they are trunked (i.e., shared on an "as-needed" basis between all potential units).
There are a variety of trunked communications systems on the market today~ each with its own set of advantages and disadvantages. The one thing all such sy~tem~ have in common i5 architectures which ~1) prohibit the use of optimum signalling baud rates, (2) inhibit diagnosis, localization and correction of hardware failures; and (3) cannot continue to support trunked operation should any non-RF signal point failure occur. The importance of each of these three points wil~ be discussed individually.
~1~ Optimum Signalling Rates The telecommunications industry invested substantial time and money towards determining the optimal way of transmitting data at 800 MHz for the cellular telephone network. Data transmission efficiency is important since it increases both requency efficiency and user efficiency of a system. It was concluded that the optimal baud rate is the hi~hest baud rate of bilevel encoded data that the channel bandwidth would support. For Public Service Trunking (PST) systems having a 25 KHz channel bandwidth, 9600 baud is the highest rate that can be supported. Nevertheless, due to hardware and architecture which are unable to support the higher processing requirement~
associated with a higher baud rate, existing systems either use low baud rates (300 baud) or ~uboptimal baud rates (3600 baud).

., :

~L3~
. ~

~5MR541 (2) Localization and Correction of Hardware Failures A computer primary site controller which oversees ~ite activity and detects site faults expedites th2 failure detection and correction process. On the o~her hand, if that same computer embodies all intslligence at the site, then fault detection within the controller it~elf becomes difficul~ to .
perform. Existing systems either have no computer to effectively detect failures, or a computer which contains all site intelligence (and thu8 cannot effectively diagnose or recover rom its own failure).
(3 ) Trunked Fail Soft Operations There are at least three reasons why site con-troller failure should not eliminate trunking capability. First, ~ince the ~ystem i8 trunked, more radio~ probably reside on the system than if it were a conventional system -- and consequently, elimination of the trunked mode cau~es system overload (~ince a trunked ~y tem can handle far more traffic ~han a non-trunked ~ystem). This ean result in units being forced off the system -- or units being unable to access the system to begin with.
Second, changing the mode of operation as seen by the users ~e.g., from a trunked ystem to a system in which users must select their own operating frequencies manually~
creates additional confusion, particularly when a user is forced to listen to all 6 ~5MR541 conversation~ -- even those that don't pertain to him/her (in a typical trunked Ry~tem, only tho~e units intended to be a part of a communication tune to the frequency on ~hich tha communication takes place~.
Third, site controller failures are not statistically independent from emergency ~ituations in the field. For example, the very ~torm that might cause emergencies in the field could cause power problems damaging the ~ite controller. The advantages provided by a trunked communication system may th~s be needed most at the time the site controller fails .
Fault tolerance can'be the most sophisticated portion of a system, and is not achieved effectively as an afterthought to the æy~tem de~ign process. Yet to date, trunked communication systems have been designed with little regard towards ault tolerance, forcing the end user to tie up capital in redundant hardware in order to obtain reliability. Affording the end user with a truly ~ault tolerant trunked co~munications Ry~tem requires ~ystem design and engineerir:lg considerations throughout the development cycle, beginning with the very conception of the sy~tem itself.
A trunked communication system must be evaluated ba~ad on all aspects of system operation, including it~ fault tolerance. A repeater 6ite architecture for a trunked (or even a non-trunked~
communications sy~tem ha3 been developed which has esccellent fault toleFan~:e and therefore overcomes the aforementioned shortcomings inherent in all other ~3~4~L~Z

known existing trunking ~ystems. Briefly, present invention provides a unique site architecture which separates signal processing unctions from data pr~ces3ing and control functions -- and distri~utes both types of processing functions throughout the architecture.
Signal processing hardware (embodied in a so-called "trunking card", or "TC") dedicated to each radio frequency channel (and to a radio transmitter and receiver operating on the channel) provides the ~ignal processing reguired for its associated channel. Each dedicated siqnal processing trunking card operates essentially independently except for higher-level required control coordination with other trunking cards and with the primary site controller computer. Durins normal operation of the sys~em, most control functions are performed by the site controller (e.g., a high speed computer with advanced, real time control capabilities) -- leaving the trunking card processors free to devote all of their processing resources to processing signals associated with the specific RF channels they are dedicated to. Synchronization lines and serial communications lines are shared among all of the channel processing trunking cards -- but flow of control information during normal system operation ls between the trunking cards and the site controller.
One of the channel signal processing trunking cards is assigned to operate on a dedicated trunking control channel (any of the trunking cards are capable of operating on the control channel, but an arbitrary trunking card is assigned -- if the assigned card fails, another trunking card takes its ~3~ 3~:

8 45MR5~1 place). All mobile units not engaged in active communications on a working channel monitor the control channal -- and there receive instructions to move to a wor}cing chanrlel to communicate with other mobile units or with the con~ole.
In prior art systems, failure of the site csntroller causes the entire system to cease operating (or at best, begin operating in a non-trunked mode wi~h each channel operating independently as a repeater with little or no coordination between the operation of diferent channels) unless and until an alternate site controller can be brought on line. In the system of the present invention, the trunking card assi~ned to operate on the control chan~el almost instantly detect~ failure of the site controller, and upon such detection, controls ~he trunking cards to operate in a "fail ~oft" mode in which the trunking cards no longer attempt to communicate with the failed site controller but instead communicate control information with one another over a backup serial link (BSL) not used during normal sy~tem operation. Communications between the trunking cards over the backup serial link is coordinated by the control channel trunking card so that each trunking card-independently mainkains system status information, and each trunking card updates the control channel trunking card and all other trunking cards of changes in status.
I~ fail soft mode, control functions handled by the site controller during normal mode operation are handled in a distributed fashion by the trunking card~. Eor examplP, a down link trunking card which ~L~

9 45MR5~1 simply passes messages between the site controller and the operator control consoLe during normal mode operation begins communicating messages originated by the console directly to working channel trunking cards and the c~ntrol channel trunking card over the BSL during fail soft operation, and also monitors status messages generated by the variou~ trunking cards and passes those message on to the console.
The control channeL trunking card be~ins assigning wor~ing channels for trunke~ communications when the fail soft mode is invoked instead of relying on the site controller to assign channels. The working channel trunking cards also begin performing control functions in the fail ~oft mode which are performed by the 8ite controller in t~e normal mode.
Although advanced control function~ (e.g., call logging, dynamic regrouping, and the like) are lost wh~n the fail soft mode is invoked, trunking capabilitie~ are maintained because trunking control functions ar~ distributed among the trunking cards.
As a result, failure o the primary site controller has little or no effect on normal communications and trunking capability.
In somewhat more detail, during fail soft mode the control channel trunking ~ard determines during each inbound control channel slot ta time interval during which a mobile or portable transceiver transmits its working channel acq~lisition request) if a message is being received. If an incoming message i~ arriving, the trunking card assigned to the control channel processes the message. For example, if the incoming message is from a mobile unit requesting to communicate with another mobile unit, ~o the control channel trunking card selects a free working channel, communicates a channel assignment messaye to the calling and called mobile units over the control channel, and al~o communicates the channel assignment message to the selected working cha~nel trunking card over the backup serial link.
On the other hand, if no message is being rec~ived, the trunking card assigned to the control channel polls the other trunking card~ in the syskem for statu~ lnformation,. each trunking card responding over the backup serial link within a corresponding time ~lot assigned to it. The entire poling process is completed rapidly (e.g., prior to the end of the inbound control channel message slot~.
The trunking card assigned to the control channel periodically sends cynchronization ignals to the o~her trunking card over a synchronization line during both normal and fail soft modes of operation -- causing those other units to loosely 6ynchronize working channel communications with the con~rol channel communications. The control channel trunking card i8 the "master" of site ~ynchronization timing, since it controls the timing of the synchronization line connected to all of the other trunking cards.
In the preferred embodiment, the width of the sync pulses generated by the control channel trunking card i8 used to indicate to the other trunking cards whether the 3ystem is in normal or failsoft operation.
Because each channel trunking card independently proce~se~ the RF 3ignals being transmitted and received by its ascociated repeater on an associated channel, rapid rate signalling ~3~

(e.g., 9600 baud) can be ~upported without overloading the site controller ~all signal processing is performed within ~he trunking cards themselves) during normal operation and during fail soft operation. ~ach trunking card is connected to the primary site controller computer via a separate parallel (e.g., RS-232C~ data link. Thus, failure of a parallel link and/or a trunking card does not disturb communications between the primary controller and the remaining trunking ~ards. Moreover~ this feature permits the site controller (or a human service technician) to more accurately diagnose any faults that do o~cur.
Perhaps one of the most important advantages of the site architecture provided b~ the present invention is that no single point failure can eliminate trunking functionality.
Should the site controller computer fail, higher-level sy~tem features (e.g., call logging and dynamic regrouping) are lost, but ~ignal processing -- and more importantly, trunking capability -- is still performed in a distributed fashion by the channel trunking cards ~since suficient computational power exists within each trunking card to perform trunking control processing~. Shou~d a trunking card fail, the unit can be removed from service and normal operations can continue with one le~s RF channel. All trunking cards are identical in the preferred embodiment (and all are programmed identically), 80 in the event the trunking card a~signed to operate on the control channel fails, that trunking card çan be removed from service and another trunking card can be a~signed to operate on 3~
.

the control channel (each channel trunking card is capable of acting as the control channel trunking card).
The system of this invention is sometimes termed a "digitally" trunked system besause trunking control is ~fected by digital ~ignals p~ssed over a continuously dedicated ~control" data channel. All units are programmed 80 as to automatically revert to the predetermined primary control channel upon being turned on or being reset. If the expected control channel data format i~ not there discovered, then alternate possible control ~hannels are successively monitored in a predetermined sequence until an active control channel is di~covered. In this manner, the usual control channel apparatus at the central control site may be temporarily removed from service l~.g., for maintenance purposes). This same feature al~o permits continued trunked system operation in the event that the regular control channel une~pectedly malfunctions or is otherwise taken out of service.
Should the backup serial link ~etween the trunking cards fail while the primary site controller i8 still operational, no operational features are lost because the serial link and the ~ite controller communication paths are used alternately. If the synchronization link between the trunking cards fails, RF channel ~ccess time increases slightly (e.g., from 280 milliseconds to 320 milliseconds) due to loS8 of loose synchronization between the control and working channels, but this slight a cess time increase is not noticeable to the us~r.
Perhaps one of the greatest advanta~es of the ~3~

site architecture provided by the pre~ent invention is its fault tolerance characteristic~. Prior repeater architectures have been provided with some degree of fault tolerance only by providing redundant hardware such a~ a backup site controller. This redundant hardware solution is not only expensi~e, but i~ less reliable than ~he distributed processing architecture provided by the present invention. For example, the portion of the ~y~tem which activate3 backup hardware can itself ~ail in ~he redundant hardware approach and prevent the ~ystem from recovexing.
Technology has finally made fault tolerant trunked communication systems a real~ty. The architecture provided by th~ present invention, with just one general purpose site controller, exhibits a ~hree times greater trunking reliability than the trunking reiliability of a non-fault tolerant architecture with a custom site controller ~upported by a "hot" ~tandby site controller unit.
In light of today' communication needs, and what current technology can deliver, fault tolerant trunked communication systems are mandated.
Appraising a sy~tem's capabilities require~
understanding the trade-off~ made by the designers in establishing a balance between unctionality, cost, and fault tolerance. And in the end~ the effective evaluation of a Rystem enable3 one to weed out those that talk fault tolerance from tho~e that deliver it.
These as well as other features and advantage~
of thi~ invention will be more completely understood and appreciated by carefully studying the following detailed deccription of the presently preferred ~ 30~13~

exemplary embodiment taken in conjunction with the accompanying drawings, of which:
EIGURE 1 is a general explanatory diagram of a trunked radio repeater system in accor.dance with khi~
invention;
FIGURE 2 i3 a simplified block diagram of a central control ~ite (as well as a satellite receiv~r site) in the trunked repeater system of FIGUXE l;
FIGURE 3 is a simplified block diagram of the general site architecture o~ ~he main controller for the central control site;
FIGURE 4 is a simplified block diagram of channel trunking cards u~ed wi~hin the various chann~ls of the central site architecture shown in EIGURE 3;
FIGURE S is a schematic diagram of synchronization control line timing in the ~ystem o~
FIGURE 2;
FIGURES 6A-6E are ~chematic diagram~ of exemplary signalling protocols for the messages sent on the backup ~erial link ~hown in FIGURE 2;
FIGURE 7 is a schematic diagram of exemplary backup ~orial link pollln~ mes~age and response timings of the FIGURE 2 system;
FIGURE 8 i~ a schematic diagram of exemplary backup ~erial link downlink poll and response timings ~f the FIGURE 2 ~ystem;
FIGURE 9 i~ a schematic diagram of exemplary backup serial link channel assignment messa~e timings of the FIGURE 2 8y8tem, FIGURES 10-13 are flow chart~ of exemplary program program control steps performed by the trunking cards of the system shown in FIGURE 3 to ~3(~4~L32 implement the failsoft mode of operation;
FIGURES 14, 15 and 16 are schematlc diagrams of exemplary signalling messages passed back and forth between control and working channel repeater ~tations of the FIGURE 2 ~ystem, control console 102, and mobile units during origination of an individual call by a mobile unit, an individual call by a control console, and an emer~ency group call by a mob~le unit, respectively, during failsoft operation;
FIGURE 17 is a 10wchart of exemplary steps to be taken to design a fault tolerant system; and FI~URE 18 is a schematic diagra~ of a two module Markov model of the system of ~he present invention.

An exemplary trunked radio repeater system in accordance with this invention is generally depicted at FIGURE 1. As illustrated, individual units of various groups communicate with each other ~both within and po6sible outside of their own group) via shared radio repeaters which are part of a trunked repeater system 100. The dispatch console 102 may be hou~ed directly at the repeater system site 104 or may be remotely located via other communication facilities 106 as will be apprecia~ed by those in the art. There ~l~o may be multiple dispatch consoles 102 (e.q., one for each separate fleet) and a ma~ter or supervisory dispatch console for the entare system as will also be appreciated by those in the art.
The central system 100 is depicted in somewhat more detail at FIGURE 2 in con~unction with one or 45MR5~1 more ~atellite receiver systems 100~ s will be appreciated, the satellite receiver systems are displaced spatially from the central ~ite 100 such that radio receptlon may temporarily be better at one or ~he other of the chosen antenna sy~tems. Thus, received signals from the ~atellite sites as well as the central systems are combined in "voter" circuitry 80 as to choose the best available ~ignal for control or communication processes.
At the central site,--a transmitting antenna 200 and receiving antenna 20Z (which may sometimes be a common antenna struct~re) may be utilized with conventional signal combining/d~combining circuits 204, 206 as will be apparent to those in the art.
The transmitting and receiving RF antenna circuitry 200-206 thu~ ir.dividually ~ervices a plurality of duplex RE channel transmit/rec~ive circuits included ln a plurality of RF repeater "stations" 300, 302, 304, 306, etc. Typically, there may be 24 ~uch stations. Each station transmitter and receiver -circuitry is typically controlled by a dedicated control shelf CS (e.g., a microprocessor-based control circuit) as is also generally depicted in FIG~RE 2. Such control shelf logic circuits associated with each station are, in turn, controlled by trunking cards TC (e.g., further microprocessor-based logic control circuits) 400, 402~ 404 and 406. Another trunking card 408 may be dedicated for digital data communications if desired.
All of the trunking cards 400-408 communicate with one another and/or with a primary site controller 410 via control data ~us 412. The primary ~3~

site controller (and optional backup controllers if desired) may be a commercially available general purpose proceRsor (e.g., a PDP 11/73 proce~sor with 18 MHz-Jll chip set). Although the major "intelligence" and control capability for the entire system resides within controller 410, alternate backup or ~fail soft~ control functions are incorporated within the trunking cards 400-408 so as to provide continued trunked repeater service even in ~he event that controller 410 malfunctlons or is otherwise taken out of servlce.
An optional telephone interconnect 414 may also be provided to the public switched telephone network. Typically, a system manager terminal, printer, etc., 416 is also provided for overall system management and control (together with one or more dispat~her consoles 102). A special test and alarming facility 418 may a}so be provided if desired.
The siqnal "voter" circuits 500, 502, 5~4, 506 and 508 are connected so a~ to receive a plurality of input digital or analog signals and to selectively output therefrom the strongest and/or otherwi~e most reliable one of the input signals. Thus, recaived 6ignals from the central 8y8tem site 100 are input to respective one~ of the channel voter circuits 500-$08 while additional similar input signals are generated from receivers in the satellite receiver site 100-l and also input to the appropriate respective voter-circuits. The results of the voting process are then passed back to the trunking card circuits 400-40B
where they are further processed as the valid "received" signals.
A slightly more detailed view of the site ~3~1~Z

a architecture for control data communication is ~hown in FIGURE 3. Here, the PDP 11/73 controller 410 is seen to communicate over 19.2 Kilobyte buses 412 with up to 24 trunking control cards TC controlling respective duplex repeater circuits in those individual channels. Another high-speed lg.Z
Kilobyte bus 420 is used in the down link to/from the dispatch console 102 (this downlink including a downlink trunking card). Other data communication with the central pro~essor 410 i~ via 9600 baud links as shown in FIGURE 3. The site controller 410 may include, for example, a 128 Kilobyte code PROM, 1 Megabyte of RAM and 32 DHV-ll/J compatible RS-232C
ports (connected to respective ones o~ busses 412).
Controller 410 may typically be programmed using micropower Pascal to provide a multi-tasking, event-driven operating system to manage all of the various data communication ports on an acc~ptable real time basis.
At each control~ed repeater channel, the 19.2 Kilobyte data bus 41~ (as well as another similar bus connected to an optional bacl~p site controller if desired) i8 monitored by an 8031 microprocessor in the TC module. The TC trunking control module may typically al~o receive hard-~ired inputs providing clock synchronization and a "fail soft" indication (e.g., indicating that normal control by the cen~ral controller 410 is not available and that an alternate distributed control algorithm should then be implemented within each of the trunkin~ control modules TC~. Control over the control shelf CS of its associated repeater is then achieved conventionaLly with dedicated audio and signalling ~3~ 3;~

1~ 45M~541 audio and control buses. In the preferred embodiment, conventional dedicated audio signal paths (not shown) connect each con~rol shelf CS with console 102, and a conventional audio.path switch (also not shown) is capable of connectinq audio signal paths of selected control shelves to other ~elected control shelves, the telephone interconnect block 414, the con~ole 102, etc.
Referring now to FIGURE 4, in th~ preferred embodiment, each trunking ~ard TC includes a microprooessor 502 and associated random acces~
memory (RAM) 504, a multiplexer 506, and a modem 508. Microprocessor 502 executes software stored in random access memory 504 (which is preferably non-volatile) in order to i~plement various control functions, including ~'failsoft" modes of operation.
Microprocessor 502 transmits digital co~trol ~ignals to ~ts a~sociated repeater transmitter and receiver via modem 508 and dedicated serial control line 510.
For example, microprocessor 502 can key and unkey the -associated repeater t~ansmitter, control the repeater transmitter and receiver to process audio or digital signals, and disconnect power from the transmitter and receiver in order to avoid waste o energy. Also via path 510 and modem 508, digital ~ignals received by the repeater receiver are communicated to microprocessor 502 and digital signals to be transmitted are communicated from the microprocessor to the repeater transmitter. -:
Each trunking card TC has three serial ports A, B and C. Multiplexer 506 selects only one of received ports A, B, C to be monitored by the trunking card at any one time ~the select input of the multiplexer being controlled by microprocessor 504). Port A is connected to primary site controll~r 410 via a dedicated paralLel RS-232 line ~12. Port B
i~ connected to an alternate ~ite co~troller ~if one is u4ed) ~ia a similar dedicated RS-232 ~i~nal path.
Port C is connected to backup serial link BSL --which interconnects all of trunking cards TC in dai.~y-chain fashion (as is shown in FIGURE 3).
If multiplexer 506 selects port A (which it typlcally doe~ during normal operation of the system), it receives message~ (in digital signal form) from primary ~ite controller 410 and aLso sends messages to the primary site controller as well as to the alternate site controller over the parallel line connected to 20rt B). Simi-larly, if multiplexer 506 selects Port B, it receives messages from the alternate ~ite controller (and not primary site controlLer 410), but all messayes microprocessor 502 sends to the alternate site controller are also sent to the primary site controller. In this way, the alternate site controller is constantly being updated with status change information, and can immediately take over control of the system if the primary site controller fail~.
During normal operation, the trunking cards relate process received signals and ~ignals to be transmitted, and perform very few control fu~ctions -- all or most of the control functions being performed by primary site controller 410 (or the alternate site controller if that controller iB
active). Primary site controller 410 executes multi-ta~king event-driven software to provide advanced control functions (e.g., call logging, ~3~32 dynamic regrouping, etc.) as well as simple control functions ~e.g., trunking channel assignments, priority call handling and the like) as described in Canadian Application Serial No. 566,664 filed May 12, 1988 of Childress; entitled "Trunked Radio Repeater System".
During normal system operation, the trunking cards generally simply pass received digital control signals on to primary site controller 410, pass lo digital control signals to be transmitted from the primary site controller to their associated rspeater transmitters, and performed various other operations (e.g., initiate transmissions, unkey their associated repeater transmitters, and the like) directly in response to control signals sent to them by a primary site controller. During normal operations, microprocessor 502 devotes most of its processing resources to processing signals received by a single repeater receiver and signals to be transmitted by a single repeater transmitter -- so that the system of the preferred embodiment supports very high data transmission rates (e.g., 9600 baud3.
During the normal mode of operation of system 100, backup serial link BSL is not used or needed. The independent operations of the various trunking cards are coordinated by primary site controller 410, and signal processing operations performed by the various trunking cards are loosely synchronized by synchronization signals produced by one of the trunking cards assigned to the control channel, these synchronization signals being communicated to the rest of the trunking cards via frame sync control line 520.

~L3~

Frame sync control line 520 is a single line that connects all of the tru~king cards together in daisy-chain fashion. This control line 520 is used by whichever trunking card i~ assigned to ~he control channel to notify all other trunking cards of the beginning of each 810t on the outbound control channel.
One of the trunking cards and associated repeater transmitter and receiver i~ assigned to operate on ~he predetermined full duplex control communication~ channel. This control channel is monitored by mobile units whenever they are not actually engaged in communications (such communications being performed on working channels assigned to the other trunking cards~. Briefly, the control channel i8 "slotted" ~i.e., time division multiple~ed), and outbound" control channel ~ignals are continuously tran~mitted by ~he control channel transmitter. Mobile units monitoring the control channel synchronize with the frame synchronization signal0 tra~mitted continuously on the outbound control channel, reducing the time required by the mobile units to synchronously receive and transmit control channel signals.
In the preferred embodiment, the trunking card a~igned to supervise control channel operations originates the control channel frame ~ynchronization timing signals, and place~ those timing signals on frame sync control line 5~0 ( as well as passing them to its as~ociated control channel repeater transmitter for transmission on the outbound control channel). Referring to FIGURE 5, the control channel trunking card generates a synchronization pulQe of about 833 microseconds in duration approximately 5 milli~econds ~48 bits) after the beginning of each outbound control channel ~lot (the beginning of a ~lot being indi~at~d by transmi3sion of a 16 bit Barker code~. Although any trunking card is capable of driving frame sync control line 520 (3ince any channel can be called upon to execute the control channel function3, o~ly the trunking card currently assigned to the control channel actually drive~ thi~
line. The beginning of`each contxol channel slot is marked ~y a po~itive going pulse on the rame ~ync control line 520.
Each of the other trunking cards of system 100 continuously monitors the frame sync control line 520, and the microprocessors of these other trunking cards synchronize signal process~ng functions with the pulses on the 8ync control line (and thus with the timing of t`he control channel). When a mobile unit receive~ a command transmitted on the outgoing control channel to change frequency to a working channel, the mobile unit is already ~ynchronized with ~he control channel timing. Since all working channels are ~ynchronized with the control channel by frame sync control line 520 -- and the mobile unit remains synchronized with the control channel timing until it begin~ receiving working channel signals (which are loosely synchronized with the control channel signal~), communications between the mobil~
unit and the working channel transmi~ter and receiver is very rapidly e~tablished and no lengthy process of re~ynchronizing the mobile unit with independent working channel timing is necessary.
Sy~tem lO0 in the preferred embodiment thus .

uses common timing for all of the working cha~nels - and the control channel (as well as the downlink).
In ~he preferred embodiment of ~yYtem 100, the duration of ~he pulses applied to frame ~ync control line 520 indicate whether the 6ystem i~ in the normal mode or tha failsoft mode. The control channel trunking card tests or failure of primary site controller 410, and if a failure occurs (and the alternate site controller i~ not available or not installed), it causes the sy~tem to begin operating in the ailso~t mode by increasing the durat~on o the synchronization pulses it applies to frame sync control line 520. In the preferred embodiment, the synchronizatiQn pulses have a duration of 833 microseconds (8 bit timing~) during normal operation, and have an 1ncreased duration of about 2.5 milli~econds (24 bit timings) when system 100 is in failsoft.
Electrical isolation circuitry of conventional design i9 used to electrically isolate the trunking cards from frame sync control line 520, thereby reducing the chance that the frame ~ync control line will fail upon failur~ of any trunking card. If the control channel trunking card fails to apply ~ynchronization pulses to line 520 (or the line itself failY), all other trunking cards use their own internally-generated independent synchronization timings instead of the control channel ~ynchronization timing. Working channel acces3 time i~ increased when the working channels are no longer synchronized with the control channel, but the slight increa8e (from ~80 mil1i~econds to 320 millisecond~3 due to loss of loose synchronization between the ~3~ Z

~5 control and working channels is not noticeable to users of mobile units.
When system 100 in the preferred embodiment begins operating in the failsot mode! the multiplexer~ 506 of all trunking cards select port C
and the ~ackup ~erial link (BSL) becomes active ~during normal operation in the preferred embodiment, the BSL does not carry any ~ignals). When failsoft is invoked, ~he trunking cards cease passing signal~
to and receiving signals from ~he primary site controller 410, and instead, control steps i~plementing trunking and other functionality are performed in a distributed fashion by the trunking card~ with signal-Q being communi~ated between the trunking cards via the BSL. While failure of the BSL
would prevent system 100 from operating in the failsvft mode in the preferred embodiment, it ls highly unlikely ~hat the BSL and the pr~mary site controller ~as well as the optional alternate sit~
controller) would all ail at the ~ame time.
The BSL communicates control signals between the trunking cards when system 100 i8 in the failsoft mode. The control channel trunking card i9 magter 0 the BSL -- no other trunXing card transmits on the BSL except in response to a poll message from the control channel trunking card. In the preferred embodiment, message protocol for the BSL is as ~ollows: -Start bit ~1) Data bit (8) Stop bit (1) CommunicationR on the BSL is half-duplex.
Only a few different types of message3 are carrled by the BSL in the preferred embodiment. Such messages include an update poll message, an all-poll message, a downlink poll message, and a channel assignment message. Working channels are assigned with channel assignment messages carried by the BSL. Update poll and all poll messages are used to maintain current channel assignment information within each trunking ca~d (and particularly within the control channel trunking card) -- a~ well as to permit the downlink trunking card to notify the system console 102 of channel avallability and other ~tatus information.
Downlink polls provide a mechanism for granting the downl~nk trunking card authorization to place console-generated channel assignment and channel unkey messages on the BSL.
Approximately 20 milliseconds after the beginning of each frame of the inbound control channel, the control channel trunking card determines whether an inbound message ~e.g., a mobil*
unit-generated channel assignment request message) is present. If an inbound message is present, the control channel trunking card wa1ts until the message i~ received, and responds to it if it is a group call, individual call, or emergency call channel request message (all other inbound messages are ignored in the preferred embodiment during fail~oft). In response to a channel request meYsage, the control channel trunking card assigns a working channel (if one i5 available) by generating a channel assignment message, transmitting the channel assignment message on the outbound control channel, and also applying the channel a signment message to the BSL. The trunking card associat~d with the ~3~ L32 27 45MR5~1 working channel being assigned by the channel a~signment message constantly monitors the BSL, and establishe~ communication~ with the reque~ting mobile unit in re~ponse to ~he BSL-carried channel a~signment me~sage.
WorXing channels are "dropped" (i.e., become inactive~ as soon as signals transmitted on them terminate (in the preferred embodiment, the "hang time" during which a working channel remains allocated to a particular communication after the mobile unit on the active working channel (or the console) unkeys is very short except when special priority, emergency calls are being handled). In the preferred embodiment, the trunking card a~sociated with a working channel unkeys ~ts associated transmitter and ceases to procPss incoming working channel ~ignals as soon as (or very shortly after) a communicated message ends. Thus, working channels become free for reassignment as soon as they no longer carry active conversations ~- and working channel trunking cards independently and autonomously discontinue ~ervice to working channels.
When sy~tem 100 is in the failsoft mode, the control channel trun~iny card uses polling to determine when channels have been dropped and are available for reassignment. An update poll message is used to request respon~es from all working channel trunking cards having a status which has changed since the last poll message. An all-poll mes~age force~ all channels to respond, and is sent ~t lea~t once every two seconds to all trunking cards in the preferred embodiment. Any trunking card that fail~
to respond to the all-poll message is considered to 13~4~3'~

be unoperational by the control channel trunking card and i~ remo~ed from service (although not actually physically disconnected in the preferred embodiment).
In the preferred embodiment of syst~m 100, there are 24 trunking cards as well as a downlink trunking card. In order to increase the rate at which polls are r~sponded to, any given update poll or.all-poll message communicated over the BSL is directed to only half of the trunking card~ ~although ~ery poll prompts a response rom the down~ink trunking card). Thu~, not all working channels are polled at once. Instead, the low vr high 12 channels are polled with either an updat2 poll or an all-poll message. An exemplary format for a typical polling message in the preferred embodiment is shown in FIGURE 6B.
In the preferred embodiment, the BSL is timed-shared between all of the trunking cards, and signals carried by it are timed-division multiplexed in order to prevent data transmission collisions from occurring. Each trunking card transmits a response to a poll directed to it during a predetermined time period (~lot~ a~siqned to it. The control ~hannel inbound frame is divided into fifteen e~ual slots each having a duration of 1.77~ milliseconds. When the control channel trunking card de~ermines that no inbound message is present, it transmits its poll message (either an all poll or an update poll message) during slot O (see FIGURE 7).
As can be seen from ~IGURE 6C (a ~chematir diagram of an exemplary format for a poll response message), poll response messageY are relatively short in the preferred embodiment -- including only a ~3~ 3Z

2g 45MR541 parity bit, a response bit (always set for a poll response), a bit indicating whether the responding channel is a~signed or unassigned ~this bit is set if the channel is assigned and is otherwise unset), and a 4 bit field identifying the responding channel.
Downlin~ trunking card poll responses are in the same fvrmat in the preferred embodiment, except that the assigned/unassigned bit is set if the downlink trunking card has received a mes~age from the console and i 8 otherwi~e unset.
In the preferred embodiment, the "poll type"
field of the polling message (an exemplary format of which is shown in FIGURE 6B) specifies the type of poll: update poll channels 1-12 (3BH), update poll channel~ 13-24 (3DH), all poll channels 1-12 (2FH), or all poll channels 13-24 ~2C~). A code 23H in this "poll type n field indic a te s a downlink poll, and the code AAH in this ield indicates that the message contains the first byte o the channel assigr~en mes~age).
Trunking cards 4~12 ( 1 ) -412 ( 12 ) respond to an update poll channels 1-12 message or all ~oll cha~nels 1-12 message by placing poll responses in slots 1-12 respectively following the slot O used to indicate a poll request ( see F~GURE 7 ) . The downlink trunking card responds during the thirteenth time ~lot of an update poll or all poll tc> channels 1-12, and also responds during the thirteenth time slot of an update poll or all poll to channels 13-~4.
Trunking cards 412 ~13)-412(24) respond during time 810ts 1-12, respectively of an update poll or all poll directed to channels 13-24.
The all-poll message requires all trunking 45MR5~1 cards associated with channeLs the all poll is directed to (as well as the downlink trunking card~
to respond 80 that the control channel trunking ~ard (and working channel trunking cards, which generate subaudible ætatus signal~) can determine which trunking ~ards are operational. Any trunking card which does not respond to an all poll directed to it is considered to be unavailable by the control channel trunking card. All poll message~ directed to channels 1-12 and 13-24 ar~ sent by the control channel trunking card about once every 2 s~conds.
The update poll messa~e requires all noncontrol channel trunking cards having states which have cha~ged since the last poll ~update poll or all poll) to respond. The update poll me~sages are sent every control channel time ~lot except ~hose ~uring which the BSL i~ used to carry a different ~ind o message (e.g., an all-poll mes~age, a downlink poll message, or a channel assignment message~. Update poll message responses inform ~ystem 100 in failsoft which working channels have been dropped and are available for rea~gnment.
A downlink poll message i~ a special mes~age which re~uires the downlink trun~ing card to respond hy placing a control message it has received from the console onto the BSL. When system 100 is in the normal mode and ~ite controller 410 is operating normally, the downlink trun~ing card communicates ~
messages between the ~ite controller and console 102. Console 102 is used by a dispatcher to initiate, monitor and otherwise participate in call~. During normal operation, message~ generated by the console are communicated to the downlink ;~3~L3Z

trunking card (which in the preferred e~bodiment is identical to the control channel and working channel trunking card~) which simply pa~ses the messages on to the site controller (such messages include chaNnel request messages and the like). The site controller performs the tasks requested by the console messages, and then sends resporlsivefconfirmation me~sages back to the downlink trunking card for cQmmunication back up to the console.
When system l90`is in failsoft mode, the downlink trunking card ceases communicating with the failed site controller 410 and lnstead communicates messages between the site controller and the BSL. In failsoft, the t~pes of console messages supported may be ~omewhat more limited than the messages supported duirng normal operation. In the preferred embodi~ent, the downlink trunking card is capable of transferring channel reguest message~
and unkey messages from the console to the BSL during failsoft operation. FIGURE 6D is a schematic diagram -of an exemplary format for a downlink originated channel reguest message, and FIGURE 6E shows ~n exemplary format for a downlink originated channel unkey message. The downlink trunking card also communicates message~ (e.g., unkey messages and status information me~sages) from the BSL Ip to console 102.
When a downlink trunking card receives a channel request ~r unkey message from the console during fail~oft, it waits for the next all poll or update poll message tv be generated by the control channel trunking card, and then responds to that poll message with an indication that it has received a ~3~4il3Z

console message. The control channel trunking card 800n thereafter originates a downlink poll message --authorizing the downlink trunking card to place the message it has received from the console onto the BSL
(see FIGURE 8).
The control channel trunking card monitors downlink poll responses to determine whether the console at the disp~tch center has re~uested a channel a~signment, since the control channel trunking card must ~enerate a channel assignment message in response to the downlink channel reguest message. As mentioned previousl~, active working channel t~unking cards independently drop their channel8 a8 800n as communications have ended and only notify ~he control channel trunking card that they have dropped channel upon receiving the next update poll or all-pol-l message. Each working channel trunking card also monitor~ the downlink poll reRponses to determine whether or not to drop channel (unkey) at the direction of the con~ole. Although the control channel trunking card genarates console channel request ~essages to assign channels, lt is the working channel trunking cards themselve~ that release act~ve working ~hannels in response to channel unkey messayes produced by the downlink trunking card in response to downlink polls.
The downlink trunking card moni~ors all traffic on the BSL, and con~tantly updates the console with the contents of channel assignment meR~ages, mobile unit oriyinated channel request mes~age3, and channel active/inactive status. This information i~ used by the console to provide indications to console operators of ongoing . . .: ' .

~L3~ IL32 communications and to confirm that actions requested by the opsrators have been successfully taken.
FIGURE 6A is a schematic diagram of an e~emplary format for a channel assignment message generated by the control channel trunking card in respon8e to either a mobile unit originated channel request message received by the control channel repeater receiver or to a console originated channel reque~t message placed on the BSL by the downlink trunking card. The control channel trunking card GauseS the channel a~ignment message to b~
transmitted on ~he out~ound control channel, and during the same control channel time slot, also place~ the channel assignment me~sage on the BSL.
The channel assi~nment message transmitted on the outbound control channel i~ received by all mobile unit~ monitoring ~he control channel, and directs specified mobile u~it~ (or groups of mobile units) to a 3pecified working channel (the control channel trunking card maintains a table of available channels and constantly updates this table based upon re~ponse~ to it~ poll~, so that it can always determine which channels are available and assign an available working channel).
The working channel trunking cards all monitor the channel assignment messages carried by the BSL, and the trunking card associated with an affected working channel responds to the workinq channel assignment message by transmitting a confirmation me~sage, then listening for hand6hake ~ignalling tranqmitted by mobile units whi ch have moved to the newly-assigned worki~g channel in response to the channel assignment mes~age on the outbound control 34 ~5MR541 channel, and then supporting co~nunications between the mobile units now on the ~orking channel. FIGURE
9 i8 a schemati~ diagram of the relative timing o a channel regue~t mes~age, outbound control channel assignment me~sage and application of the ~ame channel assignment message to the BSL.
Referring to FIGURE 6A, a ~hannel assignment me~sage generated by the control channel trunking card includes a polling byte (code AAH), a ~essage type field (typically code ~ ince ~ystem 100 support~ no special messages when in failsoft), a nibble indicating whether the channel assignment was requested by the console or by a mobile unit, an MT-A
code field, a co~munications type field, a logical identification numbex of the calling unit (if a mobile unit requested the call), a btt indicatins i~
a group of mobile stations (rather than just an individual mobile unit) has been called, a field containing designation of the channel being assigned (1-24 in the pr~ferred embodiment), a called group ID
field indicating the group or individual mobile units being called, a hang time field specifylng the length of titne the working channel trunking card being assigned should permit the working channel to remain assigned after co~nunications terminates, a standard/special bit (always indicating ~tandard rather than special communication~ durin~ failsoft i~
the preferred embodiment), a bit indicating whethe~
incoming messaqes should or should not be repeated ~the value of this bit depends on the type of communic~tion -- for example, console-to-individual communication~ requires no repeating, but con~ole-to-group communicatiQn~ doe~ require :~L3~

repeating), and a 8-bit parity field.
When ~ystem lOO i8 th~o failsoft mode, it i8 acceptable for only a subset of the differQnt type~
of channel assignment messageR normally available to be 6upported. In t~e preferred embodiment, three type~ o channel assignment me~sages are supported during failsoft: individual call messages (e-stablishing communication between console and an individual mobile unit or between two indi~idual mobile units), group call me~sages (e~tablishing comm~nications between the console and a group of mobile units or between all mobile units within a group), and emergency messages (identical to individual or group message~ except ~hat ~he working channel hang time i5 extended).
FIGURES 10-13 are ~low chart~ of exemplary program control ~teps performed by the trun~ing cards of the preferred embodiment to implement the failsoft mode. The operation of system 100 in fail~oft mode will now be described in connection with these flowcharts.
FIGURE 10 i~ a ~lowchart o exemplary program control steps perormed by each trunking card to determine whether system 100 i~ operating in the normal mode or in the failsoft mode. Each trunking card first determines what function it is performing by testing the state of an on-board ~witch (decision block 602). In the preferred embodiment,-all trunking cards are iden~ical in order to promote interchangeability (and to provide other advantages as well). In the preferred embodiment, each trunking card includes an on-board manually-operated three position switch which is used to instruct the ~3~1L3~

trunking card whether it is associated with the control channel, the working channel or the downlink. Decision block 602 simply determine the po~ition of this switch in the preferred embodiment.
If de~ired, a software-maintained register or storage location can be ~ubstituted for the manually-operated switch, and the contents o the register can be changed under software control depending upon various conditions 80 that functions of trunking caxd~ can be interchanged automatically without intervention by a human technician.
The control channel trunking card is the one card in system 100 of the preferred embodiment ~hat can initiate a changeover to the failsoft mode.
The control channel trunkin~ card tests whether the primary site controller 410 i8 operating correctly (e.g., by determining whether four consecutive site controller re~ponses expected by the control channel trunking card over its dedicated RS 232 parallel communlcation line are "bad" -- that is, not present or unintelligible~ (decision block 604). I the control channel trunking card determine~ primary ~ite controller 410 i8 operating correctly, it continue~
to apply pulses of normal duration (about 833 microseconds long) to frame sync control line 520 ~block 606), and e~ecute3 a "normal" mode control channel software routine (which, among other things, directs the control channel trunking card to pas~ all me~sages it receives from its associated repeater receiver on to parallel site controller 410 and to perform function~ it is directed to perform by the primary ~ite controller via control signal~ passed to it over its a~sociated RS-232 port ~block 608). On ~3~a3~

the other hand, if decision block 604 det~rmines that the primary site controller is not operating properly, the control channel trunking card begin~
applying wide sync pulses (e.g., 3 x 833 microseconds long) to ~ync line 520 -- thereby indicati~g to all ; of the other trunking cards that system 100 is now in the fail~oft mode -- and begin~ executing a failsoft ~oftware routine which will be discussed in greater detail shortly in connection with FIGURE
11 (block 610, 612).
Working channel trunking card~ determine whether ~ystem 100 i8 in the fail~oft mode by testing the duration of sync pul~e~ they receive over 8ync llne 520 (decision block 614). Working channel trunking card~ execute "normal" wor}cing channel software routines when 8ystem 100 i8 not in fail~oft mode (block 616), ancl execute failsoft working channel software routine~ when the ~ystem i~
in the fail~oft mode (block 618). Similarly, the downlink trunking card tests the duration of the pulses on sync line 520 to determine whether system 100 i8 in the failsoft mode (decision block 620), executes "normal" downlink software xoutines when the system ~ operating in the "normal" mode (block 622), and executes failsoft downlink 50ftware routine~ when the system is operating in the failsoft mode (block 624).
In ~he preferred embodiment, memory 504 of each trunking card store~ a copy of the nor~al and fail~oft control channel software routines, normal and failsoft working channel software routines, and normal and failsoft downlink software routine~
(even though only the one control channel trunking ~L3~L32 38 45MR5~1 card actually execute~ the control channel roukines and only the downlink Srunking card executes the downlink routine~).
FIGURE 11 is a flowchart of exemplary program control ~tep~ included in the failsoft control channel software routine of FIGURE 10 block 612. The control channel trunki~g card waits for the beginning o a control channel frame ~deci~ion block S30) --control channel frame timing being controlled by a conventional sotware or hardware oscillator or timer circuit included onboard the control channel trunking card. When the beginning of the next control channel slot (frame) occurs, the control channel trunking card determines whether it i8 required to generate a channel a~signment message in re~ponse to a channel reguest mes~age received during ~he last ~lot (decision block 632). I a channel assignment message i8 to be gener~ted, the control channel trunking card controls its associated repeater transmitter to transmit the assignment mes~age on the outbound control channel, and al80 applies the channel as~ignment message to the BSL
(block 634; ~ee FIGURES 6A and 9). The control channel trunking c~rd then tests whether an incoming me88age i8 being received (decision bloc~ 636).
Ater transmitting a channel assignment mes~age, the control channel trun~ing card simply waits for the start of the next control channel ~lot -- since th~
current 810t iS nearly over by the time the channel assignment message terminate~ (in the preferred embodiment, a three-slot delay i8 introduced between receipt of a channel reque~t mes~a~e and transmi~sion of a channel assignment me saga to give ~3~ 32 the ~ite controller time to process the channel request -- and this three-slot delay is preserved in the fail soft mode to preserve 3ystem timing~.
If a control channel message is coming in from a mobile unit (deci~ion block 636, 638), the control channel trunking card receives the incoming control message (block 640) and determineR whether it i8 a channel assignment reguest message (decision bloc~
642). Only individual, group or emergency channel assignment request me~ages are handled by the control channel trunking card during failsoft mode - all other inbound control channel me sages being ignored.
If there is no incoming control channel message, the control channel. trunking card te~ts whether the downlink trunking card has a console message to place on the BSL (by simply testing the last poll repon3e) (decision block 644). If the downlink trunking card does have a console message to place on the BSL, the control channel trunking ca~d generates a downlink poll (block 646; ~ee FIGURES 6B and 8), receives the message placed on the BSL by ~he downlink trunking channel in respon~e to the downlink poll (blocX 646) and then determines whether the console message is a channel assignment request (decision block 642j (~he control channel trunking card ignoring console unkey me~sages~. -If either the console or a mobile unit has reque~ted a channel as ignment (tested for by decision block 642), the control channel trunking card determine~ whether a channel i~ available for a~signment by testing a channel as~ignment table it ~3~3~

stores within it~ memory 504 and con~tantly updates with poll responses during the failsoft mode (and with channel allocation information provided to it by site controller 410 over it~ dedicated RS232 parallel signal path during th2 normai mode ~o that the trunking card already has curr~nt ~tatus and channel allocation information stored within it in the event 6witchover to failsoft mode i~
neces~ary~. If a channel i8 not available ~deci~ion block 648), an internal flag i~ set ~o that the cha~nel as~ignment message ~o be generated by block 634 during the next control channel ~lot will indicate in it8 channel field ~cee FIGURE 6A) that all channelq are busy (block 650). If a channel i8 available for as~ignment, the control channel trunking card stores the channel assignment in an internal buffer it uses to construct the channel assignment me~sage show~ in FIGURE 6A (block 652) in preparation for transmitting the channel assignment me~sage during the ne~t control channel ~lot (block 6~4). Control then returns to decision block 630 to wait for ~he next control channel lot.
If no outgoing channel aRsignment mes~age needs to be generated ~uring the current control channel 810t, there i~ no incoming control channel me sage, and the downlink trunking card ha not received a conRole message, the control channel trunking card determines wh~ther it is time for an all-poll me~sage to be generated ~block 654) (e.g., by testing ~he val~e of an internal timer to see whether two seconds or 80 ha~ passed ~ince the la~t all-poll me~age was generated). If it i8 time for an all-poll message, the control channel trunking 3~

~5MR541 card applie~ an all-poll me3sage (to either the low or high channel~) to the BSL (block 656), looks for the respon6e to the all-poll message, and updat~ an ~in-service" table stor~d in th~ control channel trunking card memory 504 which is used to indicate which channels are operational and which channels are not in ~ervice ~block 658). The control channel trunking card ~on~ider~ all trunking cards which do not respond to an all-poll me~sage to be non-operational and does not attempt to a~sign their ae~ociated channels as working channel~.
~owever, it a trunking card which previously fail6 to respond to an all-poll message begin~ once again responding to ~uch messages, the control channel trunking card updates its in-service table to indicate that the channel associated with 1t i~ once again operational.
rf decision block 654 determines that it i~
not yet time for an all-poll me~sage, the control channel trunking ~ard generates an update poll me~sage to either ~he low or the high channel~ (in th~ preferred embodiment, update poll messages are b alternately generated to ~h~ low and high channels) (block 660), decodes any re~ponses to the update poll message, and updates its channel a~signment table (stored in it~ memory 504) to reflect the current status of any channel~ which have ~een as~igned or released since ~he la~t all pQll or update poll message wa~ generated (block 662~.
FIGURE 12 iB a flowchart of exemplary program control 8tep8 psrormed by working channel trun~ing card~ when ~ystem lO0 i~ operating in the failsoft mode (block 61B, FIGURE 10). The working channel iL3~

45MR54l trunking card waits for the ne~t sync pulse on sync line 520, and then looks for a poll message on 1:he BSL (blocks 672, 674, 676). I~ an all-poll message i8 present, the working channel trunking card determine~ whether the all-poll message is directed to it (e.g., if the message is directed to ch~nnels 13-24 and a working channel trunking card i5 associated with cha~nel ll, it need not respond to the all-poll message (decision block 678). If an all-poll message dir~cted to the working channel trunking card is received, the working channel trunking ca.rd responds to the poll ~block 6B0). And at the same time, the working channel trunking card analyzes response~ generated by other trunking cards and updates an internal in-service" chann l status table accordingly (block 682). In the preferred embodiment, ~y~tem ~tatus information (e.g., whether the system i8 in normal or failsoft mode, which channels are assigned, and which channels are in service) i8 continuously transmitted over the active w~king channels along with other information 80 as to update mobile units active on the working channel of current ~y~tem status. Hence, in the preferred embodiment, all trunking carda (not just the control channel trunking card) maintains an in-service table and a channel assignment table.
: I the working channel trunking card determines an update poll message has been genarat~d by the control channel trunking card (block 674), it re~ponds to the update poll message if ~t~ ~tatu~ has changed since the last update poll or all-poll mes~age directed to it 80 long as the update poll message is directed to the channel bank it i8 a ~3~132 member of ~locks 6~4, 6863.
If the control channel trunking card has generated a downlink poll me~sage, no re~ponse i~
required by the working channel trunking c~rd, since the downlink trun~ing card i 8 the only tr~nking card which responds to downlink polls. However, the downlink trunking card may be applying a console-generating unkey mes~age in~tructing ~he working channel to drop channel. Accordingly, all working channel trunking cards monitor downlink poll responses, and if the downlink responds with a message instructing the working channel trunking card to drop its channel, the working channel trunking card control~ lts repeater tran~mitter to transmit a dotting string and then stop tran~mitting a1toge~her ~deci6ion block 688, block 6gO).
Finally, if the control ~hannel trunking card has generated a channel assig~ment message during the current control channel slot (a~ te~ted or by decision bloc~ 692), the working channel trunking card controls its ~ssociated repeater tran~mitter to begl~ transmitting if the channel assignment mes~age ~elects the working channel trunking card (block 694), s~ore~ the logical identific~tion of the caller in it~ memory 504 (block 696), and continues to supervise the operations of the as-~ociated working channel repeater transmitter and rece~ver for ~he duration of the call. The working channel trunking card update~ ~ts channel status ta~le ater all operations it p~rforms, and then waits for the beginn~ng of the next control channel ~lot (blocks 698, 682, 670).
FIGURE 13 is a flowchart of exemplary program ~ 3~t3Z

steps performed by the downlink trunking card when sy~tem 100 i8 in failsoft mode (see FIGURE 10, block 624). The downlink trunking card waits for the beginning of the next control channel slot (decision block 702), and then determines whether the control channel trunking card has placed an all poll or an update poll mes~age on the BSL ~decislon block~ 704, 706). If a poll m~ssage i9 generated by the control channel trunking card, the downlink trunking card monitors the responses to the poll mes~age generated by the various working channels, and informs the console of all status change~ Se.g., working channel6 that were assigned but have now been released). In the pre~erred embodiment, the downlink trunking card mainta~ns a ir~t in fir~t out queue ln lt~ m~mory 504 ~o that several messages intended for ~he console can be temporarily ~tored until the console has a chance to r~ceive and analyze the me8sage8 (blocX 708).
The downlink trunking card also maintains an inbound queue containing channel request and unkey message~ generated by the con~ole. If there is a console message in the inbound queue ~as teated for by decision block 710), the downlink trunking card responds to the control channel trunking card poll me~ags (regardless of whether the poll mes~age is an all poll or an update poll message and regardless of which bank of channels the poll me~sage is directed to) with an indication that there is a con~ole message to be placed on the BSL (block 712; see FIGURE 6C). In th~ case of an ~ poll mesgage, ~h~
downlink trunking card responds indicating that it ig operational (decision block 714, block 716) even 3l3~ 3~

if there is no console message to be placed on the BSL.
I f the control channel trunking card generates a downlink poll message (decision block 5 718), the downlink trunking card scans its inbound queue to determine whether there are any unkey messages stored there (unkey messages have a higher priority than channel assignment request messages in the preferred embodiment) ~block 720). If a console-10 originated unkey message is stored in the queue, thedownl ink trunking card generates a channel unkey message and applies it to the BSL (see FIGURE 6E) (block 722). If a channel assignment request message originated by the console is stored in the queue, the 15 downlink trunking card generates a downlink channel request message (see FIGURE 6D) and applies this message to the BSL (block 724).
If the control channel trunking card has generated a channel assignment message rakher than a 20 poll message (as tested for by decision block 726), the downl ink trunking card monitors the channel assignment request message and communicates its contents to the console via the downlink queue, and also stores the logical ID OI the called individual or 25 group (block 728).
FIGURES 21-23 are timing diagrams of exemplary signals transmitted and received by system 100 during operation o~ the system in the Iail gO:et mode. These signalling sequences and timings are 30 basically identical to those generated by the system during normal operation (as described in commonly-assigned Canadian Application Serial No.
566,664, filed May 12, 1988, of Childress;

1~0413~

entitled, "Trunked Radio Repeater System").
Generally, users of the mobile units communicating with ~y~tem 100 discern no difference in the operation of the ~ystem between no~mal and failsoft modes. Special callinq functions are not supported in the failsoft mode, 60 a special call request generated by a mobile unit will be ignored. The subaudible status information constantly belng transmitted by system 100 over the control and workin~ channels referably includes a bit indicating that eystem 100 is in failsoft 80 that users do not initiate special calls during fail30ft operation (or the mobile units may themselves have intelligence which inhibits all but individual, group and emergency calls from being initiated when the system is in the failsoft mo~e).
FIGURE 14 shows the signals generated by syQtem 100 during the failsoft mode of operation when the mobile unit originates a call to another individual mobile uni'. At A, the control channel tru~king card contrQls its associated repeater transmitter to transmit a continuous stream of control messageY which all inactive mobiles monitor and receive. During this time, if no incoming control channel radio messages are detected by the control channel trunking card during a control frame, the control channel trunking card polls the working and downlink trunking cards via the BSL beginning approximately 20 milliseconds after the beginning of the control channel frame. Up to twelva working channel trunking card~ and the downlink trunking card respond with status information, allowing the control channel trunking card to keep track of the ~3~132 activity of ~he various channels and the need to collect con~ole messages ~tored by the downlink trunking channel.
At B, a mobile unit that wi~hes to originate an individual call transmits an assignment request message on the control channel ln 3ynchroni~m with the received control channel messages. The individual call assignment reque~t message indicate the logical ID of the called and calling mobile units, along with other information. During normal operation of system 100, the control channel trunking card merely passe~ thi~ reque~t message up to the primary site controller 410. However, during failsoft operation, the control channel trunking card itself respond~ with ~ channel a~signment two-message pair transmitted on the outbound control channel at C, and al80 cends a channel a~ignment message to the working channel trunking cards and the downlink. trunking card over the BSL.
..~ The selected working channel trunking card proce~e~ the new call beginning at D by transmitting the confirmation mes~age. The or~ginati~g mobile (which has by thi8 time moved to the working channel frequency in response to the channel a~sig~ment ~essage transmitted on the outbound control channel~
receives a confirmation message tran~mit~ed on the working channel, and transmit~ 384 bit~ of dotting and then audio beginning at E. At F, the wor~ing channel trunking card receives the dottlng transmitted by the mobile and transmits unit-key/unmute messages to control the mobil~
unit to unmute it~ audio. Meanwhil~, all working .
4~L~2 channel trunking card~ update their channel aRsignment tables to reflect the new channel assignment, and this updated information is tranmltted over all active working channels in subaudible me~sages at G. The downlink trunking card receives the channel assiynment message over the BSL also~ and informs the console of the channel as 3i gnment.
At I, the transmitting mobile unkeys and send~ a non-~lotted unkey me~sage to the working channel recelver. In response, the workin~ channel trunking card controls its assoclated transmitter to transmit 896 to 2816 bits o dotting, thereby dropping all mobile units from the channel. At this point in time, the working channel trunking card has autonomously released the working channel. The working channel trunking card responds to the next control channel polling mes~a~e with its unassigned status, and the control channel trunking card (as well as all of the other working channel trunking c~rds) updates its channel assi~nment table to reflect the release of this working channel. The downlink trunking card monitors the workin~ channel trunking card poll response, and sends an unkey mes3age to the console to indicate that the conversation has been discontinued.
FIGURE 15 is a schematic diagram of exemplary signal timing of signals occurrin~ in response to -origination by the console of a call to an individual mobile unit. At A, the control channel tranRmit-s a continuous stream of control me~ages which all inactive mob11e unit~ receive, and if no incoming control channel radio messages are detected by the 13~'113;~

control channel trunking card, the control channel trunking card polls the other trunking card~. At B, the console wishing to originate an in~ividual call communicates an individual call messaye to the downlink trunking card. During the normal mode of operation of system 100, the downlink trunking card would simply pass thi 5 individual call message on to primary ~ite controller 410 for proper handling.
However, in the failsoft mode of operation, the downlink trunking card responds to the next poll generated by the control channel trunking card with a poll response indicating the need for a downlink poll. The control channel trunking card then generates a downlink poll, and the downlink trunking card sends a call request message to the control channel trunking card over the BSL. At C, the control channel trunking card generates a channel as3ignment message, transmits this me~saqe on the outbound control chann~l, and also applies the message to the BSL to control the assigned working cha~nel trunking card to begin handling the new call. The selected working channel trunking card b activates its associated transmitter, all other working channel trunking cards update their channel assignment tables accordingly, and the downlink trunking card informs the console that a channel assignment has been made.
In re3ponse to receipt of the outbound control channel assignment message, the called mobile unit switches to the assigned working channel and receives a confirmation mes~age on the working channel at D.
When the conver~ation has terminated, console ffends an unkey message to the downlink trunking card at ~3(;~ 3~

45~R541 In response tv the next control channel trunking card-generated poll, the do~ll~nk trunking card indicates the need for a downlink poll, which the control channel trunking card typically generates almost immediately. In response to t~e downl~nk poll, the downlink trunking card applies the console unkey me~sage to the BSL, which ~6 monitored by all working channel~ trunking card~ -- including the working channel trunking card handling the worklng channel to be ~ropped. At J, the working channel trunking card transmits 896 to 2816 bits of dotting to drop all mobile units from the channel. In response to the next control channel trunking card polling meRsage, the working channel trunking card re~ponds with'its unas~igned ~tat~s.
The downlink trunking card decodes the poll response me~sage, and sends a message to the console confirming that the working channel has been dropped.
Group calls originated by mobile units and the console cau~e system lOO to generate signalling which is e~sentially identical to that shown in FIGURES 14 9 and lS, the principal ~ifference being that all mobile units of a call group rather than an individual mobile unit ~witch to the a~signed working channel at D and receive a confirmation me~sage. The control channel trunking card maintains within it~
memory 504 a li~t of individual~ and groups of ~obile units that have already been assigned to a channel, and respond~ to a mobile unit-originated call to a group that has already been a~;signed to a channel by generating individual call signals on th~ outbound control channel which direct the calling mobile unit :

,, 13~3 ~13~

51 45M~541 to join th~ group conversation already occurring on the active working channel.
E~GURE 1~ is a schematic diagram of exemplary signalling occurring during the failsoft mode in respon~e to an emergency group call initiated by a mobile unit. At A, the contxol channel trunking card causes it3 aRsociated control repeater transmitter to tran~mit a continuous stream of control me~sages which all inact~ve mobiles rece~ve, and meanw~ile performs routine polling function~. The mobile unit wishing to originate an emergency group call transmits an a~sig~ment reque~t message on the inbound control channel in synchronism with the received control channel message~ at B. The control channel trunking card respon~s by causiny its associated tra~smitter to transmit a channel a~signment mes~age designating the called group and also by placing the channel a~signment me~sage on the BSL at C.
A11 mobile units wi~hin the callad group immediately switch to the as~igned working channel, and the assigned working cha~nel trunking ~ard keys in re6ponse to the channel as~ignment mes~age carried by the BSL. Hand~haking occurz at D, E and F. At G, acti~e mobile units on other working channel~
receive 6ubaudible channel assignment messages updating them on the status of system 100. When a transmitting mobile unit unkeys, it ~end~ a unkey -message at I. The working channel trunking card time~ a hang time delay period after the tran~mitting ~obile unit unkeys -- thus maintaining ~he channel assignment to the emergency call. When the hang time expires, the working channel tran~mit~ dottlng at J

13~13~

to cau3e the mobile units to drop from the working channel back ~o the control channel, and ~hen unkeys it~ tran~mitter. In response to the next poll from the control channel tru~kin.g card, the working channel trun~ing card responds with its unas~igned status which is used to update channel as8ignment tables within the control channel trunking card and the other working channel trunking cards, and i8 also u~ed by the downlink trunking card to inform the console that the working channel is no longer ass~gned.

~AULT TOLERAN OE EVALUATION

Following the initi~l ~ystem functional specification, five ~teps, executed as an interactive process, c~n be used for designlng the system to be fault tolerant. These are shown as a flowchart in EIGURE 17. The ~oal in the next ~ew pages i5 to highlight the breadth and depth of the decisions r~guired at each stage.

Step No. 1: Fault Tolerance Obiectives Initially a fault tolerance specification is developed. This provides an objective measurement for assessing when the design is complete. More importantly, it aids the end user in anticipating financial, managerial and per~onnel resources needed for maintaining and supporting the 8y8tem, a~ well as highlighting nece~sary servi~e contracts, the various modes of operation induced ~y failures, and the need for communication contingency plan~ or varlous ~3~3~
.' ~5MR541 emergencies .
. Examples of specific parts of the : specification are:

(Fault~ Coveraqe:
Two fault tolerance definitions exi~t for thi~ term (neither to be confused with RF
coverage). Coverage ~s a number between O and 1 ~hich indicates what percentage of errors can be automatically detected (fir~t definition) and then automatically circum~ented via reconfiguration (second definition). The first d~finition is clearly a procedural subset of the second, and i8 preferred 6ince what constitutes ~uccessfully automatically circumvented ~ia reconfiguration can be vague. The advent of microprocessors and computers have made coverage flgures of 90% easily achievable and coverage figures of 95% achievable with reasonable engineering . ` design effort~. Eigures in excess of 99~ are : achievable, but are signiflcant engineering undertakings. One ~hould note that coverage figures are difficult to ~ubstant~ate and that dual redundancy usually offers poor fault coverage, particularLy when dealiny with computer~.

Redundan~ V8 Graceful Deqradation:
Some applications require complete r~dundancy, although most can take as~vantage of "gracefu1 degradation. n The former offers litt~e additional b~neflt~ to the end u~er ~3~ 3~

while committing capital or computer and/or other equipment which sit idle waitlng for a failure. Typically one is willing to give up fiome, but not all, features when a failure occ-~rs in order to invest the otherwise spent capital in other araas ~e.g., radios).

F~ilure Modes:
Failures will force a ~ystem into a variety of modes. It is important that ~acceptable" failure modes truly be appropriate to the application. For e~ample, converting an airplane at 35,000 feet to a bus should an engine fail i5 an obvious mi~match (doiny so on the gro.und i~, of course, acceptable ) . A more ~ubtle mi smatch i s converting a fully loaded trunked sy~tem to an overloaded conventional vne just because o~e computer has failed.

~TBE - ~ean Time ~etween Failure~:
This is the average length o~ time, given that the aystem i8 functional, that the sy~tem will continue to function. Various MTBF figures can be significant, depending on the characteristics of the different modes of operation of the system (e.g., the MTBE of individual components, the MTBE of the ~ystem where a failure i~ considered to be losing at Least l/2 of the channels, or the MTBF of ~he 8y8tem~ S trunking capability).

~TTR - Mean Time to Repair:

~3~

This is the average length of time, given a failure has occurred, that it will take to repaix the failure. A~ with MTBF, there are various figure~ o~ interest, ranging from the MTTR of individual component to MTTR
of channels, to MTTR of computers, or even to MTTR of various eatures.

Step No. 2_ Featur~ Prioritization Both system design by the vendor and By~tem selection by a procuring agen~y should consider the communications problems being addre~sed in order to prioritize the various functions performed by the system. Some function~ are absolutely critical, others are highly desirable ~hile still others 6erve as convenience~. By ranking the various featurest graceful degradation of the system can be designed.
In fact, this step is the key for matching failure modes with their targeted end use in the field.
An obvious example is a 20 channel ~y~tem with a.~ailure of the control logic on one of the channels. In ~hi8 case, trunking i~ more lmportant than the one channel, 80 the end user would ra~her run 19 channels trunked as opposed to ~witching to a 20 channel conventional failsoft mode.
In a trunked communication system, the priority tend.~ to be on reliable, efficient communications withou~ changing the mode of operation for the users. Thi8 means a system designed to go into a conventional failsoft mode i8 le~ desirable than a system which simply loses features (e.g., interconnect and dynamic reqrouping), but maintains trunking wi~h no noticeable change to the end u~er.

~3U~3Z

45MR5~1 The former ignores user needs so as to simplify the engineering effort by placing the burden on the end user. The latter observes the end users needs, though it creates a more challenging engineerins problem by placing the burden on the system designer~.
An exemplary list of desirable feature priorities is as follows:
1) mobile-mobile communications 2) di~patch console operation 3) trunking ~full speed access) 4) priority scan 5) channel logic diaqnostics 6) call queueing 7) dynamic regrouping 8) patch 9) interconnect 10) background diagnostic~
11) user validation Step ~o. 3: Architecture Definition ..~ Defining a ault tolerant architecture adds another layer of considerations to the design task.
Functionality, modularity, hardware/software trade-offs and implementability are st~ll prime consideration~. Rut now one must also consider interdependence, functionality distribution, redundancy, and coverage/recovery algorithms. These additional problem elements significantly increase system complexity and proces~or loading.
One of the result~ of sound architecture design ifi modularity. This is also the case in fault tolerant de3ign, exçept marrying functional modularity with hardware and ~oftware modul~rity 13~

becomes even more important. The goal is to minimize interdependencies between various system modules, and to minim~ze the number o hardware modules needed for any particular feature. This will minimize the probability that the feature is lost when a failure occurs and maximize the probability of success of the reconfiguration process. Similarly, reducing ~co~mon" hardware minimizes the likelihood that ~ingle point failures ~ill cause the entire system to cease operating.
Although hardware and software are usually considered ~eparately, they are very interdependent in a fault tolerant design. The distinction between the "hardware architecture~ and the "software structure" becomes blurred ~t the system level (in evaluating a system, neither should be considered without understanding the trade-offs made between the two).
~ evertheless, one specific software issue should be highlighted: Software modularity is ex~remely important. In a fault tolerant system, reconfiguration capabilities are achieved by having various hardware module~ support similar functionality. Consequently, ~oftware modularity assures greater code simplicity, predictability, and reliability by forcing a single version vf software to exist for any particular function.
Error propagation is another consideration.-When a failure in the system occurs, i~ is possible for it to spread (e.g., a failed component on a computer bus can cause the ~ntire computer to cease operating). In a trunked system, this further suggests modularity and distributed processing --~3~4~

discouraging the pLacement of all control functionson a single bus computer.
Particularly in a trunking system, all these considerations suggest placing channel ~ignalling and control at each channel with overall ~ite control in ~ site controller. Thi~ lets each channel be an autonomous unit, offering both feature benefits as well a8 significant reconfiguration capabilities. ~t al~o remove~ ~ignal prQcessing loading from the ~ite controller, which can then be a general purpose computer, enabling the use of off-the-~helf hardware, multi-ta~king operatinq ~ystems, and high level languages. These, in turn, offer greater software and hardware reliability.
The next architectur~l con~ideration i~ that of coverage. The purpo~e of coverage is to detect failed modules 50 that they can be removed from cervice. Coverage should be achieved via both intra-module (self-diagnostics) and inter-module diagnostic algorithms. Inter-module testing of ç~ntrol module "~anity" 6hould employ only the existing hardware interfaces, and not e~tra hardware. On the other hand, inter-module te~ting o non-control functionality, ~uch a~ RFt often will require fipecific hardware.
In a trunked system, diagnostic~ ~hould have a negligible effect on ~ite controller loading. As more loading is caused by performing diagno~tic functions, le~s processing can be used to offer end user eature~. Thi~ i8 another reason why do-it all custom controller~ can be inappropriate. In the preferred embodiment, the monitoring of diagno~tic peripherals, and all vther diagnostic functions, are ~3~

conducted via background software routines through s~andard RS-232C interfaces interconnecting hardware blocks. The real-time monitoring is effecti~ely off-loaded from the site controller and only incurs processor loading if a fault is detected or if the site controller has nothing else to do.
~ n integral part of coverage design involves ranking failure6 based on both their likelihood of occurrence and their consequences. This is followed by designing algorithms for detecting the most probable failures. Complete coverage of any, let alone all, modules is impossible. Neverthele~s, the coverage relative to the probability of failure of each hardware and software component should be estimated and the results u~ed in evaluating the appropriateness of the given architecture. Thi6 involves maximizing coverage for the mo~t likely failures, but also considering the ~onsequences of failing to detect certain failures when they occur.
At thi~ point the necessary reconfiguration al~orithms and their resultant complexity must also be considered, *or even perfect coverage i~ usele~s if ~he system cannot reconfigure from the failure.
In a trunked system, besides RE failures, the most likely failure is the site controller or its peripherals. In the preferred embodim~nt, ~hould the failure of a peripheral go undetected, its cons~quences are minimized ( since its hardware is not lumped into the same box as the heart of the sy~tem~. AR an additional precautiorl, any peripheral failure of misdiagnos~ 8 that could re~ult in ~;evere con~equences if undetected has an alternate pat~ for verification on the part of the site controller. The :~3~

same i8 true for channel logic card failure~. There are a multitude of other processors observing the ~ite controller. Since the~e proces~ors can behave autonomously, an incorrect diagnosis of the site controller by one of the processors only affects the processor and not the rest of the system.
Recovery i8 the culmination of the architecture definition. This is where the goals of Step No. 1, the priorities of Step No. 2, the functionality overlap among system modules, and the coverage all come into play. System operational modes mugt be defined and detailed as to what ~eature~/functions are available under the various fault reconfiguration modes. Once the various modes are defined, the transition~ between the modes must be determined. Thi~ usually rPquires intermediate ~t~te~. All state6 (technically, each operational mode is considered a state) must be carefully examined and defined at this point. It is imperative that os~illatory behavior of state transitions be a~ided, and that when a module diagnoses itself or another module as bad, its decision only affects its~lf.
A methodology must exist for ~erifying the coverage and reconfiguration process. This is the appropriate time to develop those test procedures.
The preferred embodiment is an excellent ~olution for a fault tolerant trunked system.
Channel failure~ can be detected from three paths (the 6ite controller, an RF monitor unit whi~h monitors repea~er outputs in a multiplexed fa~hion, and a test unit which i8 capable of independently testing the operation of each of the trunking card~

~L!3~ 2 without significantly loadinq or depending upon the ite controller). Failures of peripherals remain local to the peripheral and only the unctionality of the failed peripheral is lost. Should the downlink fail (this is the interconnection between the site and the dispatch center), a channel can be remoYed from ~ervice and used as the downlink (a~ opposed to paying monthly fo~ the unused, redundant phone line). Should the site controller fail, trunking control is assumed by the repeater control cards:
Trunking continues and usexs perceive no difference in channet access time. Even if additional channel logic fails after the site controller has failed the system will continue to reconfigure.

Step_No 4: Cost~Resource Utilization It i~ now time to determine whether the system iB 8till affordable, and whether some of the desi~n objectives established earlier are really worth the cost. A well engineered fault tolerant system has li~tle, if any, idle hardware whose sole purpose i~
to achieve redundancy. Expensive, idle hardware 8ugge8t~ either the initial design ls inadeguate, or possibly the design constrairlts are too demanding.
Should the fault tolerance capabilities appear to be too costly, further architecture design efforts and strategic relaxation of the design objectives of Step No. 1 can be expended~
The architecture should be examined in light o the feature priorization e~tablished in Step No.
2. Do the reconfiguration modes, with their relative probabilities of occurrence, truly adhere to the design criteria ~uggested by the list? Is the ~3~ 3Z

prioritization list itself realistic with the additional understanding obtained during the design process? Clearly the design process becomes an iterative one at this point.
The architecture's complexity should be examined to determine if risk or feasibility issues exi t. Measuring complexity can be difficult. Block diagrams, state diagrams and flowcharts can be over-simplified by lumping complex i~sues into single blocks, combining states, and highlighting extraneous details. They al80 fail to represent the relationship between the probability of a failure and the degree to which the system can detect it and successfully reconfigure. Without Markov modeling, reliability claims are virtually impossible to verify and reconfiguration is far from trustworthy.

Step No. 5: Model~q The system may be modeled to determine whether it meets the fault tolerance objectives selected in Step No. 1. Markov chains are an excellent tool, providing MTBF and MTTR figures as well as providing the probabilities of the ~ystem being in each of its po~sible ~tates. It i8 based on the following:
(1) Component failures are modeled with an exponential probability distribution.
This ignores infant mortality rates, but if equipment is burned in it prove~ to be an excellent model.
(2) Failure rat~s for an aggregate of parts are also exponentially distributed since exp(A) *exp(~) = exp~A~B). The failure rat~ can either be calculated :~3(J~3Z

: ' ' u~ing military handbooks fQr the individual components making up the assembly, or can be determined by conducting life tests.
(3) P(failure in time interval t, t+T) =
exp(- /T). Thi5 will be approximated a~
simply /T with no loss of accuracy in the final re~ult.
(4) Theorem: Every finite state irreducible aperiodic Markov chain has a limiting distribution. This limiting distribution is the only equilibrium distribution.
(5) At equilibrium - P~being in state X at time t) is the same as P(being in state k at time t+T).
(6) It can be shown that the steady sta-te .
801ution is the wor8t case MTBE figure (it gives the highest failure rate . possi~le given the system is working ~t time t=O~.
(7) The ~um of the probabilities of exiting a state mu~t equal one (including the probability that a state exist~ itself in order to return to itself).
The ~um of ~he probabiliti~s of all states equals one.
(9~ The MTBF o~ the system is the reciprocal of its failure rat~.
(10) Operational states are ~tates in which the ~ystem is available (e.g., trunked). Non-operational ~3tates are state~ in which the ~ystem i 8 not 130~.3~

_ 64 45M~54l available.
(ll) The failure rate for the ~ystem is the sum of the probabilities of entering a non-operational state from any operational one. See below:

op~ F~ to Sta~ N~-Op ~ System = Pav ~ ( PJ ~ ~k) With these eleven facts, a Markov model can be constructed and a solution found using linear algebra. A two-module example is shown in FIW RE l~.
Modules "x" and "y" each have different ailure rate~ and identical repair rates. Given any sma~l interval in time, the probabilitie~ of changing to variou~ states are shown with arrows. The steps in solving for the probabilities of being in each o the four states are shown below:

.
Two Module Markov Model F~om tho m~ o th~ trbc Pl ~tt ~t) 1-(~+~ ~t ~ t ~ pl (t) P2tt+s~t) --~ +~ 0 0 p2(t) .
P~(t~) _ .~7~t 0 1-(~ t O P~
P4~t~) _ ~q~t ~ t -p4(~) ~3~l3~

_ 65 45MR541 t~o~r pc~lorm ~h~- dot~a: 1) R~Grrong- tonn~
2) Dhld~ by ~t 3) Indudo ~ Pn (t)-- 1 ~) Includ~ th~ fcct th~t t~ t Pn(~ + ~t)_-- P~(t) _ O
_ _ -t 1 1 ' ~ - ~~
O ~(~+~ p2(t) o _ ~ a.) O P~,(t) _~0_ ~ O ~ P4(~) Solvlng yleldx p ~ . ~

p~ (Pl ~ P2 ~ f'~ ) _ 66 45MR541 The interpretation of the ~tates can be considered two different ways, as depicted below:

P~-- P

Sp~m ~ p ( P
~laF--P~v~ P~ t P2 ~ P~ I

5~ 1 - p~ ( (P2~ ) ~ (P~ )) i ~T~F-- ~ + 2 ~ 2 ~ ,2 + ~,~2 In t~e serial case the ~ystem requires both modules to be operational, meaning ~hat state one is the only operational state. In the parallel case just one of the two modules is required for the system to be operational, meaning states one, two and three are operational ~tates.
It is cl~ar that for ~he ~erial case the failure rate should be the ~um of the failure rates for the two modules. In fact, the model predicts exactly that. On the other hand, the failure rate for the parallel case is not so obvious, and i it were not for the model we would have no idea what the failure rate is. 1.

13C~L32 .

_ 67 45MR541 Even this relatively simple model demonstrates how complicated the solution can becoms. Values for the various failure and repair rates can be ~ubstituted up front and an off-the-shelf conventional software package can be used to solve the simultaneous equations. If extensive modeling is to be performed, fairly sophisticated software packages are available for performing the complete reliability analy is.
To demonstrate the usefulness of Markov modeling, a ten channel version of the design depicted in FIGURE 2 was modeled and compared to a non-fault tolerant design that uses a redundant site controller. The results shown below indicate it is three times more likel~ for .trunking capability to be lost in the non-fault tolerant system with a redundant controller than for trunking capability to be lost in the fault tolerant syste~ of the preferred embodiment.

' NON--FAW T l~iTFAIILT ll~R~WT r Redun~iant SC NO YES NO
Trunkhc uTaF
h ~r~Q999 87 :512 P(fa3uro) __ 10 )~51.0000.105 0.0315 20 )oor~1.000 0.205 0.0621 . Fdur~ h dd~ dS
30 ~ocr1.000 0.202 O.O~i7 Lolw o~ t~ur~g Losa o~ msro thcn 3 cJ~onnd~

~SSUMPTIONS:
Sitc cootroii~r IJ3BF -- 1 ~r Trunklng card UTBf ~ 2 ~anc Stcltbns ~iTBF ~ 1 )ear ~iT3R --~18 ha~ra NOTE:
rcdundant Ito controilcr ia opUcrlci k~ th~ Foult Toi rant Archlt~ctur~.

.

3~3~ 32 A ., ~ 68 45MR541 While the present invention has been deficribed with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the appended claims are not to be limited to the disclosed embodim~nts but, on the contrary, are intended to cover modifications, variations and/or equivalent arrangements which retain to any of the novel features and advantages of this invention.

Claims (47)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:
1. A fault tolerant trucked radio frequency (RF) repeater system including:
plural RF repeaters each of which transmit and receive ratio frequency signals carried over at least one corresponding RF frequency associated therewith;
plural trucking card means each associated with a different one of said plural RF repeaters, said plural trucking card means each for operating alternately in (a) a normal mode and (b) a fail soft mode, said trucking card means each for cooperating with its associated corresponding RF repeater to effect RF signal transceiving in both said normal mode and said fail soft mode; and primary site controller means operatively connected to said plural trunking card means for, in said normal mode, coordinating the operation of said respective plural trunking card means so as to perform trunking control functions and thereby provide trunking of said RF
frequencies corresponding to said plural RF repeaters;
said trunking card means each communicating transceived signals between said RF repeater associated therewith and said site controller means when operating in said normal mode, said trunking card means each cooperating and communicating with others of said plural trunking card means to perform trunking control functions in a distributed manner with the others of said plural trunking card means, and communicating trunking control signals with the other trunking card means when operating in said fail soft mode, wherein trunking control functions are performed in a distributed manner by said plural trunking card means without control by said site controller means upon the absence or failure of said site controller means .
2. A method for achieving reliable radio frequency communication within a trunked radio repeater system having a digital RF control channel and plural RF
working channels, which working channels are assigned for temporary use by individual radio units specified by digital control signals on the control channel, said method comprising the steps of:
(a) operating a site controller central processor to originate trunking control signals specifying working channel assignments to calling radio units;
(b) transmitting RF messages specifying said working channel assignments over said RF control channel in response to receipt by a control channel trunking card of trunking control signals from said site controller, said control channel trunking card operating to communicate signals between said RF control channel and said site controller during normal operation of said site controller;
(c) sensing when said site controller fails; and (d) originating calling ratio unit working channel assignments at said control channel trunking card in the absence of receipt of trunking card control signals from said site controller and causing corresponding working channel assignment messages to be transmitted over said RF control channel upon sensing failure of said site controller.
3. A method for achieving reliable RF
communication within a trunked radio repeater system having a digital RF control channel and plural RF working channels, which working channels are assigned for temporary use of individual radio units specified by digital control RF signals transmitted on the control channel, said method including the steps of:

(a) receiving working channel requests originated by calling radio units and transmitted over said RF control channel with a control channel trunking card associated with said control channel;
(b) in a normal mode of operation, performing the following steps:
(1) communicating said received requests from said control channel trunking card to a site controller responsive to digital messages received over said RF control channel and over said plural RF working channels, (2) generating working channel assignment messages with said site controller in response to said communicated requests, and (3) communicating said working channel assignment messages as trunking control signals from said site controller to said control channel trunking card, thereby trunking said working channel;
(c) in a fail soft mode different from said normal mode, generating working channel assignment messages with said control channel trunking card and without receiving trunking control signals from said site controller in response to said received requests; and (d) whether or not said site controller has failed, effecting transmission of said working channel assignment messages over said RF control channel with said control channel trunking card.
4. A method for achieving reliable communication within a trunked radio repeater system having a digital RF control channel and plural RF working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the RF control channel, said method comprising the steps of:

(a) receiving working channel release RF signals transmitted by a radio unit temporarily assigned to said working channel with a processor associated with and dedicated to said working channel;
(b) de-assigning said working channel with said working channel processor in response to said received release signals;
(c) in a normal mode of operation, passing said received release signals from said working channel processor to a site controller; and (d) in a fail soft mode of operation, passing said received release signals directly to a further processor associated with said RF control channel, said RF
control channel further processor performing real time processing of digital signals communicated over said control channel.
5. A method as in claim 4 further including the steps of:
(e) transmitting digital signals over said working channel with said working channel processor at substantially 9600 bits per second;
(f) in said normal mode, reassigning said working channel with said site controller in response at least in part to said passed release signals; and (g) in said fail soft mode, reassigning said working channel with said control channel processor in response, at least in part, to said passed release signals.
6. A method for achieving reliable communication within a trunked radio repeater system having a digital control RF channel and plural working RF
channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said method comprising the steps of:

(a) operating said system alternately in a normal mode and in a fail soft mode;
(b) in said normal mode, controlling the trunking of said plural working channels with a central site controller processor, including the step of communicating trunking control signals between said central site controller processor and plural individual trunking card processors corresponding to and associated with said RF control channel and plural RF working channels; and (c) in said fail soft mode, controlling the trunking of said plural working channels in a distributed processing manner with said plural individual trunking card processors corresponding to and associated with said RF control channel and plural RF working channels, said fail soft mode trunking being performed independently of trunking control signals from said central site controller processor and including the steps of communicating trunking control signals between said plural trunking card processors.
7. A method as in claim 6 further including the step of performing real time signal processing functions associated with said control channel and plural working channels with said individual trunking card processors.
8. A method as in claim 6 wherein said controlling step (c) includes passing control signals between said trunking card processors over a backup serial link connected therebetween, said backup serial link being inactive except when said system operates in said fail soft mode.
9. a method as in claim 6 wherein said operating step (a) includes causing said system to operate in said fail soft mode when said trunking card processor associated with said control channel fails to detect signals generated by said site controller processor for a preset time period.
10. A method as in claim 6 further including:
(1) generating synchronization pulses of a first width with said trunking card processor associated with said control channel when said system operates in said normal mode;
(2) generating synchronization pulses of a second width different from said first width with said trunking card processor associated with said control channel when said system operates in said fail soft mode;
(3) applying said synchronization pulses to said trunking card processors associated with said plural working channels; and (4) operating each of said working channel trunking card processors in said fail soft mode whenever synchronization pulses of said second width are applied thereto.
11. A method for achieving reliable communication within a trunked radio repeater system having a digital control channel and plural working channels, which working channels are assigned fox temporary use of individual radio units specified by digital control signals on the control channel, said method comprising the steps of:
(a) receiving digital control signals transmitted over a communications channel with a trunking card associated with said channel;
(b) communicating said received digital control signals from said trunking card to a site controller;
(c) generating trunking control signals with said site controller in response to said digital control signals communicated thereto from said communications channel trunking card;
(d) communicating said trunking control signals from said site controller to said trunking card;
(e) operating said trunking card in response to said communicated trunking control signals communicated thereto so as to effect transmitting on said channel; and (f) if said generating step (c) and/or said communicating step (d) are not performed due to failure or absence of said site controller, inhibiting said communicating step (b) from being performed and originating said trunking control signals with said trunking card.
12. A method for achieving reliable communication within a trunked radio repeater system having a digital RF control channel and plural RF working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said method comprising the steps of:
(a) operating said system alternately in a normal mode and in a fail soft mode;
(b) communicating digital control signals between a dispatch console and a down link trunking card;
(c) in said normal mode, communicating said digital control signals between said down link trunking card and a site controller; and (d) in said fail soft mode, ceasing to receive signals from said site controller and instead communicating said digital control signals over a backup link between said down link trunking card and a further trunking card associated with said control channel.
13. A trunked radio repeater system having a digital control RF communications channel and plural working RF communications channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system comprising:
plural discrete digital signal processing means associated with corresponding plural communications channels, each of said plural signal processing means for performing signal processing functions associated with the communications channel associated therewith;
site controller means operatively coupled to each of said plural signal processing means for generating digital control signals coordinating the functions of said plural digital signal processing means and thereby effecting trunking of said communications channels;
signal path means connected between said plural digital signal processing means and said site controller means for communicating trunking control signals between said site controller means and said plural digital signal processing means;
alternate signal path means connected between said digital signal processing means for communicating trunking control signals between said plural signal processing means so as to facilitate and provide distributed trunking control; and control means operatively associated with said plural digital signal processing means for sensing failure of said site controller means, for receiving digital control signals over said first-mentioned signal path means when said sensing reveals no failure of said site controller means, and for receiving digital control signals over said alternate signal path when said sensing reveals failure of said site controller means.
14. A system as in claim 13 wherein said control means operatively associated with one of said processing means includes means for sensing failure of said site controller means in response to the absence of digital control signals applied by said site controller means to said first-mentioned signal path means and for communicating said sensed failure to the rest of said plural signal processing means.
15. A system as in claim 13 wherein said system further includes further signal path means connected to each of said signal processing means for means: and said control means of one of said processing means includes means for sensing failure of said site controller means in response to the absence of digital control signals received from said site controller means over said first-mentioned signal path means and for communicating said sensed failure to the rest of said plural signal processing means over said further signal path means.
16. A system as in claim 15 wherein said one signal processing means also generates synchronization signals and applies said synchronization signals to said further signal path means.
17. A system as in claim 16 wherein:
said one signal processing means generates one type of synchronization signals when said sensing reveals said site controller means has not failed, generates a different type of synchronization signals when said sensing reveals said site controller means has failed, and applies said synchronization signals to said further signal path means; and all of said plural signal processing means except said one processing means synchronize with said synchronization signals applied to said further signals path means, and sense failure of said site controller in response to the type of synchronization signals applied by said one signal processing means to said further signal path means.
18. A system as in claim 13 wherein:
the control means of one of said processing means periodically applies polling digital control signals to said alternate signal path means; and the control means of all but said one signal processing means applies digital control signals responsive to said polling digital control signals to said alternate signal path means.
19. A trunked radio repeater system having a digital RF control channel and plural RF working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system including:
site controller means for originating working channel assignments to calling radio units and for generating trunking control signals indicating said working channel assignments; and trunking card means associated with and corresponding to said control channel and operatively connected to said site controller means for processing signals communicated over said control channel, said trunking card means including:
means for effecting transmission of RF signals specifying said working channel assignments over said control channel in response to receipt of trunking control signals from said site controller means, means for sensing when said site controller means fails, and means coupled to said sensing means for independently originating working channel assignments to calling radio units without generation of said trunking control signals by said site controller means when failure of said site controller means is sensed.
20. A trunked radio repeater system having a digital RF control channel and plural RF working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals in the control channel, said system including:
trunking card means associated with said control channel for receiving working channel requests from calling radio units over said control channel, said trunking card means including means for communicating said received requests to a site controller means connected thereto when operating in a normal mode:
site controller means for generating trunking control signals in response to said passed requests and for communicating said trunking control signals to said control channel trunking card;
said trunking card means further including means for independently generating trunking control signals in response to said received requests when operating in a fail soft mode of operation different from said normal mode, and means for effecting transmission of corresponding working channel assignment messages in the form of RF signals over said control channel.
21. A trunked radio repeater system having a digital control channel and plural working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system including:
processing means associated with said working channel for receiving working channel release signals transmitted by a radio unit temporarily assigned to said working channel and for processing digital signals communicated over said working channel, said processing means including:
means for de-assigning said working channel in response to said received release signals, first means operative in a normal mode of operation for forwarding said received release signals from said processing means to a site controller, and second means operative in a fail soft mode of operation for forwarding said received release signals over a backup communications link to a further processor means associated with said control channel, said further processor means for performing processing of digital signals associated with said control channel.
22. A system as in claim 21 wherein:
said processing means includes means for transmitting digital signals over said working channel at substantially 9600 bits per second;
said site controller reassigns said working channel in response at least in part to said passed release signals during operation in said normal mode; and said further processor includes means for reassigning said working channel in response, at least in part, to said passed release signals during operation in said fail soft mode.
23. A trunked radio repeater system having A
digital control channel and plural working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system comprising:
means for operating said system alternately in a normal mode and in a fail soft mode; and central site controller processor means operative in said normal mode for controlling the trunking of said plural working channels through plural individual trunking card processor means, corresponding to and associated with said control channel and plural working channels;
said plural individual trunking card processor means operative in said fail soft mode for cooperating and communicating with one another to control the trunking of said plural working channels in a distributed manner without requiring trunking control by said site controller.
24. A system as in claim 23 wherein said plural individual trunking card processor means performs real time signal processing functions associated with said control channel and plural working channels.
25. A system as in claim 23 further including backup serial link means connected between said plural individual trunking card processor means for passing control signals between said trunking card processor means, said backup serial link means being inactive except when said operating means operates in said fail soft mode.
26. A system as in claim 23 wherein said operating means includes means for causing said system to operate in said fail soft mode when said trunking card processor means associated with said control channel fails to detect signals generated by said site controller processor means.
27. A system as in claim 23 wherein:
said trunking card processor means associated with said control channel includes means for generating synchronization pulses of a first width when said system operates in said normal mode, for generating synchronization pulses of a second width different from said first width when said system operates in said fail soft mode, and for applying said synchronization pulses to said trunking card processor means associated with said plural working channels; and each of said working channel trunking card processor means operate in said fail soft mode whenever synchronization pulses of said second width are applied thereto.
28. A trunked radio repeater system having a digital control channel and plural working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system comprising:

trunking card means associated with a single communications channel for receiving digital control signals transmitted over said communications channel and for communicating said received digital control signals to a central site controller means operatively coupled thereto;
said site controller means for generating trunking control signals in response to said received digital control signals applied thereto and for passing said trunking control signals to said trunking card means:
said trunking card means also for effecting trunking of said channel, and if said site controller means fails, for effecting trunking of said channel and generating trunking control signals in the absence of said trunking control signals generated by said site controller means.
29. A trunked radio repeater system having a digital control channel and plural working channels, which working channels are assigned for temporary use of individual radio units specified by digital control signals on the control channel, said system including a dispatch console, a down link trunking card, a site controller, and further trunking cards associated with said control channel and RF working channels, said system comprising:
means for operating said system alternately in a normal mode and in a fail soft mode;
means connected between said dispatch console and said down link trunking card for communicating digital control signals between said dispatch console and said down link trunking card;
means connected between said down link trunking card and said site controller operative in said normal mode for communicating said digital control signals between said down link trunking card and a site controller; and backup link means connected between said down link trunking card and said further trunking card operative in said fail soft mode for communicating said digital control signals between said down link trunking card and said further trunking card instead of between said down link trunking card and said site controller, said backup link communicating said digital control signals between said further trunking cards and said console upon failure or absence of said site controller.
30. A method for achieving RF communications channel trunking within a trunked radio frequency communications system having a digital control RF channel and plural working RF channels, which working channels are assigned for temporary use by individual radio units specified by digital control signals communicated over the control channel, said method including the steps of:
providing, for each of said RF channels, an RF
transceiver and an associated digital trunking card processor, each said trunking card controlling the operating of its associated RF transceiver; and controlling the temporary assignment of said plural working channels in a distributed manner solely with said plural individual separate and discrete trunking card processors corresponding to and associated with said RF control channel and plural RF working channels, said plural trunking cards communicating and cooperating with one another and thereby coordinating the trunking of said RF working channels.
31. In a digitally trunked radio frequency communications system of the type which temporarily assigns RF channels to mobile digital radio transceivers in response to channel request messages, a method of providing distributed trunking control including the following steps:
(a) receiving a channel assignment request message with a first trunking means associated with and corresponding to a first RF communications channel;
(b) generating a working channel assignment specifying a second RF communication channel with said first trunking means in response to said request message;
(c) transmitting a RF channel assignment message specifying said second channel over said first RF channel in response to said generated working channel assignment;
and (d) temporarily assigning said second RF channel and facilitating communications to occur over said second RF channel in response to said generated working channel assignment with a second trunking means associated with and corresponding to said second RF channel, said first and second trunking means cooperating together and communicating with one another to provide distributed trunking control of said RF channels associated therewith.
32. A method as in claim 31 wherein said method further includes the step of communicating said generated working channel assignment from said first trunking means directly to said second trunking means over a backup communications link.
33. A method as in claim 32 wherein said method further includes the following steps:
(i) testing for c o m p l e t i o n o f said communications over said second RF channel with said second trunking means:
(ii) de-assigning said second RF channel with said second trunking means when said testing step reveals said communications having completed: and (iii) communicating a message indicating said de-assignment from said second trunking means to said first trunking means over said backup communications link.
34. A method as in claim 33 further including the preliminary steps of:
(i) generating said channel assignment request message with a console; and (ii) communicating said channel assignment request message from said console to said first trunking means over said backup communications link.
35. . A method as in claim 31 further including the preliminary steps of:
(i) generating said channel assignment request message with a mobile radio transceiver; and (ii) communicating said channel assignment request message from said mobile transceiver to said first trunking means over said first RF channel.
36. In a digitally trunked radio frequency communications system of the type which temporarily assigns RF channels to mobile digital radio transceivers in response to channel request messages, a distributed processing system for providing distributed trunking control including:
first trunking means associated with and corresponding to a first RF communications channel for receiving a channel assignment request message, for generating a working channel assignment specifying a second RF communication channel in response to said request message, and for transmitting a RF channel assignment message specifying said second channel over said first RF channel in response to said generated working channel assignment; and second trunking means, associated with and corresponding to said second RF channel, separate and discrete from said first trunking means, and connected to receive said generated working channel assignment, for temporarily assigning said second RF channel and for facilitating communications to occur over said second RF

channel in response to said generated working channel assignment, said first and second trunking means cooperating together and communicating with one another to provide distributed trunking control of at least said second RF
channel.
37. A method as in claim 36 further including backup communications means connected between said first and second trunking means for communicating said generated working channel assignment from said first trunking means directly to said second trunking means.
38. A system as in claim 37 wherein said second trunking means includes:
means for testing for completion of said communications over said second RF channel, means for de-assigning said second RF channel when said testing means reveals said communications have completed, and means connected to said backup communications means for communicating a message indicating said de-assignment from said second trunking means to said first trunking means.
39. A system as in claim 37 further including:
console means for generating said channel assignment request message; and down link means connected between said console means and said backup communications means for communicating said channel assignment request message from said console means to said first trunking means over said backup communications means.
40. A system as in claim 36 further including mobile transceiver means for generating said channel assignment request message and for communicating said channel assignment request message to said first trunking means over said first RF channel.
41. A digitally trunked radio frequency communications system of the type which temporarily assigns RF working channels to mobile digital radio transceivers transmitting working channel request signals over an RF control channel, said system including:
a control channel RF transceiver for transmitting and receiving RF control signals over said RF
control channel;
discrete control channel signal processing means operatively connected to said control channel RF
transceiver for processing said transmitted and received RF control signals and for controlling the operation of said control channel RF transceiver;
at least one working channel RF transceiver for transmitting and receiving RF working channel signals over a corresponding RF working channel;
discrete working channel signal processing means separate from said control channel signal processing means for processing said transmitted and received working channel signals and for controlling the operation of said working channel RF transceiver;
control channel trunking means connected to said control channel RF transceiver for receiving channel assignment request messages from said mobile transceivers, for generating working channel assignments, and for controlling said control channel signal processing means to effect transmission of responsive channel assignment messages specifying said working channel assignments over said control channel: and working channel trunking means separate and distinct from said control channel trunking means and connected to receive said generated working channel assignments for controlling said working channel signal processing means to effect transmission of RF working channel signals over said assigned working channel in response to said working channel assignments, wherein said control channel trunking means and said working channel trunking means each include a digital signal processor separate and distinct from the digital signal processor of the other and cooperate together and communicate with one another so as to provide distributed trunking control over said working channel.
42. A system as in claim 41 further including backup link means connected between said control channel trunking means and said working channel trunking means for communicating digital signals indicating said generated working channel assignments from said control channel trunking means to said working channel trunking means.
43. A system as in claim 42 wherein said control channel trunking means includes means for polling said working channel trunking means over said backup link means.
44. A system as in claim 43 wherein:
said polling means includes means for generating an update poll message and for communicating said update poll message to said working channel trunking means over said backup link means; and said working channel trunking means includes means for receiving said update poll message and means for responding to said update poll message if said working channel trunking means has released said working channel since receipt of a previously received update poll message.
45. A system as in claim 44 wherein said backup link means includes time division multiplexing means for providing time division multiplexed serial digital signals between said control channel trunking means and said working channel trunking means over said backup link means.
46. A system as in claim 41 further including:
console means for generating working channel request messages; and backup link means, connecting said console means, said control channel trunking means and said working channel trunking means, for: (a) communicating said console-generated working channel request messages from said console means to said control channel trunking means, and (b) communicating messages indicating said working channel assignments from said control channel trunking means to said working channel trunking means.
47. A system as in claim 41 wherein:
said control channel trunking means includes storing means for storing said generated working channel assignments;
said working channel trunking means includes working channel de-assignment means for controlling said working channel signal processing means to release said working channel in response to completion of working channel RF signalling over said working channel; and said system further includes backup link means connected between said working channel trunking means and said control channel trunking means for updating the stored contents of said storing means in response to said working channel release.
CA000566663A 1987-06-03 1988-05-12 Fail-soft architecture for public trunking system Expired - Lifetime CA1304132C (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US5704687A 1987-06-03 1987-06-03
US057,046 1987-06-03

Publications (1)

Publication Number Publication Date
CA1304132C true CA1304132C (en) 1992-06-23

Family

ID=22008182

Family Applications (1)

Application Number Title Priority Date Filing Date
CA000566663A Expired - Lifetime CA1304132C (en) 1987-06-03 1988-05-12 Fail-soft architecture for public trunking system

Country Status (6)

Country Link
JP (1) JP2967573B2 (en)
KR (1) KR960009454B1 (en)
CA (1) CA1304132C (en)
DK (1) DK305488A (en)
GB (2) GB2206019B (en)
HK (2) HK80192A (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE446954B (en) * 1985-03-12 1986-10-20 Uponor Ab SET FOR EXTRUDING A DOUBLE WALL PLASTROR AND EXTRACTING TOOL FOR EXTENDING THE SET
GB2243974B (en) * 1990-03-22 1994-04-06 Motorola Israel Ltd Trunked radio system
US5541978A (en) * 1994-08-18 1996-07-30 Telefonaktiebolaget Lm Ericsson Method and system for implementing a backup digital control channel within a cellular telecommunications network
US5970416A (en) * 1996-07-31 1999-10-19 Motorola Provision of distributed call handling over a plurality of network nodes
US7373764B1 (en) * 2002-08-19 2008-05-20 Sorkin Felix L Extruded upper beam slab bolster for use in construction

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS55132137A (en) * 1979-03-31 1980-10-14 Fujitsu Ltd Multiplex radio repeater
JPS5831624A (en) * 1981-08-19 1983-02-24 Nippon Telegr & Teleph Corp <Ntt> Radio communication system
JPS58182937A (en) * 1982-04-20 1983-10-26 Nec Corp In-trouble switching system of communication controller

Also Published As

Publication number Publication date
GB2206019B (en) 1992-06-03
JPS644126A (en) 1989-01-09
GB2247380A (en) 1992-02-26
GB2206019A (en) 1988-12-21
GB8813169D0 (en) 1988-07-06
DK305488A (en) 1989-03-15
KR960009454B1 (en) 1996-07-19
KR890001307A (en) 1989-03-20
GB2247380B (en) 1992-06-03
HK80192A (en) 1992-10-23
GB9110869D0 (en) 1991-07-10
JP2967573B2 (en) 1999-10-25
DK305488D0 (en) 1988-06-03
HK80292A (en) 1992-10-23

Similar Documents

Publication Publication Date Title
US5175866A (en) Fail-soft architecture for public trunking system
US5274838A (en) Fail-soft architecture for public trunking system
US5365512A (en) Multisite trunked RF communication system with reliable control messaging network
US5650995A (en) Console dispatch in an extended multisite radio communications network
AU642138B2 (en) Method and apparatus for a distributive wide area network for a land mobile transmission trunked communication system
US4835731A (en) Processor-to-processor communications protocol for a public service trunking system
US5659881A (en) Distributed method of call arbitration in an RF trunking multisite coordinator architecture
US5128930A (en) Processor-to-processor communications protocol for a public service trunking system
US7187926B1 (en) Method and system for controlling the use of satellite transmission capacity in terrestrial networks
US5206863A (en) Processor-to-processor communications protocol for a public service trunking system
CA1304132C (en) Fail-soft architecture for public trunking system
US5970416A (en) Provision of distributed call handling over a plurality of network nodes
JP2962062B2 (en) Processor monitoring method
JP2005340993A (en) Method for detecting and restoring abnormality of base station
JP2545890B2 (en) Satellite communication earth station monitoring system
JP2633283B2 (en) Control method of multi-channel access wireless telephone
JPH10243446A (en) Down-load method for multi base station
CA1305524C (en) Processor-to-processor communications protocol for a public service trunking system
KR100221840B1 (en) Apparatus for processing command in satellite communication system
JPH03240329A (en) Call system for simultaneous notice
JPH04260232A (en) Control channel monitor system for mobile communication system
KR19990061638A (en) Frequency Hopping Frequency Sharing System Dual Controller of Switching Station
JPH024048A (en) Communication control device
JPH03252224A (en) Communication system for multiple access control system to request assignment
JPH01170126A (en) Satellite communication earth station supervisory system

Legal Events

Date Code Title Description
MKLA Lapsed
MKLA Lapsed

Effective date: 20020625