Dynamic regrouping for trunked radio systems

- 1 - 45MR-00591 13~9~ DYNAMIC REGRO~PING ~O~ TRUNRED RaDIO COMMUNICA~ION8 SYS~N CRO88-REFERENCES TO REL~TED APPLICATION5 This application is-related to commonly assigned Canadian Application Serial No. 580,097 filed on October 13, 1988. This application is also related to the following commonly-assigned Canadian Application Serial No.'s all filed on May 12, 1988: Application Serial No. 566,664 o~ Childress et al; Application Serial No. 566,~63 o~ Childress et al; Application Serial No. 566,660 o~ Childress; Application Serial No.

566,662 of Childress et al. This applica~ion is also related to the following commonly assigned Canadian applications serial numbers filed on October 13, 1988:

Application Serial No~ 580,065 of Nazarenko et al; ~ Application Serial No. 580,064 of Dissosway et al;~and Application Serial No. 580,094 of Cole et al . This application is also related to Canadian Application ~J Serial Number ~9~ ~93 , filed ~ ~r~r~ æ3,j7~7 .

,A` i' .~IE~D OF THE INVENTION This invention is generally directed ~Q the art of trunked radio repeater systems. It is more particularly directed to a trunke.d radio repeater system arrangement and me~hod which permits individual and groups of mobile radio units to be dynamically regrouped to allow communications between units which cannot normally communicate with one another.

;

9 ~ ~ - lA - 45MR 00591 BRIEF DE8CRIPTION OF T~E DRAWINGS Features and advantages of this invention will be more completely understood and appreciated by carefully studying the following taken in conjunction with the accompanying drawings, of which:

FIGURE 1 is a schematic diagram of simplified exemplary user groupings in a typical trunked radio repeater system;

FIGURE 2 is an overall block diagram of a digitally trunked radio repeater system with dynamic regrouping capability in accordance with the presently preferred exemplary embodiment of the present invention;

FISURE 3 is more detailed schematic block diagram of the repeater site architecture shown in FIGVRE 2;

FIGURE 4 is a detailed schematic block diagram of the system manager 416 shown in FXGURES 2 and 3;

FIGURES 5-7 are schematic flowcharts of exemplary data structures maintained by:site controller 410 for implementing dynamic regrouping f~mctions;

FIGURES 8-14 are flowcharts of exemplary program steps performed by site controller 410 and mobile/portable radio transceivers 150 to implement the dynamic regrouping features provided by the present invention, and FIGURE 13 is found on the same sheet of drawings as FIGURE 16; and FIGURES 15-16 are flowcharts of exemplary program control steps performed by system manager 416 and site controller 410 to implement the dynamic regrouping features provided by the present invention.

- 2 - 45MR-00591 ~3.~93~ BACKGROUND AND SUMMAR~ OF TEE INV~NTION Radio repeater trunking ~ time sharing of a single repeater communications channel among many users) is well-known. Early trunking systems used analog control signals while some more recent systems have utilized digital control signals. Control signals have been utilized on a dedicated control channel a~d/or on different:ones of the working channels for various different reasons and effects.

A non-exhaustive but somewhat represen~ative sampling of publications and patents describing typical prior art trunked radio repeater syst~ms is identified below:

U.S.

Patent No. 3,898,390, Wells et al (1975) U.S.

Patent No. 4,392,242, Kai (1983) U.S.

Patent No. 4,534,061, Ulug (1985) U.S.

Patent No. 4,649,567, Childress (1987) U.S.

Patent No. 4,~58,435, Childr~s et al (1987) U.S.

Patent No. 4,716,407, Borras et al (1987) JAP~N 61-102836 (A) Ishikawa ~May 1986) U.S.

Patent No. 3,292,178, Magnuæki (1966) U.S.

Patent No. 3,458,664, Adlhoch et al (1969) U.S.

Patent No. 3,571,519, Tsimbidis (1971) U.S.

Patent No. 3,696,210, Peterson et aI (197~) 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, Ross et al (1976~ U.S.

Patent No. 4,001,693, Stackhou~e et al (1977) U.S.

Patent No. 4,010,327, Kobrinetz et al (1977) U.S.

Patent No. 4,012,597, Lynk, Jr. et al (1977) U.S.

Patent No. 4,022,973, Stackhouse et al (1977 - 3 - 45MR-00591 13~93~ U.S.

Patent No. 4,027,243, Stackhouse et al (1977) U.S.

Patent No. 4,029,901, Campbell ~1977) U.S.

Patent No. 4,128,740, Graziano (1978) U.S.

Patent No. 4,131,849, Freeburg et al ~1978) U.S.

Patent No. 4,184,118, Cannalte et al (1980) U.~.

Patent No. 4,231,114, Dolikian (1980) U.S.

Pa~ent No. 4,309,772, Kloker et al (1982) U.S.

Patent No. 4,312,970, Coombes et al ~1982) U.S.

Patent No. 4,312,074, Pautler et al (1982) U.S.

Patent No. 4,326,264, Cohen et al (1982) U.S.

Patent No. 4,339,823, Predina et al (1~82) U.S.

Patent No. 4,347,625, Williams (1982) U.S.

Patent No. 4,360,927, Bowen~et al ~1982) U.S.

Patent No. 4,400,585, Kamen et al (1982) U.S.

Patent No. 4,409,687, Berti et al (1983) U.S.

Patent No. 4,430,742, Milleker et al (1984) U.S.

Patent No. 4,430,755,~Nadir et al (19843 U.S.

Patent No. 4,433,256, Dolikian (1984) U.S.

Patent No. 4,450,573, Noble (1984) U.S.

Patent No. 4,485,486, Webb et al (19~4) U.S.

Patent No. 4,578,815, Persinotti (1985 :

There are many actual and potential applications for trunked.radio repeater systems.

However, one of the more important applications is for public ser~ice trunked (PST) ~ystems.

For example, one metropolitan area may advantageously use a single system of trunked radio repeaters to provide efficient radio communications between individual radio ~nits within many different agencies.

As is well-known to those familiar with trunking theory, a relatively small number of~ adio repeaters can efficiently service all of~needs of a public service - . . , ', ~, ' .

- 4 - 45MR-00591 ~3~3~ organization within a given geographic area if they are trunked (i.e., shared on an "as-needed" basis between all potential units3.

Before modern trunked radio repeater systems were developed, mobile radio transceivers were provided with crystal controlled frequency synthesizers providing a limited number of fixed transmit/receive channels -- and the various channels were assigned for use by different "groups" of radio transceivers. Referring to FIGURE 1, for example, fixed channels might be assigned as follows:

channel A to police squad A, channel B to police squad B, channel C to rescue sguad/paramedics, channel D to snow removal equipment, channel E to municipal vehicles, channel F to fire squad A, and channel G to fire squad B;.

Every mobile transceiver in a gr~oup was typically capable of communicating with other members of its group (and wibh a central dispatcher) over its assigned communications channel. In addition, several additional chan~els wer~ typically provided for "cross-group~ communications. For example, an additional channel H might be u~ed to permit members of police squad A and police squad B to communicate with one another -- while still permitting squad A to u5e its private~y and exclusively assigned channel A to communicate with other members of squad A without 3 disturbi~g members of squad B. Similarly, an additional channel I mi~ht be provided for communications between fire sguads A and B and the rescue squad; and a further channel J might be - 45MR-00591 131~9~9 provided for communications between members of police squad A and/or B, the rescue squad, and members of one or both fire squads.

This type of arrangement, although certainly providing private and reliable communications, had some severe disadvantages. One disadvantage was that the "cross-group" channels were usually under-utilized (since most routine communications take place within a group), but often became extremely congested during disasters or emergencies requiring coordina~ion between members of different groups. Moreover, "cross-group" communications typically required some degree of advanced cooperation on the part of each and every member involved (e.g., each user had to properly switch his transceiver to the "cross-group" channel or be sure his "scanning" type transceiver was enabled to monitor that "cross-group" channel). Suppose, for example, that a police officer in police squad A wished to communicate with a rescue vehicle in the rescue squad. The police officer could switch his tran~ceiver to communications channel J and call the rescue vehicle he wished to communicate with -- but there was no guarantee that the specific rescue vehicle he was trying to reach would in fact be monitoring channel J (since the rescue vehicle driver would first have to change his channel selector to channel J as well~. Central dispatchers often had the burden of manually directing the various different personnel to cross-group channels, and much time was wasted coordinating such efforts when emergency or disaster situations made time of the essence.

- 6 - 45MR-00591 ~3~ ~939 In contrast to the old crystal controlled fixed frequency systems, prior art trunked radio repeater systems rely upon preprogrammed group identifications rather than preset operating frequencies to provide the communications partitioning shown in FIGURE l. TrunXed radio communications systems assign communications channels on an "as needed" basis ~or the exclusive use of calling mobile units requesting communications and to the group of mobile units being called. It is possible to provide much additional flexibility by pre-programming mobile units in advance with several different group identifications tthus making a given mobile unit a "member" of several different groups of transceivers). Since the number of groups the system can support is limited only by the RF signalling protocol providing identification of groups (and the programming capabilities of the mobile transceivers), it is possible to provide an almost arbitrarily large number of different logical groupings of transceivers -- for example, the assignee's signalling protocol disclosed in Canadian application serial~no. 566,664 to Childress et al entitled "Trunked Radio Repeater System" filed May 12, 19~8, and Canadian application serial no 5~ 3 to Childress ~ntitled "Trunked Radio Repeater System" filed ~e~r~qr~ æ3 /~ , provides for individual identification of each and every mobile transceiver in the field and supports over 4000 different groups.

This trunked arrangement provides for much additional flexibility.

For example, re~erring again - 7 - 45MR~00591 9 3 ~ to FIGURE 1, a first group might be formed by all members of police squad A; a second group might consists of all members of police squad A and B; a third group might consist of a subset of police squad A (e.g., certain detectives and a supervisor); a fourth group might consist of all police supervisors from squads A and B; and a fifth group might consist of all members of police squad A and all members of the rescue squad.

Even though all groups are in effect "reusing" the same communications channels in this trunked radio system, the trunking is mostly transparent to individual users. That is, when a police officer in police sguad A switches his "channel" (actually gro~p) selector switch to correspond to the first group and actuates his "push-to~talk" microphone switch to make a call, his tran~,ceiver and all other active transceivers of police sguad A are automatically controlled to switch to a free "working" channel temporarily dedicated to their use -- and significantly, no other tnobile tranSceiYerS are permitted to monitor or participate in the :communications over this chan~el. This privacy feAture afforded by trunked communications systems is important ox providing each group of users with efficient, reliable communications, is critical for certAin sensitive communications services (e.g., the police narcotics and detective squads) and is also critical for preventing interference from other users (e.g.~ the driver of a snow removal vehicle cannot interfere with communications between members of police squad A no matter what the snow truck driver does with his transceiver). Thus, in this respect - 8 - 45MR-00591 ~31 -~3~ the trunked system behaves from a user's view point like the prior systems in which each service had a channel dedicated to its exclusive use -- while providing the radio spectrum and cost economy derived from channel and repeater sharing.

In a trunked environment, compartmentalizing radio transceivers into groups is essential to effective, reliable, private communications. In the past, however, such compartmentalization resulted in serious inflexibility when special situations arose.

In most prior systems, all groupings of radio transceivers had to be defined beforehand (e.g., by hardwiring or preprogramming at the time the transceivers were issued to users and placed in the field). E'or example, when a police officer in squad A was issued his radio transceiver, the transceiver would typically be preprogrammed to respond to calls for certain groups and to never~respond calls for other groups. A disaster situation (plane crash, 20 major fire, landslide, earthquake, etc.) or a special event (e.g., county fair, parade and the like) migh~ require this police officer to communicate with other : users he normally does not communicate with.

Eor example, those assigned to crowd control a~ a special 25 event such a~ a parade might incIude a squad A police officer, a rescue sguad vehicle, several municipal vehicles, and an officer from police squad B.

It would be highly desirable to permit these different users to communicate with one another over their own 30 communications cbannel for the duration of the ~ special event without disturbing or interfering with communications of the rest of the two police squads, the rescue squad a~d the municipal vehicles.

;

.`~' :

~ 9 - 45~R-00591 9 3 ~ Prior trunked repeater systems sometimes provided the capability of combining several groups together into a large group via a multiple group call -- so that all members of, or example, police squad A, the rescue squad, all municipal vehicles and all members of police squad B could be collected onto a single communications channel in response to a single (typically dispatcher initiated) "multiple group call". The problem with this approach is that it involves too many radio users to be effective (i.e., many more than are needed for the necessary communications) -- and more seriously, may draw users not involved in the necessary communications away from other radio calls important to them. The only really effective way in the past to accomplish the desired result was extremely inconvenient and costly -- issuing each of the users a "floater" transceiver specially programmed for a sparle group (and making sure they each returned their transceiver at the end of the special event).

The concept of "dynamic regrouping" in a trunked radio system is generally known. Dynamic regrouping a~low~ a system operator to program customi7.ed group identifications into radio transceiver~ in the ield from the central system facility at will -- and dynamically form special groups for special purposes. Disasters such as plane crashes, severe storms, major fires, landslides and earthquakes as well as special events are all examples where the ability to guickly reconigure radios could be a valuable tool to the public safety officer. As an example, personnel involved in handling the crisis of a plane crash might include - 10 - 45MR-00591 ~3~33~ c~rtain police officers, certain rescue vehicles, certain municipal vehicles and certain fire vehicles. It would be highly advantageous to provide some way to reconfigura the fixed, compartmentalized groups of transceivers normally provided by a trunked system to dynamically form spe~ial groups consisting only of these involved radio units -- while preserving the units' existing group classifications ~and thus, in some cases, their capability to make routine calls) and also without disrupting any other communications takiny place on the system.

The need for dynamic regrouping typically arises when dispatchers and field personnel are under tremendous pressure to perform under unpredictable conditions. The trunked communication system should help alleviats confusion rather than contribute to it -- so that if dynamic regrouping is to implemented at all, it must occur rapidly and predictably and in a fashion that can be monitored and controlled by any supervisor. It is especially important that activating a dynamically created group ("regroup") does not interfere with any ongoing radio communications in the field. Unfortunately, exi~ting techni~ues for implementing dynamic reg~ouping have not met these demanding requirements and have therefore caused dynamic regrouping to remain in the realm of merely a great idea that cannot be practically implemented in the form of a usable tool.

Motorola, Inc. of Shaumburg, Illinois has developed a so-called "SMARTN~Tt' trunked radio communications system which offers a limited dynamic regrouping capability.

The optional dynamic 9 3 9 - 11 - 45MR-00591 regroupiny capability provided in this 800 MHz trunked system allows the dispatcher to reassign radios into new talk groups without any mobile operator involvement to provide communications flexibility during emergency situations.

Motorola 7 S subscriber dynamic regrouping communications system is described in WO PCT Patent Publication No. 8701537 published 12 March 1987 entitled "Method For Dynamically Regrouping Subscribers On A Communications System", and in press releases dated ~ugust 6, 1987 and June 27, 1986.

Briefly, the Motorola scheme provides for downloading a single dynamic reprogramming instruction to specified individual radio transceivers in the field via digital messages transmitted over the control channel to each of the transceivers individually. Upon receipt of the reprogramming message, the individual transceivers acknowledge the message, store the downloaded dynamic regroup identifier in an internal memory, and switch to a dynamic regroup mode in which they transmit and receive using the dynamic group instead of their old group(s). In another mode, a l'group" dynamic re.group message is transmitted ~o an entire group of transceivers at a time in order to increase regrouping speecl. The receiving transceivers begin using an alternate, ~ixed ~'dynamic code" previously programmed at tim~ of manufacture and/or "personality PROM" programming. The units continue to use this "dynamic code" until dynamic regrouping me~sages cease being periodically transmitted over the control channel.

AmeriCom Corp. of Atlanta, Georgia has advertised an RF communications system featuring "over-the-air" reprogramming to add channels and reprogram mobiles without expensive ROM changes. This feature is described as providing more responsive service by dynamically reprogramming mobiles in order to lower service costs and permit real time l'over-the-air'l reprogramming of radio configurations and permissions.

The following issued U.S.

Patents may also be - 12 - 45M~-00591 9 3 9 gsnerally relevant to the concept of dynamic regrouping:

U.S.

Patent No. 4,594,591 to Burke U.S. Patent No. 4,517,561 to Burke et al U.S. Patent No. 4,152,647 to Gladden et al 5U.S~ Patent No. 4,612,415 to Zdunek et al U.S. Patent No. 4,427,980 to Fennel et al U.S.

Patent No. *,553,262 to Coe Unfortunately, existing dynamic regrouping schemes (~;uch as those described above) exhibit many 10 practical problems when they are ac:tually used in the real world.

For example, existing techniques do not meet the demanding requirements of rapid and predictable regrouping which can be monitored and controlled by any supervisor -- and which does not 15 interfere wilth ongoing radio communications in the field.

The user interface has been one of the more widely and strongly criticized elements in existing dynamic regrouping sch~mes.

Some criticize the user 20 interface itself and others criticize the entire regrouping process because it is too conîu~;ing to be of any value.

Es~isting dynamic regrouping :3chemes require a supervisor to specify 'iregroups" (new, dynamically configured groups) from the "ground up" 25 by keying in an identification for each and every individual radio transceiver to be placed in the regroup -- a difficult task to perform under time pressures of an emergency.

Because dynamic regrouping changes the way the communications system 30 operates on a very fundamental user level, for any practical and useful dynamic regrouping scheme the supervisor and the system dispatchers must be capable of: ~a) accurately tracking -- on an interactive - 13 - 45MR-00591 131~39 basis -- what radios are in what groups, (b) quickly assessing whether the regrouping process is proceeding in a suitable fashion or should instead be aborted or altered, and (c) easily altering regroup plans during activation or after they have been activated in response to changes in conditions and personnel~ System supervisors and dispatchers must also be able to effectively handle and control communications during the regrouping process which, once initiated, causes entire groups to become fragmented and undefined unti-l the proce~s is complete. Existing dynamic regrouping systems simply do not meet these needs.

Additional complexity arises from the fact that most modern trunked communications systems serve a sufficiently large geographical service area to require multiple repeater sites -- and it is not possible to determine which users are being served by which sites at the time dynamic regrouping is activated~ Existin~ dynamic re~grouping systems provide no quick and efficient way to set up and execute dynamic regrouping plans having no con1icting regrouping requests relative to any of the mobile transceiver involved. Very seriou~ problems could also arise in existing systems if a site controller fails either while radios are being dynamically regrouped or a~ter they have been regrouped.

Another serious inadequacy of prior dynamic regrouping schemes is the lack of support offered to field personnel. For example, the capability of placing only one dynamically configured group assignment in a transceiver at any time is generally .

- 14 - 45MR-00591 131~g3~ insufficient. In an emergency, key personnel must be able to switch between two or more of "regroups" -but if their radio transceivers can accept only one regroup at a time, this switching is impossible. The police chief, the supervisors and other Xey personnel with the most knowledge, information and tactical experience become hamstrung because they are unable to participate in communications in more than one of the new dynamically configured groups.

Perhaps the most serious shortcoming of the existing dynamic regrouping schemes is that they often force users into "immature" groups for relatively long time periods. The dynamic regrouping process takes some time to complete in any syst~m.

An immature group is a group that is in the process of being formed by the regrouping process but because it is only partially formed, does not yet include enough transceivers to be an effective or usable group. The result is a temporary loss of communications effectiveness as transceivers are removed from existing group~ and placed into a new group -- where they must wait for the regroupinq process to reach some sufficient level of completion before effective communications can be established.

For example, assume an officer in the field is involved in a communique exchange and suddenly finds his transceiver automatically locked in a "regroup" with only one or two other transceivers.

The system has not yet regrouped other radios into this new group, so he cannot yet communicate effectively in the new group -- and he also cannot comm~nicate in the old group his transceiver was just removed from because the dynamic regrouping scheme has forced him - 15 - 45MR~00591 131~93~ into priority communications with the regroup.

Meanwhile, the dispatcher has no idea at any given time who has or ha~n't yet been regrouped, and therefore does not know what groups to talk to to reach specific per~on~el. A solution to this problem offered by the prior art îs to permit each transceiver to generate a "reprogram request" which th~ dispatcher must manually respond to. This is hardly an efective solution for the officer in the field during an emergency.

One way to lessen the bad "side effects" of the dynamic regrouping process is to make the process occur as rapidly as possible. Unfortunately, the task of reaching and remotely reprogramming, in a reliable manner, tens or hundreds of geographically scattered transceivers is a difficult ta~k to accomplish at any speed, let alone as rapidly as possible. The flow of information from the regrouping terminal to the repe!ater site or sites, - 20 the rate at which transceivers can be regrouped, and the resulting loading of the digital control channel (which adds to existing control channel loading from other communications the syst~m i~ supporting~ are interrelated items that must work together effectively if the regroupin~ process is to proceed effectively. The regrouping proce~s should occur as rapidly as possible to minimize the amount of confusion it creates. Unfortunately, existing dynamic regrouping schemes have not been designed with the real world in mind. Regrouping over the control channel limits the rate at which radios can be regrouped to only a few per second at best (due to the limited data transfer rate over the control .

- 16 - 45MR-00591 ~3~3g channel and normal control channel loading). This limited regrouping rate is further aggravated by requiring the regrouping terminals to send initial re~uests via the control channel. Of course, multi-site configurations require regrouping terminals in the range of each individual site hardly an effective or efficient solution.

The present invention provides an improved dynamic regrouping scheme which includes an effective user interface, automatic support of multi-site systems, the capability to program individual radio transceivers with multiple new groups dynamically, a fast rate of reconfiguration, instantaneous switch over to prevent radios from residing in immature groups, and a satisfactory mode of operation should the site controller (or site controllers in non-fault tolerant systems) fail. Some oE the ~eatures and performance specifications provided by the presently preferred e~emplary embodim~nt of the present invention include:

Fea~ures Unlimited prestored plans Unlimited source and destination groups per plan Regrouping at the plan or destination group level Advanced user interface Automatic support of multiple sites Fast regrouping Regrouping at a rate of over 30 radios per second is possible while reducing loading on the control channel.

Fast activation/deactivation - 17 - 45MR-00591 ~31~39 Each plan can be immediately activated or deactivated. Users are effectively regro~ped together.

Up to 8 regroups per radio If a radio does need multipl~ regroups, the user interface allows the supervisor to specify the knob setting for each regroup.

In accordance with one significant feature of the invention, dynamic regrouping is permitted to proceed extremely rapidly with very little additional loading on the digital control channel and without S being affected by existing control channel loading.

Dynamic regrouping takes place in two phases in the preferred embodiment. In "phase I", a special dynamic regroup call is transmitted over the control channel which directs an entire transceiver "source group" to a working channel (this source group i5 deined in terms of a "normal", existing transceiver group). Typically, only some and not all o~ the transceivers in the "source group" are actually to be dynamicalIy regrouped. A11 of the transceivers in ~ 15 the ourc~ group react by~retuning to a further ~ ` communications channel normally used by the system as a working channel -- just as they would for a "normal" group call. However, the further communications channel has meanwhile bee~ reconfigured by the system as an alternate control channel -- and carries all of the control channel signalling needed to efficiently handshake with and transfer mes ages to and from the tran~ceivers (the alternate ~ontrol channel is distinguishable from the "real" control channel so th~t transceivers rom di~ferent groups do not mistake the alternate control ~ :

..

- 18 - ~5MR-00591 13~ ~3~ channel for the "real" control channel). Since the alternate control channel to handles only messages for regrouping selected mem~ers of the source group and is not loaded with control messages fox other systems communications (and also because of the 9600 bps data control channel transfer rate of the preferred embodiment), dynamic regrouping messages transmitted over the alternate control channel can "regroup" transceivers on an individual basis extremely rapidly (e.g., 30 or more transceivers per second).

The communications system can activate as many alternate control channels simultaneously as desired -- and thus simultaneously dynamically regroup many different source groups each containing tens or hundreds of transceivers.

Not all required transceivers typically respond to a dynamic regroup call issued at a given site at a given time. Some transceivers may be in the service range of a different repeater site, other transceivers may be inactive (e.g., "off"), and stlll other transceivers may be temporarily unavailable (e.g., blocked by an obstruction from communicatin~ :

with the ~ite) In accordance with another feature of the invention, a central regrouping terminal constantly monitors the progress of the regroupin~ procsss, and coordinates the process between di~ferent sites in a multi-site configuration. After ~phasë I of the regrouping pxocess is completed, the central terminal causes the system to begin "phase II" in which the alternate control cha~nel is released and dynamic regrouping messages are periodically sent over the main control channel - - 19 - 45MR-00591 ~31~3.~ but only to those few individual transceivers that failed to respond to the phase I messages (the number of transceivers that "missed" the phase I signalling will generally be relatively small, so that the main control channel is not overloaded or backed up with dynamic regrouping messages and acceptable control channel message handling rates can be maintained for routine communications as well as for the phase II dynamic regroup messages).

In accordance with still another eature of the invention, dynamic regroup activation does not actually occur in either phase I or phase II in order to avoid the formation of immature regroups. Phase I and phase II of the process simply make the new "regroup" information "resident" in the transceivers being regrouped -- and the system automatically keeps track of which transceivers have actually respanded.

A regroup is not activated until (a) a sufficient number of transceivers in the regroup have responded, and (b) certain transceivers specified as being critical to the effectiveness of the regroup have responded. When both of these requirements have ~een met, a further message transmitted over the main control channel to ~he source groups forming the regroup cause all of the transceivers previously made "resident" in the regroup to immediately activate the regroup. Multiple regroups can be active and/or "resident" on the system simultaneously.

Meanwhile, a system manager may interactively monitor and modify the regrouping process as it progresses through an advanced user interface which is a further feature of the invention. The user interface provides instantaneous status information - 20 - 45MR-00591 13~3~ ragarding what units have been made "resident", what units have become active in a regroup, and what units are still being searched for. The system manager can alter the regrouping process as it progresses ~e.g., abort the process, delete certain units from the regroup and add other units, etc.). The system manager can also easily remove units from and add units to an active regroup at will.

In accordance with still another feature of the invention, the advancsd user interface permits a user to speciy regroups on several different levels. In particular, the dynamic regrouping process is defined in terms of plans, source groups and destination groups ("regroups").

Each regroup plan may speciy multiple destination groups -- and - the system manager may activate the entire plan, or only some of the destination groups in the plan.

Significantly, the system managi3r specifie3 wh~t transceivers are in a particular destination group by specifying the "source" group (i.e., normal group classification) of those tr~n~ceivers. As each source group is selected, all transceivers in the source group are listed on a di~play and the 8y8tem manager can select some and omit others rom the destination groupO The source groups selected in this mannsr are the same ones called in "phase I" of the dynamic regrouping processes discussed above.

Any given transceiver can be included in multiple regroups simultaneously, and the advanced user interface permits the system manager to allocate specific regroups to specific positions on the group selector control knobs and also make regroups mandatory or user selectable (e.g., to specify - 21 - 45MR-00591 131~9~ whether the user is forced into a regroup and/or can tune to a diferent group once regrouped3 on a transceiver by transceiver basis. This flexibility permits the system manager to avoid conflicting transceiver regroup assignments and actually define to some extent the manner in which the transceiver operators interface with the reconfigured system.

In accordance with a further feature of the invention, both handshaking and non-handshaking dynamic regroup deactivation is provided. The pre~erred technique for deactivating an active regroup is to perform a signalling exchange similar to the "phase I" signalling used for making a dynamic regroup "resident" -- and positively deactivate the regroup in each transceiver with each transceiver positively acknowledging deactivation. However, to prevent regrouped transceivers that "miss" the deactivation signalling ~rom becoming trapped in dynamic regroup "limbo", a further means to deactivate regroups is also provided. A message is periodically transmitted ovar the main control channel specifying on a plan-by-plan basis which plans are active and which plans are inactive (and also which plans are "resident" and which plans are non-resident). Such message transmission is maintained long after dynamic regroup plans are~ deactivated. Any transceiver active in a regroup which receives a message specifying that the regroup is inactive immediately deactivates the regroup -thu~ providing an immediate, "fail-safe" way to deactivate regroups (e.g., if the system manager panics~ and to also deactivating regroups in transceivers that "missed" the handshaking 1 3~ ~939 -- 22- 45MR--00591 deactivation signalling.

/ :

131~39 - 23 - 45MR-00591 D~AILBD D~8CRIPTIO~ OF PRE~NTLY PREYE~RED EXE~P~RY ~MBO_INEN~8 OVERAL~ 8Y~EM~ ARC~I~EC?URE An exemplary trunked radio repeater ~ystem 100 in accordance with this invent.ion is generally - depicted in FIGURE 2.

System 100 includes at least one (and typically many) mobile (or portable) radio transceiving stations 150 and at least one (and typically many) RF repeater stations 175. Mobile transceiving station 150 communicates via an RF link and repeater station 175 with other mobile transceiving stations and/or with landbased parties connected to the repeater station by conventional dial-up landlines.

Repeater station 175 includss a site controller 410, individual repeater channel transceivers 177, and a multiplexing telephone interconnection network ("switch", ar ''MTXI') 179.

Site controller 410 is preferably a mainframe digital computer which oversees the general operation o~ ~ repeater station 175.

In particular, sita c:ontroller : :-:

410 controls t~e operation of RF transceivars 177 by : :

traosmitting digital signals to and receiving digital , - 24 - 45MR-00591 ~3~3~ from "trunking cards" ("TC") 400 connected between the site controller and individual transceiver~ (although only one transceiver 177 and one trunking card 400 are shown in FIGURE 1, there typically are many such trunking card/transceiver combinations in repeater station 175 -- one for each RF channel the repeater station operates on3.

Site controller 410 communicates with one or more dispatch consoles 102 via a "downlink" 103 which includes a "downlink" trunking card 450 and a "switch" trunking card 4S4. The downlink 103 also typically is channeled through switch 179. Also connected to switch 179 are AVL (automatic vehicular locating system) 181 and C~D (computer aided dispatch system) 183. A system manager computer system 416 (hereafter referred to as the "system manager") is connected to site controller 410 and to switch 179 to allow a system manager to oversee and control the :

overall operation of system 100 - and to control the dynamic regrouping process.

A remote receiver 187 and associated concentrator/voter 18~ may be connected to trun~ing card 400 to allow so-called "RSSI" signal strength measurements to be based on the stronger of the signal level received at the central repeater station site and the signal level received at a remote site -- thereby increasing the reliability of such measurements.

An RF link ("RF"~ connects RF repeater transceivers 177 with mobile transceiving stations 150. Mobile station 150 is capable of transmitting digitized voice or digital data signals (encrypted or unencrypted) to and receiving such signals from - 25 - 45M~-00591 ~31~3~ repeater station 175 over the RE link.

In the confi~uration shown in the upper left-han~ portion of EIGURE 2, mobile station 150 includes a mobile RF transceiver 152 connected to a control head 154 via a serial digital bus 153.

Mobile transceiver may al50 be connected to a vehicular repeater 156 via the serial bus. A mobile data terminal interface 158 may connect the serial bus to a mobile data terminal (MDT) 162. A separate digital voice guard module 164 performs data encryption and decryption on digitized voice and/or digital data signals using the conventional DES algorithm.

In the alternate mobile radio configuration shown in the lower left-hand corner of FIGURE 2, a coupler 166 is used to connect dual control heads 154A, 154B to serial bus 1~3. In this configuration, a mobile data terminal 162 and associated inter~ace 158 may be connected directly to serial:bus 153 and/or to bus 153A (on the output of the coupler 166). Voice guard module 164 is preferably connected to bus 153A when dual control heads 154A, 154B and associated coupler 166 are used.

As illustrated, individual radio units (mobile or portable radio transceivers) of various groups communicate with one other (both within and possibly outside of their own groups) via shared radio repeater channe}s. A dispatch console 102 supervises the operation of repeater system 102. There may be multiple dispatch consoles 102 (one for each separate fleet of mobile/portable units) and a master or supervisory dispatch console for the entire system if desired. Systems manager 416 is capable of - 26 - 45~R-00591 131~39 specifying new groupings and causing such new groupings to be dynamically activated on command, as will be explained shortly.

CENTRAL SITE ARC~ITECTURE Briefly, referring now more particularly to FIGURE 3 ( a block diagram of a single repeater site of which typical systems may have more than one), a transmitting antenna 200 and re~eiving antenna 202 ~which may sometimes be a common antenna structure) may be utilized with conventional si~nal combining/decombining circuits 204, 206: as will be apparent to those in the art. The transmitting and receiving RE antenna circuitry 200-206 thus individually services a plurali ty o~ duplex RF channel transmit/recei~e circuits included in a plurality of RF repeater "station~" 300, 302, 304, 306, etc. Typically, there may be 24 such stations.

Each station transmitter and receiver circuitry i8 typically controlled by a dedicat~d control shelf CS ~~e.g., a microprocessor-based control circuit).; Such control shelf logic circuits assoc~ated 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 i.f desired.

All of the trunking cards 400-~08 communicate with one another and/or with a primary site con~roller 410 via control data links 412. The primary site controller (and optional backup controllers if desired~ may be a commercially - 27 - 45MR-00591 ~ 3 available yeneral purpose processor (e~g., a PDP 11~73 proce~sor with 18 M~z-Jll chip set). Although the major "intelligence~' and control capability for the entire ~ystem re~ides within controller 410, alternate bachup or "fail soft" control functions are incorporated within the trunking cards 400-408 sa as to provide continued trunked repeater service even in the event that controller 410 malfunctions or is otherwise taken out of ser~rice.

An optional teLephone interconnec~ 414 may also be provided to ~he public switched telephone network. A system manager 416 is also provided for overall system management and control (to~ether with one or more dispatcher console~ 102).

A power monitoring unit ~PMU) 500 allows site controller 410 to monitor the actual RE parameters a~sociat~d with repeater system 100. For example, PMU 500 constantly monitors power output of each repeater channel, as well as i.nsertion loss and VSWR ~voltage standing wave ratio) of each repeater antenna. PMU 500 is connectPd to site controller 410 via a high speed data link 412 (P~U).

A test, alarm and co~trol u~it (TAU) ~18 is provided for det~cting and diagnosing error conditions.

RF SIGNALLI~G ~RR~MGEMSNT AND PROTOCOL The RF signalling protocols and formats used in the preferred embodiment are described in detail in Canadian Application Serial Number 591,893, filed February 23, 1989, entitled "Trunked Radio Repaater System".

.,,~ - 28 - 45MR-00591 1 3 ~ 9 Briefly, all inactive radio transceivers monitor a digital RF control channel for messages which identify groups the transceivers are members of. To establish "normal" communications between a mobile transceiver and other transceivers within its group, the mobile transceiver transmits a channel request message over the contro] channel.

In response, the site transmits a channel assignment message directed to the transceiver group -- this assignment message specifying a free working channel. All of the transceivers in the group react to this channel assignment message by retuning to the specified working channel. Voice and/or data communications are permitted between the transceivers in the group over the working channel after various handshaking signalling has been exchanged.

The signalling protocol described in the above-mentioned Canadian Application Serial No.

has baen supplemented with several additional messages used to implement dynamic regrouping. Exemplary message formats for those messages appear below.

/~ - 29 - 45 ~ -00591 ~31~93~ Olll'BOUND_NTROL C~IEL M13$SA~ES D ~ amic ReqrouP Message ~1 FORMAT: 27........................ 0 111 MT-A 111 MT-B 10000 MT-D fff Number of fleet bits 11111111111111 Logical Message #2 FnRM~T: 27........................ 0 111 MT A 111 MT-B Partlal MT-D PPPP Plsn number tt Regroup type kkk Group knob setting - Undefined g~gg88gggBg Group Second mess~ge Regroup t~pe definition:

00 ---> Forced select, no deselect 01 ---> Forced select, optional deselect 10 ---> Undefined 11 ---> ~ptlonAl select Pln~PO5E:

':

- 30 - ~5MR-00591 131~39 This dynamic regroup message specifies the new group into which the unit is being regrouped.

The fff field speciies the number of fleet bits used in this particular agency (to allow the radio to continue 1eet call decoding during the regroup).

The group knob setting field specifies the dynamic regroup knob position within the radio to be usad (000 indicates posi~ion 01, ..., 111 indicates position 08). These bits (along with the type bits) are echoed in the inbound acknowledgement.

The pppp field specifies a dynamic regroup plan number.

See the outbound control channel PBM (Plan Bit Map~ message for explanation of the use of plan numbers.

This message is sent in "phase I" on an alternate control channel and in "phase II" periodically as a background task of the control channel.

In failsoft or before the site controller informs the control channel trunking card of plan status, all bits will be set.

CANCEL DYNAMIC R~GROUP FORMAT: 27....................... o 111 MT-A 111 MT-R ooooo MT-D kkk Group knob setting 11111111111111 Logical ID PV~POSE To cancel the dynamic regrouping function performed on a radio. The group knob setting ield specifies the dynamic regroup position being - 31 - ~5MR-00591 ~314~39 cancelled. These bits must be echoed in the acknowledgement in the preferred embodiment.

SYSTEM DXNAMIC REG~O~P PLAN BIT ~AP FORM~T: 27....................... 0 111 MT-A 111 MT-B 00100 NT-D b Plan bank r r r r r r r r Plan residency a a a a a a a a Pl~n activation b = Plan bank bit. A "0" here means plans 0 through 7 are described in the residence and activation fields. A "1" here means plans 8 through 15 are des~ribed in the residence and activation fields.

rrrrrrrr = Plan residency bits.

The first bit in this field (MSB) is plan 7 (15 if b is set~.

The last bit (LSB) is plan 0 (9 if b is set). A~"l" in the plan's residence bit inorms mobiles that the plan is resident on the ~ystem.

aaaaaaaa = Plan activation bits.

First bit (MSBj is plan 7 (15 if b is set).

Last bit (LSB) is plan 0 (8 if b is set) . A "1" in the plan's activation bit informs mobiles that the plan is active on the system.

PURPOSE:

To noti~y all units of resident and active .

- 32 - 45MR-00591 ~3t~3~ dynamic regroup plans.

Plans are numbered from 0 to 15, divided into two banks of 0-7 and 8-15.

In the preferred embodiment, a mobile or portable unit can only participate in one plan at a time, and can hold at most 8 dynamic regroups from that plan.

The pla~ number i5 passed to the units in the dynamic regroup meqsaging. A resident plan is one which has been (or is being) downloaded to the mobile and portable units.

The plan is not available for user acces~ at this point, but is retained by the units.

An active plan is one which is available for user access.

Active plans must first be made resident.

Any unit which has loaded regroups from a given plan will automatically remove them from memory if the resident bit for that plan is 0 in this me.ssage.

No acknowledgement is sent to the site when this occurs.

DATA STRUC~URES ~AI~TAINED BY ';ITE CO~TROLLER 410 Below is a brie discussic)n of the implementation and functionality of the major data structures used by site controller ~10 in the preferred embodiment to impIement dynamic regrouping.

These data structures are updated periodically by system manager 416 in a manner that will be explained shortly Two data struc~ures are maintained by site controller 410 to keep track of and control the dynamic regroup proce~: a queue 1400, and a "regroup control buffer" 1420.

The queue 1400 maintains information about individual transceivers 150 involved in the regrouping process, while buffer 1420 - 33 - ~5MR 0059~.

~3~939 stores status information about regroups.

The primary data storage area for the dynamic regrouping task is the queue data structure 1400 shown in FIGURE 5.

Queue 1400 consists of an array o 1024 queue elements 1402(0)-1402(n3 in the preferred embodiment -- each element relatinq to a specific individual transceiver to be regrouped.

Each gueue element 1402 contains a logical/unit id field 1404, a home (source) group id field 1406, a field 1408 pointing to the next element in the same regroup (or a "-1" for the last element for the regroup in the queue), a status field 1410, and a unit control block 1412.

Status field 1410 is used in the preferred embodiment to identify those units that have responded to the regroup command.

The unit control block field 1412 contained in each queue element 1402 identifies the type regroup request for that particular unit:, the unit's acknowledgement flags, and the unit's group knob setting.

The diagram below shows an exemplary format for the unit control block 1412 in the preferred embodiment:

- 34 ~ 45MR-005~1 13~ ~3~ B15 Bl~ B10 B9 B8 B7 B6 B3 B2 Bl B0 ..... _ _ . .

A I Unused I B IC ¦D ¦E IF I Unused _ _ _ _ Bl5 through B13 (A) group knob setting B12 through BlO unused B9 through B8 (B) type request 00 --~ forced select, no deselect 01 ~-> forced select, option deselect 10 --> undefined 11 --> option select B7 (C) active pending B6 (D) active BS (E) cancel pending B4 (F) cancelled B3 through B0 unused When a mobile responds to a regroup command, the "active pending" bit in the corresponding u~it control block record 1412 must be cleared.

Unfortunately, in the preferred embodiment the only identifiable means finding the c~ueue element is :

through the logical id.

However, in the preferred embodiment, records 1402 of queue 1400 are no~ sorted by logical id field 1404, and although index d by pointer 1408 for associated regroup, may be scattered throughout the queue in any order.

To search the queue by logical ID field would be very inefficient without some higher level search algorithm~ In the preferred embodiment, a sort control block is maintained which~provides an array of pointers.

These pointers point "into" the ~ueue 1400, and index :' ' ' . .' ' :

- 35 - 45MR-00591 ~ 31~93~ the queue records 1402 by sorted logical identification field 1404.

A queue control block, a further data structure used to implement dynamic regrouping in the preferred embodiment, is a simple structure that maintains information regarding queue space used, ~ueue spaced allocated and a pointer to the ~ree list.

This gueue control block permits the system to manage the queue 1400.

An exemplary format for the queue control block is shown below:

Total Used¦Total AllocatedlFree Pointer¦RCB Cnt¦S~r~ice ..._~ Another data structure used in the preferred embodiment to implement dynamic regrouping is the regroup control block 1420 schematically shown in FIGURE 6. A regroup control blocX 1420 is created for each active or resident regroup plan on the system.

The regroup con~rol block 1420 includes a ;

record 14~2 corresponding to eac:h regroup (destination group) in a particular regroup plan.

Each record 1422 contains information about tha dynamic regroup process~ includi.ng: tha destination grQUp id field 1424 (primary identifier of each regroup process); a field 1426 pointing to the first unit in the regroup; a field 14~8 pointing to the last unit in the process; a field 1430 containing the current number of elements available (allocated currently used); a counter 1432 containing:the number : of times to retry the regroup before reporting the status to the system manager; the current retry count 1434; a statuq field 1436; and an "acknowledge pending" bit 1438.

- 36 - 45MR-00591 3 ~ FIGURE 7 is a detailed schematic diagram of an exemplary status field 1436, this field containing an active/inactive field 1436(a) and a fleet decode field 1436b.

The following describes the significance of fields 1436a,b: :

Active/inactive ield 1436a:

0 --> regroup is not currantly active 1 --> active regroup Fleet decode field 1436b:

Contains fleet number decoding information Site controller 410 data structures handle dynamic regroup information on the regroup level rather than on the plan Ievel.

It is the responsib:ility of system manager 416 to manage regrouping processes in the preferred embodiment to permit activation of entire regroup plans.

FIGURE 8 is a flowchart of exemplary program control steps performed by system 100 to manage dynamic regrouping; FIGURES 9, 11 and 12 are flowcharts of exemplary program control steps performed by site controller 410 in the preferred embodim~nt to implem~nt the dynamic regrouping function; and FIGURES 10, 13, and 14 are flowcharts of exemplary program control steps performed by mobile radio transceiver 150 for implementing dynamic regrouping in the preferred embodiment.

These FIGURES 8-14 will be discussed together in order to describe the overaIl steps performed by system lO0.

All dynamic regrouping commands originate at system manager 41G in the preferred embodiment.

System 100 processes ~hese commands (FIGURE S block 501) by first decoding them to determine whether they ~ 37 - 45MR-00591 ~3~93~ are commands to make a regroup resident or change a resident regroup (decision block 502~; commands to cancel a regroup (decision block 503); or commands to activate/deactivate a resident regroup (decision block 505).

If the inputted command requires a new regroup to be made resident on system 100 (block 502~, system manager 416 sends messages to site controller 410 requiring it to initiate the regrouping process (in the preferred embodiment, this command is actually carried out by first updating site controller data structures 1400, 1420 with information needed to begin the regrouping process, and then sending the site controller a "start regroup" request, as will be explained).

The site controller 410 performs the regrouping process in three stages: (a) the "phase I" regrouping process (block 506); the "phase II" regrouping process (block 508); and a "bitmap handling" process tblock 510).

All three processes are typically performed simultaneously by site controller 410 in the preferred embodiment.

Referring now to FIGURE '3 (the detailed flow chart of the "phase I~ regroup process 506), site controller 410 in effec~ breaks down regroup requests by source groups from which the individual transceivers to be regrouped reside -- as specified in the "home group ID" fields 1406 within gueue elements 1402.

That is, for "phase I" processing, controller 410 first contacts entire "source groups" of transceivers -- some of the member transceivers of which may not be involved in the regrouping process, and then exchanges signals on a transceiver-by-transceiver basis with each - 38 - 45MR-00591 ~3~3~ transceiver to be regrouped.

In the preferred embodiment, the "phase I" regroup process proceeds by calling all source groups (that is, groups normally resident on the communications system) from which individual transceivers are taken to form the new regroup and causing these source groups to monitor an alternate control channel temporarily; and then sending regroup messages (and receiving responses) over the alternate control channel to each individual transceiver to be in the new regroup.

Site controller 410 first determines whether any more source groups need to be contacted in order to form the new regroup (FIGURE 9 decision block 514).

Site controller 410 selects the 1'next" source group in the planned new regroup (block 516) and determines whether there are more than "x" (x=3 in the preferred embodiment) units in this source group (decision block 518).

If more than x units are in the new regroup, site controller 410 executes the "phase I" regrouping process (FIGURE B block 506, FIGURE 9 blocks 520-530) involv:ing an alternate control channel.

On the other hand, messages to only "x" or fawer mobiles will not isnpose burdensome loading on the main control channel and may not justify the additional overhead required to perform "phase I" processing -- and therefore, in the preerred embodiment, only the "phase II" (background) regrouping process is used for such small regroups (FIGURE 8 block 508 and EIGURE 12 blocks 532-538).

It should be noted that there are advantages to specifying large source groups.

First, it is easler for the supervisor to build regrouping plans - 39 - 45MR-00591 i3~3~ and visualize the plans when they are executed.

Second, the regrouping process is not only faster but also more efficient if larger numbers of units to be r0grouped can be han~led simultaneously by the '~phase I" portion of the process.

In addition, there is a very subtle but important third advantage addressing the fact that regroup plans can't be independent of "shift" -- that is, periods during the day and night when different personnel are working.

Unfortunately,~ the world is not blessed with accidents that wait until the shift personnel stored in a particular plan are on duty.

An emergency dynamic regroup plan must thereore be independent of shift.

Achieving shit independence can be difficult if not impossible to achieve in practice, but the regrouping provided by the present invention can relieve the problem to some extent.

Since the regrouping process can occur so quickly, any plan can include radios from multiple shifts.

Within a short time of execution of the plan, the operator of system manager 416 can determine which radios have been regrouped and which radios are not present.

Radios that have not responded to regroup messages (~most likely because they are "off duty" ) can be interactively removed from the regroup plan.

If there are more than "x" units in the source group, '`phase I" regrouping can proceed for that source group, and a channel assignment for the source group is transmitted over the main control channel -this channel assignment message specifying a free working channel (block 520).

All mobile transceivers in the specified source group monitoring the main control channel respond to the group channel - ~0 - 45MR-00591 ~ 3 ~ 3 ~ assignment message in ~he same way they respond to any routine group channel assignment message in the RF signalling protocol of system 100 -- except that in this case site controller brings up the free channel as an alternate control channel instead of as a working channel (FIGURE 9, block 520).

Site controller 410 merely controls the working channel trunking card (e.g., 402) associated with the free working channel to behave as a contxol channel trunking card rather than as a working channel trunking card (in the preferred embodiment, any trunking card can cause its associated repeater to act as the control channel repeater for "fail-soft" considerations -- this feature of the system architecture is used to advantage in the phase I dynamic regroup process by simply reconfiguring a free working channel as an alternate control channel).

The alternate control channel activated by block 51~ has all of the same signalling as the main system control channel -- except that a certain bit sequence in periodically-transmitted control channel protocol is modified slightly on the alternate control channel so that mobile units can distinguish between an alternate control channel and the "real" control channel.

Suppose, for example, that a mobile transceiver enters the geographical area served by a site (or is turned on) while an alternate control channel is activated, begins searching for the control channel and comes across the altsrnate control channel before it discover~ the "real" control channel.

In this situation, the mobile transceiver detects that even though the control ~ 45MR-00591 ~ 3 ~ 9 channel it is monitoring "looks" like a control chann~1, the bit seguence corresponding to dynamic regrouping is present, and therefore the mobiLe transceiver continues scanning until it finds the main control channel.

Referring briefly to FIGURE 10, mobile transceivers in the called source group respond to the channel assignment message issued by site controller 410 over the main control chann~1 in the same way they respond to any routine group channel assignment message -- by loading their internal frequency synthesizer with the appropriate frequency (block 704) -- thereby retuning to th~ alternate control channel.

The called source group transceivers then obtain synchronization with the "slotted" outgoing digital control channel signals site controller 410 cau`ses to have transmitted over the alternate control channel (block 706) and decodes each outgoing alternate control channel message as it is transmitted (block 708).

Meanwhile, after site controller 410 "collects" t~e source group containing transceivers to be regrouped onto the alternate control channel, it makes up to three attempts to contact each individual mohile transceiver to actually be regrouped.

It is an important feature of one aspect of the present invention that FIGURE 9 block 520 causes all transceivers in a specific source group (even those that will not be dynamically regrouped) to begin monitoring an alternate control channel.

Typically~ only some and not all of the transceivers in a particular source group will actually be sent a dynamic regroup command by block 530.

However, - 42 - 45MR-00591 1 3 ~ hecause of the rapid data transfer rate over the alternate control channel (which in the preferred embodiment carries no messages not needed for either the dynamic regroup process or for sustaining synchronization between the site and the mobile units in the source groups), dynamic regroup messages can be transmitted very rapidly over the alternate control channel -- and because there are no contentions on the i~bound control channel, transceivers can send acknowledgments just as rapidly.

Using this technique, over thirty mohile transceivers per second can be "regrouped" via the "phase I" process 506 in the preferred embodiment -and thus, mobile transceivers not actually being regrouped but which are members of source group containing mobile units which are being regrouped are only taken away ~or normal communications for an instant (not long enough to interfere with any routine calls they might recei~e).

FIGURE 9 decision block 522 tests whether three passes have been completed for each mobile transceiver to be reyrouped.

If three passes have not been completed for each transceiver, site controller 410 next determines whether all units to be regrouped from the source group have been processed (FIGURE 9 decision block 524~.

If some units have not yet been "regrouped", then site controller 410 selects the next individual ~nit rom the source group to be "processed" (block 526), and tests whether this unit has already sent an acknowled~ement message over the alternate c~ntrol channel (~ignifying that it has already recei~ed and processed the dynamic regroup message -- as recorded - 43 - 45MR-00591 ~3~9 3~ by a bit in the unit control block field 1412 o~ associated queue element 1402) (block 528).

If the selected unit has not yet sent an acknowledg~ment, site controller 410 transmits a dynamic regroup outbound control channel message over the alternate control channel directed to that specific unit (block 530). The format of this outbound contrQl channel dynamic regroup message was set forth previously, and includes a first message specifying the logical identification of the individual transceiver being regrouped and a second message specifying various parameters of the new regroup (e.g., regroup plan number, regroup type, group knob setting and identification of the regroup).

Each mobile transceiver 150 is equipped with sufficient internal non-volatile memory spaca to store up to 8 regroups at a time (in the preferred embodiment all a regroups must be part of the same regroup plan).

Referring now again to F:tGURE 10 (a flow chart of exemplary program control stepS performed by mobile transceivers 150 in the prefaxred embodiment to implement dynamic regrouping), when a mobile unit decodes a dynamic regroup command transmitted by FIGURE 9 block 530 that specifies its own individual identification (FIGURE 10 decision block 710), the transceiyer stores the regroup information contained in the dynamic regroup message into an internal non-volatiLe memory (FIGURE 10 block 712) and transmits a s~andard protocol acknowledgement message to the site (~his acknowledgement message echoing the regroup parameters fields contained in the second message in the outbound control channel dynamic - 44 - 45MR~00591 ~ 3 ~ regroup message pair) (block 714~. Site controller 410 awaits receipt of acknowledgement messages transmitted by block 714 (FIGURE ll block 801). When an acknowledgement message is received, site controller 410 finds the appropriate queue element 1402 shown in EXGURE 5 corresponding to the specific mobile transceiver which has sent the acknowledgement (e.g., by locating the correct logical id field 1404 through a sort control block used to index the queue) (FIGURE 11 block 802), changes the Unit Control Block bit 1412 in the appropriate queue element to reflect that the unit has responded to the regroup command (block 804), and returns to what it was previously doing (FIGURE ll blocks 801, 802, 804 may be performed on an "interrupt-driven" basis if desired).

All mobile transceivers in the source grou~ continue to monitor the alternate control channel until site controller 410 causes a termination message to be transmitted over the alternate control channel (FIGURE 9, block 532). In the preferred embodiment, this termination message is simply the standard "site id" message with the site id set .to a specific value not used by any existing site in system~lO0 (e.g., Site ID = 63). Hence, mobile units in the source group that are not being regrouped and mobile units that have already received a dynamic regroup message directed to them and acknowledged the message continue to monitor the alternate control channel in the preferred embodiment until a "~ite id" type termination message is transmitted by the site controller (FIGURE 9, block 532) and received by the mobiles (FIGURE 10, decision blocks 716, 718), at ~ 45 - ~5M~-005gl ~31~939 which time the mobiles return to the main control channel (FIGURE 10 block 720) and monitor the main control channel in normal fashion to await receipt of call messages specifying either their "normal" groups (or a "regroup activation" bit map message if they have been reconfigure~ by block 712).

Referring once again to FIGURE 9, blocks 522-530 are performed three times in the preferred embodiment for each mobile transceiver to be regrouped~ That is, each transceiver to be reconfigured into the new regroup is sent an outbound control channel dynamic regroup message, after which site controller 410 waits briefIy for an acknowledgement.

If no acknowledgement is received within a certain time-out period, site controller 410 sends the mobile transceiver another outbound control channel dynamic regroup message and waits for an acknowledgement.

If no acknowledgement is sent to the second message, the site controller 410 transmits 2 a third dynamic regroup message to the mobile unit and waits for an acknowledgement.. If no acknowledgement is received in response to this third dynamic regroup message, site controller 410 '!gives up" attempting to dynamically regroup that specific mobile transceiver in the "phase I" proces~. Site controller 410 then releases the source group and the alternate control channel (e.g., by transmitting a terminate message as described, although it might also be possible to release the source group by transmitting a working channel as~ignment message specifying the main control channel if desired, or alternately, by simply "dropping" the alternate control channel and thereby causing the mobile 3 ~ ~ 46 - 45MR-00591 transceivers to scan for the main control channel), and repeats block 514-530 for the next source group containing mobile units to be placed into the new regroup. Site controller 410 is capable of concurrently performing the l'phase Il' process 506. That is, multiple alternate control channels can be established simultaneously, and process 506 can be performed for dif~erent regroups simultaneously (or ~or different source groups for the same regroup simultaneously) using different alternate control channels if desired.

When each such source group has been processed ~as tested ~or by decision block 514), the "phase I" process has been completed, site controller 410 begins performing "normal" tasks (including "phase II" dynamic regrouping in the "background" over the main control channel) for that group. This can occur simultaneously with Phase I of the next source group.

Even after the "phase I" regroup process has completed, there may still be (and typically are) a few mobile transceivers that for various reasons have not yet been "regrouped". For example, FIGURE 9 block 518 specifically avoids regrouping certain mobiles in "phase I"; and some mobile transceivers may not have been powered-on during the "phase I" regrouping process, while others may have been obstructed by a hill or a bridga from receiving "phase I" regroup messages intended for it. Even though redundancy is "built in" to the ~F signalling protocol being used (e.g., after the channel assignment message is transmitted by FIGURE 9 block 520 over the main control channel, it may be periodically retransmitted via subaudible signalling on the working channels and is repeated periodically 9 3 9 -- 47 - 45MR-00591 over the main control channel to reach mobile transceivers that may have "missed" the ~irst channel assignment message to permit "late entry"), some mobile transceivers that need to be regrouped may not be regrouped by the 'Iphase I" regroup signalling transaction. "Phase II" regroup signalling over the main control channel is used to reach: (1) mobiles that are called to the alternate control channel but fail to respond and/or acknowledge regroup messages transmitted to them: (2~ mobiles from source groups containing fewer than a specified number of mobile transceivers needing to be regrouped; and (33 mobiles that were turned off or out of range for phase I.

FIGURE 12 is a flow chart of exemplary program control steps per~ormed by site controller 410 to implement the "phase II" dynamic regroup signalling process, and FIGURE 13 is a flow chart of exemplary program control steps performed in the preferred embodiment by mobile transceivers 150 in response to "phase II" dynamic regrouping signalling.

Referring now particularly now to FIGU~E 12, site controller 410 (which is typically engaged in transmitting various different messages over the main control channel, including routine p riodicallytransmitted status messages and channel assignment messages for routine group and individual calls) determine whether any mobile units need to be regrouped using "phase II" signalling (this information may be obtained by searching through the queue 1400 for unresolved regroup requests (FIGURE 12 decision block 533).

If there are mobile units to regroup using "phase II" signalling, the "next" unit is selected (block 534) and the queue element 1402 corresponding to that unit is tested to determine - 48 - 45MR-00591 ~31~3~ whether the unit has already acknowledged a dynamic regroup message directed to it (decision block 536).

If the unit has not yet acknowledged, a dynamic regroup outbound control channel message transmitted over the main control channel directed to the unit to be regrouped (block 538).

In the preferred embodiment, this outbound control channel dynamic regroup message is identical to messages transmitted over the alternate control channel by FIGURE 9 block 530 -- and mobile transceivers respond in the same manner as the transceivers do on the alternate control channel (see FIGURE 10) by insuring the dynamic regroup message is intended for them, storing the regroup parameters in their internal memories, and transmitting acknowledgements to the site (EIGURE 13, blocks 710a-714a).

In the preferred embodiment, phase II signalling is performed indeinitely for all mobiles to be regrouped that do not respond (typically a relatively small nu~ber) until system 2 manager 416 cancels the regroup reguests as to those mo~ile transceivers.

The "phase II" process taking place on the main control channel adjusts the number of outbound dynamic regroup control channel messages based on system loading.

If loading is light, there is no reason why several regrouping co~mands per second can't be issued. A system loading increases, the rate at which dynamic regroup control channel messages transmitted over the main control channel is decreased to avoid adverse impact on other system operations.

In accordance with an important feature of a further aspect of the invention, mobile transceivers ~ 49 - ~5MR-00591 ~3~3~ "regrouped" as discussed above (that is, dynamically reconfigured during the "phase I" and "phase II" signalling processes) do not begin using the regroups dynamically allocated to them until they receive a further message to do so over the main control channel. Only upon the transmission of a regroup plan bit map message specifying activation of a particular plan previously made "resident" do all previously programmed transceivers in a particular regroup virtually instantaneously respond -- all at essentially the same time -- by activating the newly activated dynamic regroup. Immature groups are entirely avoided using this virtually instantaneous activation technique. In addition, even though it is desirable to transmit outbound control channel cancel dynamic regroup messages to individual transceivers and receive responsive positive acknowledgements in order to cancel (make non-resident) a resident dynamic regroup plan, it is possible in an emergency (or panic situation) to make a resident (active or inactive) regroup plan immediately inactive and non-resident by issuing a single outbound control : channel bit map message specifying that the plan is non-resident.

Referring now to FIGURE 8 block 510, around the time "phase I" ~ignalling is occurring, site controller 410 performs a bit mask handling routine that issues updated bit map outbound control messages over the main control channel.

As discussed 3 previously, the system dynamic regroup plan bit map periodically transmitted over the main control channel notifies all mobile units on communications system 100 of the current status Iresident and/or - 50 - 45MR-00591 ~3~93~ active) of up to sixteen different regroup plans.

As soon as "phase I" signalling process 506 is performed for any (the first) regroup in a regroup "plan" (each plan may contain an arbitrary number of regroups in the preferred embodiment), site controller 410 must modify the bit plan map periodically transmitte~ over the main control channel to reflect that the new regroup plan has been made "resident" on system 100.

The site controller 410 performs this updat~ng merely by changing the appropriate "plan residency" bit in the .egroup plan bit map to reflect that a new regroup plan has been made resident on system 100 -and transmitting the updated bit map in a message over the outbound (main) control channel.

When a lS mobile transceiver receives an outbound control channel regroup plan bit map message over the main control channel (block 716 of FI W RE 14), it decodes the message and, if it stores any regroup plan parameters in its internal memory, it tests the plan residency bit~s) corresponding to the internal regroup plans it stores.

If the resident bit in the received bit map corresponding to a particular plan stored in the internal memory is not set, the mobile transceiver autonomously purges the area of its inte~nal memory storaging dynamic regroup parameters (decision block 718, block 720 o FIGURE 14) --:this purging process being relatively simple in the preferred em~odiment because of the restraint that only one regroup plan can be resident in a given mobile at a given time. On the other hand, if the residency bit corresponding to an internally stored dynamic regroup plan is set (indicating that the plan is still or has become resident on system 100), the - 51 - 45MR-00591 ~31~93~ mobile transceiver retains the plan parameters in memory (block 722)~ Mobile transceivers 150 also test the plan bit map to determine whether they should activate resident dynamic regroup plans.

In accordance with an important feature of one aspect of the present invention, dynamic regroups may be "resident" but not yet "active".

Referring briefly to FIGURE 8, if system manager 416 co~nmands that a formerly inactive resident regroup plan is to be made actiye (decision block 505), site controller 410 transmits an updated bit map message over the main control channel with both the "residency" and ~"active" bits for that regroup plan being set (block 511).

When a mobile transceiver receives A plan bit map that specifies a particular plan (parameters of which are stored in its internal memory) as being both "resident" and "active", the transceiver activates the regroup plan (e.g., by responding to all channel assignment message calls issued on the main:control channel corresponding to the regroup or regroups in the plan, by permitting the user to access the regroups in the plan that knob control settings specified by the regroup paramet~rs, and in some cases, ~y forcing the transceiver to operate only on the regroup as specified by the "regroup type definition" issued as part of the dynamic regroup outbound control channel :` message making the regroup plan "resident")~(decision block 724, block 726 of FIGURE 14).

Similarly, ite controller 410 can make a previously active regroup plan inactive by simply transmitting an updated bit map with the status bits corresponding to the regroup plan set to "resident" - 52 ~ 45MR-00591 ~31~ but "inactive".

If a previously "active" regroup plan is deactivated, receiving mobile transceivers simply discontinue using the regroup plan parameters (e.g., by preventing the user from accessing the regroups via the group select knob, and by ignoring group call messages directed to the regroups) (FIGURE 14, decision`block 7~4, block 728).

Significantly, the deactivated "plan" remains "resident" in the transceiver until the transceiver receives a further 1 plan bit map specifying it should be made non-resident (and/or until the transceiver receives a cancel regroup command as will be explained) -- so that multiple (and even alternate) regroup plans can be "resident" on system 100 simultaneously and system manager 416 can activate or deactivate regroup plans at will without the time delay involved:in sending each individual transceiver to be regrouped new parametars.

Referring to FIGURE 8 once again, cancelli~g a resident dynamic regroup plan can be performed in either of two ways.

If a resident plan i8 to be cancelled (decision block 503), the system manager 416 can specify a non-emergency ~more ordered) ::

cancellation (decision block 504, ~locks 506a-510a) or an emergency (decision block 504, bIock 510a) cancellation.

In the non-emergency cancellation, the "phase I" and "phase II" steps shown in FIGURES 9-14 are performed just as for making a new plan resident -- except that the channel assignment messages transmitted by block 520, FIGURE 9 may be directed to the regroups instead of to the source groups (if the plan being cancelled is still active at time of cancellation) -- and FIGURF 9 block 530 and FIGURE 1 - 53 - 45MR-00531 9 3 ~ blo~k 538 transmit cancel regroup messages rather than dynamic regroup messages to individual transceivers.

This non-emergency cancellation technigue assures a positive acknowledgement from each mobile transceiver in response a cancel regroup message directed specifically to it (in response to which cancel regroup message the mobile transceiver erases the appropriate plan parameters from its internal memory rather than adding them as in EIGURE 10 block 712, FIGURE 13 block 712a).

The "emergency" type cancellation uses an updated bit map message to control all transceivers in which a particular plan is "resident" to purge the dynamic regroup information from their internal memories.

In the event of a ~Ifail soft" situation (see commonly assigned Canadian application serial no.

566,663 filed June 3, 1987), the control channel trunking card sets a bit in the outbound control channel protocol to indicate that system 100 is in fail soft mode.

Upon detection of this bit, all transceivers 150 in which a regroup plan is "resident" and "active" automatically override the dynamic regroup "regroup t~pe" parameter transmitted as part of the dynamic regroup message making the plan resident -and set this parameter to "11" (optional select).

In other words, all active regroups revert to a mode which allows users to optionally switch into and out of them whenever the system enters the "fail soft" mode.

Meanwhile, the control channel trunking card is capable of handling calls to and from regrouped transceivers as well as "normal" transceiver groups when operating in fail soft mode -- and is also capable of handling console commands to cancel '~ ' - 54 - 45MR-00591 ~L31~39 regroup plans and transmit bit map messages making active plans non-resident.

An acceptable mode of operation is thus provided even if site contrvller 410 fails at the time a regroup plan is only partially implemented.

SYS~EM MANAGER 416 System manager 416 plays an important role in controlling system 100 and is thP portion of the communication system in the preferred embodiment which directs dynamic regrouping functions.

System manager 416 also handles all of the alarm and control functions provided by ACU 600, and al~o receives notification of alarm and other error conditions qenerated by test unit 700 and power monitor unit 500.

System manager 416 in the preferred embodiment is intended to be operated by the system manager operators -- people who are responsible for the overall operation and maintenance of system 100.

FIGURE 4 is a detailed sahematic diagram of the structure of system manager 416.

System manager 416 include~ a central processing unit 600, a random access memory 602, a fixed disk 604, floppy disk drives~606, an optional tape drive 608, a printer 1610, a serial I/0 interface 1612, an expanded serial I/0 interface 614, serial modems 616, and one or more display terminal~ 618.

Central processing unit 600 may be any de~ired conventional general purpose digital computer in the preferred embodiment (e.~., an IBM PC) connected to which is random access memory device 602, serial I/O interface 1612, 614, tape drive 608, fixed disX 604 and floppy disk drive 606.

.

~ 55 - 45MR-00591 ~ 3~9~ In the preferred embodiment, site controller 410 includes no hard disk drive, so that one of the responsibilities of system manager 416 is to store system parameters on fixed disk 604 and download those parameters to site controller 410 upon power-up of sy~tem 100.

CPU 600 communicates simultaneously with one or more display terminals 618 (each încluding the CRT display and a keyboard) via expanded serial I/0 interface 614 (of conventional design).

Printer 610 is provided to permit printing of a running log (or other desired reports) of system events. CPU 600 communicates with site controller 410 via a serial data link 417 (and communicates with a backup site controller via an additional serial data link~.

System manager 416 in the preferred embodiment is capable o managing plural sites simultaneously, and thus may be in contact simultaneously with several repeater sites.

Modems 616 ~of conventional design) may be provided to allow communication between the site controller 410 and system manager 416 over a conventional landline.

Some of the functions performed by system .

m~nager 416 in the preferred embodiment inc~ude:

~ Dynamic Re~roup Group and Plan Assignments;

.

Dynamic Regroup Activation;

Dynamic Re~roup Deactivation; and Dynamic Regroup Site Coordination.

T~E DYN~MIC ~EGROUP SYSTEM MANAG~R USER INTE2EACE As mentioned, the dynamic regroup interface in the preferred embodiment is used to plan in advance - 56 - 45MR-00591 9 3 9 fvr situations that require units from various home groups be temporarily configured to a group(s) other than their home group.

The configurations are then saved in destination group(s) under a plan name and can later be activated with a minimum number of Xeystrokes. A supervisor is able to activate from the plan level (which activates all destination groups under the plan) or from the destination group level (which only activates a single destination group at a time).

The dynamic regroup function in the preferred embodiment provides:

an unlimited number of plans up to disk storage capacity each plan can have many destination groups each destination group can identify many source groups rom which the units are selected It is important for the dynamic regroup user interface to be easy to use and easy to understand.

The preferred embodiment user interface uses menu driven software to present information to the u er in an easily understandable and digestible format and to allow the user to simply and easily specify desired group configuration information.

In the preerred embodiment, the user interface consists of three "screens" or menus: the "main" screen; the "units" screen; and the "group" screen.

The data is entered via the keyboard of one of terminals 618, and the various menus are displayed via the CRT of the terminal 618.

Moving between screens as well as other operations can be specified via the function keys of the keyboard in the preferred embodiment.

- 57 - 45MR-00591 ~31~3~ An exemplary "main" screen format is shown below:

56E i6-PLUS TRUNKIN6 SYSTElt Dynaæic Regroup Plan Direttory Pl~n~: _ D2stin~ti~n: _ Source:

3escrip~io~:

Pl~lis ' Oest.natiu~ 6r~ups ' Sour~e Sr~ups _ .. .,. - ----! - - -- --~_ , ___ _ , _ , ___ j ETil S~E DELETE ~ODPCT 6RPSC~EEN SU~IT SIOP ~STARTRE~CYE The main screeIl consists of three "regions":

the "plan" region, the "destination" qroup regio~, and the "source~ group region.- The "plan" region lists predefined dynamic regro~ping plans availabIe for execution. Each regroup p-lan specifies at least one (and typically more than one) new group in terms of the "normal" groups the mobile transceivers to be regrouped normally reside in ~i.e., the "source" groups) and the new groups these mobiles are to ba dynamically regrouped into (i.e., the "destination" groups, or ~'regroups"3. In somewhat more detail, each plan consists of at least one destination group and at least one source qroup (each group can be a subfleet, a fleet or an agency). A "destination" - 58 - 45MR-00591 13~9~ group defines a new group into which radio transcei~ers are being dynamically regrouped (that is, a "regroup"). A "source" ~roup is a group from which the mobile transceivers are being taken (i.e., a group in which the mobile transceivers "normally" reside).

This concept of specifying dynamic regroups in terms of regroup plans each specifying a set of existing groups and new groups allows the user creating, activating or reviewing a regroup plan to Xeep an overall perspective (by maintaining a "top-down" approach, the user doesn't get lost in detail).

When the user selects a specific plan from ~he plan region of the main menu, a list of the destination groups in the plan appears in the destination region.

If the user then selects one of the listed destination groups, the source groups used to "build" that destination group are listed in the source yroup region of the menu.

By then selecting a - 59 - 45MR-00591 ~ 3 ~ specific source group from the list, the "units" screen appearing below is displayed:

` Page 1 ~t 1 SE Ib-PLUS TRUN~N6 SYSTE~I i Dyna~ic Regroup Units Current l~od~: CRE~IE Reqroup Plan : Units froa S~urce 6rw~:

DestiDation Sroup: . 6roup Leve:

Description:

_ Unit K Unit ~ Unit K Unit r~ Unit K Unit K ~ _ ~ _ P~rc~ntaqe Required: _ Colplete: Q ., C~itical Unit Count: O Resolved: Q ~ NE~P6 ~ODCRlT CRITICAL SEL~LL ST~IUS iiH~a/SEL PURSE NO~E , E~lll S~IE NXTGRP .

The "units" screen lists all of the units in 20 the specified source group that are to be extracted from the 30urce group and dynamically regrouped into the destination ~roup.

~f a new source group is selected on the main screen (e.g., when a plan is being created or 25 modified), all of the units associated with the: :

selected source group are lis~ed on the units screen -- and the operator can then select which units he desires to include in th~ destination group.

Once the operator completes his selection of desired 30 units, sy~tem manager 416 automatically purges unselected units and alphabetizes the list (if a source group already specified in a plan is displayed, the units included in this displayed ~3~93~ - 60 - 45MR-00591 source group are listed in alphabetical order). New units can b~ added or existing units easily deleted using this same unit screen.

Specifying individual mobile transceivers in terms of the source group they are normally included within reduces the level of user complexity and permits the user to specify dynamic regroup plans in a natural manner -- and also has an impact on the way dynamic regrouping i5 activated.

Some of the function keys displayed at the bottom of the units screen can be used to toggle the "K" field between l'K" (knob setting~, "T" ltype of regroup), and "S"(status). Since some radios need to be programmed with multiple new groups, the ability ~5 to specify the group's knob setting eliminates ambiguity or conflicts. In the preferred embodiment, new groups specified using the dynamic regrouping feature do not replace existing groups in a radio transceiver, but rather are positioned "below" them on the transceiver channel selection knob/display.

Suppose, ~or example, that a mobile radio transceivsr is set to group "1". If the transceiver user sPlects the next "higher" group by clicking his channel selection knob one position to the right, the transceiver will begin operating in the next higher "normal" group. If, on the other han~, the transceiver user selects a "lower" (i.e., left-hand position) group, the transceiver will begin operating on the "highest" regroup programmed into the radio. Turning the channel selection knob an additional position to the left selects the next "lower" regroup, this selection continuing until all '~regroups" have been 131~3~ - 61 - 45MR-00591 selected.

Regroups are distinguished from ~Inormal~ groups on transceiver digital displays by displaying the 1l0l- in the first digit position.

For example, if a radio transceiver is programmed with "normal'l groups "1", "2" and "23" and the radio is regrouped with two regroups, one with the knob setting "ol" and the other with the knob setting "05'i, the sequence of groups as accessible from the group select control knob would be "01", "05", ~ , "2" and "23" (in that order as the knob is turned from left to right in the preferred embodiment).

The "type" setting specifies whether the radio should or should not be forced to join a dynamically allocated group and whether or not the user can override the regroup command i~ he desires.

There are four possible values for this "type" setting in the preferred embodiment:

(a) the regrouped transceivers is forced to a regroup and cannot deselect the re~roup, (b) the regrouped transceiver is forced to a regroup but can deselect the regroup and use another group, (c) the regrouped transceiver can freely select and deselect the regroup; and (d) the regrouped transceiver is not forced into the regroup, but if the transceiver user selects the regroup the transceiver is forced to remain on the regrouping.

The system manager user can change any of the four "type" settings on a unit-by-unit and regroup-by-regroup basis.

The "status" field is used when a regrouping plan is active to indicate whether or not a radio - 62 - 45MR-00591 ~3~ ~93~ transceiver has actually been regrouped or whether the regroup reques~ is pending as to it ~e.g., the unit has not yet been located so it is not yet regrouped).

This status field thus allows the system manager operator to intsractively monitor regrouping as it progresses.

The preferred embodiment also permits the supervisor to specify not only what unit~ will be regrouped into specific destination groups, but also the identification of the destination group.

This additional information is speciied by using the "group" screen shown below: :

. ~ 6E 16-PLUS TRUHKIN6 SYSTE~ :

Dyna~ic Regroup De~iae Screea Plan Na~e : Dest. 9rDup: Rercent Req.: 100 Description : _ Agency ~ueber : _ Fleet ~luaber: _ Subtleet Nu~ber: _ Record TYpe : _ Console ha~e : _ Console ~ay Nu~ber: _ C~nsole ~odule: _ (Ni~ei ' lCitY) . : ~IState): _ Iz]p~ (Phqne Nusber) :

Prior~ty : (Hang Tisel:

-- 1111111111~22222~2333 -Site Nu~ber 123~5678901234567B90123456799012 Actiye tY) : _ F6 F7 F10 EXIT SRYE CLEAR I , _ _ By specifying the destination ~roup and striking the "group" function key; ~he group screen is displayed.

This group screen lists the name of the plan and the name of the destination grQup ( regroup) and allows - 63 - 45MR-00591 13~ ~g39 the user to input information identifying the regroup (e.g., agency, fleet or subfleet~.

The priority and hang time to be associated with a regroup may also be specified, in addition to "percent required" and "critical unit" information which permits a new group to become active only when a specified percentage of total units in the designation group and all units designated to be critical to the regroup have actually been regrouped.

The procedure for defining a regroup plan may proceed as follows:

1.

Decide which units need to be included in the plan.

If a number of units are in the same home group(s~, record the home group name(s).

These home group names are the source groups.

The nfmes~o,f a/ll units in the source group will be generated~by the system on the units screen.

The user is able to edit ths source group unit by unit, 90 it is not necessary that a home group be identical to the source group.

2.

List the names of any units that are to be included in ~he plan that do not a~pear in any common home group.

3.

Decide on the number of destination groups ("regroups"~ for the plan and give a unique destination group name (up to 8 characters) to each one. List the home group names in step 1 and the units in step 2 in order of which ones you want to be able to activate together under a destination group name.

4.

If any destination group has only names - 64 45MR-00591 3 ~ from step 2 and no home group names from step l, write the word INDIVIDL under the destination group name. INDIVIDL is the source group nam~ for this list. When setting up the plan, you will have to type each individual unit name only for individual units that don't appear in any common home group on this list on a screen under the INDIVIDL source group name.

The attached Appendix A sets forth specific exemplary operator instructions for interacting with one version of the menu driven software executed by system manager 416 in the preferred embodiment.

SYSTEM MANAGER MESSA~E FORMATS The following describes exemplary messages and message conventions communicated between system manager 416 an~ site controller 410.

MESSAOE P~OTOCOL Mes3ases are transmitted between system manager 416 and site controller 410 in 8-bit data pacXets delimited by frame start characters and checksum characters. Each packet starts with a frame byte character of OAA hex. The internal structure of a packet is as follows:

ff tt dd dd dd ... dd cc where ff is the frame sync character (OAA hex), tt is the messa~e type byte (which defines the content of the message), - 65 - 45MR-00591 13~93~ dd are data bytes, and cc is a checksum (formed by taking the exclusive OR of each byte in the messa~et starting with the message ID byte, and then negating the result~.

~CKNOWLYDGæ~æNT RULES Any valid message received is acknowledged. A valid message is defined as one in which the checksum of the data bytes matches the checksum transmitted.

If a packet is received but has an invalid checksum, a negative acknowledgement (NACK) is sent.

MessAges are transmitted singly threaded, waiting for an acknowledgement before sending the next message. Receiving a negative acknowledgement results in immediate retransmission of the pacXet.

If an acknowledgement is not rec:eived wi~hin two seconds, the same message is retransmitted.

RetransmisRion should occur three times before erroring out.

An acknow}edgement message has the following form: f~ AA tt 0~ cc FF (checksum of 00) A negative acknowledgement message has the 25 ~ollowing form: ff M tt FF cc 0~ FIGURE 15 is a flowchart of exemplary program 30 control steps performed by both system manager 416 and site controller 410 to transfer messa~es in the format above between the two of them.

- 66 - 45MR-00591 ~3~93~ SYSTEM MANAG~R TO SITE CONTROLLER MESSAGES The following describes exemplary messages used to communicata dynamic regrouping commands and information from the system manager to site controllers in the preferred embodiment.

~EGROUP BUFEER REQU~ST - MESSAGE T~PE 37 The regroup buffer request is implemented to allocate/extend a dynamic regroup control buffer from -the site controller. When received, the site controller will scan the regroup control blocks (RCB) for a match of the destination group id. Providing no match is found and the appropriate buffer space is available, the site controller will create an RCB for the specified destination group id. However, if there is a positive match between the destination group id and an RCB, the site controller will e~tend the buffer space available for that regroup.

,~, - 67 - 45~R-00591 1 3 ~ 3 9 A response from the site controller is generated from reception of this command.

:................. Message type (37~ ..Dl,. .D2.. Destination group id t0-2048) . D3.. . D4.. Number of units to be regrouped (0-1024) :................. Regroup qualifier Re~roup Qualifier B7 B6 B5 B4 B3 B2 Bl B0 Plan number for regroup¦ Not ¦ Fleet Decode Field used . . I 1.

Fleet decode field contains the number o~ bits required by the mobile to properly decode the fleet.

Plan number is the number used in t~e regroup commands.

- 68 - 45MR-00591 ~ 3 ~ SUBMIT COMMAND ~ MESSAGE TYPE 38 The purpose of the submit command is to plac~ the specified unit into the regroup control buffer identified in the destination group id.

.MM............. Message type (38) .Dl.. ..D2.. Destination group id (0-20483 :.. :.......... Home group id (0-2048) D5 D6 Logical id (0-16383) :.. D7............. Request qualifier (see below) :................. Status qualifier (see below) - 69 - 45MR-00591 131~ Re~uest ~ualifier B7 B6 B5 B4 B3 B2 Bl ~0 Unused ¦ Type Request ¦ Group Knob Setting _ _ Type request:

00 -~-> Forced select, no deselect 01 ---> Forced select, optional deselect 10 ---~ Undefined ~ > Optional s~lect Group knob setting:

... 7 - Associates regroup ~ith group ~nob setting Status ~ualifler B7 B6 B5 B4 B3 B2 B1 B0 A B C D E ¦ Unused .A active pending B active; C cancel pending; D cancelled E report status - ~must be cleared when resolving units) - 7~ - ~5MR-00591 131~9 START REGROUP REQUEST - MESSAGE TYPE 39 A start regroup request is issued to initiate the regroup process.

Once issued, the site controller will attempt to regroup all units in the specified buffer until (1) all units have been regrouped or (2) a discontinue regroup command is received.

The retry count identiies the number of attempts to make before reporting the status back to the system manager. A start regroup request with a retry count of zero is decoded as a discontinue/halt regroup command.

When received, regroup processing is discontinued until resumed.

Buffer contents remain the same.

:~ Message type (39) ..D?. D2 , Destination group id (0-~0~48) :.................

Report count (0-25~) ,D4 Regroup status (see below) Reqroup Status B7 B6 B5 B4 B3 B2 Bl B0 Unused . ' ¦ A A) process foreground flag 1 ---> process foreground ~ 71 - 45MR-00591 ~ 3 1 ~ STATUS El~:EDBACK E;U~:QUF:ST - MESSAGE TYPE 3A This co~mand is used to request a list of all units that have acknowledged the specified regroup.

Once this command is received and decoded by the site controller, a stream of status feedback responses will be sent identifying units that have acknowledged the regroup.

.MM Message type (3A) Dl . D2 Destination group id ( 0-2o48 ) DELETE BUFFER CO~AND - MESSAGE TYPE 38 The primary purpose of this command is to free up regroup buffer space in the site. This command gives the system manager the option of deleting a single element or deleting the entire group.

If the delete qualifier contains a zero, the unit specified in the logical id field will be deleted.

If the delete gualifier is a one, the entire regroup buffer will be deleted.

Message type (413 Dl. D2 Destination group id (0-2048) :

D3 D4 Home group ~0-2043) D~5. D6 Logical id ~0-16383) : D7 Delete qualifier (see below) 72 - 45MR-00~91 ~31~39 Delete Oualifier B7 B6 B5 B4 B3 B2 B1BO . . ~ Unuse~ ¦ A . . . _ .

A) Delete qualifier:

0 ---> Individual unit delete 1 ---> Regroup delete PL~N LEVEL BIT MAP ~FOR PLAN NUMBER X) MESSA~E TYP~ 16 Used to tell the site controller (which then tells the control channei) the state of each plan in the system. A11 plans are assumed to be not resident and not active initially.

:.................

Message type (22) :.. 1.... Plan number and bit states :

Plan Nu~ber and Bit 5tate~ -_La~ut :

B7 B6 B5 B4 B3 B2 Bl BO Unused ¦Active ¦Resident¦ Plan number (0-15j :

bit bit state state SITE CONTR~LLER TO SYSTEM MANAG~R ~ESSAGES The following are exemplary formats of ~ 73 ~ ~5MR-00591 9 ~ ~ :

messages used to communicate dynamic regrouping information from the site to the system manager.

REGROUP REQUEST RESPO~SE - M~SSAGE TYPE 37 This command is sent in response to a regroup buffer reguest.

If the buffer space reguested is available, the site controller will al~ocate the space reguested and report the remaining space allotment.

If the requested buffer space is not available, the site controller will utilize this command to report the remaining space allotment.

MM :............. ..........Message type (37 D1 . D2 Destination group id ~0-2048 :...... :......

Number of elements available (0-1024 :............. ..........Ack/Nak (0-255) START REGROUP R~QUEST RESPONSE MESSAGE TYPE 39 Upon receiving a start/initiate regroup request, this command will be issued to acknowledge reception of the command and confirmation of the resroup id.

MM Message type (39) Dl D2 Destination group id (0-2048) :....................... Ack/Nak ~0-255) .

.

- 74 - 45MR-00591 9 3 ~ STATUS FEEDBAC}C RESPONSE - MESSAGE TYPE 3A The site controller will issue this command to alert the system manager that a regroup (pass) has been completed on the grotlp idantified in the destination group id field. The system manager will then use the information contained (group id) to issue a status feedback request. When the request is received, the site controller will utilize this command to report back to the system manager the unit that has acknowledged the regroup request.

:....................... Message type (3A~ ;

..D?.. . D.2.. Destination group id ~0-20~8) ,,D3., ,,D4, Logical id (0-16383) ,D5,, Unit status (see below) Unit Status B7 B6 B5 B4 B3 B2 Bl B0 A B C D E ¦ Unused A active pending; B active; C cancel pending; D cancelled; E report status - (must be cleared whan resolving units) - 75 - 45MR~00591 ~3~ ~39 INTERACTION BETWEEN SITE CONTROL~ER AND SYSTEM ~NAGER The technigues by which regroup plan parameters are interactîvely inputted and displayed by system manager 416 have already been described.

The interactive software used to perform these display, input and data storage functions are menu-driven modules that result in storing the inputted parameters in disk files on system manager fixed disk 604. When the operator of system manager 604 issues a command to make a dynamic regroup plan (or a particular destination group from plan) "resident", system manager 416 issues a "regroup buffer request" message to each site controller 410 of system lOO at high speed over landland links in ` the preferred embodiment (FIGURE 16 block 902). The regroup buffer request command causes each site controller 410 in communication wlth system manager 416 (the system manager is typically in communication simultaneou~ly with-all site co~trollers in a multiple si~e ~ystem) ~o allocate and/or extend its regroup control block 1420 to add additlonal queue elements 1422 corresponding to regroups in the regroup plan to be made resident.

When site controller 410 receives this regroup buffer re~uest, it scans its regroup control block 1420 to determine whether there are any records 1422 with a matching destination group identification field 1424.

If no match is found in the appropriate buffer space, the site controller creates a new record 1422 with the specified destination group.

If - 76 - 45MR-00591 3~ there is a record already existing specifying that regroup, on the other hand, site controller 410 extends the buffer space available for that regroup.

Site controller 410 then responds by generating the "regroup re~uest response" message which acknowledges receipt of the request and reports remaining space allotted to the buffer 1420.

System manager 41~ may then submit commands to various sites by transmitting "submit command" messages ~FIGURE 16 block 904).

Each '~submit command" specifies an indivi~ual transceiver to be regrouped into a new or existing planO Site controllers 410 receiving "submit command" messages from system manager 416 add records to queue 1402 corresponding to units specifiecl by the submit commands - ensuring that the records created in buffer 1420 corresponding to the regroup are updated to point into queue 1400 and also ensuring that queue 1400 home group id fields 1406 reflect the proper regroup (and, o~ course, also en~uring that duplicate gueue elements are not created). Since system manager 416 generally has no way to tell what sites are serving partic~lar units to be regrouped, the system manager ~ransmits the submit command messages to all sites (or to particular multiple or single sites if the unit can be guaranteed to be opera~ing within a subset of possible sites) to thereby automatically permit "searching" for mobile units during the course of normal dynamic regroup phase I and phase II signalling.

When all individual mobile units to be regrouped have been specified by "submit command" messages, system manager 416 may initiate ~he - 77 - 45MR~00591 ~31~39 regrouping process by issuing a "start regroup request" message to all sites (FIGURE 16 block 906).

Site controller 410 updates retry count field 1432 of the appropriate record 1422 in regroup control buffer 1420 in response to the "start regroup requPst" message and issues a "start regroup response" message back to system manager 416 positively acknowledging receipt of the "start regroup request" message. Site controller 416 then begins performing the main regrouping routine shown in FIGURE 8 and discussed previously, and continues to perform this routine for the specified regroup until all units have been regrouped or until system manager 416 issues a discontinue regroup command.

In the preferred embodiment, site controller 410 operates on the regroup level rather than on the plan level. That is, site controller 410 is only responsible for making regroups -- and not entire plans -- resident or active.

System manager 416 provides the coordination in the preferred embodiment to permit activation on the regroup plan level (e.g., by issuing multiple start regroup request messages -one for each regroup in a particular plan), and also for coordinating between 5it8S.

Periodically during the regrouping process ~and at any time upon the request of an operator of system manager 416), the system manager may issue a "status feedback request" message to request a list of all units that have ack~owledged in the specified regroup (block 908) -- ~nb~ in which the regroup is therefore resident -- from each site.

In response t~ receipt of a "status feedback request" message, site controller 410 transmits a "status feedback response" - 78 - 45MR-00591 131~93~ message -- a stream of status feedback responses identifying individual units that have acknowledged outbound control channel dynamic regroup messages.

In the preferred embodiment, site controller 410 obtains this information by simply transmitting a list of all units in quaue 1400 corresponding to particular regroup with status fields 1410 indicating that the unit has acknowledged. When system manager 416 receives this information, it resolves units from diff~rent sites (block 910) to prevent one site from continuing to attempt to regroup units that have already been regrouped by other sites. For example, if system manager 416 receives a "status feedback response" message from site A stating that a particular mobile unit has acknowledged a dynamic regroup message, the system manager transmits "delete buffer command" messages to all other sites specifying that individual unit - thus preventing the other sites continuing to attempt to regroup that unit (block 912).

The status feedback response messages returned by site controllers 410 to system manager 416 are - also used by the system manager to update~its "units" screen to indicate whether individual units have or have not been "regrouped". The operator of system manager 416 may monitor this unit screen and watch as the status of diferent units change from "not yet regrouped" to regrouped".

System manager ~16 also maintains a current disk file listing of all units that have been regrouped in a particular regroup, and periodically tests this listing against the "percentage reguired" and "critical unit count" information specified at ` 79 - 45MR-00591 :l3~.93~ the time the regroup was specified. The most current results of this comparison are displayed on the "units screen". When this stored list of acknowledged units in a specific regroup contain both (a) the requi~ite percentage of units and (b) the requisite specific critical units needed to make the regroup effective, system manager 416 may automatically issue an updated plan level bit map message to inform all site controllers of the state of all plans on system 100 -- and specifying an active status for regroup ~or the operator of system manager 416 can override the percentage/critical unit defaults at any time to force such a message to be generated). The effect of this bit map message command is to activate the regroup on system 100 in the manner explained above in connection with FIGURE 14.

System manager 416 may deactivate an active regroup by issuing a further updated plan level bit map specifying a particular regroup is to be inactive (or inacti~e or non-resident). The efect of this further command is to cause all site controllers to issue modify dynamic regroup bit map messages -- and ultimately, to cause all mobile radios to autonomously respond by deactivating and/or making non-resident plans specified in the bit map information. This type of deactivation can be used in a "panic" situation or in an emergency (e.g., to immediately abort a regroup plan having unexpected results or for some reason interering with critical communications), although the "normal" method of making resident regroups non-resident is to perform steps 902-912 -- except that system manager ~16 - 80 - 45MR-00591 9 3 ~ issues "submit command" messages with "status qualifier" fields specifying "cancel" rather than "active pending" status.

All of the same steps (including acknowledgements) performed by site controllers 410 and mobile transceivers 150 to make a regroup plan resident are then performed to make the regroup plan "non-resident".

In addition, system manager 416 maintains an historical dynamic regroup bit map including the sixteen most recently resident regroup plans (with all non-resident plans having both resident and active bit unset) so that, for example, any mobile transceiver that was powered-off or removed from the coverage of communications system 100 at the time a regroup was active will, upon locking onto the system control channel, soon make the plan (which shoul~ still be resident in its internal memory) non-resident in response to a bit map message on the outbound control channel.

New plans are assigned arbitrary "plan numbers" (0-16) for purposes of the outbound control channel bit map messages (and : dynamic regroup messages~ -- with new plan numbers - being assigned to overlay the oldest deactivated plan (so that the historical deactivation data stays in the system as long as possible).

SAMPLE COMMnNICATION SESSIONS The following chart describes~sample communication exchanges between the system manager and the site controller in the preferred embodim~nt for initiating a sample dynamic regrouping process:

- 81 - 45MR-00591 ~31~3~ Svstem Manaaer Site Controller Regroup buffer request -->

<-- Regroup bufer response Submit command -->

Submit command -->

.

Submit command -->

Start regroup request -->

<-- Start regroup response + + + Processing + Status feedback request -->

<-- Status feedback response <-- Statu~ eedback respo~se :

c-- S~atus feedback (end) + + Resolving units + ~ + Delete unit command -->

Delete unit command -->

.~ '!~ .

- 82 - ~5M~-00591 ~ 3 ~ 3 ~ Delete unit command -->

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

' ~ . `, A P P E N D I X ~3 L 3 ~ 4 9 3 9 ~ETTING ~P A DYNA~IC REGRO~P To set up a Dynamic Regroup Plan you must enter and saYe information about the Plan on the three Dynamic Regroup screens (Directory, Definet and Units) in the following order:

1~ ENTER THE PLAN N~ME on the Directory screen 2. ENTER THE DESTINATION GROUP NA~E on ~he Directory screen 3. C~EATE A DEF~NE RECORD FOR T~E DESTIN~TION ~ROUP on the Dafine screen 4. ENTER T~E SOURCE G~OUP NAMX on the D~rectoxy screen 50 SE~ECT THE UNITS from the Units screen (or e~ter the ~nit na~es on the Unit screen) Steps 1 and 2 place the Plan and Destination group names in associated Dynamic Regroup Directories. S~ep 3 creates a record that defines the condi~ions the Destination Group operates under when activated. Step 4 places the Source group name in ~he associated Dynamic Regroup Directory.

Step S invol~e~: 2ither selecting units from the Source grou~ to form the Destination Group or entering the na~es of the units in the Destination Group.

NOTE ~ - The Directo~y screen initially displays only the names of the Plans set up. Each Plan will have a Destination Groups ~irectory and each Destination Group will have a Source Groups Directory. once they ara set up, the Plan (or Plan/Destinatîon Group) must be selected using the command line be~ore the associated directories appear.

-- ... _ , .

Select D~n~mic Reg~oup fro~ the menu and start with the Dynamic Regroup Directory screen:

. ~NTE~ P~AN NA~ Enter a unique Plan nama in the Plan: field (up to 8 alphanumeric characters). ~ress Return.

Enter a description of the Plan in the Des~riptioL: field (up to 2 lines, ~O ch~racters per line).

Press F7 (SAVE). The Plan name will appear in the Plan Directory.

2. EN~rE~ DEsTINa~TIot3 GROlJP Enter the name of the Plan NAME* created in Step 1 in the Pl~:

field and press Return. ** Enter a unique Destination group name in the Desti~tio~: f ield ( up to 8 characters ), press Retur~.

The De~ina screen will appear with the word CRE~TE ;n the upper right corner.

3. C~TE D~B ~coaD T~e n~DIe o~ t~e plan will appear in the Pl~: ~ield. ~f t~e name o~ sti~ation Group entered in St~p 2 appears ln the D~t.

~oups field, ~ n press Return.

Otherwise, en~er the Destination Grollp nz~ne in the~ Do~tO Group: Sield and press Re~urn.

Enter the pexcent (1-100~ oî non-~-riti:c:al units that ~ust respond be~ore the Regroup can be considered "active" in the Perce~t Reg.: f ield .

Press Return.

Enter a desc~.iption (up to 2 lines, 40 c~aracters per line) of the De~itination Group in the De~criptio~: field and press Return.

Enter the Agency Number assigned to the D~stination Group in the ~ge~cy: ~ield and press Return.

Enter the Fleet Num~er assigned to the Destination Group in the F1~at: field and -press~ ~Return~ Enter the Subf leet Nu~Qr assigned to the Destination Group in the Subfleet: field and ~:

press Return .

* For Plans with multiple Destination groups, complete Steps 2-5 using the first ~estination Group name and 'chen refer to "PLANS WITH MULTIPLE DESTI21ATION GROUPSn.

~* If Plan name appears in the Plan: field, just press Return.

- ~3~l~939 Enter an A (~gency3 or F (Fleet) or S ~Subfleet) or D (Dynamic) in the Recorfl Type~ field to identify the record type and press Return.

Move the cursor to the ~oti~e:

~ield and enter a Y under all the site numbers that will participate in thi~ regroupO De~ignate at lea~t on~ ~ite~ Pre~s Return.

~he re~aining fiQlds arë optional. See ~he Define Screen Optional Fields.

When completed, press F7 ~SAVE) and then F6 (EXIT). ~he Directory screen will appear.

7 ~NTE~ ~O~RC~ G~O~P N~NE~ Enter the name o~ th~ Plan crsated in Step 1 in the Plan:

field and press Return.* Enter the na~e of the Destination group crea~ed in Step 2 in the De~ti~tio~:

field, press Return.

Enter the name of the Source ~roup in the 80~CE: field.

(This name will either be a valid Group na~e from the System Manager Database or INDIYIDL).

P~ess Return. The Units sereen will appear.

s. 8E~ NI$8 If you identified a va}id Group name as the sourcé group, read Grou~ NameL and con~inue with Unit Screen Options.

OR If you identified INDIVIDL as the Sc~urce group, r~aad Un~s from Source Group : INDIVIDL and continue with Unit Screen Options.

* For Destination groups with multiple Source group~ complete Steps 4-5 using the first Source Group name and ~hen refer to "DESTINATION GROUPS WITH MULTIPLE SOUR~E GROUPS".

~ ~ 3 ~ ~nits from Source Group : ~Valid Grou~ Name~ The Units screen will display the units ~by Unit name) from the specfied source group as they appear in the System Manager Database.

The Knob Se~ting (X field) for each unit defaults to 1.

Initially, the first page will ~e displayed.

If the Source group contains more units than can be displayed on one screen page, multiple screen pages will be created as indicated in the "Page X of X '; field in the upper left corner of ~he screen. Vse the NEXT SCREEN and PREV SCREEN keys to move from page to page. Use the function keys to select unit~ for the Destination group and to identify which units are critical to the Destination group.

Refer to the Unit Screen Option~. Attributes are applied to the Unit name as you make thes~ choices (see UNIT N~ME ATTRIBUTES)~ When all changes to a page are co~pleted, press F7 (S~YE). After reviewing all pages, purge the unselected un~ts wit~ the Fl9 (PURGE). Before exiting, the screen~s~ should display only the Unit names you want included in the Destination group.

N~TE: To retrieve the units in the original Source group, unselect all units and press Fl9 (PURGE). Wait or the na~es of all units in the original So~rce group to appear and ~tart ov~r.

Units from Source Group : INDI~I~L The Units screen will initially display only blank Unit fields.

You must enter the valid unit name (from the System Manager Database) of each unit you want included in the Destination group in the fields provided.

Enter a unit name. The Xnob Setting ~K field) for each unit defaults to 1.

Each valid Unit entered is automatically "salected" for the Destination group so the Unit name will appear in reverse video.

Use the function keys to identify which units are critical to the Destination group. Refer to the Unit ';creen Options. Attributes are applied to the Unit name as you make these choices (see UNIT NAME ATTRIBUTES).

When all changes to a page are completed, press F7 (SAVE). Before exiting, this screen should display only the Unit names you want in~luded in the Destination group.

UNIT ~AME ATTRIBUTES If the Unit is: jThe Unit Name will appear in:

______~_--________________________________________________________.

Selected for the Destination Group Reverse Video Selected for and Critical to the Destination group ~everse Video/801d Not Selected for the Destination Group No Attributes UN~T SCREEN OPTIONS 1 3 1 ~ 9 3 9 I f You ~a~t To: The~:

Select~Unselect All Units Press F14 (SEL~LL).

on the Page Select a Unit Locate the cursor on the unselected Unit name yoU want to select and press SELECT~ Unselect a Selected Unit Locat~ th~ cur~or on ~he selected Unit name you want to unseleGt and pre~s SELæCT.

Id~ntify a Unit as Critical Locate ~ha Cursor on the non-critic21 ~nit na~e and pr~ss F12 tCRITICAL).

If unit iS uns~lected, F12 al60 sel~cts it.

Chan~e a Critlcal Unit to Locate ~he cursor on the ~elected Non-Critical ` critical Unit name and press F12 (CRITICAL).

Unit remains selected and chan~es to non-critical.

Change the Select Type of a Unit field headings mUst read Unit Unit-T. I~ not, press F18 (KN08/SEL) to change.

Locate cursor on T field of desired unit and overwrite T field (0-2).

Change the Knob Setting o~ a Unit fieId headings must read Unit Unit-K. I~ not, press F18 (~NOB~SEL) to change.

Locate cursor on R ~ield of desired unit and ~verwrite K field (1-8~.

Add a Unit** Locate the cursor on the first position of an empty Unit field.

Enter the name of the unit.

Chanqe the Select Type and Knob Setting, i~ desired.

Purge All Vnselected Units Press F~9 (Purge).

Deletes the unselected u~its and rearranges the . selected units alphabetically.

* Press F10 for new page, if desired.

** Unit must be a valid unit in the System Manager Database.

_ _ _ _ _ . __ NOTE PRESS F7 (SAVE) ~HEN ALL SELECTIONS AND CHANGES ON A PAGE ARE MADE.

AFTER ALL PAGES ARE COMPLETED PRESS F6 (EXIT).

r_ - _ _ _ ~ 13~3~ PLANS WIT~ MULTIPLE DESTINATION GROUPS Each Plan can have up ~o 14 Des~ination groups.

For each Destination group within a plan, you must have a Define record a~d a Unit record. Select the same Plan from the Plan Directory by typing the Plan name in the Pl~nO field and press Return. Enter the next Destination group name in the De3tinatio~: field and press Return.

Assign different Agency-Fleet-Subfleet numbers to each Destination group within a Pla~ so that you will have the option of regrouping all Destination ~roups (activate the Plan) or regrouping ~he Destination groups separa~ely. When co~pleted, the Destination Group name will appear in the Destination Group Directory. Repe~t for each Destination Group. . .

DESTINATION GROUPS ~ITH MULTIPLE SOU~CE GROUPS Each Destinatio~ group can name up to 21 Source groups. Only one o~ the 21 Source groups can ~e INDIYIDL.

Select the sa~e Plan ~rom the Plan Directory by typing ~h~ ~lan name in the P~n: field and press 2eturnO The Destination Group name will appear in the Destination Group Directory. Select the Destination Group by typing the D~stination Group name in the ~es~inationo field and press Return. Enter the name of the next Source Group in the Source: field. Press Return~ Follow the instructions in Step 5.

When completed the Source ~roup Name will appear in the Source Group Directory. Repeat for each Source Group.

- ~L 3 ~ D~FIN% SCREEN ~NFORM~T~ON FI~D Pl~ N~e Na~e o~ the Plan (a~ entered on the Directory screen) that the Destination group belongs to.

REQUI~D FI~D8 D~t. G~o~p DESTINATION G~OUP.

The name (up to ~ ch~r~ctsrs) o~ the Destination groupO ~er~o~t ~oq. PERCENT ~EQ~IRED.

The percent (1-100) of non-crit~cal units th~ must respond befor~ ~he Regroup can be considered ~ACTIVEn.

De~rlpt~on D2scription (up to 2 lines, 40 characters per line~ of the Destination gro~p.

Age~cy Number Agency number assigned to the ~estination group.

Fleet ~umber Fleet nu~bar assigned to the Destination group.

8ubfleet N~mber Subfleet Nu~ber assigned to the Destination group.

Recor~ Type System ,generated based on the entries in the A-F-S field.

Press Return ~with cursor in Record Type field.

Identifies the Destination group re~ord as an Agency, Fleet, Subfleet or Dynamic racord.

To change ~he Record Type to Dynamic, overwrite the ~irst position of the field with the letter D and press Return.

~ct~e ~Y) A YfN ~YES/NO) 32 posit~on field which spe~ifies which o~ the 32 possible sites will participate in the Regroup of this D~stination group.

At least one valid site must be designated Y.

DEFINE SC~EEN co~t~d ~ 4 9 3 9 OPTIO~L FI~DS ~on~ole Na~e Na~e (up to 8 characters) of the console assigned to the Destination group.

Co~ole B~y Number Bay NuDber of the console named.

Co~ole ~oaule Nu~ber of the module in the Console Bay assigned to the Des~ination group.

Di~l~on Na~e o~ the divi~ion associated wi~h the Destination group;

N~e Na~a o~ ~he p~r~on responsible for ~he Destination group.

~tre~t Cit~ Zt~t~ ~lp Per~a~snt mail~ng address of ~he perso~ responsible for the Destination group.

Phon~ Number Telephone number where the person responsible for the Destination group can be reached.

~ang Ti~e LRngth of time (0-255 seconds) the ~or~ing cha~nel ~eeps the channel up bef~ore issuing a drop channel message.

~riority Operational priority (0-7) o~ the Destination group.

Priority is used by the site controller only when no channels are available and a channel request is made.

FnNcTIoN g~8 F6 E~ eturns to the Dynamic Regroup Directory screen.

~7 8~ Saves the newly entered valid information.

Flo C~EAR ` Clears the data from the screen and displays a blank record form, with the exception of the Plan name which remains as entered on the Directory screen.

~1 U~IIT SCREEN REO~IRED FIE~DS U~it. Heading for the unit fields directly below.

The unit ~ields will either display valid Unit names, blank unit ields or a combination of both.

Blank unit ~ields provide space to add Unit name~.

T Heading ~or the Select Typ~ ~ield directly below it.

Select Type of the unit (0-2) ~8 a code that speci~ies if the control unit will be forced to regroup or not and if the user can or cannot leave or return to the regroup by turning the Group knob on the control unit.

O - Forced to regroup, Cannot change 1 = Default.

Forced to regroup, Can change.

2 = Not forced to regroup, Can change.

Heading for the Knob Setting ~ield directly below it.

Specifies the Group ~lob Setting on the control unit (1--8).

Units in ~ore than one regroup must have a different Knob Settings for each Destination group.

INFOR~ATIO~ FI~pS P~ge XS o~ X~ Current screen page number and the total nu~ber o f pages used for the units display.

Curre~t ~0~8 Current mode o~ the Destination group BUILD (INACTIVE), ACTIVE, ACT STP (ACTIVE STOPPED), or REMOVE (C~NCEL).

~egroup Pl~ Name of the Regroup Plan (from the Directory file) the Unit record belongs to.

~itq fro~ ~ource Group Name o~ the group in the System Manager database that the units are displayed from.

UNIT scREE~ ~o~t~d ~ 3 Destin~tion Group Nam~ selected for the Destination group ~fro~ the Dafine record~.

Group ~e~el Displays the Group Level (Agency, Fleet or Sub~leet) of the Source group.

Descriptio~ Destination group description from th~ Define record.

Per~t~ge ~gulra~ Percent of non-critical units ~hat must respond before the resroup can be con~idered "ACTIVE.~ (from t~e Define record~.

Co~pl~te Percent o~ non--critical units submitted that have been ~ctivated.

Crit~Gal ~t Cou~t ~u~ber of criti Q l units sub~itted.

Re~ol~e~ Number of critical units sub~itted that have bee~ activated.

Must egual the Critical Unit Count for regroup to be considered "ACTIVE'~.

F~NCTION ~EYS~ F6 E~IT Returns to the Directory screen.

F7 S~B Saves the displayed screen.

F9 N~TG~P NEXT G~C)UP.

Displays the first page of units in the next Source group d~!fined for the Destination group.

F10 NBWPA~ NEW PAGE.

Creates and di~plays a blank unit page for adding units.

Y12 C~ITIC~L Used to identify a unit as Critical/Non-critical.

Fl~ ~h~LL SELEC~ ALL.

Selects/Unselects all units on the displayed page.

~18 gNOB/8E~ KNOB~SELECT.

Alternately displays the Unit R field, Group Knob Setting (}-8) and the Unit T field, Select Type (0-2).

F19 P~RGE Removes all the units not selected in the Source group. ~isplays selected units alphabe~ically in the Destination group.

F20 MO~E Displays additional function keys.

; .:

.

.

~13 ~31~3g tJNIT SCB.EEN co~ t: ' 51 ~ELECT 5elects/Unselects a ~mit.

Cursor mu~;t be within the desired unit f ield .

Does not oper~te in REMOVE Mode .

NE:XT 5C~2E~ Displays the next units scr~en page in the unit f ile or a ~essage if the last page is c:urren~ly displayed PR~V ~CRE2~N P~rIOUS SC:REEN.

Displays the previou~; units ~icreerl page or a ~e~;sage if She first p~ge is currently displayed.

*Fll ~ODC~IT), F17 ~STATUS), INSE~T and R~OVE are def~ned in the operations Section ~nd used only in Active Mode.

~3~3~ -OE~ATIONS The Dynamic Regroup Directory screen is divided into two sections:

Command lines on the upper portion and Directory displays on the lower portion. Use the command line (upper portion) to select a Plan, Plan/De~tination Group, or Plan/Destination Group/Source Group for an operation from the Directories (lower portion).

Each Dynamic Regroup Plan has 2 additional associated screens: a Define screen that defines the conditions t~e regroup operates under during activation and a Units screen that displays t~e unit name o~ each unit in the Plan. Operational instructions ~or ~hese scr~ens are included in this section. Depending on the operation selected, the associated screen displays may or may not appear.

This ~unction will allow you to activate fro~ the Plan leYel or from the Uestination Group level.

If you activate the regroup ~ro~ the Plan level, all D~stination Groups associated with the Plan will also be activa~ed.

If you activate the regroup from the Destina~ion Group level, only the Destination Group selected will ~e activated.

~hen a Dyna~ic Regroup Plan ~or a Des~ination Group within a Plan) is sub~itted for activation, the units that are select~d on the Plan's Unit screen are reassigned one by one ~rom their original group to the regroup. When all of the units marked "critical" on the Unit screen and the required percent of non-critical units (on the Define screen) are regrouped, a message will appear to declare the Plan "ACTIVEn. You can activate more than one plan at a time however, a given unit can only participate in one plan at a time.

~fter a Plan is submitted for activation and prior to the Plan being declared "ACrIVE", you can:

o STOP (and RESTART) the REGROUPING PROCESS to allow another Plan submitted for activation to regroup sooner.

o MODIFY the PERCENT o~ NON-CRITICAL UNITS REQUIRED ~o allow selected activated Plan to regroup sooner.

o MONITOR the UNITS by checking the status of each unit in terms of whether the unit is regrouped (ActiYe), in the process o~ being regrouped (Pending) or if the unit is cancelled (reassigned to its original group).

Once a Plan is "ACTIVE", you can:

o ADD or ~EMOVE UNITS to/from the REGROUP by accessing the Plan's Units screen.

The Plan can be cancelled by selecting the Plan on the Directory screen and using the REMOVE key. The units are then reassigned back to their original group. When all units are contacted, a message appears to declare the Plan cancelled.

DY~AMIC REGROUP DIRECTORY 1 31~ 9 3 9 ~ , . . ~ CE l~-nus ~RUII~IIIC 5'tSTE\~ Dyr~it Re~ro~ Pl~n D~ r ectory P~n: Destimltion: Sourcr:

~esctipt~~: ' Pl~s ~ t~n~t~on C~'OL~3¦ Souret Cro4~ ____~_ _...._ ____....___.________--------.----------.--------------------~------------~------------- F6 F7 F8 F12 fl~ DO F17 F115 E%IT 5~VE D~LETE ~ODPtr GQPSCREEtl SU~IT STOP ItESTA~T QE~ NOTE Each Plan has a Destination Groups Di.rectory and each Destination Group has a Source Groups Dir~ctory.

The Plan ~or Plan~Destina~ion group) must. be selected before the associ ted directories appear.

DI~ECTO~Y N~M~ ATTRIB~8 If the name appears in: ¦ Then the Plan ox Destination I group is:

No Attributes Build ~ode (Inactive) Highlighted, Underlined ActiYe or Active Stopped Mode ~ow Intensity, Underlined Remove Mode (in proce s of being cancelled) Plan/Destination group names also appear in Re~erse Video when selectedO To 8EL~CT A PL~N Enter the name of the Plan name you want to select (~rom the Plan directory) in the Pl~: field and pxess Return. Choose an option and continue.

9~ ~3~3~ options_for Plan in Active Mode Remove (Cancel) Active Plan Press REMOVE key. Cancels the activated Regroup Plan and rea5si.gns all units in the regroup back to their oriqinal group. When completed, the message PLAN XXXXXXXX CANCELLED will flash across the bottom of the screen and the Plan will return to Build Mode.

options for ~lan Su~mitted for A~tivatiQn 5top Activated Plan Press F17.~STOP~. Stops ~he Regroup process ~or the selected Plan.

Restart "Stopped A~ti~e~ Plan Press F18 (RESTART). Restarts the Regroup process.

Select a Destination Group Enter the name o~ the active ~estina ion group you want and press Return.

See options under "Select a Destination ~roupl'.

Monitor Units Enter the name of the active Destination group you want to monitor and press Return.

Enter the desired Source group name and press Return.

The Units screen will appear.

Modify the Percent Enter t'he name of the acti~e Destination group you want and press F14 (GRPSCREEN).

Overwrite the P~rce~t Req.: field.

Press F7 (S~VE~ then F6 (EXIT).

Press F12 (MODPCT) to:send the change to the regroup scheduler.

Options for Plan_in_Build Mode Acti~ate the Plan Press DO.

At~empts to submit for activation the units selected in all the Destination groups associated with the PlanO When completed, the message PLAN XXXXXXXX ACTIVE will flash across the bottom of the screen.

Delete the Plan Press F8 (DELETE).

Also deletes all Destination and Source groups ~Define and Unit records) associated with t~e Plan.

1~ ~ 31~939 O~tions for Plan in Build Mode cont ' d Change the Descriptiorl Overwrite the De~:ript~o~: field.

Press F7 (SAVE).

Select a Destination Group Enter the name of the Destination group you want and press Pceturn.

See options under ~To sQlect a Dcstinatioll Groupn.

Add Destination Group ( s ~ Enter th~ na~e oi~ the Destinat:ion ~roup tal be add~d. P~ess Return.

See NSettin~ Up a Dylla~ic Regroup.

Display Units Enter the na~e of the ~estination group you want, press Returra.

Enter the na~ne of th~ Source group you want and press Return.

The Unit:; screen wîll appear.

9~ 131~3~ 'ro 6E~EC~ A DESTIN~ION GROIJP After a Plan is selected, enter the name of the DestinatiOn Group you want (from the Destination Group directory) in the De~tl~tio~:

field and press Return. Select an option and continue.

O~ions for Destination GrouD in Active Mode Remove (Cancel) Active Desti~ation Group ~res~ REMOVE.

Cancel~ the actiYe ~egroup Plan and reassigns all un~ts in ~he regroup back to thelx orig~ nal group~ When co~pleted, the message ~LAN XXXXXXXX DESTINATION XXXYXXXYX CANCELLED will flash across ~he bottom of the screen.

OPtions ~or_pestination ~rouP-submi~ted ~or a~tivatio~ Stop Activated Destination Group Press F17 (STOP). Stops the regroup process for the selected Plan/Destination group.

Restart "Stopped Active" Press F18 (REST~T).

Restarts Destination Group t~e regroup process.

Modify the Percent Press F14 tGRPSCREEN).

Overwrite the Pe.r~e~t Req.: field O Press F7 ~SA~E) then F6 (EXIT~.

Press F12 (MODPCT) to se~d the change to the regroup scheduler.

Monitor Units Enter the name of the Source group you want and press Return.

The Units screen will appear.

Press F17 to display the status of each unit.

Options for Destination Group in ~uild_Mode Activate the Destination Group Press DO. Attemp~s to submit for activation only the selected units in the selected Destination group. When completed, the message PLAN XXXXXXXX DESTINATION XXXXXXXX AC~IVE will flash across the bottom of the screen.

99 ll 31~ DD~Lons for Destination Group 1 Build Mode_cont'd Delete the Destination Group Press F8 (DELETE).

Also deletes all Source group names (and Define and Unik records) associated with the Destination ~roup.

Chan~e Data in Define Record Press ~14 (GRPSCREEN).

Overwrite the data in desired ~ields.

Press F7(SAVE1.

Press F6 (EXIT).

Display U~its Enter ~he na~e of the Source group you want and press Return.

The Units screen will appear.

Add Sour~e Group(s) See Setting Up a Dyna~ic Regroup.

T0 8~LECT ~ 80~RCE GRO~P After ~h8 Plan and Destination Group are selected, enter the name of the Source Group you want (from the Source Group directory) in the Sou~ce~ field and press ReturnO The Units screen will appear. See Unit Screen Operations.

D~REC'rORY SC~EEN IL 314 9 ~ 9 FI~LD~ . c3 Pl~ Name (up to ~ characters) of the selected Plan.

De~tinat~on Name (up to 8 ch~racters) of khe selected Destination group~ Source Name (up to B characters) of the selected Source group.

Des~ript~o~ Descripkion (up to 2 l~nes, 40 ch~ract~rs per line) o~ the selected Plan.

~nNcTIoN R~Y8 ESI~. Exits the Dynamic Re~roup function and returns to the Super~isor'~ ~enu.

~7 SA~E Saves all newly entered valid information.

F8 DE~ETE Deletes the selected Plan or Destination group and associated Define and Unit records.

F12 ~ODPCT MODIFY PERCENT.

Used only after a Plan has been activated and be~ore it is declared:active to send a Percent Required change to the regroup scheduler.

Change and save the Percent Required on the Define screen first and then return to the Directory screen and press F12.

F1~ GRPSC~EN GROUP SCREEN.

Di~plays the De~ine screen for the selected Plan and Destination ~roup.

DO 8UB~I~ Submits the units for the selected Plan (or s lected PlanJ~estination group) ~or activation.

When all of the critical units and the specified percent of non-critiral units are activa~ed, the message PLAN XXX DESTI~ATION XXX A~TIVE will flash across the bottom of the screen.

1~1 13~3~ -- DIBEc~ro~ EE~ cor~t ~ ~ F17 S~OP Places the selected active Plan or Destination group in Active Stopped Mode .

F18 RE8T~R~ Returns the sele ted Plan orDestination group in Activ~ Stopped Mode to Active Mode.

RE~101~ Canc~ls the ~ctive ~ode for the ~;el~ct~2d Plan or l~stination group.

~o~ 131~39 ~ `INE SCREEN ~ PLU5 7RUS~ C S~STEi4 D~e R~r~ lI~fir~ S~r~ Pl-n 1~ :De~.

Croup: Per~ent ~eq.:

Des~ri~ot~ .

Agencr ~Iwbe~ :Fteet ~ ber: Subflee~ ll~r:

Itce~ C~o~ ~y ~ r: Ca-#ole Ibdul~!:

~D~vl~ :

~ ' ' tStr~*t) Stl~ee): ~ZIP):

~ :

P~ ;H~s~ 71~e):

~111111111222222æZ~ Si S~te ~ 1ZK5~S~8W12~4S~8901ZS~5~7~012 Act~ t) :

Fh F-t F10 EXIT SJ~VE Sl.EA~ ._ _ There is a Define record for every Plan\Destination group set up that defines the conditions the Plan\Destination group operates under when it is activated. You can change any of the ~ata on this screen by overwriting the field~s) you want to change. When all changes are completed, press F7 to update the record.

INFOR~AT~ON FIE~D Plan Name Name of the Plan (as entered on the Directory screen) that the Destination group belongs to.

V~--D ~LDJ DestO Gro~p . DESTINATION GROUP. ~he name ~up to 8 alphanumeric characters) of the ~estination group.

Perce~t Req. PERCENT REQUIRED.

The peroent t~ 0~ Of non-critical units that must respond before the Regroup can be consldered ~ACTIVEn.

De~cription Description (up ~o 2 lines, 40 characters per line) of ~he Destination group.

Agency Number Agency number assigned to the Destination group.

53 io3 13:L~93~ _F~ ;t N~mber Fleet number assigned to the Destin~tion group.

~ubfleet N~ber Subfleet Number assigned to the Destination group.

Recor~ Type Sys em generated based on the entries in the A-F-S field.

Press Return with cursor in Record TXpe field~ Identifies the Des~ination group record as an Agency, Fleet, Sub~leet or Dy~amic record.

To change the Record Type to D~na~ic, overwrite ~he first position o~ the field with t~e letter D and press Return.

actl~e ~Y) A Y/N ~YES/N0) 32 position field which speci~ies which o~ the 32 possible sites Will participate in t~e Regroup of this Destination group.

At least one Yalid site must be designated Y.

OPTION~L FI~D~ Con~ola N~me Name (up to 8 characters) of the console assigned to the Destination group.

Co~sole B~y Nu~ber Bay Number of the console named.

Co~sole Mo~ul~ Number of the module in the Console Bay assigned to the Destination group.

Di~ision Name of the division associated with the Destination group.

~ame Name o~ the per on responsible for the Destination group.

Street City St~t~ Zip Permanent mailing address of the person responsible for the Destination group.

Pho~o NuM~er Telephone number where the person responsible for the Destination group can be reached.

Ha~g Ti~ Length of time (0-255 seconds) the working channel keeps ~he channel up before issuing a drop channel message.

3~39 Priority Operational priority ~0-7) o the Destination group.

Priority is used by the site controller only when no channels are available and a channel request is made.

F~NCTION ~EY8 F6 E:~IT Returns to the Dynamic Regroup Directory screen.

~7 821,~B Saves the newly entered val~d infor~aat~on .

~F10 c~Ea Clears the data ~ro~ the sc:x~en and displays a blank record fox~, with t~e exception o~ the Plan name..which re~ains as entered cn the l); rectory sc:reenO ~ 131~939 ~- ~S ~C~EEN ~ ..

P~ge ot C~ PLUS IRU#~IIIC SYSTEH D~ic ~:~r~up Un1t~ Curr~nt l~ ~egroup Pitn : llnits fr~ Scurce Croup:

~e~tilution Gro~.p: Cr~up Ltvel:

O~scription:

Unit r Unit T Unit T L~nit T Unit r unit T Per~nt~ equired: Co~lete:

C~t~c~ it ColMt: Re~ol~d:

f6 F7' F9 flO fll Fl2 Fl~ Fl~ F11S Fl9 ~20 EXIT S~VE Illt~G~P 5iE~PAC ~CIIIT CRIT1CAL S~LALL ST~IUS ~JS~L ~UR~ I~E 1~ P~Elr f20 S~LEC7 I~ ItE~NE SCREE~ SC~EEII P!a~E ~ .

The Units scree~ will display all the units (by ~nit name) currently in the Destination Group and along wi~h the Knob Setting ~nd the Select Type for each unit. Initially, ~he first page will be displayed.

If the Source group contains more units . than can be displayed on one screen pag~, ~ultiple screen pages will be created as indicated in the ~Page X of X " field in the upper left corner of the screen. Use the NEXT SCREEN and PREV SCREEN ~eys to move from page to page.

To ~odify this screen, first check the Cur:rent ~ode and then refer to the Unit Screen Options. Attributes are ajpplied to the Unit names ~see UNIT NAME ATTRIBUTES).

~NIT NAM~ ~T~RIB~TE8 FOR B~IhD ~OD~ I~ the Unit Name appears in: ¦ Then the Unit is:

_______~____________~___________~________ __u____~__________________ No Attri~uteg Not Selected for the Destination Group Reverse Video Selected for the Destination Group Bold Critical Unit ~NIT N~Moe ATTRI8~TES FOR ACTI~E, ~CTI~ 8TOPP~D a~d RE~oVE ~ODES If the Unit Nzme appears in: ¦ Then the Unit is:

_______ ______________________ _______________________.._~__________ Reverse Video & Underlined Selscted for an operation (e.g.REMOVE) Bold & Underlined Critica} Unit in an Active state~ Underlined In an Active state* *Unit active states are: Active, Pending or Cancelled.

l 0~ I ~31~939 o~tions for Selected Source Group, Mode: Active Act S~e Add a Unit Locate the cursor on the ~irst position of an empty Unit field.

Enter the name of the unit.

Change the Select Type and Knob Setting, if desired.

Press INSERT.

Re~ove a Unit Locate ~he cursor on the name of tAe unit you want to remove~ Press SELECT and t~en press REMOVE.

Identi~y a Unit as Cri~cal Locate ~he cursor on the non-eritical Unit name, pxess F12 ~CRITI~A~and then press Fll (MO~RI~ nit remains selected and change~ to non-crikical.

Unit ~ust ba in P (Pending) status.

Change a Critical Unit to ~ocate the cursor on the selected Non-Critical critical Unit name and press F12 (CRITIC~L).

Unit must be in P (Pending) status.

Monitor the Units Press F17 (STATUS).

Displays the status of each unit~ A (Unit has be~n regrouped), P (Unit is pending, not regrouped yet), or C ::

(Unit is in cancelled state).

Options for Selected Source Group~wMode:_ Build Monitor the Units Pre~s F17 (STATUS).

Displays the status of each unit. A ~Unit has been regrouped), P (Unit is pending, not regrouped yet), or C (Unit is in cancelled state).

131~39 o ions for selected Source Group~ Mode Build If You ~nt To: ~e~ .

Select/Unselect All Units Press Fl4 (SELALL).

on the-Page Select a Unit Locate the cursor on the unselected Unit n~e you want to select a.nd press SELECT.

Unselect a Selected Unit Locate the cursor on the selected Unit na~e you want to u~select and pra-l~; S~I ECT . , Identi~y a Unit a~ Critic~l Locate the cursor on the non-critical Unit namQ and prass F12 (CRITICAL). I~ unit is unselected, F12 also selects it~ Change a Critical Unit to Locate the cursor on the selected Non-Critical critical Unit name ~nd press F12 ~CRITICAL).

Unit remai~s selected and changes to non-critical.

Change the Select Type of a Unit field headings must read Unit Unit-T.

If not, press F18 (KNO~/SEL) to change.

Locate cursor on T field of desired unit and overwrite T field (0-2)0 Chang~ the Knob Setting o~ a Unit ~ield headings must read Unit Unit-~.

If not, press Fl8 (KNOB/SEL) to change.

Locate cursor on K field of desired unit - and overwrite X field (1-8).

Add a Unit** Locate the cursor on the first position o~ an empty Unit field.

Enter the name of the unit. C~ange ~he Select Type a~d Knob Setting, if desired.

Purge All Unselected Units Press Fl9 (Purge).

Deletes the unselected units and rearranges the selected uni~s alphabetically.

*Press F10 for new page, i desired.

**Unit m~st be a ~alid unit in tbe System Manager Database.

~ ~ _ . . , NOTE PRESS F7 tSAYE) WHEN ALL SELECTIONS AND CHANGES ON A PAGE ARE MADE.

AFTE~ ALL PAGES ARE COMPLE~ED PRESS F6 (EXI~).

.

d 3 ~ ~ ~ 3 ~ REO~IRED ~T~D~ ~it ~eading for the unit ~ields directly below.

The unit fields will either display valid Unit names, blank unit ~ields or a combination o~ both. ~lank unit fields provide space to add Unit names~ T T, Select Type of ~he Unit ~O 2).

O = Forced S~lect, No Deselect 1 = De~ault.

Forced Select, Optio~al Daselect 2 c No Select, Optional Select R Group ~nob Setting on ~he unit ~l-B~.

INFO~MATION FI~D8 :

~ag~ r2 o~ ~X Current page number and the total number of pages in the unit file.

Curre~t ~ode Current mode of the Destination g~oup- BUILU (not AC~IVE), ACTIVE, ACT STP (ACTIVE STOPPED), or REMOVE (CANCEL).

Regroup Pl~ Na~e of the Regroup Plan (from the Directory file) the Unit record belongs to.

U~it~ from Sourc~ Group Name of the group in the System Manager database that the units are displayed from.

Dest~natio~ ~roup Name selected:for the ~estination group (from the Define record).

Group Le~el Displays the Group Level (Agency, Fleet or Subfleet) of the Source group.

Descriptio~ Destination group description from the Define record.

s (~nit--s) Statu~ of the unit- ~A for Active, P for Pending or C for Cancel).

Functions only in Active and Remove Mode.

I (~'q ~ 3 1 ~ ~ P~cent~g~ Require~ Percent: of non-critical units necessary for the regroup ( fro~ the l)ef ine record ~ .

Co~plete Percent of non-critical units submitted that have been activated.

Critic~l ~nit Cou~t Number o~ critical units submitted.

~ol~ad Nu~ r o~ critical units subDIitt~d that have been activated.

131~939 F-'~C~ION KEy~;

E~I~ Returns to the Directory screen~ ~7 8A~ Saves the d.isplayed screen.

F9 NXTGRP NEXT GROUR. ~isplays the first page of units in the next Source g~up .

Fl~ NEWPA~ NEW PAGE.

Displays a bla~k unit pa~e ~or addi~g units.

F11 ~oDca~T ~ODIFY CXITTC~L. A~TIVE Mode only.

Send~ changèd Cr~tical~Non-cr~tical ~ta~e o~ a un~t to the scheduler.

~12 C~IT~C~ Alternate a¢tion key.

Designates a :.

unit as CriticalJNon-critical.

F1~ 8~h~LL S~LECT AIL.

Sel~cts/Unselects all units on the displayed page.

Fl'l ~TAT~8 Unit-S.

Displays the status of each unit as A (ACTIVE), P (P~NDIN&) or C (CANCEL).

Does not operate in BUI~D Mode.

FlB ~NOB/SEL KNOB~SELECT.

Alternates between Unit K, Group Rnob Setting (1-8) and Unit T, Select Type (0-2).

Fl9 P~GE Removes all the units not selected in the Source group.

Lists selected units alphabetically in the Destination group.

F20 ~ORE Displays additional function keysO 8BL~C~ Selec~s/Unselec~s a unit.

Cursor must be within the desired unit field~ Does not operat~ in REMOVE Mode.

INS~T Allows additional units to be added during ACrIVE Mode.

Adds units after restart in ACT STP Mode.

Does not operate in BUILD or ~EMOVE Mode.

Ill 131~39 -- .~OVE Allows units to be removed during ACTIVE Mode.

Allows units to ~e selected Sor removal in ACT STP mode and ren~oves theDI ~;

restaxt .

I)oes not operate in BUILD or REMOVE Mode .

C~REE~ ~isplays the next pay~ in the unit file or a ~essage if the last page i8 currently ~displayed.

PREV ~RBX~ PREVIOUS SCREEN.

Displays t.he previous pay~ in the unit f ile or a ~ssag~ if t:he ~rst page is currer~ly displayed.

I 1 ~ 1~14.g39 MESSAGES Criti~ Bit Solli~ion E~cou~tere~; Regroup Not ~ub~itted -Reqroup Aas des~ignated two or more units as critical under the sa~e unit group knob setting.

Regroup ~ctivation reguest aborted.

One ~r ~or~ Non-Critic~l U~it~ Not ~ub~itted -- Not sub~itted due to non-critical unit collision or insufficient regro~p buffer space at the site.

Ple~s- E~tor ~ts ~o Be R~g~oup~ Regroup Activation reguest ~ub~itted with no units supplied.

~gro~p ~ct~ Regroup Act~vation request ~mitted on ACTrVE regroup.

R~gro~p ~ctive -- Request sub~itted requires regroup to be ACTIVE, reg~oup found to be INACTIVE.

~og~o~p Inao~iste~t Wit~ ~equest ~eque~t Da~e~ -- Current state of regroup will not allow request.

Regroup Xe~or~ Not Fou~ -- Regroup request submitted for undefined regroup.

~ble To Allocate ~oup Record; Regroup Not ~ub~itted ~- Cannot find Group ID record available for dyna~ic regroup within designed Group ID pool of the specified regroup.

~ble To ILs2rt All ~its: ~group Not 8ubmitte~ -- Insufficient regroup buffer space at site ~or total nu~er of critical units submitted or no regroup buffer space at all.