Method and apparatus for providing site and system-wide alert tones

In a two-way radio frequency (RF) communications system having at least one fixed terminal, one or more channels, and a plurality of subscriber units, the method comprising, a device receives, from a first subscriber unit, an alert tone request identifying at least a type of alert tone and at least one destination. In response, the device causes one or more fixed terminals corresponding to one or more radio sites associated with the destination identified in the alert tone request to instruct their subscriber units to play back a locally stored or generated alert tone corresponding at each subscriber unit. Receiving subscriber units then play back the alert tone on a continuous, periodic, or semi-periodic basis, selectively mixing the alert tone with call audio if present.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to providing site and system-wide mining tones for groups of radios in a digital radio access network.

BACKGROUND OF THE DISCLOSURE

Wireless communication systems provide for radio communication links to be arranged within the system between a plurality of user terminals. Such user terminals may be mobile and may be known as ‘mobile stations’ or ‘subscriber units.’ At least one other terminal, e.g. used in conjunction with subscriber units, may be a fixed terminal, e.g. a control terminal, base station, repeater, and/or access point. Such a system typically includes a system infrastructure which generally includes a network of various fixed terminals, which are in direct radio communication with the subscriber units. Each of the base stations operating in the system may have one or more transceivers which may, for example, serve subscriber units in a given local region or area, known as a ‘cell’ or ‘site’, by radio frequency (RF) communication. The subscriber units that are in direct communication with a particular fixed terminal are said to be served by the fixed terminal. In one example, all radio communications to and from each subscriber unit within the system are made via respective serving fixed terminals. Sites of neighboring fixed terminals in a wireless communication system may be offset from one another or may be non-overlapping or partially or fully overlapping. In another example in which subscriber units can operate in a direct mode (e.g., without having to pass through a repeater or base station), a fixed terminal such as a control terminal may provide for a mechanism to update the direct mode subscriber units with new program settings, channels, groups, etc.

Wireless communication systems may operate according to an industry standard protocol such as, for example, the Project 25 (P25) standard defined by the Association of Public Safety Communications Officials International (APCO), or other radio protocols, such as the TETRA standard defined by the European Telecommunication Standards Institute (ETSI), the Digital Private Mobile Radio (dPMR) standard also defined by the ETSI, or the Digital Mobile Radio (DMR) standard also defined by the ETSI. Communications in accordance with any one or more of these standards, or other standards, may take place over physical channels in accordance with one or more of a TDMA (time division multiple access), FDMA (frequency divisional multiple access), or CDMA (code division multiple access) protocols. Subscriber units in wireless communication systems such as those set forth above send user communicated speech and data, herein referred to collectively as ‘traffic information’, in accordance with the designated protocol.

Many so-called “public safety” wireless communication systems provide for group-based radio communications amongst a plurality of subscriber units such that one member of a designated group can transmit once and have that transmission received by all other members of the group substantially simultaneously. Groups are conventionally assigned based on function. For example, all members of a particular local police force may be assigned to a same group so that all members of the particular local police force can stay in contact with one another, while avoiding the random transmissions of radio users outside of the local police force.

Similar wireless communication systems may be used at mining sites, where events such as blasting operations impart unique requirements on the wireless communication system supporting the mining operation across one or more mining sites. Conventional methods of signaling events such as blasting amongst subscriber units have typically relied upon an assignment of a separate RF channel over which predefined analog audio is mixed at the infrastructure and broadcast from the fixed terminal to the subscriber units, and played back at the subscriber units that are tuned to the separate RF channel, to indicate the respective situation.

However, with the recent advent of digital radio systems, the conventional analog methods can either no longer be used or have become prohibitively expensive to implement in terms of cost and system resources. Accordingly, a system and method is needed for digital two-way radio systems to allow for continuous, periodic, or semi periodic tones to be mixed with digital audio and played back at subscriber units across one or more sites to indicate a respective situation, and a system and method to allow subscriber units to initiate the play back of the continuous, periodic, or semi periodic tones, without unnecessarily impacting network bandwidth or frequency channel availability, and while making allowances for calls existing at the time of the initiation of the continuous, periodic, or semi periodic tone to continue.

DETAILED DESCRIPTION OF THE DISCLOSURE

In light of the foregoing, it would be advantageous to provide for a system and method that allows for continuous, periodic, or semi periodic (e.g., irregular or sporadic) tones to be mixed with digital audio and played back at subscriber units across one or more sites to indicate a respective situation, and a system and method that allows subscriber units to initiate the play back of the continuous, periodic, or semi periodic tones, without unnecessarily impacting network bandwidth or frequency channel availability, and while making allowances for calls existing at the time of the initiation of the continuous, periodic, or semi periodic tone to continue.

In one embodiment, a device receives, from a first subscriber unit, an alert tone request identifying at least a type of alert tone and at least one destination. In response, the device causes one or more fixed terminals corresponding to one or more radio sites associated with the destination(s) identified in the alert tone request to instruct their subscriber units to play back a locally stored or generated alert tone at each corresponding subscriber unit.

In another embodiment, receiving subscriber units play back the indicated alert tone on a continuous, periodic, or semi-periodic basis, selectively mixing the alert tone with call audio if present.

Each of the above-mentioned embodiments will be discussed in more detail below, starting with example network and device architectures of the system in which the embodiments may be practiced, followed by a discussion of alert tone initiation and implementation from the point of view of the infrastructure device (zone controller) and the subscriber unit. Further advantages and features consistent with this disclosure will be set forth in the following detailed description, with reference to the figures.

I. NETWORK AND DEVICE ARCHITECTURES

FIG. 1shows a wireless communication system100which may be adapted in accordance with an embodiment of the disclosure. It will be apparent to those skilled in the art that the system100and the components which are to be described as operating therein may take a number of forms well known to those skilled in the art. Thus, the layout of the system100, and of its operational components to be described, should be regarded as illustrative rather than limiting. The system100ofFIG. 1will be described as an illustrative wireless communication system capable of operating in accordance with any one or more standard protocols, such as the APCO P25 standard, the DMR standard, or the TETRA standard, among other possibilities.

The system100shown inFIG. 1is implemented across a plurality of mining zones including a first mining zone101and a second mining zone151, interconnected via a system infrastructure103. WhileFIG. 1uses a plurality of mining zones, one zone for each of two physical mines, as example service areas, the system100could be applied to other types of functional service areas as well, such as but not limited to, construction sites, oil or gas drilling sites, and demolition sites. The first mining zone101(a zone being comprised of one or more related radio sites) includes one or more fixed terminals (e.g., base stations/repeaters/control terminals) (BSs)102,141which may be operably connected to the system infrastructure103via respective wired or wireless links131,135. While the term BS will be used to refer to the fixed terminals, for ease of reference, it should be noted that the fixed terminals may, in some embodiments, be a repeater or a control terminal, or some other type of fixed terminal. The BS102has radio links with a plurality of subscriber units, particularly subscriber units (SUs) in a service cell or radio site133at least partially defined by a geographic location of the BS102. In addition to SUs, BS102may maintain a link with a dispatch console121or other operator in the system infrastructure103. The dispatch console121may be configured to act as a communications client of BS102, but may also provide administrator control access to BS102so that an administrator may update operational parameters at BS102, including defining or adding alert tone IDs or identities of other SUs or radio sites or zones. Three SUs SU1105, SU2107, and SU3109are illustrated inFIG. 1as being within the service area of, and being registered with, BS102via respective radio links111,113,115. In one embodiment, the BS102serves SUs including the SUs SU1105, SU2107, and SU3109with radio communications to and from other terminals, including (i) other SUs served by the BS102, (ii) SUs served by other BSs such as BS141, (iii) other SUs in other zones (e.g., SU's at the second mining zone151) operably linked to the BS102via the system infrastructure103, and (iv) the console121. In another embodiment in which SUs SU1105, SU2107, and SU3109are operating in a direct communication mode (DCM) via example radio links112,114, one of the DCM SUs SU1105, SU2107, and SU3109could be designated or elected as a master radio and perform some or all of the ZC and/or BS functions described herein.

BS141similarly has radio links with one or more SUs, particularly SUs in a service cell or radio site143at least partially defined by a geographic location of the BS141. In addition to SUs, BS141may also maintain a link with the dispatch console121or other operator. Two SUs SU4145and SU5147are illustrated inFIG. 1as being within the service area of, and being registered with, BS141via respective radio links142,148. The BS141thereby serves SUs SU4145and SU5147with radio communications to and from other terminals, including (i) other SUs served by the BS141, (ii) SUs served by other BSs such as BS102, (iii) other SUs in other zones (e.g., SU's at the second mining zone151) operably linked to the system100via the system infrastructure103, and (iv) the console121.

The second mining zone151includes one or more fixed terminals (e.g., base stations/repeaters/control terminals) (BSs)152,172,192which may be operably connected to the system infrastructure103via respective wired or wireless links151,171,191. The BS152has radio links with a plurality of SUs in a service cell or radio site153at least partially defined by a geographic location of the BS152. In addition to SUs, BS152may maintain a link with a dispatch console122or other operator. The dispatch console122may be configured to act as a communications client of BS152, but may also provide administrator control access to BS152so that an administrator may update operational parameters at BS152, including defining or adding alert tone IDs or identities of other SUs or radio sites or zones. Two SUs SU6155, SU7157are illustrated inFIG. 1as being within the service area of, and being registered with, BS152via respective radio links161,163. In one embodiment, the BS152serves SUs including the SUs SU6155, SU7157with radio communications to and from other terminals, including (i) other SUs served by the BS152, (ii) SUs served by other BSs such as BSs172,192, (iii) other SUs in other zones (e.g., SU's at the first mining zone101) operably linked to the BS152via the system infrastructure103, and (iv) the console122. In another embodiment in which SUs SU6155, SU7157are operating in a DCM via example radio link165, one of the DCM SUs SU6155, SU7157could be designated or elected as a master radio and perform some or all of the ZC and/or BS functions described herein.

BS172similarly has radio links with one or more SUs, particularly SUs in a service cell or radio site173at least partially defined by a geographic location of the BS172. In addition to SUs, BS172may maintain a link with the dispatch console122or other operator. One SU SU8175is illustrated inFIG. 1as being within the service area of, and being registered with, BS172via respective radio link176. The BS172thereby serves SU175with radio communications to and from other terminals, including (i) SUs served by the BS172, (ii) SUs served by other BSs such as BSs152,192, (iii) other terminals including SUs in other systems (e.g., SU's at the first mining zone101) operably linked to the BS172via the system infrastructure103, and (iv) the console122.

BS192similarly has radio links with one or more SUs, particularly SUs in a service cell or radio site193at least partially defined by a geographic location of the BS192. In addition to SUs, BS192may maintain a link with the dispatch console122or other operator. One SU SU9195is illustrated inFIG. 1as being within the service area of, and being registered with, BS192via respective radio link194. The BS192thereby serves SU195with radio communications to and from other terminals, including (i) SUs served by the BS192, (ii) SUs served by other BSs such as BSs152,172, (iii) other terminals including SUs in other systems (e.g., SU's at the first mining zone101) operably linked to the BS192via the system infrastructure103, and (iv) the console122.

Each of the BSs102,141,152,172, and192may operate as a conventional radio site or a trunked radio site. In a conventional radio system, a plurality of SUs are formed into groups. Each group uses an associated channel (shared or separate) for communication. Thus, each group is associated with a corresponding channel, and each channel can only be used by one group at any particular moment in time. Channels may be divided by frequency, time, and/or code. In some systems, multiple groups may operate on the same channel, and may use a unique group ID embedded in the group communications to differentiate them. In a trunked radio system, SUs use a pool of channels for virtually an unlimited number of groups. Thus, all groups are served by all channels. For example, in a trunking system, all SUs operating at a radio site idle on an initial designated control channel or rest channel and when a new call is requested over the control or rest channel, is assigned a new traffic channel for the new group call while remaining SUs not participating in the new group call stay on the initial designated control channel or rest channel. Other conventional and trunked configurations are possible as well.

The system infrastructure103includes known sub-systems required for operation of the wireless communication system100. Such sub-systems may include for example sub-systems providing authentication, routing, SU registration and location, system management and other operational functions within the system100. In some embodiments, a zone controller (ZC) provided for each zone such as first and second zone controllers ZC1181, ZC2182may provide for some or all of the authentication, routing, SU registration and location, system management and other operational functions for their corresponding zone (in this case, the first mining zone101including radio sites133and143and the second mining zone151including radio sites153,173, and193, respectively). While the example set forth inFIG. 1includes radio sites in a zone that are associated based on their geographic co-location relative to a physical mining operation, other attributes or characteristics may be used to group radio sites into a zone. For example, in some embodiments, a zone may be associated with a particular user type (police, fire, etc.), a particular owner operator (govt. agency, company, etc.), a particular geographic area other than a physical mine (schools, government buildings, armed forces bases, etc.), or some other attribute or characteristic.

The system infrastructure103may additionally provide routes to other BSs or zones (not shown) providing radio sites serving other SUs, and/or may provide access to other types of networks such as a plain old telephone system (POTS) network or a data-switched network such as the Internet. The system infrastructure103may also maintain a logging server199, coupled to the first and second zone controllers ZC1181, ZC2182via wired or wireless links183,184for maintaining records of alert tone requests and instructions received by and issued by the first and second zone controllers ZC1181, ZC2182.

FIG. 2is an example functional block diagram of an infrastructure device such as ZC1181operating within the system100ofFIG. 1in accordance with some embodiments. Other infrastructure devices such as ZC2182may contain same or similar structures. Furthermore, for example, in a conventional radio system, other infrastructure devices such as a repeater station or BS may be an infrastructure device that provides the functionality disclosed herein with respect to a ZC.

As shown inFIG. 2, ZC1181includes a communications unit202coupled to a common data and address bus217of a processing unit203. The ZC1181may also include an input unit (e.g., keypad, pointing device, etc.)206and a display screen205, each coupled to be in communication with the processing unit203.

The processing unit203may include an encoder/decoder211with an associated code Read Only Memory (ROM)212for storing data for encoding and decoding voice, data, control, or other signals that may be transmitted or received between BSs, other ZCs, or SUs in the same zone as ZC1181, or perhaps between BSs, other ZCs, or other SUs in a remote radio site or zone such as at the second mining zone151. The processing unit203may further include a microprocessor213coupled, by the common data and address bus217, to the encoder/decoder211, a character ROM214, a Random Access Memory (RAM)204, and a static memory216.

The communications unit202may include one or more wired or wireless input/output (I/O) interfaces209that are configurable to communicate with BSs such as BSs102,141, with other ZCs such as ZC2182ZC2182, with other devices in the system infrastructure103, and/or with the console121. The communications unit202may include one or more wireless transceivers208, such as a DMR transceiver, an APCO P25 transceiver, a TETRA transceiver, a Bluetooth transceiver, a Wi-Fi transceiver perhaps operating in accordance with an IEEE 802.11 standard (e.g., 802.11a, 802.11b, 802.11g), a WiMAX transceiver perhaps operating in accordance with an IEEE 802.16 standard, and/or other similar type of wireless transceiver configurable to communicate via a wireless network. The communications unit202may alternatively additionally include one or more wireline transceivers208, such as an Ethernet transceiver, a Universal Serial Bus (USB) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link or a similar physical connection to a wireline network. The transceiver208is also coupled to a combined modulator/demodulator210that is coupled to the encoder/decoder211.

The microprocessor213has ports for coupling to the input unit206and to the display screen205. The character ROM214stores code for decoding or encoding data such as control channel messages, mining alert request and instruction messages, and/or data or voice messages that may be transmitted or received by the ZC1181. Static memory216may store operating code225for the microprocessor213that, when executed, receives and processes alert tone requests, determines a status of fixed terminals associated with the request, determines whether to allow or deny the request, and transmits an alert tone instruction to the fixed terminals associated with the request if it is determined to allow the request instructing subscriber units currently operating in corresponding coverage areas of the one or more fixed terminals to play back a locally stored or generated alert tone corresponding to the type of alert tone included in the alert tone request, in accordance with one or more ofFIGS. 4-9and corresponding text. Static memory216may comprise, for example, a hard-disk drive (HDD), an optical disk drives such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a solid state drive (SSD), a tape drive, a flash memory drive, or a tape drive, to name a few.

FIG. 3is an example functional block diagram of a SU such as SU105operating within the system100ofFIG. 1in accordance with some embodiments. Other SUs such as SUs107,109,145,147,155,157,175, and195may contain same or similar structures. As shown inFIG. 3, SU105includes a communications unit302coupled to a common data and address bus317of a processing unit303. The SU105may also include an input unit (e.g., keypad, pointing device, etc.)306, an output transducer unit (e.g., speaker)320, and a display screen305, each coupled to be in communication with the processing unit303.

The processing unit303may include an encoder/decoder311with an associated code Read Only Memory (ROM)312for storing data for encoding and decoding voice, data, control, or other signals that may be transmitted or received between other BSs or SUs in the same radio site or zone as BS101, or perhaps between other SUs or BSs in a remote radio site or zone, such as in the second mining zone151. The processing unit303may further include a microprocessor313coupled, by the common data and address bus317, to the encoder/decoder311, a character ROM314, a RAM304, and a static memory316. The processing unit may also include a digital signal processor (DSP)319, coupled to the speaker320and the common data and address bus317, for operating on audio signals received from one or more of the communications unit302, the static memory316, and a tone generator unit321for generating audio tones, and providing a resultant audio signal to the output transducer320.

The communications unit302may include an RF interface309configurable to communicate with other SUs within its communication range such as SUs107,109and with BSs within its communication range such as BS102. The communications unit302may include one or more wireless transceivers308, such as an APOCO P25 transceiver, a DMR transceiver, a TETRA transceiver, a Bluetooth transceiver, a Wi-Fi transceiver perhaps operating in accordance with an IEEE 802.11 standard (e.g., 802.11a, 802.11b, 802.11g), a WiMAX transceiver perhaps operating in accordance with an IEEE 802.16 standard, and/or other similar type of wireless transceiver configurable to communicate via a wireless network. The transceiver308is also coupled to a combined modulator/demodulator310that is coupled to the encoder/decoder311. The character ROM314stores code for decoding or encoding data such as control channel messages, alert tone request and instruction messages, and/or data or voice messages that may be transmitted or received by the SU105.

Static memory316may store operating code325for the microprocessor313that, when executed, generates alert tone requests and causes the requests to be transmitted, receives alert tone instructions and processes the instructions, determines whether the SU is currently engaged in an active call, plays back a locally stored or generated alert tone corresponding to the type of alert tone included in the alert tone instructions, and selectively mixes the stored or generated alert tone with audio signals from a currently active call if it is determined that the SU is currently engaged in an active call, in accordance with one or more ofFIGS. 4-9and corresponding text. Static memory216may comprise, for example, a HDD, an optical disk drives such as a CD drive or DVD drive, a SSD, a tape drive, a flash memory drive, or a tape drive, to name a few.

II. MINING TONE ALERT PROCESSES

FIGS. 4-5set forth example flows of an alert tone process that may be executed at a SU and at an infrastructure device (ZC) in accordance with some embodiments. In the examples set forth in detail below, only particular sequences are disclosed with respect to the ZC (FIG. 4) and the SU (FIG. 5). Of course, additional steps not disclosed herein could be additionally added before, after, or in-between steps disclosed inFIGS. 4 and 5, and the presence of such additional steps would not negate the purpose and advantages of the alert tone examples set forth in detail throughout the remainder of this disclosure. Steps drawn with a dashed outline inFIGS. 4 and 5should be understood to be optional steps. Further details regarding messaging set forth inFIGS. 4-5will be described with respect toFIGS. 6-9.

FIG. 4sets forth a method400executable at an infrastructure device, such as ZC1181, for receiving, processing, and maintaining alert tones across one or more radio sites or zones in a wireless communication system such as wireless communication system100. At step402, the ZC receives an alert tone request indicating a type of alert tone and one or more destinations at which to raise the alert. At optional step404, the ZC determines a status of each destination indicated in the request. A destination could include a particular radio site, a particular zone, or all radio sites or all zones (e.g., system-wide). Determining a status of each destination indicated in the request may include accessing a database stored at the ZC to determine whether, the last time it checked, each of the destinations indicated in the request are operational and accessible, or could include subsequently transmitting simple messages (such as a Ping or ACK request) that functions as an inquiry into the status of each destination indicated in the request. BSs that do not respond to the simple message could be marked as inoperational at the ZC and BSs that cannot be reached marked as inaccessible, and information regarding the updated status shared with other ZCs in the system (e.g., in the system infrastructure103). For those wireless communication system architectures including more than one zone or sets of radio sites, infrastructure devices (such as ZCs ZC1181and ZC2182) may periodically, or upon request, share status information regarding the status of BSs under their control such that each infrastructure device may have up to date information regarding destination status.

At optional step406, the ZC determines, based on the status of each destination determined in step404, whether all of the destinations in the request are in fact operational and accessible and thus currently capable of broadcasting an alert tone instruction to its SUs. If the determination at step406is that not all destinations in the request are in fact operational and accessible, processing proceeds to optional step408where the ZC may simply drop the request (e.g., take no further action on the request), deny the request, and/or may transmit a notice back to the requesting SU informing the requesting SU that not all destinations in the request are operational and accessible. If the SU decides to proceed with the alert tone request, the SU may send a subsequent follow-up alert tone request instructing the ZC to proceed despite the unavailability of at least one destination in the original request, which the ZC could receive in a subsequent iteration of step402.

Returning to step406, assuming that the ZC determines at step406that all destinations set forth in the request are operational and accessible (or, e.g., that the request indicates an instruction for the ZC to proceed despite the fact that not all destinations may be operational and accessible), processing proceeds to step410. At step410, the ZC transmits an instruction to all fixed terminals associated with the destinations indicated in the request to broadcast an instruction to SUs in their coverage areas to play back a locally stored or generated alert tone corresponding to the type of alert tone indicated in the request. In the event that the destination is a radio site, the ZC may simply transmit the instruction to that radio site. In the event that the destination is a zone, the ZC may access a mapping that associates each zone with a number of radio sites and transmit the instruction to the mapped radio sites, or may transmit the instruction to ZC's associated with each zone in the request and rely upon those ZCs to map the instruction to a number of radio sites and further distribute the instruction to those radio sites in their zone. In the event that the destination indicates a system-wide alert, the ZC may access a mapping that lists all zones and/or radio sites in the system, and then proceed to transmit the instruction in the manner set forth above.

Once instructed to begin playing back or generating the alert tone (continuously, periodically, or semi-periodically), SUs may continue to do so until instructed to stop (or until the device is powered off or perhaps a manually inputted instruction is received at the SU to halt the alert tone). At step412, the ZC receives an alert tone cancellation request requesting cancellation of the same type of alert tone and at the same destinations as indicated in the alert tone request of step402. After step412, the ZC may similarly optionally determine the status of each destination indicated in the cancellation request, in a manner similar to that already set forth in steps404-408. At step414, the ZC transmits an alert tone instruction to all fixed terminals associated with the destinations indicated in the cancellation request to broadcast an instruction to SUs in their coverage areas to halt play back of the locally stored or generated alert tone corresponding to the type of alert tone indicated in the cancellation request.

FIG. 5sets forth a method500executable at a SU, such as SU1105, for receiving alert tone instructions, determining whether the SU is currently engaged in a call, playing back a locally stored or generated alert tone corresponding to the type of alert tone included in the alert tone instruction, and selectively mixing the stored or generated alert tone with audio signals from the currently active call responsive to a determination of whether the SU is currently engaged in an active call. Prior to step502inFIG. 5, the same SU executing steps502-512, or perhaps some other SU in the radio system, may have generated and transmitted an alert tone request to an infrastructure device in the wireless communication system. Assuming that the infrastructure device determines that the alert tone request should be allowed and further distributed, steps502-512set forth a method that may be executed at SUs at the one or more destinations set forth in the alert tone request in response to receiving a subsequently issued alert tone instruction.

At step502, the SU receives an alert tone instruction (via its serving BS) to begin continuous, periodic, or semi-periodic play back of a locally stored or generated alert tone corresponding to a first type of alert tone. At step504, the SU determines if it is currently participating in an active call. The call could be an individual voice call, a group voice call, an audio conference, a voice over IP (VoIP) call, an audio stream (e.g., perhaps from a surveillance camera and perhaps multiplexed as part of an audio/video stream), or some other source of audio being provided to the SU via its RF interface (seeFIG. 3, for example). If the SU determines at step504that it is not currently participating in an active call, processing proceeds to step506, where the SU plays back a stored audio signal or generates an alert tone corresponding to the first type of alert tone indicated in the received alert tone instruction. The SU may play back the stored audio signal continuously or on a periodic or semi-periodic basis. Alternatively, the SU may generate the alert tone on a continuous, periodic, or semi-periodic basis. Parameters related to a particular alert tone such as on-duration and repetition rate, including for the first type of alert tone, may be pre-stored at the SU, or may be provided in the alert tone instruction.

In addition to the audible alert, the SU may also provide an external visual indication at a same time that the stored audio signal or generated tone is played back, for those cases where a user may be hearing impaired or may be wearing equipment that negatively affects their ability to hear the alert tone. The external visual indication may include one of driving a particular light-emitting-diode (LED) associated with the alert tone, driving a particular LED in a particular manner associated with the alert tone, and displaying text on a display (such as an LCD display) as a function of the type of alert tone.

If, however, the SU determines at step504that it is currently participating in an active call, processing proceeds to step510, where the SU proceeds to sum a first audio signal from the call (e.g., an audio signal retrieved from voice and/or data packets via the RF interface) with a second audio signal corresponding to the stored or generated alert tone in accordance with the first type of alert tone indicated in the received alert tone instruction, and proceeds to send the summed audio to a speaker for reproduction. In one example, a DSP in the SU may execute the summing, and may do so on a continuous basis, or at some periodic or semi-periodic interval based on alert tone parameters associated with the first type of alert tone. In some examples, the DSP may be configured to decrease a relative volume of the one of the first and second audio signals with respect to the other of the first and second audio signals before summing them. For example, in one embodiment, the DSP may decrease the volume of the stored audio signal or generated audio signal associated with the alert tone relative to the active call audio prior to summing the two audio signals together, thereby avoiding drowning out the active call audio and preventing the active call from continuing while the alert tone is playing. In another embodiment, the DSP may increase the volume of the active call audio relative to the stored audio signal or generated audio signal associated with the alert tone prior to summing the two audio signals together. Of course, for particular alert tones that perhaps are more important or life threatening than others, the DSP may be configured to increase the volume of the alert tone audio relative to the active call audio (or decrease the volume of the active call audio relative to the alert tone audio).

Whether the alert tone is being summed together with other received audio (step510) or not (506), at step508, the SU determines whether a subsequent alert tone cancellation instruction has been received instructing the SU to stop further play back the first type of alert tone. The SU, in some embodiments, may also determine whether a maximum period of time has elapsed since a last instruction to play back the first type of alert tone has passed. The SU may be pre-configured with a value of the maximum period of time, or may be informed of the value of the maximum period of time in the alert tone instruction at step502. If no subsequent alert tone cancellation instruction has been received, and in some embodiments if the maximum time period since the last alert tone instruction has not yet passed, processing loops back to the respective alert tone play back step506or510, where the alert tone is further played back according to its associated periodicity (e.g., continuous, periodic, or semi-periodic depending on the type of alert tone).

If, however, it is determined at step508that an alert tone cancellation instruction has been received instructing the SU to stop further play back of the first type of alert tone (whether continuous, periodic, or semi-periodic), or in some embodiments that the maximum period of time since the last alert tone instruction authorizing or enabling the first type of alert tone has passed, at step512, the SU stops further play back of the first type of alert tone, perhaps halting any further output to the speaker if no call audio is available for play back, or halting any further summing of active call audio being received from the RF interface with the first type of alert tone if call audio is available for play back.

III. MINING ALERT TONE MESSAGING

FIGS. 6-9include ladder diagrams and set forth example messaging flows and message structures that may be used to communicate messages between SUs such as an SU602, BSs such as a BS604, an infrastructure device such as ZC606, and a logging server608. The SU602ofFIGS. 6-9may be configured similarly to the SU105ofFIG. 2and may be configured to execute one or more of the steps in process500set forth inFIG. 5. The ZC606ofFIGS. 6-9may be configured similarly to the ZC1181ofFIG. 2and may be configured to execute one or more of the steps in process400set forth inFIG. 4. WhileFIGS. 6-9set forth example communications consistent with the APCO P25 standard document “Trunking Control Channel Messages” version TIA-102.AABC-C, August, 2009, the disclosed methods and system are equally applicable to other standard and non-standard based communications. For example, whileFIGS. 7-8disclose a trunking signaling block (TSBK) data burst example that includes a 2 octet header and 8 octet data payload consistent with the P25 standard, the disclosed methods and system are equally applicable to other standard protocols, such as the digital mobile radio (DMR), ASTRO, and TETRA standards, and to other sizes and lengths of headers and payloads. Furthermore, whileFIGS. 6-9disclose examples associated with a mining operation, the same or similar messaging flows and message structure could be used for other types of operations and conditions, and are not limited in their application to the exemplary field of mining set forth herein.

When a user associated with the SU602determines that a mining alert tone should issue, perhaps to signal an imminent or forthcoming blasting event or some other condition or event, the user may actuate an input element of the SU602to select, perhaps from a displayed list, one of a type of alert tone or the actual condition or event (which may then be mapped to or associated with a type of alert tone in the SU602). The user may then be prompted for additional parameters for the alert tone, condition, or event. For example, the SU602may prompt the user to select one or more destinations for the alert tone (including an option to select a particular radio site or zone, or a system-wide destination) and, in the case of a forthcoming event such as a blasting event, perhaps when and where the event will take place. With reference toFIG. 1, the user may be using a SU602such as SU1105, and may select to alert only the SUs within the radio site133, only the SUs within the radio site143, all SUs at the first mining zone101, one or more particular radio sites153,173,193at the second mining zone151, or perhaps all radio sites133,143,153,173,193at the first mining zone101and second mining zone151(e.g., a system-wide alert).

In response to receiving the user-initiated input, the SU602generates a mining alert tone request message (Mining_Alert_Req)610that includes the SU's hardware identifier (perhaps its hardware MAC address, radio ID, or some other identifier), the type of alert tone being requested, and one or more destinations (radio sites and/or zones) where the alert tone should be raised. The SU602then transmits the Mining_Alert_Req message610over the air to its serving BS604. The Mining_Alert_Req message610may be transmitted on an existing control channel, rest channel, and/or traffic channel in a trunked radio site, or may be transmitted on an existing traffic channel in a conventional radio site. Upon receipt, the BS604may then perform processing on the Mining_Alert_Req message610and forward at least the hardware identifier, the type of alert being requested, and the one or more destinations from the received Mining_Alert_Req message610in a forwarded Mining_Alert_Req—2 message612.

One or both of the initial Mining_Alert_Req message610and the forwarded Mining_Alert_Req—2 message612may have a messaging structure the same or similar to the Mining Alert Request message structure700set forth inFIG. 7. The first two octets702of the Mining Alert Request message structure700may include an opcode field that defines a function of the message structure700and a manufacturer's ID field that defines a manufacturer and/or manufacturer feature set. The third and fourth octets704(octets2and3) may include one or more reserved fields R. The fifth octet706may include one or more reserved fields R, a force all available radio sites field F, an all radio sites field A, and an alert tone # field. The alert tone # field may identify, by number, code, description, index, or some other manner, a particular alert or alert tone being requested by the transmitting SU602. For example, the alert tone # field may be indexed and may identify a particular alert or alert tone in accordance with a look-up table such as the look-up table set forth in Table I below.

For example, an alert tone # of “0” may indicate no alert tone and may be used as a method of cancelling a previously instructed alert tone. An alert tone # of “1” may indicate a blasting tone function that should be sourced from a local tone generator at each SU using the parameters associated with that alert tone # (parameters that may be stored at each SU), which may include one or more of frequency of the tone, duration of the tone (on duration, perhaps including a predefined value implying a continuous on duration), and repetition rate of the tone (time between adjacent on periods, which may be 0 for a continuous tone). An alert tone # of “2” may indicate an evacuation function that is also sourced from a local tone generator, but perhaps using different parameters to distinguish it from the blasting tone. An alert tone # of “3” may indicate a stop work tone sourced from a locally stored spoken audio file stored at each SU, and the parameters column may specify the file name and/or path to retrieve the stored digital audio file for play back. Parameters for the stored audio file may also include a duration value and a repetition rate value defining when and for how long to play back the stored audio file, similar to the tone generator parameters. In another embodiment, no parameters may be included in the look-up table for stored audio files and instead, the stored audio file itself may be played back in a looped fashion and may itself include the repetition rate and duration within the stored digital audio recording. Table I sets forth just one example of an index structure that may be used at SUs and ZCs for indexing alert tones. Of course, other types of indexing methods could also be used and other methods of identifying a particular tone or stored audio file for play back could also be used.

The all radio sites field A in message structure700may designate, without having to separately list each radio site, a system-wide alert tone (including all radio sites in all zones, if there are multiple zones) such that all radio sites in the radio system are to be included as destinations for the specified alert tone #. The force all radio sites field F in message structure700may designate that, notwithstanding a notice received at the SU602that not all radio sites designated in a previous all radio sites alert tone request are currently operational and accessible, that the receiving ZC606should proceed to distribute the alert tone request to those remaining radio sites (perhaps re-listed in their entirety in a subsequent alert tone request, or pruned to remove the indicated non operational or non accessible radio sites) that are operational and accessible. The sixth octet708may contain one or more additional reserved fields R.

The seventh octet710may include a destination ID field that contains one or more radio site IDs or zone IDs that identify one or more destinations at which to raise the alert tone # specified in octet5706. For example, if the SU602is the SU1105operating at the first mining zone101inFIG. 1, the destination ID field may include a radio site ID associated with BS102and coverage or service area133. Additionally or alternatively, the destination ID field may include a radio site ID associated with BS142and coverage or service area143. Additionally or alternatively, the destination ID field may include one or more radio site IDs associated with a BS and corresponding coverage or service area at the second mining zone151, such as BS152and associated coverage or service area153.

In another example, the destination ID field may include a zone ID associated with the first mining zone101(including radio sites associated with BSs102and141and corresponding coverage or service areas133and143). Additionally or alternatively, the destination ID field may include a zone ID associated with the second mining zone151(including radio sites associated with BSs152,172, and192and corresponding coverage or service areas153,173, and193). In at least some embodiments, one or more pre-determined destination ID values (e.g., such as all 0's or all l's) could be used to indicate all radio sites and/or all zones (e.g., a system-wide alert) in place of using the all radio sites or all zones fields noted earlier.

The eighth-tenth octets712may set forth the source address of the message. The source address could be, for example, a network hardware MAC address associated with the SU602, a radio address of the SU602, or some other identifier used to identify the source of the message. The eleventh-twelfth octets714may include a cyclic-redundancy-check (CRC) value for use in verifying that the message has been received at a receiving device in an error-free state.

Returning toFIG. 6, the forwarded Mining_Alert_Req—2 message612is received at the ZC606and processed at step614. At step614, the ZC606may execute any one or more of the steps in the method400set forth inFIG. 4. Assuming that there were no errors found in the Mining_Alert_Req—2 message612, and that all destinations indicated in the message are operational and accessible, the ZC606transmits a Mining_Alert_Update message616to a logging server608so that a record can be maintained of when and what types of alerts were requested, and when and what types of alerts were allowed and distributed by the receiving ZC606. While only one ZC is illustrated inFIG. 6, the logging server608may provide logging services for more than one ZC at a time, and may differentiate between the ZCs by associating received messages for logging with a network hardware address or some other unique identifier associated with the source ZC or zone indicated in the Mining_Alert_Update message616.

The ZC606, after sending the Mining_Alert_Update message616(but in some embodiments, perhaps before sending the Mining_Alert_Update message616), optionally transmits a Mining_Alert_Resp message618towards the SU602indicating whether the alert tone requested in the Mining_Alert_Req message610has been approved and will be distributed by the ZC606. The receiving BS604then forwards at least a portion of the contents of the Mining_Alert_Resp message618to the source SU602in a Mining_Alert_Resp—2 message620again indicating whether the alert tone requested in the Mining_Alert_Req message610will be distributed by the ZC606. Alternatively, and in some embodiments, the ZC606may refrain from sending the Mining_Alert_Resp message618and the BS604may refrain from sending the Mining_Alert_Resp—2 message620, and instead, both may rely on the existence of subsequent messages to indicate to the source SU602whether or not the alert tone requested in the Mining_Alert_Req message610will be distributed by the ZC606.

The ZC606may then transmit a Mining_Alert_Update—2 message622towards all BSs associated with the destinations in the Mining_Alert_Req—2 message612(perhaps reduced to only those BS determined to be operational and accessible) instructing each receiving SU to play back an alert tone as indicated in the Mining_Alert_Update—2 message622. Each receiving BS, such as BS604, may then broadcast a Mining_Alert_Bcst message624in their respective coverage or service areas in accordance with the parameters of the received Mining_Alert_Update—2 message622. The Mining_Alert_Bcst message624may be a dedicated messaging structure used solely to alert SUs of new or expiring alerts, or may be a conventional message modified to include a mining alert tone indicator, perhaps by using previously reserved bits of the conventional message. Preferably, if the Mining_Alert_Bcst message624is an adapted conventional message, the adapted conventional message is chosen to be one that is transmitted at a periodic or semi-periodic rate, so that SUs can have up to date information, and newly arriving SUs that perhaps missed a previous alert tone instruction can, in a relatively short amount of time, receive and process a subsequent alert tone instruction. For example, a Motorola Solutions proprietary MOT_SYS_BCST outbound signaling packet (OSP) used to signal site or system specific information may be modified to also signal an alert tone as Mining_Alert_Bcst message624. Whether the Mining_Alert_Bcst message624has a dedicated messaging structure or is an adapted conventional messaging structure, it is preferably periodically transmitted at between 1 and 60 minute intervals.

The Mining_Alert_Bcst message624may be transmitted on an existing control channel, rest channel, and/or traffic channel in a trunked radio site, or may be transmitted on an existing traffic channel in a conventional radio site. Each BS604may be configured to periodically or semi-periodically broadcast additional Mining_Alert_Bcst messages624indicating an active alert tone until a subsequent Mining_Alert_Update—2 message622received at the BS604from the ZC606instructs the BS604to inactivate the alert tone, perhaps by continuing to periodically or semi-periodically broadcast the Mining_Alert_Bcst message624with an alert tone # of 0 (perhaps in response to a Mining_Alert_Req message received at the ZC606from the SU602instructing the ZC606to stop the alert tone indicated in the request, perhaps using an alert tone # of 0). This allows new SUs entering the coverage area of the BSs subject to the alert tone to be notified of the need (or lack of need) to play back an alert tone.

FIG. 8sets forth an example message structure800that may be used in the Mining_Alert_Bcst message624. In this example, the message structure800is a conventional MOT_SYS_BCST proprietary OSP that periodically transmits proprietary site and/or system information consistent with a Motorola Solutions feature set. The first and second octets802include an opcode field and manufacturer's ID field that are set consistent with the Motorola Solutions feature set. The third through eighth octets804contain propriety signaling consistent with the Motorola Solutions feature set. The ninth octet806includes a Reserved field and an alert tone # field. The alert tone # field identifies the alert tone, perhaps consistent with the manner in which the alert tone was identified in the Mining Alert Request message structure700set forth inFIG. 7. The tenth octet includes an additional Reserved field. The eleventh-twelfth octets810may include a CRC value for use in verifying that the message has been received at a receiving device in an error-free state.

Returning toFIG. 6, at step626, each SU in each coverage area corresponding to each BS that broadcasts the Mining_Alert_Bcst message624, including SU602, processes the received Mining_Alert_Bcst message624. If this is the first time the SU has received the Mining_Alert_Bcst message624indicating the particular alert tone included in the message, it begins to play back a continuous, periodic, or semi-periodic alert tone corresponding to the alert tone indicated in the message, perhaps in accordance with one or more steps of process500set forth inFIG. 5. Additionally or alternatively, if the SU has already received a previous Mining_Alert_Best message624already indicating the particular alert tone included in the current message, it continues to play back the continuous, periodic, or semi-periodic alert tone according to the parameters previously received, perhaps in accordance with one or more steps of process500set forth inFIG. 5.

FIG. 9sets forth a modified example ofFIG. 6that illustrates an example use of the all radio sites field A and force all radio sites field F of the Mining Alert Request message structure700set forth inFIG. 7. In this example, when a user associated with the SU602determines that a mining alert should issue at all radio sites (e.g., system-wide), perhaps to signal an imminent or forthcoming blasting event or some other condition or event that may affect more than just the current radio site or zone, the user may actuate an input element of the SU602to select, perhaps from a displayed list, an all radio sites type of alert tone (or the actual condition or event which may be preconfigured to be associated with a type of alert tone that signals all radio sites) or a particular alert tone along with a separate input for indicating that the particular alert tone should be made at all radio sites (e.g., system-wide). With reference toFIG. 1, the user may be using a SU602such as SU1105, and may select to alert all SUs at all radio sites at both the first mining zone101and the second mining zone151(which perhaps may be in proximity to the first mining zone101).

In response to receiving the user-initiated input, the SU602generates an all radio sites mining alert tone request message (Mining_Alert_Req)910similar to the Mining_Alert_Req610, but with the all radio sites field A set to indicate an all radio sites request. The SU602then transmits the all radio sites Mining_Alert_Req message910over the air to its serving BS604. BS604may then perform processing on the all radio sites Mining_Alert_Req message610, and forwards at least the hardware identifier, the type of alert being requested, the all radio sites field A, and the one or more destinations from the received Mining_Alert_Req message610in a forwarded all radio sites Mining_Alert_Req—2 message912.

One or both of the initial all radio sites Mining_Alert_Req message910and the forwarded all radio sites Mining_Alert_Req—2 message912may have a messaging structure the same or similar to the Mining Alert Request message structure700set forth inFIG. 7. The forwarded all radio sites Mining_Alert_Req—2 message912is received at the ZC606and processed at step914. At step914, the ZC606may execute any one or more of the steps in the method400set forth inFIG. 4, including the steps404-408. Assuming that the ZC606determines at step914that not all destinations (e.g., all radio sites at the first mining zone101and the second mining zone151, perhaps determined in cooperation with another ZC such as ZC2182inFIG. 1, for example) indicated in the Mining_Alert_Req—2 message612are operational and accessible, it transmits a Radio_Status_Traffic message916to the logging server608indicating the denial of the mining alert tone request so that a record can be maintained of when and what types of alerts were requested and denied and perhaps the reason for the denial.

The ZC606, after sending the Mining_Alert_Update message916(but in some embodiments, perhaps before sending the Mining_Alert_Update message916), transmits a Mining_Alert_Resp message918towards the SU602indicating that the alert tone requested in the Mining_Alert_Req message910has been denied. The receiving BS604then forwards at least a portion of the contents of the Mining_Alert_Resp message918to the source SU602in a Mining_Alert_Deny_Rsp message920indicating that the alert tone requested in the Mining_Alert_Req message910has been denied.

At step922, the source SU602processes the Mining_Alert_Deny_Rsp message920and may provide an audio or visual prompt to its user indicating that one or more of the destinations previously indicated in the Mining_Alert_Req message910(e.g., perhaps a radio site in the first mining zone101, for example) is currently inoperational or inaccessible. The prompt may inquire whether the user wishes to proceed with the alert tone request with a subset of the originally requested destinations (e.g., minus the inoperational or inaccessible destinations). Assuming that an input sequence detected at the SU602indicates that the user does wish to proceed with the reduced subset of destinations, a second all radio sites Mining_Alert_Req—3 message924is generated that either duplicates the first all radio sites Mining_Alert_Req message910, with the exception of setting the force all radio sites field F to a value to indicate that the ZC should proceed despite the inoperational or inaccessible status of at least one destination, or duplicates the first all radio sites Mining_Alert_Req message910, with the exception of removing the one or more inoperational or inaccessible destinations that may have been identified in the Mining_Alert_Deny_Rsp message920.

The SU602then transmits the second all radio sites Mining_Alert_Req—3 message924over the air to its serving BS604. BS604may then perform processing on the second all radio sites Mining_Alert_Req—3 message924, and forwards at least the hardware identifier, the type of alert being requested, and either the force all radio sites field F or a reduced subset of destinations from the received Mining_Alert_Req—3 message924in a forwarded all radio sites Mining_Alert_Req—4 message926.

One or both of the second all radio sites Mining_Alert_Req—3 message924and the forwarded second all radio sites Mining_Alert_Req—4 message926may have a messaging structure the same or similar to the Mining Alert Request message structure700set forth inFIG. 7. The forwarded second all radio sites Mining_Alert_Req—4 message926is received at the ZC606and processed at step928. At step928, the ZC606may execute any one or more of the steps in the method400set forth inFIG. 4, perhaps again including the optional steps404-408. Assuming that the ZC606determines at step928to proceed despite the fact that not all destinations indicated in the second forwarded Mining_Alert_Req—4 message926are operational and accessible (or determines at step928that the destinations in the second forwarded Mining_Alert_Req—4 message926have been updated to remove the inoperational or inaccessible destinations included in the first forwarded Mining_Alert_Req—2 message912and thus all destinations included in the request are now, in fact, operational and accessible), the ZC606transmits a Mining_Alert_Update—2 message930to a logging server608so that a record can be maintained of when and what types of alerts were requested, and when and what types of alerts were allowed and distributed by the receiving ZC606.

The ZC606, after sending the Mining_Alert_Update—2 message930(but in some embodiments, perhaps before sending the Mining_Alert_Update—2 message930), optionally transmits a Mining_Alert_Resp—2 message932towards the SU602indicating that the alert tone requested in the second forwarded Mining_Alert_Req—4 message926will be distributed by the ZC606. The receiving BS604then forwards at least a portion of the contents of the Mining_Alert_Resp—2 message932to the source SU602in a Mining_Alert_Resp—3 message934indicating that the alert tone requested in the second all radio sites Mining_Alert_Req—3 message924will be distributed by the ZC606. Alternatively, and in some embodiments, the ZC606may refrain from sending the Mining_Alert_Resp—2 message932and the BS may refrain from sending the Mining_Alert_Resp—3 message934, and instead, rely on the existence of subsequent messages to indicate to the source SU602whether or not the alert tone requested in the Mining_Alert_Req—3 message924will be distributed by the ZC606.

The ZC606may then transmit a Mining_Alert_Update—3 message942towards all BSs associated with the destinations in the second all radio sites Mining_Alert_Req—3 message924(e.g., perhaps to all destinations mapped at the ZC606as associated with an all radio sites alert tone request, perhaps reduced to only those BSs determined to be operational and accessible) instructing each receiving SU to play back an alert tone as indicated in the Mining_Alert_Update—3 message942. Each receiving BS, such as BS604, may then broadcast a Mining_Alert_Bcst message944in their respective coverage or service areas in accordance with the parameters of the received Mining_Alert_Update—3 message942. The Mining_Alert_Bcst message944may be broadcast in the same or similar to the Mining_Alert_Bcst message624already set forth inFIG. 6.

At step946, each SU in each coverage area corresponding to each BS that broadcasts the Mining_Alert_Bcst message944, such as SU602, processes the received Mining_Alert_Bcst message944. If this is the first time the SU has received the Mining_Alert_Bcst message944indicating the particular alert tone included in the message, it begins to play back a continuous, periodic, or semi-periodic alert tone corresponding to the alert tone indicated in the message, perhaps in accordance with one or more steps of process500set forth inFIG. 5. Additionally or alternatively, if the SU has already received a previous Mining_Alert_Best message944already indicating the particular alert tone included in the current message, it continues to play back the continuous, periodic, or semi-periodic alert tone according to the parameters previously received, perhaps in accordance with one or more steps of process500set forth inFIG. 5.

Advantageously, by transmitting alert tone instructions over-the-air by piggy-backing on conventional messaging, or via a new dedicated alert tone messaging structure, alert tones can be requested, managed, distributed, and played back at one or more radio sites without dedicating a separate channel (frequency) to the tone (e.g., separate from a control channel or separate from a traffic channel), and allows SUs to continue their active calls by mixing locally stored or generated tones with incoming call audio. Furthermore, because the tones are locally generated at the radio, they do not suffer from the affects of digitizing and vocoding of tones. Other advantages and benefits are possible as well.

In accordance with the foregoing, a digital two-way radio communication system and method is disclosed that allows for continuous, periodic, or semi-periodic tones or digital audio files to be selectively mixed with digital call audio (if present) and played back at subscriber units across one or more radio sites to indicate a respective situation, and a system and method to allow a subscriber unit to initiate the play back of the continuous, periodic, or semi-periodic tones, without unnecessarily increasing network bandwidth or frequency channel availability, and while making allowances for calls existing at the time of the initiation of the continuous, periodic, or semi-periodic tone to continue.