Extended Trunked RF Communications Systems Networking

The present invention generally relates to a distributed control multisite switch architecture which coordinates digitally trunked radio frequency (RF), digital data and digital audio communications within a network of multiple sites, and, more particularly, to a network interface which allows the interconnection of a plurality of multisite switch controlled networks together to form an extended overall network of communication systems.

Trunked RF repeater systems have become a mainstay of modern RF communications systems, and are used, for example, by public service organizations (e.g., governmental entities such as counties, fire departments, police departments, etc.). Such RF repeater systems permit a relatively limited number of RF communications channels to be shared by a large number of users--while providing relative privacy to any particular RF communication (conversation). Typical state-of-the-art RF repeater systems are "digitally trunked" and use digital signals conveyed over the RF channels (in conjunction with digital control elements connected in the system) to accomplish "trunking" (time-sharing) of the limited number of RF channels among a large number of users. A number of such systems are commercially available, such as the Clearchannel LTR system from E. F. Johnson and the Smartnet and Privacy Plus systems from Motorola.

Briefly, such digitally trunked RF communications systems include a "control" RF channel and multiple "working" RF channels. The working channels are used to carry actual communications traffic (e.g., analog FM, digitized voice, digital data, etc.). The RF control channel is used to carry digital control signals between the repeater sites and user RF transceivers (radiounits) in the field. When a user's transceiver is not actively engaged in a conversation, it monitors the control channel for "outbound" digital control messages directed to it. User depression of a push-to-talk (PTT) switch results in a digital channel request message requesting a working channel (and specifying one or a group of callees) to be transmitted "inbound" over the RF control channel to the repeater site. The repeater site (and associated trunking system) receives and processes the channel request message.

Assuming a working channel is available, the repeater site generates and transmits a responsive "outbound" channel assignment digital message over the RF control channel. This message temporarily assigns the available working channel for use by the requesting transceiver and other callee transceivers specified by the channel request message. The channel assignment message automatically directs the requesting (calling) transceiver and callee transceivers to the available RF working channel for a communications exchange.

When the communication terminates, the transceivers "release" the temporarily assigned working channel and return to monitoring the RF control channel. The working channel is thus available for reassignment to the same or different user transceivers via further messages conveyed over the RF control channel. An exemplary "single site" trunked RF repeater system is disclosed in commonly-assigned U.S. Pat. Nos. 4,905,302 and 4,903,321.

Single site trunked RF repeater systems may have an effective coverage area of tens of square miles. It is possible to provide one or more satellite receiving stations (and a single high power transmitting site) if a somewhat larger coverage area is desired. However, some governmental entities and other public service trunking system users may require an RF communications coverage area of hundreds of square miles. In order to provide such very large coverage areas it is necessary to provide multiple RF repeater sites and to automatically coordinate all sites so that a radio transceiver located anywhere in the system coverage area may efficiently communicate in a trunked manner with other radio transceivers located anywhere in the system coverage area.

FIG. 1 is a schematic diagram of a simplified exemplary multiple-site trunked radio repeater system having three radio repeater (transmitting/receiving) sites S1, S2, and S3 providing communications to geographic areas A1, A2, and A3, respectively. Mobile or portable transceivers within area A1 transmit signals to and receive signals from site S1; transceivers within area A2 transmit signals to and receive signals transmitted by site S2; and transceivers within area A3 transmit signals to and receive signals transmitted by site S3. Each repeater site S1, S2, S3 includes a set of repeating transceivers operating on a control channel and plural RF working channels. Each site may typically have a central site controller (e.g., a digital computer) that acts as a central point for communications in the site, and is capable of functioning relatively autonomously if all participants of a call are located within its associated coverage area.

However, to enable communications from one area to another a switching network, as for example the assignee's "multisite switch" described herein, must be provided to establish audio and control signal pathways between repeaters of different sites. Moreover, such pathways must be set up at the beginning of each call and taken down at the end of each call. For example, the site controller (S1) receives a call from a mobile radio in A1 requesting a channel to communicate with a specific callee. A caller requests a channel simply by pressing the push-to-talk (PTT) button on his microphone. This informs the site controller S1 via an "inbound" digital control message transmitted over the RF control channel that a working or audio channel is requested. The site controller assigns a channel to the call and instructs the caller's radio unit to switch from the control channel to the audio channel assigned to the call. This assigned channel is applicable only within the area covered by the site.

In addition, the site controller sends the channel assignment to the multisite switch (200) which assigns an internal audio slot to the call. The multisite switch also sends a channel request over a control messaging bus to other site controllers having a designated callee within their site area. Audio signals are routed such that audio pathways are created to serve the callee(s) and one or more dispatcher consoles 202 involved in the communication. Upon receiving a channel request, these "secondary" site controllers (in the sense they did not originate the call) assign an RF working channel to the call. Each secondary channel is operative only in the area covered by the secondary site controller. The secondary site controller(s) also sends the channel assignment back up to the multisite switch.

Thus, the caller communicates with a unit or group in another area via the multisite switch. The call is initially transmitted to the primary site controller, routed through an assigned audio slot in the switch, and retransmitted by the secondary sites on various assigned channels in those other areas. When the call ends, the primary site controller deactivates the assigned channel for that site and notifies multisite switch 200 that the call is terminated. The multisite switch propagates an end of call command ("channel drop") to all other site controllers. This releases all working channels assigned to the call and breaks the associated audio routing pathways.

In addition to providing communications between mobile radio units in different areas, multisite switch 200 provides communications between land-line telephone subscribers and radio units as well as dispatchers and mobile radio units. Land-line telephone subscribers can communicate with radio units by dialing an access number as well as a radio unit (or group) identification number which is routed to the trunked communications system through a central telephone interconnect switch (CTIS) 212 and multisite switch 200. One or more dispatch consoles 202 is connected to the multisite switch in the same manner as the site controllers 102. Both land-line subscribers and dispatch console operators can issue a channel call request through the multisite switch to a site controller 102 to call for example a mobile radio unit.

Each dispatch console 202 may participate in calls in its area. Thus, when a call comes through the multisite switch from another area to a mobile radio, the switch informs the dispatch console 202 of the call in addition to notifying the corresponding site controller 102. The dispatch operator can then listen or participate in the call. Multisite switch 200 also handles calls to groups of mobile units and/or dispatch consoles by ensuring that the site controllers for all of the callees in the group assign a channel to the group call.

The multisite switch has a distributed control architecture. The logical functions and computational workload of the multisite switch are shared by various distributed microprocessor "nodes". Each node is connected either to a site controller 102, dispatch console 202, public and/or private landline telephone exchanges and other components of the particular communications system. Most nodes function as switch interfaces and include, for example, Master Interface Modules (MIMs) for nodes coupled to site controllers and Console Interface Modules (CIMs) for nodes coupled to dispatch consoles. Each interface module is supported by a controller card that utilizes several microprocessors. All of the cards have substantially the same hardware and are interchangeable. Each card acts as a gateway interface into the distributed control switch network.

Detailed description and operation of the multi-site switch, generally, is set forth in commonly assigned U.S. patent application Ser. No. 07/658,844 filed Feb. 22, 1991 entitled "Distributed Multisite Switch Architecture", the disclosure of which is also incorporated herein by reference.

In general, trunked communications systems of the type described above operate independent of one another. Consequently, a user (or "communications unit") located in a first multisite communications system is not generally able to communicate with a second user located in a second multisite communications system. Thus, the overall coverage available to a user is limited to the particular coverage areas of a single multisite communications system. The present invention overcomes this limitation by providing fully trunked communication links between one or more multisite systems in a manner that is fast, flexible, compatible with existing multisite switch architecture and essentially transparent to users. More specifically, a dedicated Network Interface Module (NIM) is provided in the multisite switch to permit the interconnection and communication between multiple multisite switch controlled networks to create an extended overall communications network. In accordance with a preferred embodiment of the present invention, the Network Interface Module allows a remote multisite switch controlled network to appear as just another node to the local multisite switch. Each network can then communicate over this commom "node" interface permiting internetwork communication that is predominantely transparent to a network user. Moreover, using a plurality of network interface modules per switch, the overall communications network can be much extended by connecting individual multisite switch controlled networks together, for example, in series, "star" or multiple "star" configurations.

These and other features and advantages of the present invention will become more completely understood by referring to the following detailed description of presently preferred exemplary embodiments in conjunction with the FIGURES in which like reference numerals refer to like elements throughout:

FIG. 1 is a schematic illustration of an exemplary multisite trunked RF communications system;

FIG. 2 is a schematic of an exemplary architecture for a distributed, digitally trunked, RF communications multisite switching network;

FIG. 3 is a detailed block diagram of a single exemplary node (with multiple audio sources/destinations) shown in FIG. 2;

FIG. 4 is a block diagram illustrating the node (interface module) data processing and control message bus architecture;

FIG. 5 is a block diagram showing the various control buses employed in the control messaging network of the multisite switch;

FIG. 6 is a block diagram of a pair of multisite network switches interconnected through a multisite audio and control communication link via a network interface module (NIM);

FIG. 7 is a block diagram illustrating an exemplary multiple multisite network configuration having the multisite switches of each network linked together by a central multisite network switch that contains multiple NIMs;

FIG. 8 is a detailed block diagram of a network interface module (NIM);

FIG. 9 is a block diagram illustrating call traffic routing between NIMs in separate networks;

FIGS. 10A and 10B are flow diagrams outlining exemplary processing procedures for NIM call routing and channel selection in accordance with the present invention;

FIGS. 11A and 11B are information flow diagrams illustrating a login information flow and "on site" flag status arrangement that facilitates tracking a mobile communications unit;

FIG. 12 is a flow diagram outlining exemplary processing procedures for NIM communications unit/group tracking in accordance with the present invention;

FIG. 13 is a flow diagram illustrating call group information flow between multisite networks which have mobile units tracked for a particular group.

In the following limitation, for purposes of explanation and not limitation, specific details are set forth, such as particular circuits, circuit components, interfaces, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well known methods and programming procedures, devices, and circuits are omitted so as not to obscure the description of the present invention with unnecessary detail.

An exemplary trunked radio repeater system 100 in accordance with the invention is generally depicted and was described above in conjunction with in FIG. 1. In the preferred multisite system 100, for example, the site controller (S1) receives a call from a mobile radio in coverage area A1 requesting a channel to communicate with a specific callee or group of callees. The caller requests the channel simply by pressing the push-to-talk (PTT) button on the microphone of his remote RF transceiver. This informs the site controller (e.g., via an "inbound" digital control message transmitted over the RF control channel) that an audio working channel is needed. The site controller assigns a working channel to the call and instructs the caller's radio unit to switch from the control channel to the assigned working channel. This assigned working channel is thus ready to support communications within the area covered by the site.

In addition, the site controller sends a message indicating the channel assignment to multisite switch 200. The switch, in turn, sends a channel request to all other site controllers and routes audio signals such that an audio signal pathway is created between the RF repeater servicing the caller and the RF repeater(s) servicing the callee(s). Additional audio signal pathways may also be established in similar fashion such that one or more dispatch consoles 202 and land-line subscribers may become involved in the communication. Upon receiving a channel request message, these "secondary" site controllers may each assign an RF working channel to the call (e.g., if a callee designated by the caller's channel request message happens to be physically located within the coverage area serviced by the associated RF transceiving site). Meanwhile, multisite switch 200 ensures that the caller's audio has been routed from the active RF receiver of site S1 to active transmitters of each of the other sites participating in the call.

FIG. 2 is a detailed schematic diagram of the architecture of multisite switch 200 provided by the presently preferred exemplary embodiment of this invention. The multisite switch 200 communicates with each site controller 102 and dispatcher console 202 via data and audio communication lines which may include dedicated land lines or microwave links.

The multisite switch 200 establishes and removes audio connections between sites 102 and dispatch consoles 202 using a local area network of nodes (e.g., MIMs, CIMs, NIMs, CTIM, and MOMs). As shown in FIG. 2, the nodes are labelled corresponding to whether they interface with a site controller, dispatch console, landline telephone switch, another multisite switch or some other system component (or as in the case of MOM 205 perform some other control function). For example, MIMs 203 are interface modules in the switch that interface with site controllers and CIMs 204 are nodes that interface with dispatch consoles. The MOM supervises control communications over the control message bus and interfaces the system manager 211 and the MOM PC (personal computer) 252 that have supervisory responsibility for multisite switch 200 and the overall radio communications system as connected through the switch. The LRIM (206) interfaces recorders to the switch assigned to log calls for various groups or units. The CTIM (207) functions much the same as a MIM with respect to interfacing a site to the multisite switch except that it interfaces to landline telephone lines from Central Telephone Interconnect Switch (CTIS) 212 to switch 200. The Network Interface Module (NIM) interfaces one multisite switch 200 to another multisite switch at another similar radio communications system to provide an even greater coverage area. Using NIM 253, multiple multisite switches can be connected in various configurations to provide a much extended communications network as discussed in greater detail herein below.

Each node in the multisite switch is supported by a microprocessor-based controller module. All of the nodes (the MIMs, CIMs, CTIM, MOM, LRIM, and NIM) have the same hardware and are interchangeable. The nodes have different "personalities" to indicate that they are assigned to, for example, a site controller or a dispatch console, etc. Each node can be easily configured to be a MIM, CIM, etc. by setting a few switches.

As shown in FIG. 2, the nodes of multisite switch 200 are connected into a control message network 209 and a digital audio (TDM) network 210. The control message network is preferably a message network employing a conventional Global Serial Channel (GSC) digital messaging protocol, for example, as implemented using an Intel 80C152 GSC microprocessor. The GSC microprocessor is used as the communications controller in the controller module in each node and is essentially dedicated to performing I/O functions for the node. The control message bus 209 is a high speed data bus that interconnects the communication processors in the controller of each node.

The audio bus 210 comprises up to thirty-two (32) time division multiplexed (TDM) buses in the preferred embodiment. Each bus contains thirty-two (32) slots, each slot corresponding to a single audio channel. Therefore, a maximum of 1024 audio slots may be routed through the multisite switch (i.e., 32 buses.times.32 slots), although some of the slots are used for other purposes (e.g. signalling). In the presently preferred embodiment, eight (8) buses are provided and only 240 channels of digitized audio are carried by audio TDM network 210.

MOM 205 is the interface module for System Manager 211 and MOM PC (personal computer) 250. The System Manager updates databases maintained in all of the nodes. The MOM 205 maintains certain specialized databases including databases for smart calls, confirmed calls, and activity status of every node in the network. Smart calls relate to the operation of the dispatch console 202. A call is "smart" if the call is selected by the dispatcher via a select speaker in the console 202. A confirmed call is one for which the audio channel and slot assignments must be confirmed before the caller begins talking. A node's status (e.g., active or inactive) is monitored periodically by the MOM. Polling messages from the MOM addressing specific blocks of nodes are transmitted over control message bus 209. Each node monitors the control message bus to determine if its address falls in the range currently being addressed. If it is, the node responds to the poll by sending a Node Access Message (NAM) over the message bus to the MOM. The MOM then correlates each received NAM with its corresponding node of origin to record its active status in the node activity status data base.

As part of the multisite switch initialization procedure, the nodes connect their assigned TDM bus slots to the node's external channel inputs. For example, a MIM will assign each channel from its site controller to a separate audio TDM bus slot on audio network 210. Once the TDM bus slot is linked to the site channel, the bus slot continuously receives the output from the channel through the host node without requiring further channel setup. Of course, the site channel has no intelligible signal until it is assigned to a call by the site controller. Although a TDM bus slot is linked to a corresponding site channel, no other nodes (MIM, CIM, etc.) listen to that bus slot until the host node sends a slot assignment message throughout multisite switch 200 over message network 209 notifying all nodes that an active call from the site has been assigned to that bus slot.

FIG. 3 is a high level block diagram of a single (multiple audio channel) exemplary MIM 203 provided by the presently preferred exemplary embodiment of this invention. The architecture of other nodes is virtually the same as that for the MIM. As mentioned above, the "highway" used to communicate signals between interface modules includes an audio (TDM) network 210 and a control message network ("GSC") 209. The TDM audio bus simply transfers whatever digital information is placed on the TDM bus slot. MIM 203 typically services multiple RF channels providing multiple audio source/destinations each of which are connected independently to a TDM bus slot.

MIM 203 includes a controller module 300, a backup controller module 302, and plural (preferably eight) audio modules 304 (only four are shown for purposes of illustration). Each audio module 304 in the preferred embodiment is connected to a maximum of four RF repeaters of an RF trunking site, or in the case of a CIM and a CTIM (for console and landline communications) to four bidirectional audio links. For example, audio module 304(A) includes bidirectional audio links 306(1)-306(4) serving associated first through fourth trunked RF repeater site "channels" (i.e., RF transceiving/repeating decks associated with particular trunked RF channels). The audio modules 304 act as source gateways ("entrance/exit ramps") which convert analog audio signals generated by MODEMs from the trunked repeater sites into digitized audio (PCM) signals and place the digitized audio signals onto the audio TDM network 210. These same audio modules 304 act as audio destinations by taking selected signals from the audio TDM network 210, converting them from digital into analog form, and providing the resulting analog signals to the RF repeater site "channels" for transmission via RF links.

Controller module 300 communicates with each of the four audio modules 304 via a common HDLC link 307 and an audio control link 308. The HDLC link 307 is used, for example, to carry fault indications and messages relating to RF "channel" status between audio modules 304 and controller module 300. Audio control link 308 permits the controller module node 300 to set channel parameters (e.g., level adjustment, TDM slot assignment, etc.) within each audio module 304.

Detailed description and operation of the audio modules 304 is set forth in commonly assigned U.S. patent application Ser. No. 07/658,636 entitled "Audio Routing Within Trunked Radio Frequency Multisite Switch" filed on Feb. 22, 1991 and incorporated herein by reference.

FIG. 4 shows a block diagram of an exemplary architecture for node controller 300. Each node controller 300 includes a communications controller 310, a dual-port random-access-memory (RAM) 312 and an interface processor 314. Communications controller 310 receives and routes control messages between the control message bus 209 and interface processor 314. Communications controller 310 may be, for example, an Intel 80C152 GSC microprocessor. Dual-port RAM 312 is used to communicate between the communications controller and the interface controller. Messages received from site controller 102 over the serial port 316 are translated into a format usable by the multisite switch. The communications controller 310 also translates multisite switch messages into a format that the site controller or console understands.

Interface processor 314 performs substantially all the logical functions for the node (interface module) and is effectively the "intelligence" of MIM 203. Interface processor 314 (which may be, for example, an Intel 80C186 microprocessor) initially assigns TDM bus slots to channels for the individual RF transceivers associated with audio links 306(1)-306(4) of audio modules 304 using parallel audio control bus 308. The interface processor sets up the connection between a site RF channel (or an audio/dam channel at a dispatcher console or a CTIS) and the audio slots on the multisite switch TDM audio bus to establish a communications link for a call and also terminates the link when a call ends. As previously described, each MIM is preassigned a set of TDM bus slots for outputting audio signals onto the TDM bus, and these slots are not assigned and de-assigned during the course of normal call routing. A more detailed description of the node controller architecture is provided in commonly assigned U.S. Pat. No. 5,239,538 to Gulliford et al., entitled "Controller Architecture for an RF Trunking Multisite Switch", which is incorporated herein by reference.

Each call through multisite switch 200 is patched from its assigned TDM bus slot on the audio bus 210. Since the interface processor for each node assigns slots, connects audio slots to the site controller or dispatch console to establish a communications link, and terminates calls, the nodes must continually inform each other of their slot assignments when a call involving that slot becomes active. Accordingly, the nodes send control messages regarding slot assignments, slot updates and slot idles over the control message network 209 to other nodes.

The communications controller (310) for each node initially processes all of the messages on the GSC message network (209). Slot assignments are forwarded to the interface processor (314) through a dual-port RAM (312). The communications controller also processes slot update and slot idle messages by referring to a slot bit "map" or database, located and maintained in the dual-port RAM, for all TDM bus slots on the audio bus. By referring to the slot bit map, the communications controller determines whether the slot status message conveys information already known, or if the slot status message conveys new information about a TDM bus slot. Update messages are sent regularly by the nodes hosting calls to confirm to other nodes the active status of a slot. When a host terminates a call, it sends a "slot idle" message to the other nodes and also periodically resends idle messages until the slot is involved in another call. Thus, all nodes are continually informed of the status of all TDM bus slots that have been assigned at least once. A more detailed description of the slot bit map and slot status messages is provided in commomly assigned application serial number 07/658,640 filed on Feb. 22, 1991 entitled "Message Bus Slot Update/Idle Control and RF Trunking Multisite Switch" which is incorporated herein by reference.

Each MIM is coupled to its site controller through a standard serial telephone line or other transmission media. MIMs receive digital command signals from their site controllers 102 through a downlink line as is described in commonly assigned U.S. Pat. No. 4,835,731, entitled "Processor-To-Processor Communications Protocol For A Public Service Trunking System" also incorporated by reference.

Each MIM also maintains a radio unit database that identifies the radio units within its site and the groups that correspond to active calls. These databases are set up by the system manager 211 (FIG. 2) and sent to all interface modules. The radio unit database identifies each mobile radio unit in the wide area system. For each MIM, some of the mobile units will be in its assigned site area and others will be outside of its area. Each MIM keeps track of which units are in its area and which group(s) is currently selected by the unit. Since each mobile unit may be capable of participating in several different groups, the mobile unit operator selects the desired group at any particular time. Whenever a call comes in for the selected group, then the unit will receive the call.

The MIMs also maintain a group database. A group is a collection of units that communicate together on a single call. For example, there may be a group for the fire department that allows all of the fire trucks to listen to the central dispatcher or the fire chief. The dispatcher programs this group into his console to broadcast messages to all fire trucks. Similarly, groups can be established for rescue stations, police units assigned to a particular precinct, and many other combinations of users of the public service radio system.

When a unit enters a new site area, a log-in message is sent from its new site controller to the corresponding MIM identifying the unit and its currently selected group(s). The MIM receiving the login signal through its serial control port 304, i.e. from the site controller via the downlink, increments the group "count" for the unit's selected group. Similarly, when a unit leaves an area, the corresponding MIM logs the unit out of its group count database by decrementing the count of the unit's current group. In addition, when a unit changes groups, it sends a group login message that causes the MIM for its area to increment the count for the newly selected group and decrement the count of the old group.

The procedures followed by the multisite switch 200 in activating a call from a radio unit and from a dispatcher console, confirming receipt of the call request, and terminating the call are now described. A more detailed description of the messaging and protocols involved in the call setup and takedown procedures is provided in commonly assigned U.S. Pat. No. 5,200,954 entitled "Communication Link Between Multisite RF Trunked Network and an Intelligent Dispatcher Console," the disclosure of which is incorporated herein by reference.

A "primary" MIM receives a radio unit originated channel assignment from its corresponding site controller. This signal indicates that a mobile unit in the area assigned to that MIM wants to call another unit or a group and its site controller has assigned a channel to the call for its area. The MIMs assigned to callees are "secondary" MIMs. The channel assignment is sent to the multisite switch as described above and received in the MIM by the communications controller 310 as are all communications from outside of the multisite switch. The MIM translates the site channel assignment into a TDM bus slot assignment for use within the multisite switch and that the slot assignment is sent to all other interface modules and components. The primary MIM logs that TDM bus slot (i.e. channel) as active and also performs slot status updating tasks by sending slot update messages to the other interface modules.

More specifically, referring again to FIG. 2, the MIM responds to the site originated TDM bus slot assignment by sending messages on the multisite switch message bus 209. A TDM slot assignment message is sent to all multisite switch components (e.g., interface modules or .sup."nodes") identifying the TDM bus slot on the audio bus 210 that is assigned to the call. Upon receipt of the slot assignment message, each CIM (204) looks through its database to determine if the callee is programmed at its corresponding console 202. If the callee is programmed and the channel assignment message indicates that the audio is not encrypted, CIM 204 connects its corresponding dispatch console 202 to the audio slot for the call. In this way, the dispatch console can monitor all unencrypted calls involving groups or units that have been programmed by the dispatcher. The MOM (205) sets up group calls, informs CIMs of smart calls, and tracks which calls have been "selected" by a dispatch console. The secondary MIMs receive a TDM bus slot assignment and a slot update from the primary MIM. Each MIM checks its unit database to determine whether the callee(s) is listed as being in its area. If the callee(s) is not in its area, then the MIM does nothing. If there is a callee(s) in its area, the MIM is designated as a secondary MIM and sets the assigned TDM bus slot bit (or clears the bit if the slot assignment says the channel is dropped) on the bit map maintained in its RAM (312) to stop subsequent updates from being sent to the interface processor (314).

Each node is essentially a circuit card or board which is physically inserted into a centralized interconnect terminal which includes a back plane having all of the necessary hardware connections between the nodes, e.g. power, data, and control buses. Each node has a unique node identification number that may be dynamically assigned. In addition, DIP switches on each node card can be manually set to indicate whether that node is an "end node" (i.e., a node located at a physical "end" of message network bus 209 in the multisite switch). FIG. 5 symbolically represents the configuration of nodes connected to the back plane. As depicted, two GSC message buses 209a and 209b are bidirectionally connected to each node. End node 406 and GSC BUS 209b are provided for bus failure (i.e., break detection and prevention). In the preferred embodiment, the nodes are configured such that MOM 205 is inserted at one end of the back plane at one bus termination (e.g. the left end in FIG. 5), and an end node 406 is connected to the opposite end of the back plane (e.g. the right end in FIG. 5). Between MOM 205 and end node 406, the remaining nodes represented by nodes 1, 2, etc. (404) are bidirectionally hardwire-connected to the GSC buses 209a and 209b. All of the nodes including MOM 205 and end node 406 are also connected to a GSC bus select line 402 used to coordinate uniform node switching from one GSC control message bus to the other whenever required. A more detailed description and operation of the MOM is provided in commonly assigned U.S. application Ser. No. 08/084,944, filed Jul. 2 1993, entitled "A Multisite Trunked RF Communication System With Reliable Control Mesaging Network" and incorporated herein by reference.

In accordance with the present invention, to permit the interconnection and communication between multiple multisite switch controlled systems so as to create an extended overall communications network, one or more dedicated Network Interface Modules (NIMs) are also provided within the multisite switch. The Network Interface Module (253) consists of substantially the same hardware as used for other nodes, such as a MIM, but is software configured to allow a remote multisite switch controlled network to appear as just another node to the local multisite switch. Each network can then communicate both TDM audio and GSC message information through this common "node" interface resulting in intersystem communication that is mostly transparent to a network user. Moreover, using the basic MIM site interface design and protocol allows maximum use of existing hardware and software. Furthermore, using a plurality of network interface modules per switch, the overall communications network can easily be much extended, for example, by connecting individual multisite switch controlled networks together in a star or series configuration as explained further herein.

Referring now to FIG. 6, an exemplary extended networking arrangement is shown consisting of a pair of multisite network switches (701, 702) interconnected via NIMs (710, 720) through a multisite link (700). For the simple arrangement shown, all that is required is a single multisite link and a single NIM at each multisite switch to control the interface. Multisite link 700 consists of one internetwork control channel and up to twenty (20) internetwork audio channels and may utilize conventional T1 landline or microwave communication links. The NIM essentially performs like a virtual MIM-like site interface between two multisite switches. For a more complex extended network arrangement, multiple NIMs may be utilized at each multisite switch. For example, a "stargate" system arrangement, such as shown in FIG. 7, might consist of more than two multisite switch networks linked together by a central multisite switch network that contains multiple NIMs.

In the preferred exemplary embodiment, the NIM uses an RS232 serial link for the control link, which can configured for 9600 19.2K or 38.4K baud operation. The average control message signalling for a multisite linked call, including call set up and call teardown, requires about fifty (50) bytes (based on the MIM type protocols described in the commonly assigned related applications described above). The NIM assigns audio channels in simplex and will assign an idle audio channel for each call attempt. Such simplex channel selection allows each multisite switch to select from the full set of audio channels independently. In the unlikely event that no idle channel is available, the NIM queues the call in an assignment queue located in an internal nonvolitile RAM memory (possibly resulting in some delay).

Referring to FIG. 8, the architecture of NIM 253 (similar to the MIM module described above) includes a controller module 300 and up to eight audio modules 304 which are connected to the controller via audio control bus 308 and HDLC link 307. The description and operation of controller module 300 is consistant with that described in conjunction with the interface module controller card architecture depicted in FIG. 4. The description and operation of each audio module 304 is consistent with that described above in conjunction with the architecture of the audio modules as set forth in commonly assigned U.S. patent application Ser. No. 07/658,636 entitled "Audio Routing Within Trunked Radio Frequency Multisite Switch" and incorporated herein by reference. The individual audio/data channels of NIM 253 audio modules 304 connect to corresponding internetwork communication links (channels) through a multisite link (depicted in FIG. 6). Each NIM supports up to twenty (20) internetwork audio links (channels) and at least one control link.

The NIM operation supports both transmission trunking and control message trunking using simplex or duplex communications for the audio links. To the originating multisite switch network, the NIM appears as a normal node receiving a call over the TDM audio bus (i.e., a MIM-like trunked site). To the destination multisite switch network, the NIM appears as a normal node (trunked site) originating the call. This fully trunked arrangement provides very fast access times throughout the extended network.

Each NIM controller is software configured for performing all node functions, such as tracking channel assignments, updates and idles of other interface modules of the multisite switch in its corresponding data base, in the same manner as described above for the MIMs and other nodes (see commonly assigned U.S. Pat. No. 5,239,538 identified above). In addition, each NIM is also responsible for tracking mobile communication units (operators) between linked multisite networks, monitoring call traffic on the local multisite switch network and routing any calls that have operators tracked to the remote switch network, selecting an audio channel for all calls routed by the NIM, and broadcasting all calls received from the remote mulltisite switch network to all sites/consoles on the local multisite switch. These main NIM processing tasks are now described starting with FIG. 9 which illustrates the general call traffic routing process between a NIM pair at two different multisite switch networks.

Referring to FIG. 9, long dashed lines are indicative of call traffic originated on multisite switch A and dotted lines are indicative of call traffic originated on multisite switch B. As illustrated by blocks 901, 902, and 903, each NIM has the additional capability of performing three respective main procesing tasks of: 1) routing local calls; 2) selecting an audio channel; and 3) broadcasting remote calls. The NIM pair initially configure themselves to operate in a Master/Slave relationship (predetermined, for example, by conventional switch or software flag settings). The Master NIM performs all channel selections so as to preclude the arising of call collision conditions (also known as "glare") resulting from the same channel being selected on both ends simultaneously. Accordingly, the audio channel selection processing task (2) is only run on one NIM of a NIM pair. In the configuration shown in FIG. 9, NIM A operates as the Master NIM. The process flow for handling internetwork communications in each NIM will now be described in conjunction with FIGS. 10A-10B.

Referring to FIG. 10A, the NIM call routing task processing illustrated is first explained. In the present invention, a callee must be "multilink enabled" for internetwork routing to take place. Accordingly, a special multilink enable bit for this purpose must be added to the conventional multisite switch network System Manager unit/group definitions. The routing task monitors all call traffic on the local multisite switch, and picks up any calls that need to be heard on the remote switch network. The processing is similar to a MIM site interface call routing procedure. Mobile communication unit tracking information is contained in the local NIM controller memory (NIM tracking procedures discussed further below). Local multisite switch network calls are examined (block 1010). A call is routed by the local NIM only if the called entity has multinode privileges (decision block 1020), and is "tracked" to the remote multisite switch network (decision blocks 1025, 1030 and 1040). Next, the call "type" is determined (decision block 1025). For an "individual" type call, the individual mobile communication unit is tracked to the remote NIM when the individual is initially "logged on" at any trunked site on the remote network. For a "group" type call, the call is tracked to the remote NIM if any units are logged on to the group at any trunked site on the remote network. The call is not routed and is not handled by the local NIM if the call has not been tracked to a group or unit in the remote NIM (decision blocks 1030 and 1040). If the local NIM is a "master" (decision block 1050), the channel selection will be made locally by local NIM channel selection task processing (block 1060). If the local NIM is a "slave", channel selection will be handled by the master NIM at the remote network (block 1070).

The second main NIM task process of channel selection is now discussed. Briefly, as previously explained, the NIM has two different channel selection modes: Transmission trunked (simplex) and Message trunked (duplex). In the transmission trunked mode the NIM assigns a channel for a radio/console PTT (push-to-talk) signal, and drops the channel on unkey. The operation is similar to transmission trunking for a trunked MIM site, except that the NIM can route two different simplex calls in opposite directions on the same channel. In the message trunked mode, the NIM reserves a separate channel in both directions (i.e., a "duplex" channel) and keeps them "reserved" for some predetemined "hang-time" between PTT signals. This ensures that the channel is available for subsequent PTTs during the duration of a "conversation".

Referring now to FIG. 10B, call type is first determined (block 1110). If it is a transmission trunked call, the channel data base stored in the NIM controller is first searched for a free simplex channel (block 1120). If a simplex channel is not free, an available duplex channel is used (block 1140). If either type channel is available, it is used for the call (block 1150). If neither are available, the call is queued and channels are assigned as they become available (block 1160). If the call is a message trunked type call then the channel data base is first checked to see if a duplex channel is currently still reserved for that call (block 1142). If a reserved duplex channel is not found, the data base will be searched for an available duplex channel (block 1142). If no duplex channels are currently free, the call will be queued (block 1160). If a duplex channel is still reserved for the call or an available duplex channel is found, it is assigned to the call (block 1150).

The NIM controller also searches its entire channel data base for each call to provide error detection (e.g., calling radio already busy on another channel), and to allow prioritizing channel selection. For example, for a simplex call, a channel free only in the direction of the call is selected in favor of a channel free in both directions. This allows the former to be used by a duplex call if required.

The third main processing task (not illustrated) performed by the NIM is to broadcast the presence of an incoming remote call. The NIM on the destination multisite switch network connects the transmit audio to the multisite switch TDM audio bus slot assigned to the channel. It then broadcasts a "slot assignment" to all other interface modules (nodes) in the switch, informing them of the incoming transmit audio.

As mentioned above, all mobile communication units are tracked between networks. Tracking information is contained in a data base in every NIM controller memory. Each NIM uses the same tracking data base arrangement as a MIM (or a CIM). However, whenever a NIM changes an element in its tracking data base, it must also send a message to the remote NIM to which it is connected so that the remote NIM can update its tracking data base accordingly. Basically, a mobile communications unit is marked as "on site" at a local NIM (i.e., a software flag is set in tracking data base of that NIM), only if it is also marked as "on site" at a MIM or NIM located on a remote network to which the local NIM is connected. Likewise, a unit is marked as being "on site" at a remote NIM if the unit is logged as being "on site" by any MIM or other NIM on a local multisite switch network connected to the remote NIM. Consequently, a previous (or original) login site of a mobile unit can be tracked back between networks by noting which NIMs have the unit marked as "on site" in their tracking data base.

This arrangement may be more clearly illustrated by FIGS. 11A and 11B which show the flow of login information for mobile radio unit/group login procedures (dotted lines) both within and between multisite networks MSC1, MSC2 and MSC3 interconnected in an exemplary star configuration. FIG. 11A shows the login information flow and "on site" flag status for an exemplary mobile unit, "A", which logs on at site "1" on MSC1. (A "**" is used to indicate that a node has its "on site" flag set for unit "A"; a "XX" indicates that the flag is not set at the node for unit "A"). FIG. 11B shows the login information flow and "on site" flag status when mobile unit "A" roams to site "2" on MSC2. As a mobile unit attempts login at a site in a different network, it is tracked back to a site on its previous multisite switch network, the "on site" flag at that NIM is cleared, the login information for the unit is sent to the remote multisite switch and an "on site" flag in the remote NIM is set. An exemplary NIM processing procedure for tracking a mobile communications unit is depicted by the flow diagram of FIG. 12.

Referring now to FIG. 12, before mobile radio call login information (e.g., unit ID/group ID) is processed by a NIM, it first determines the source of the login information (blocks 1210 and 1220). If login information of a mobile unit which had roamed to another network was received by a NIM via its local network GSC message bus, the NIM checks its tracking data base to determine if that unit is currently marked as "on site" (block 1230). If the unit is marked as "on site", the unit is logged off the NIM by clearing its "on site" flag in the NIM tracking data base (block 1232). A "group count", indicating the number of units that are logged on site at the NIM as members of the particular call group to which that unit belongs, is also decremented. The login information is then sent to the remote NIM via the appropriate control link (block 1234). On the other hand, if the source of the login information is via the control link from another network and the NIM tracking data base indicates that the unit is not currently marked as being "on site" (block 1240), then the unit is logged on the local NIM by setting the "on site" flag, the group count is incremented (block 1242) and the login information is broadcast over the local network GSC message bus (block 1244).

In yet another example of call tracking, FIG. 13 illustrates the information flow that takes place between NIMs, CIMs and MIMs at multisite networks MCS1-MCS3 for a group call where sites "1", "2" and "3" in different networks have mobile units tracked for a particular group.

While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.