Methods for enhanced communication between a plurality of communication systems

FIELD OF THE INVENTION

0001The present invention relates generally to features that enhance communications between two or more distinct communication systems, more specifically talk permit tones, emergency announcement and vocalic radio patch establishment features.

BACKGROUND OF THE INVENTION

0002Interoperability between the communication systems of local, state and federal agencies became of paramount importance as a result of the terrorist attacks to the United States on Sep. 11, 2001. In response to these events, the U.S. Department of Homeland Security (DHS) was created to facilitate a national effort to prevent and respond to such acts of terrorism. A major component of the DHS' domestic preparedness initiatives is the ability of First Responders to an emergency situation (including those from local, state and federal agencies) to communicate during the crisis.

0003A number of interoperability systems have been developed to interconnect users of various communications systems (e.g. trunked radio systems users, conventional radio systems users, public switched telephone network (PSTN) users, cellular telephone users, etc.) to allow them to converse with each other on a day to day basis or during times of crisis. Interoperability is in general based upon known similarities between the systems being interconnected. One obvious similarity is that essentially all of the communication systems for local, state and federal agencies provide for a plain media interface (e.g., base-band analog audio, base-band analog video, plain data, etc.) and typically have access to packet-switched communication systems (or networks). A packet-switched network is defined herein as a network that serves as the medium through which messages may be transmitted between two endpoints or nodes (e.g., between a source and a destination), wherein the message is broken down into a set of units commonly referred to as “packets,” and the packets are transferred across the network.

0004A commonly used packet-switched network is an Internet Protocol (IP) based network, wherein the message is packetized and routed over the network using the Internet Protocol. The Internet Protocol is an open standard network layer (Layer <b>3</b> of the Open Standard Interconnection (OSI) model) routing protocol defined in the Internet Engineering Task Force (IETF) Request for Comment (RFC) 791 and any subsequent corresponding RFC updates as recognized in the art. Since IP-based networks are the types of networks most prevalently used by local, state and federal agencies, existing interoperability solutions are, accordingly, typically IP-based. Such IP-based solutions are desirable mainly because they do not require a costly and, quite frankly, unrealistic replacement of equipment that would be necessary to conform the existing communication systems of all of the various agencies to the same type of radio system, equipment and standards.

0005Moreover, existing solutions are typically either based upon a client-server networking approach or a peer-to-peer solution for interoperability. When using the client-server approach, a client system that wants to be interconnected with another client system must first communicate with a third-party application (i.e., a server) to facilitate the interoperability and resultant communication with the other client system. Whereas with a peer-to-peer solution, once a logical path is established through a network between, for example, two packet-switched apparatus (i.e., a connection is established), communication frames may be transmitted over the connection without the need for a third-party application (e.g., a server). In other words, once a connection is established between two packet-switched apparatus, communication frames may be transmitted directly from one apparatus to the other over the established connection without any server intervention.

0006Although systems for interoperability have been developed, there still exists a need for features that enhance communications between two or more distinct communication systems connected using these interoperability systems. For example, talk permit tones, emergency announcements and vocalic radio patch establishment features are three such features that may be extremely useful and desirable in today's interoperability systems.

BRIEF DESCRIPTION OF THE FIGURES

0007A preferred embodiment of the invention is now described, by way of example only, with reference to the accompanying figures in which:

0008<figref idref="DRAWINGS">FIG. 1</figref> illustrates a diagram of a system that may be used to implement the present invention;

0009<figref idref="DRAWINGS">FIG. 2</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating a talk permit tone between a conventional radio system and a trunked radio system connected via an interoperability system;

0010<figref idref="DRAWINGS">FIG. 3</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating a talk permit tone between a conventional radio system and a trunked radio system connected via a peer-to-peer based interoperability system;

0011<figref idref="DRAWINGS">FIG. 4</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating a talk permit tone between two trunked radio systems connected via an interoperability system;

0012<figref idref="DRAWINGS">FIG. 5</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating a talk permit tone between two trunked radio systems connected via a peer-to-peer based interoperability system;

0013<figref idref="DRAWINGS">FIG. 6</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating emergency information between a trunked radio system and a conventional radio system connected via an interoperability system;

0014<figref idref="DRAWINGS">FIG. 7</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for communicating emergency information between a trunked radio system and a conventional radio system connected via a peer-to-peer interoperability system;

0015<figref idref="DRAWINGS">FIG. 8</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for establishing a vocalic radio patch between two radio systems connected via an interoperability system;

0016<figref idref="DRAWINGS">FIG. 9</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for establishing a vocalic radio patch between two radio systems connected via a peer-to-peer interoperability system;

0017<figref idref="DRAWINGS">FIG. 10</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for using tones to enhance communication between a PSTN system and a radio system connected via an interoperability system; and

0018<figref idref="DRAWINGS">FIG. 11</figref> is a bounce diagram illustrating a method in accordance with an embodiment of the present invention for using tones to enhance communication between a PSTN system and a radio system connected via a peer-to-peer interoperability system.

DETAILED DESCRIPTION OF THE INVENTION

0019While this invention is susceptible of embodiments in many different forms, there are shown in the figures and will herein be described in detail specific embodiments, with the understanding that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described. Further, the terms and words used herein are not to be considered limiting, but rather merely descriptive. It will also be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to each other. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding elements.

0020Disclosed herein are various embodiments of the present invention that address features for use in an interoperability system that enhance the ability of public-safety first responders and dispatchers from different agencies (police, fire, Emergency Medical Center (EMC), etc.), for example, to communicate during a time of crisis or, if necessary, on a day-to-day basis. <figref idref="DRAWINGS">FIG. 1</figref> illustrates a system <b>100</b> that may be used to implement the various embodiments of the present invention. System <b>100</b> includes any suitable interoperability system <b>10</b> known in the art. The interoperability system <b>10</b> may be, for example, a client/server based interoperability system, a peer-to-peer interoperability system or some combination.

0021Interoperability system <b>10</b> may be used to connect on demand any two or more communication systems or apparatus (e.g., <b>20</b>-<b>60</b>) also included in system <b>100</b> to, for example, form dynamic talk groups, to enable the connected communication systems or apparatus to communicate with each other. Those of ordinary skill in the art will realize that communication systems and apparatus <b>20</b>-<b>60</b> are exemplary and that the number of and variety of communication systems and apparatus that may be interconnected via interoperability system <b>10</b> may be tailored to meet a customer's requirements without loss of generality of the embodiments of the present invention as illustrated by reference to <figref idref="DRAWINGS">FIGS. 2-11</figref>.

0022Communication systems and apparatus <b>20</b>-<b>60</b> are all conventional, the elements and functionality of which are well known in the art and will therefore only be briefly described. Communication system <b>20</b> is illustrated as a trunked radio system <b>20</b> having operatively coupled thereto a radio apparatus <b>22</b> that is used to facilitate communication between a plurality of users using communication units (e.g., a unit <b>24</b> that may be, for instance, a mobile radio) that are operatively coupled to radio apparatus <b>22</b>. Communication system <b>30</b> is illustrated as a conventional radio system <b>30</b> having operatively coupled thereto a radio apparatus <b>32</b> that is used to facilitate communication between a plurality of users using communication units (e.g., a unit <b>34</b> that may be, for instance, a portable radio) that are operatively coupled to radio apparatus <b>32</b>. Radio systems <b>20</b> and <b>30</b> may be, for example, existing public safety systems serving various local fire, police and EMC agencies or various state and federal agencies. These radio systems may include one or more base radio sites (e.g., respectively radio apparatus <b>22</b> and <b>32</b>) that may be used to enable communication between, for example, mobile and portable radios (e.g., respectively units <b>24</b> and <b>34</b>) used by the public safety officers of the given agencies that may be coupled to the base radio site.

0023Communication system <b>40</b> is illustrated as a conventional cellular system <b>40</b> that is used to facilitate communication between a plurality of users using communication units (e.g., a unit <b>42</b> that may be, for instance, a wireless cellular telephone) that are operatively coupled to cellular system <b>40</b>. The cellular system <b>40</b> provides telephony services to public users using wireless phones located anywhere in the cellular system coverage area.

0024Communication system <b>50</b> is illustrated as a PSTN system <b>50</b> that is used to facilitate communication between a plurality of users using communication units (e.g., a unit <b>52</b> that may be, for instance, a landline telephone). The PSTN system <b>50</b> provides telephony services to public users using copper wire phones.

0025Communication apparatus <b>60</b> is illustrated as a dispatcher apparatus <b>60</b>. Dispatcher apparatus <b>60</b> is used by a dispatcher (e.g., <b>62</b>) that is ideally trained in interoperability. Typically, each dispatcher apparatus includes a computer system <b>64</b>, e.g., a personal computer, having a processing device and a storage device, a Graphical User Interface (GUI) for operating applications stored on the storage device and executed by the processing device and audio accessories operatively coupled to the GUI such as a headset, a microphone and one or more speakers. Dispatcher apparatus may be distributed throughout a given geographical coverage area to facilitate interoperability within that coverage area between the communication systems included in system <b>100</b>. The number of dispatcher apparatus used in system <b>100</b> depends in part on the size of the coverage area and the anticipated number of communication systems, for instance, that may need to be interconnected.

0026The communication systems and apparatus (<b>20</b>-<b>60</b>) may be operatively coupled or interconnected to thereby communicate over a common network, ideally a packet-switched network, wherein the systems and apparatus operate using a corresponding routing protocol that enables communication over that network. For example, the communication systems and apparatus of system <b>100</b> may be interconnected via an IP network operated over a Wide Area Network (WAN) or a Local Area Network (LAN), for instance, and each of the systems and apparatus would be, accordingly, configured to run IP for communicating over the IP network. The Internet Protocol may be any version thereof such as IPv<b>4</b> or IPv<b>6</b> and may or may not support functionality such as Quality of Service (QoS), Multi-protocol Label Switching (MPLS), Virtual Private Network (VPN), etc., depending on the particular implementation. In other embodiments, packet-switching may, alternatively, be implemented using another protocol (e.g., X.<b>25</b>, which is another open standard protocol that was originally recommended by the International Consultative Committee for Telegraphy and Telephony (CCITT) called the International Telecommunication Union (ITU) since <b>1993</b>) over a related packet-switched network. Moreover, the methods illustrated by the bounce diagrams of <figref idref="DRAWINGS">FIGS. 2-11</figref> may be implemented, for example, in system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>, wherein the methods may be stored in a storage device and executed by a processing device coupled to the storage device or may be, alternatively, implemented in hardware.

0027We now turn to a first embodiment of the present invention illustrated in FIGS. <b>2</b>-<b>5</b>—a method in an interoperability system for notifying a first communication system that a second communication system is ready to receive data. Trunked radio systems, unlike conventional radio systems, have shared resources that are allocated on request. These radio systems accordingly typically employ a significant push-to-talk (PTT) grant delay (e.g., 50-500 msec), wherein a PTT grant signal indicates that resources for communications have been allocated. PTT grant is typically signaled to the user by a “talk permit tone” from the trunked radio system notifying the user through the user's communication device that access to the trunked radio system has been granted.

0028An interoperability system must mitigate against this PTT grant period in a remote trunked radio system in order to avoid audio clipping caused by another radio system, for example, which is connected to the remote trunked system being unaware of when the remote trunked system is ready to receive communications. A straight-forward solution is to have large audio buffers that would delay the voice, for instance, in the interoperability system until a PTT grant signal has been received from the remote trunked system. However, this solution suffers from large audio delay. <figref idref="DRAWINGS">FIGS. 2-5</figref> illustrate methods in accordance with an embodiment of the present invention to address the above shortcomings. In accordance with this embodiment, special signaling (ideally special tones) are used to indicate that a radio system that is connected via an interoperability system to a remote trunked radio system, has been granted access to the remote system and that the remote system is ready to receive communications from the radio system.

0029The methods illustrated by the bounce diagrams of <figref idref="DRAWINGS">FIGS. 2-5</figref>, in general, include the steps of: receiving from a first communication system a request to communicate with a user of a second communication system; forwarding the request to communicate to the second communication system; sending a first signal to the first communication system indicating that the second communication system is not ready to receive the data; and upon receipt of notification that the second communication system is ready to receive the data, sending a second signal to the first communication signal indicating that the second communication system is ready to receive the data.

0030<figref idref="DRAWINGS">FIG. 2</figref> illustrates a radio system <b>220</b> and a radio system <b>230</b> that are operatively connected together via an interoperability system <b>210</b>. Further shown is a user <b>224</b> of a radio <b>222</b> that is operatively coupled to radio system <b>220</b> who desires to communicate with a user of a radio <b>232</b> that is operatively coupled to radio system <b>230</b> via the interoperability system connection. In this embodiment, radio system <b>220</b> is a conventional radio system, and radio system <b>230</b> is a trunked radio system.

0031In operation, the user <b>224</b> of radio system <b>220</b> initiates a request to communicate with the remote trunked radio system <b>230</b>. In one embodiment, the user presses a PTT button on the radio <b>222</b> which generates a PTT request that is communicated via radio system <b>220</b> to interoperability system <b>210</b>, ideally as a carrier operated relay (COR) signal. In response to receipt of the PTT request, system <b>210</b> forwards the PTT request to the remote radio system <b>230</b> to key on system <b>230</b> and also sends a signal, preferably an audible signal, to the radio system <b>220</b> that is coupled to radio <b>222</b> to be heard by the user <b>224</b>, indicating that the remote trunked radio system is not yet ready to receive communications (e.g. voice, video, etc.) from user <b>224</b>. Ideally, the audible signal is a tone and is illustrated in <figref idref="DRAWINGS">FIG. 2</figref> as an “interoperability wait tone.” System <b>210</b> sends this interoperability wait tone to user <b>224</b> until it receives an indication or notification from the remote trunk radio system that it is ready to receive communications from radio system <b>222</b>. This notification is typically a PTT grant signal.

0032Upon receipt of the PTT grant signal from system <b>230</b>, interoperability system <b>210</b> sends a second signal, preferably an audible signal, to the radio system <b>220</b> that is coupled to radio <b>222</b> to be heard by the user <b>224</b>, indicating that the remote trunked radio system <b>230</b> is now ready to receive communications from user <b>224</b>. Ideally, this audible signal is also a tone and is illustrated in <figref idref="DRAWINGS">FIG. 2</figref> as an “interoperability permit tone” that is ideally distinguishable from the interoperability wait tone. User <b>224</b> can then press the PTT button and talk to a user of the remote trunked system <b>230</b>. Alternatively, in the event that system <b>230</b> denies the PTT request, upon receipt of this indication or notification from system <b>230</b> the interoperability system <b>210</b> may send a signal, preferably an audible tone that is distinguishable from both the interoperability wait and permit tones, to the user <b>224</b> indicating that the PTT request was denied. Since the user <b>224</b> of the conventional radio system <b>220</b> does not typically have to wait for a given tone to begin talking when using system <b>220</b>, such a user would ideally be trained in the use of the above-described method. Specifically, if radio <b>222</b> supports simplex or half duplex operation, then user <b>224</b> would have to release the PTT button (after initiating the PTT request) in order to hear the interoperability wait and permit tones. Typically, the interoperability system <b>210</b> detects that the user <b>224</b> has released the PTT button via a COR release signal from radio system <b>220</b>. Alternatively, where radio <b>222</b> supports full duplex operation, it is unnecessary for the user <b>224</b> to release the PTT button.

0033<figref idref="DRAWINGS">FIG. 3</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 2</figref>, the difference being that in this embodiment the interoperability system is a particular implementation of a peer-to-peer interoperability system. Accordingly, <figref idref="DRAWINGS">FIG. 3</figref> illustrates a radio system <b>320</b> and a radio system <b>330</b> that are operatively connected via an interoperability system over a network <b>310</b> that is ideally an IP network. Further shown is a user <b>326</b> of a radio <b>324</b> that is operatively coupled to radio system <b>320</b> who desires to communicate with a user of a radio <b>334</b> that is operatively coupled to radio system <b>330</b>. In this embodiment, radio system <b>320</b> is a conventional radio system, and radio system <b>330</b> is a trunked radio system.

0034The interoperability system that interconnects radio systems <b>320</b> and <b>330</b>, in this embodiment, includes a packet-switched apparatus <b>322</b> (illustrated in <figref idref="DRAWINGS">FIG. 3</figref> as a “Radio Soft Switch”) that is coupled to and preferably integrated within radio system <b>320</b> and a packet switched apparatus <b>332</b> (also illustrated in <figref idref="DRAWINGS">FIG. 3</figref> as a “Radio Soft Switch”) that is coupled to and preferably integrated within radio system <b>330</b>. Radio Soft Switch <b>322</b> is ideally connected to Radio Soft Switch <b>332</b> via a packet-switched IP network <b>310</b>. Each Soft Switch is ideally implemented as a software platform or stack having process steps that may be stored on a storage device and executed by a processing device coupled to or included within the radio system, although those of ordinary skill in the art will realize that the Soft Switches may alternatively be implemented in hardware. For example, the Radio Soft Switches <b>322</b> and <b>332</b>, respectively, for radio systems <b>320</b> and <b>330</b>, may each be stored on a storage device and executed by a processing device included within or coupled to a base radio site operating within the respective radio systems. Moreover, each Soft Switch includes process steps for implementing a session layer framing protocol or method that facilitates the interoperability between the radio systems (e.g., <b>320</b> and <b>330</b>) as a peer-to-peer solution for interoperability. This session layer protocol is also referred to herein as a peer-to-peer remote PTT framing layer (or RPDFL) without loss of generality.

0035Each Soft Switch stack further ideally includes an interface application. The interface application implements all the necessary hardware and software elements to communicate the plain media (e.g., audio, video or data) to the radio system. The radio interface application may be implemented, for example, using a Four Wire Ear and Mouth (<b>4</b>W E&amp;M, sometimes also referred to as <b>6</b>W) interface, wherein the <b>4</b>W lines carry the bi-directional base-band analog audio, and the E&amp;M bi-directional signals instruct whether audio is incoming (E active) or outgoing (M active). Another industry standard that may be implemented is a <b>4</b>W Tone Remote Control (TRC), wherein in-band tones are used to replace and extend the E&amp;M signals to also include instructions to a radio to key-on the radio's transmitter to certain carrier frequencies.

0036Each Soft Switch stack also ideally includes a standard Session Initiation Protocol (SIP) User Agent for use in establishing and terminating connections between two endpoints, wherein SIP is defined in IETF RFC <b>3261</b> and any corresponding subsequent RFC updates as recognized in the art. Finally, each Soft Switch stack ideally includes a protocol stack in accordance with the OSI model, for example, that includes the network layer (or Layer <b>3</b>) that implements IP and the transport layer (Layer <b>4</b>) that implements the User Datagram Protocol (UDP) or the Transport Control Protocol (TCP), which are also both standard protocols that are defined, respectively, in the IETF RFC <b>768</b> and RFC <b>793</b> and any corresponding subsequent RFC updates as recognized in the art. It should be understood by those of ordinary skill in the art that although each radio system in <figref idref="DRAWINGS">FIG. 3</figref> is illustrated as including a single Soft Switch, any or all of the radio systems may include multiple Soft Switches without loss of generality.

0037Returning to the method illustrated by the bounce diagram of <figref idref="DRAWINGS">FIG. 3</figref>, the user <b>326</b> of radio system <b>320</b> initiates a request to communicate with the remote trunked radio system <b>330</b>. In one embodiment, the user presses a PTT button on the radio <b>324</b> which generates a PTT request that is communicated via radio system <b>320</b> to Radio Soft Switch <b>322</b>, ideally as a COR indication. In response to receipt of the PTT request, Soft Switch <b>322</b> forwards the PTT request (indicated as a PTT_P signal in <figref idref="DRAWINGS">FIG. 3</figref>), ideally a plurality of times, to Soft Switch <b>332</b> and also sends a signal, preferably an audible signal, to the radio system <b>320</b> that is coupled to radio <b>324</b> to be heard by the user <b>326</b>, indicating that the remote trunked radio system is not yet ready to receive communications (e.g. voice, video, etc.) from user <b>326</b>. Ideally, the audible signal is a tone and is illustrated in <figref idref="DRAWINGS">FIG. 3</figref> as an “interoperability wait tone.” Soft Switch <b>332</b> forwards the PTT request to the remote radio system <b>330</b> to key on system <b>330</b>. Soft Switch <b>322</b> sends the interoperability wait tone to user <b>326</b> until it receives an indication or notification from the remote trunk radio system, via Soft Switch <b>332</b>, that it is ready to receive communications from radio system <b>320</b>. This notification from the remote trunked system is typically a PTT grant signal, and Soft Switch <b>332</b> ideally sends an indication of the PTT grant signal (illustrated as a PTT_OK signal in <figref idref="DRAWINGS">FIG. 3</figref>) ideally a plurality of times to Soft Switch <b>322</b>. The radio signaling, e.g., the PTT_P and PTT_OK signals, is ideally transmitted between the Soft Switches a plurality of times (in one embodiment a predetermined number of times) to increase the reliability of the receiving Soft Switch actually receiving at least one of the signals.

0038Upon receipt of the PTT grant signal from Soft Switch <b>332</b>, Soft Switch <b>322</b> sends a second signal, preferably an audible signal, to the radio system <b>320</b> that is coupled to radio <b>324</b> to be heard by the user <b>326</b>, indicating that the remote trunked radio system is now ready to receive communications from user <b>326</b>. Ideally, the audible signal is also a tone and is illustrated in <figref idref="DRAWINGS">FIG. 3</figref> as an “interoperability permit tone” that is ideally distinguishable from the interoperability wait tone. User <b>326</b> can then press the PTT button and talk to a user of the remote trunked system <b>330</b>. Alternatively, in the event that system <b>330</b> denies the PTT request, upon receipt of this indication or notification from system <b>330</b> via Soft Switch <b>332</b>, Soft Switch <b>322</b> may send a signal, preferably an audible tone that is distinguishable from both the interoperability wait and permit tones, to the user <b>326</b> indicating that the PTT request was denied.

0039Since the user <b>326</b> of the conventional radio system <b>320</b> does not typically have to wait for a given tone to begin talking when using system <b>320</b>, such a user would ideally be trained in the use of the above-described method. Specifically, if radio <b>324</b> supports simplex or half duplex operation, then user <b>326</b> would have to release the PTT button (after initiating the PTT request) in order to hear the interoperability wait and permit tones. Typically, the Radio Soft Switch <b>322</b> detects that the user <b>326</b> has released the PTT button via a COR release signal from radio system <b>320</b>. Alternatively, where radio <b>324</b> supports full duplex operation, it is unnecessary for the user <b>326</b> to release the PTT button.

0040<figref idref="DRAWINGS">FIG. 4</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 2</figref>, the difference being that the user desiring to communicate with the remote trunked radio system is also communicating via a trunked radio system. Accordingly, <figref idref="DRAWINGS">FIG. 4</figref> illustrates a radio system <b>420</b> and a radio system <b>430</b> that are operatively connected together via an interoperability system <b>410</b>. Further shown is a user <b>424</b> of a radio <b>422</b> that is operatively coupled to radio system <b>420</b> who desires to communicate with a user of a radio <b>432</b> that is operatively coupled to radio system <b>430</b>. In this embodiment, both radio systems <b>420</b> and <b>430</b> are trunked radio systems. The method illustrated by the bounce diagram <figref idref="DRAWINGS">FIG. 4</figref> is essentially identical to the method illustrated by the bounce diagram of <figref idref="DRAWINGS">FIG. 2</figref> except that radio <b>422</b> would also receive a talk permit tone from its own radio system <b>420</b> (to be heard by user <b>424</b>) indicating when this radio system has allocated resources for transmission of communications from user <b>424</b> to the interoperability system <b>410</b>. Further details of the method in accordance with the bounce diagram of <figref idref="DRAWINGS">FIG. 4</figref> will not be repeated here for the sake of brevity.

0041<figref idref="DRAWINGS">FIG. 5</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 3</figref>, the difference being that the user desiring to communicate with the remote trunked radio system is also communicating via a trunked radio system. Accordingly, <figref idref="DRAWINGS">FIG. 5</figref> illustrates a radio system <b>520</b> and a radio system <b>530</b> that are operatively connected via an interoperability system over a network <b>510</b> that is ideally an IP network. Peer-to peer interoperability is enabled using a Radio Soft Switch <b>522</b> coupled to and ideally integrated within radio system <b>520</b> and a Radio Soft Switch <b>532</b> coupled to and ideally integrated within radio system <b>530</b>. Further shown is a user <b>526</b> of a radio <b>524</b> that is operatively coupled to radio system <b>520</b> who desires to communicate with a user of a radio <b>534</b> that is operatively coupled to radio system <b>530</b>. In this embodiment, both radio systems <b>520</b> and <b>530</b> are trunked radio systems. The method illustrated by the bounce diagram <figref idref="DRAWINGS">FIG. 5</figref> is essentially identical to the method illustrated by the bounce diagram of <figref idref="DRAWINGS">FIG. 3</figref> except that radio <b>524</b> would also receive a talk permit tone from its own radio system <b>520</b> (to be heard by user <b>526</b>) indicating when this radio system has allocated resources for transmission of communications from user <b>526</b> to the Soft Switch <b>522</b>. Further details of the method in accordance with the bounce diagram of <figref idref="DRAWINGS">FIG. 5</figref> will not be repeated here for the sake of brevity.

0042Only one remote trunked radio system is shown connected via the interoperability systems illustrated in <figref idref="DRAWINGS">FIGS. 2-5</figref> for ease of illustration. However, those of ordinary skill in the art will realize that two or more remote trunked radio systems could be connected via the respective interoperability systems. In that case, ideally the user of the radio system desiring to communicate with all of the radio systems connected to the interoperability system would wait to communicate until receiving an interoperability permit tone corresponding to a PTT grant signal from each connected trunked system. One interoperability permit tone could be sent to the user after all of the PTT grant signals have been collectively received by the interoperability system. Alternatively, multiple interoperability permit tones could be sent to the user with one interoperability permit tone corresponding to each PTT grant signal received. Any suitable means known in the art could be used to enable the interoperability system or the user to have knowledge regarding the number of remote trunked systems connected via the interoperability system and the number of corresponding interoperability wait tones the user should receive before beginning the communications.

0043We next turn to another embodiment of the present invention illustrated in <figref idref="DRAWINGS">FIGS. 6 and 7</figref>—methods in an interoperability system for emergency announcements. Trunked radio systems typically include an “emergency” feature, which allows a radio user who happens to get into a distress situation to press a special “emergency” button on the radio to inform his talk-group and any dispatcher of the distress situation. The “emergency” message typically includes an “emergency-id” identifying the distressed user. The methods in accordance with the bounce diagrams of <figref idref="DRAWINGS">FIGS. 6 and 7</figref> enable a user of a first radio system (e.g., conventional or trunked) connected through an interoperability system to a second radio system (e.g., trunked) to be informed of an emergency situation of a user in the second radio system.

0044<figref idref="DRAWINGS">FIG. 6</figref> illustrates a radio system <b>620</b> and a radio system <b>630</b> that are operatively connected together via an interoperability system <b>610</b>. Further shown is a user <b>624</b> of a radio <b>622</b> that is operatively coupled to radio system <b>620</b> and a user <b>634</b> of a radio <b>632</b> that is operatively coupled to radio system <b>630</b>. In this embodiment, radio system <b>620</b> is a conventional radio system, and radio system <b>630</b> is a trunked radio system. In operation, if user <b>634</b> is in a distress or emergency situation, the user can send an indication of the emergency to its radio system <b>630</b> using radio <b>632</b>. Typically the emergency indication is generated by the user <b>634</b> pressing an emergency button on the radio <b>632</b> and, in response, the radio sending an emergency message (e.g. emergency data in the form of a text message) to radio system <b>630</b> that ideally includes within the emergency message the identity of user <b>634</b> (e.g. user <b>634</b> ID). Radio system <b>630</b> would then forward the emergency indication (e.g., the emergency text message) to interoperability system <b>610</b>.

0045Upon receipt of the emergency indication, system <b>610</b> ideally converts it to an emergency message having a suitable format that is readable or usable by radio system <b>620</b> and then sends the emergency message to radio system <b>620</b>. For example, system <b>610</b> might convert the data message to an audible signal, such as speech, that radio system <b>620</b> could then broadcast to user <b>624</b> via radio <b>622</b>. In another embodiment, system <b>610</b> might convert the data message to a short message format such as, for instance, email that radio system <b>620</b> could forward to radio <b>622</b> to be read by user <b>624</b>.

0046<figref idref="DRAWINGS">FIG. 7</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 6</figref>, the difference being that in this embodiment the interoperability system is a particular implementation of a peer-to-peer interoperability system. Accordingly, <figref idref="DRAWINGS">FIG. 7</figref> illustrates a radio system <b>720</b> and a radio system <b>730</b> that are operatively connected via an interoperability system over a network <b>710</b> that is ideally an IP network. Peer-to peer interoperability is enabled using a Radio Soft Switch <b>722</b> coupled to and ideally integrated within radio system <b>720</b> and a Radio Soft Switch <b>732</b> coupled to and ideally integrated within radio system <b>730</b>. Further shown is a user <b>726</b> of a radio <b>724</b> that is operatively coupled to radio system <b>720</b> and a user <b>736</b> of a radio <b>734</b> that is operatively coupled to radio system <b>730</b>. In this embodiment, radio system <b>720</b> is a conventional radio system, and radio system <b>730</b> is a trunked radio system.

0047The method illustrated by the bounce diagram <figref idref="DRAWINGS">FIG. 7</figref> is essentially identical to the method illustrated by the bounce diagram of <figref idref="DRAWINGS">FIG. 6</figref> except that the emergency indication is received at Radio Soft Switch <b>732</b> and transmitted to Radio Soft Switch <b>722</b> (illustrated as a “DATA”“Emer” signal in <figref idref="DRAWINGS">FIG. 7</figref>) ideally a plurality of times using the RFPDL protocol such that Soft Switch <b>722</b> receives at least one of the emergency indications. Upon receipt, Soft Switch <b>722</b> converts the emergency indication into an emergency message having a format that is suitable for radio system <b>720</b>. Further details of the method in accordance with the bounce diagram of <figref idref="DRAWINGS">FIG. 7</figref> will not be repeated here for the sake of brevity.

0048We next turn to another embodiment of the present invention illustrated in <figref idref="DRAWINGS">FIGS. 8 and 9</figref>—methods for establishing a vocalic radio patch between two communication systems in an interoperability system. In many cases, dispatchers trained in interoperability systems are responsible for connecting (or patching) the various disparate communication systems to form, for instance, radio system talk groups in an interoperability system that include two or more radio systems. However, in certain circumstances, for example in remote geographical locations, a communication system user (e.g., a mobile user) might have a need for interoperability communication when there is no interoperability dispatcher to serve him. The methods illustrated by the bounce diagrams of <figref idref="DRAWINGS">FIGS. 8 and 9</figref> enable a user to make a patch between his communication system and another communication system in the interoperability network by using a vocal command to the interoperability system.

0049Accordingly, <figref idref="DRAWINGS">FIG. 8</figref> illustrates a user <b>824</b> of a communication (e.g., radio) system <b>820</b> that desires to be connected using an interoperability system <b>810</b> to another communication system (e.g., radio system <b>840</b>). Coupled to, and preferably integrated within, interoperability system <b>810</b> is a conventional Interactive Voice Response (IVR) device (e.g., a server) for facilitating this embodiment of the present invention. A typical IVR server is at a minimum operable to provide for playing and recording prompts and gathering touch-tone input. In addition, an IVR server may provide for recognizing spoken input from callers (i.e., voice recognition) and translating text into spoken output for callers (i.e., text-to-speech).

0050In operation, the user <b>824</b> would send an audible signal to the interoperability system <b>810</b> indicating that the user desired to have radio system <b>820</b> connected (or patched) to another radio system (e.g., radio system <b>840</b>). Ideally, the user would press a PTT button on radio <b>822</b> and speak predefined words (e.g., “connect me”) into the radio. Alternatively, if the user <b>824</b> is coupled through a communication system such as, for instance, a PSTN system the user could generate predefined tones using the PSTN device. Ideally, for any radio system that does not have an active connection in the interoperability system <b>810</b> (e.g., radio system <b>820</b>), system <b>810</b> would constantly direct incoming audible signals or calls from that radio system to the IVR server <b>830</b> for monitoring these signals to detect a request to connect. Upon detecting that an audible signal from radio system <b>820</b> is a request to connect with radio system <b>840</b>, then interoperability system <b>810</b> would create the patch.

0051More specifically, upon detecting the request from radio system <b>820</b> to create a patch, ideally the IVR server <b>830</b> verifies the request for a connection, for example, by generating an audible or vocalic response to the user (e.g., “please specify your request”) via interoperability system <b>810</b> and radio system <b>820</b> that the user hears from radio <b>822</b>. If the radio <b>822</b> supports simplex or half duplex operation then the user <b>824</b> must release the PTT button in order to hear the vocalic response. The user <b>824</b> could then vocalically or audibly verify the request for a patch by, for example, reiterating its request using the same or similar predefined words (e.g., “patch me to radio system <b>840</b>”). Upon receipt of the verification, the IVR server <b>830</b> ideally directs interoperability system <b>810</b> to create the connection between radio systems <b>820</b> and <b>840</b>, preferably using a digital message. Alternatively, instead of requesting to be connected to a particular communication system, the interoperability system <b>810</b> or the IVR server <b>830</b> may be configured for searching for the nearest (relative to the requesting radio user) communication system to which to patch radio system <b>820</b>. Once the connection is created, the IVR may in one embodiment generate and send a vocalic or audible message notifying the user <b>824</b> that a patch has been created with radio system <b>840</b>. Although communication systems <b>820</b> and <b>840</b> are illustrated in <figref idref="DRAWINGS">FIG. 8</figref> as radio systems, those of ordinary skill in the art will realize that either or both systems could be a conventional or a trunked radio system and that either or both systems could be another type of communication system such as, for instance, a PSTN or cellular system.

0052<figref idref="DRAWINGS">FIG. 9</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 8</figref>, the difference being that in this embodiment the interoperability system is a particular implementation of a peer-to-peer interoperability system. Accordingly, <figref idref="DRAWINGS">FIG. 9</figref> illustrates a user <b>918</b> of a communication (e.g., radio) system <b>910</b> that desires to be connected using an interoperability system to another communication system (e.g., radio system <b>920</b>). Peer-to peer interoperability is enabled using a Radio Soft Switch <b>912</b> coupled to and ideally integrated within radio system <b>910</b> and a Radio Soft Switch <b>922</b> coupled to and ideally integrated within radio system <b>920</b>. Further illustrated for facilitating this embodiment of the present invention is an IVR device (e.g., server) <b>914</b> that is coupled to, and preferably integrated as part of, Radio Soft Switch <b>912</b> and an IVR device (e.g., server) <b>924</b> that is coupled to, and preferably integrated as part of, Radio Soft Switch <b>922</b>. Those of ordinary skill in the art will realize that in another embodiment one or more IVR devices could alternatively be included within a central server instead of being integrated within each Soft Switch.

0053In operation, the user <b>918</b> would send an audible signal to the Radio Soft Switch <b>912</b> indicating that the user desired to have radio system <b>910</b> connected (or patched) to another radio system (e.g., radio system <b>920</b>). Ideally, the user would press a PTT button on radio <b>916</b> and speak predefined words (e.g., “connect me”) into the radio. Alternatively, if the user <b>918</b> is coupled through a communication system such as, for instance, a PSTN system the user could generate predefined tones using the PSTN device. Ideally, for any radio system that does not have an active connection in the interoperability system (e.g., radio system <b>910</b>), the corresponding Radio Soft Switch would constantly direct incoming audible signals or calls from that radio system to the corresponding IVR server for monitoring these signals to detect a request to connect. Upon detecting that an audible signal from radio system <b>910</b> is a request to connect with radio system <b>920</b>, then Radio Soft Switch <b>912</b> would create the patch.

0054More specifically, upon detecting the request from radio system <b>910</b> to create a patch, ideally the IVR server <b>914</b> verifies the request for a connection, for example, by generating an audible or vocalic response to the user <b>918</b> (e.g., “please specify your request”) via Radio Soft Switch <b>912</b> and radio system <b>910</b> that the user hears from radio <b>916</b>. If the radio <b>916</b> supports simplex or half duplex operation then the user <b>918</b> must release the PTT button in order to hear the vocalic response. The user <b>918</b> could then vocalically or audibly verify the request for a patch by, for example, reiterating its request using the same or similar predefined words (e.g., “patch me to radio system <b>840</b>”). Upon receipt of the verification, the IVR server <b>914</b> ideally directs Radio Soft Switch <b>912</b> to create the connection between radio systems <b>910</b> and <b>920</b>, preferably using a digital message. Alternatively, instead of requesting to be connected to a particular communication system, Radio Soft Switch <b>912</b> or the IVR server <b>914</b> may be configured for searching for the nearest (relative to the requesting mobile user) communication system to which to patch radio system <b>910</b>. Once the connection (ideally an RFPDL connection) is created, the IVR server <b>914</b> may in one embodiment generate and send a vocalic or audible message notifying the user <b>918</b> that a patch has been created with radio system <b>920</b>. Although communication systems <b>910</b> and <b>920</b> are illustrated in <figref idref="DRAWINGS">FIG. 9</figref> as radio systems, those of ordinary skill in the art will realize that either or both systems could be a conventional or a trunked radio system and that either or both systems could be another type of communication system such as, for instance, a PSTN or cellular system.

0055<figref idref="DRAWINGS">FIG. 9</figref> also illustrates a Server <b>926</b> implementing a session layer protocol (e.g., a SIP Server) that is ideally included within the peer-to-peer interoperability system and coupled to Radio Soft Switches <b>912</b> and <b>922</b> to facilitate the connection between the Radio Soft Switches. Thus, each Soft Switch ideally runs a SIP-UA (User-Agent), and each Soft Switch ideally has a unique SIP URI (User Registration Identity). Accordingly, to establish the peer-to-peer connection between Radio Soft Switch <b>912</b> and Radio Soft Switch <b>922</b> using the SIP protocol, Radio Soft Switch <b>912</b> initiates a SIP Invite Request to the SIP Server <b>926</b>. The SIP Server <b>926</b> forwards this SIP Invite to Radio Soft Switch <b>922</b>. Upon accepting the SIP Invite, Radio Soft Switch <b>922</b> sends a <b>200</b> OK to the Radio Soft Switch <b>912</b> via the SIP Server <b>926</b>, and Radio Soft Switch <b>912</b> sends a return acknowledgement (ACK) to Radio Soft Switch <b>922</b>. Ideally, the ACK is communicated to the respective IVR Servers <b>914</b> and <b>924</b>, which could each in turn generate and send a message to the respective users of the radio systems via their radios (e.g., an audible message to user <b>918</b> via radio <b>916</b>) notifying the users that a patch has been created to the other radio system).

0056We next turn to a final embodiment of the present invention illustrated in <figref idref="DRAWINGS">FIGS. 10 and 11</figref>—methods for enabling a PSTN device to communicate with a communication system in an interoperability system. Communications between PSTN users and users of other communication systems, particularly radio system users, may suffer from conversational problems because the PSTN user is using a full-duplex communication device with no PTT button while the radio user is typically using a simplex or half-duplex communication device with a PTT button. The methods illustrated in the bounce diagrams of <figref idref="DRAWINGS">FIGS. 10 and 11</figref> facilitate communications (or calls) between PSTN users and users of other communications systems (e.g., radio system users) in an interoperability system.

0057<figref idref="DRAWINGS">FIG. 10</figref> illustrates a radio system <b>1020</b> and a PSTN device <b>1030</b> that are operatively connected via an interoperability system <b>1010</b>. Further shown is a user <b>1024</b> of a radio <b>1022</b> that is operatively coupled to radio system <b>1020</b>. Radio system <b>1020</b> may be, for instance, a trunked or a conventional radio system. In operation, when user <b>1024</b> is sending data (e.g., voice by pressing a PTT button and speaking into radio <b>1022</b>) to PSTN device <b>1030</b> via the interoperability network <b>1010</b>, a user of device <b>1030</b> could simply listen to user <b>1024</b>. When user <b>1024</b> stops speaking, upon detecting this using any suitable voice activity detection means known in the art such as, for instance, a voice band energy detector algorithm, the interoperability system <b>1010</b> would send a signal to the PSTN device <b>1030</b> to notify the user thereof that the call is still in progress but that user <b>1024</b> is not currently speaking. Ideally, the signal is an audible tone, which is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> as an “Idle” tone.

0058Upon receipt of the idle tone, the PSTN device user could begin talking and the interoperability system <b>1010</b> would key-up radio system <b>1020</b> so that user <b>1024</b> could hear the communications from the PSTN user. While the user of the PSTN device <b>1030</b> is talking, interoperability system ideally detects the user's voice using any suitable voice activity detection means known in the art and sends a signal to key up the radio system <b>1020</b> and sends another signal to the PSTN device <b>1030</b> to notify the user thereof that the call is still in progress and that the user is being heard by user <b>1024</b>. Ideally, the signal to the PSTN device is an audible tone, which is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> as an “OK” tone. When the PSTN user stops talking, the interoperability system ideally detects this and sends a signal to the radio system <b>1020</b> to key off the radio system and sends the idle tone to the PSTN device <b>1030</b> until either of the users begins talking again.

0059In one embodiment, the interoperability system <b>1010</b> could key-on radio system <b>1020</b> to receive the PSTN user's voice data (and key-off radio system <b>1020</b>) based upon the PSTN user's voice (or absence thereof) using any suitable voice activity detection means known in the art. In an alternative embodiment, the interoperability system <b>1010</b> could key-on radio system <b>1020</b> to receive the PSTN user's voice data (and key-off radio system <b>1020</b>) based upon a signal from the PSTN device <b>1030</b> such as, for instance, a Dual Tone Multi-Frequency (DTMF) signal or tone that may be generated by the user pressing one or more predetermined buttons on the PSTN device <b>1030</b>. The resulting signaling from interoperability system <b>1010</b> to radio system <b>1020</b> to key-on the radio system is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> as a PTT Press and a PTT and Voice signals. The resulting signaling from interoperability system <b>1010</b> to radio system <b>1020</b> to key-off the radio system is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> as a PTT Release signal.

0060<figref idref="DRAWINGS">FIG. 11</figref> is a bounce diagram illustrating an embodiment of the present invention that is similar to the embodiment illustrated by the bounce diagram in <figref idref="DRAWINGS">FIG. 10</figref>, the difference being that in this embodiment the interoperability system is a particular implementation of a peer-to-peer interoperability system. Accordingly, <figref idref="DRAWINGS">FIG. 11</figref> illustrates a radio system <b>1110</b> and a PSTN device <b>1122</b> that are operatively connected via a peer-to-peer interoperability system that includes a Radio Soft Switch <b>1112</b> that is coupled to and ideally integrated within radio system <b>1110</b>. Further shown is a user <b>1116</b> of a radio <b>1114</b> that is operatively coupled to radio system <b>1110</b> and a PSTN Gateway coupled to the PSTN device <b>1122</b> and to the Radio Soft Switch <b>1112</b> (ideally over an IP network) for facilitating this embodiment. The method illustrated by the bounce diagram or <figref idref="DRAWINGS">FIG. 11</figref> is essentially identical to the method illustrated by the bounce diagram of <figref idref="DRAWINGS">FIG. 10</figref> except that the Soft Switch <b>1112</b> performs the functionality of interoperability system <b>1010</b>, and the PSTN Gateway <b>1120</b> servers as an IP interface between the PSTN device <b>1122</b> and the Radio Soft Switch <b>1112</b> using a suitable standard IP-based protocol such as, for instance, voice over IP (VoIP).

0061While the invention has been described in conjunction with specific embodiments thereof, additional advantages and modifications will readily occur to those skilled in the art. The invention, in its broader aspects, is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described. Various alterations, modifications and variations will be apparent to those skilled in the art in light of the foregoing description. Thus, it should be understood that the invention is not limited by the foregoing description, but embraces all such alterations, modifications and variations in accordance with the spirit and scope of the appended claims.