Method and apparatus for efficient and deterministic group alerting

0001This application claims the benefit of U.S. provisional application Ser. No. 60/636,094, filed Dec. 16, 2004.

BACKGROUND OF THE INVENTION

0002The ability to alert and mobilize first responders is central to the readiness of any public safety agency. In the aftermath of recent major public safety events, including natural and man-made disasters, the public safety community has thoroughly examined all aspects of wireless interoperable voice communications. However, first responder alerting has remained largely unexamined for over a decade, and in communities relying on volunteer first responders, the critical importance of first responder alerting rivals that of interoperable voice communications.

0003Shortcomings with current alerting technologies are well documented in the public record. One analysis of communication failure during periods of profound crisis, the <i>Arlington County After</i>-<i>Action Report on the Response to the September </i>11 <i>Terrorist attack on the Pentagon </i>available from Arlington County, Virginia, notes failures in all forms of communications, from initial alerting to tactical voice communication. As stated in this report, during the events of Sep. 11, 2001, radio channels became oversaturated, and interoperability problems among jurisdictions and agencies persisted throughout the entire response process. Otherwise compatible portable radios were preprogrammed in a manner that precluded interoperability. Cellular telephone systems and even the public switched telephone network (PSTN) became congested and unusable.

0004This report cited traditional, 1-way paging systems as the most reliable method of alerting and notification. However, the lack of a paging response channel left responders relying on other, less reliable forms of communication to escalate, reply to, or even confirm receipt of their instructions. These problems with cellular telephone networks and the PSTN limited the overall effectiveness of 1-way paging as an alerting system. This created serious operational challenges during the Sep. 11, 2001 series of events, and they will create similar problems in any such future events.

0005Even during day-to-day public safety activity, these alerting system limitations are problematic. In most cases, when volunteer groups are alerted by pager, incident commanders do not know who will actually respond until personnel begin to arrive on scene. This delay postpones decisions regarding escalation and mutual aid, letting critical time slip by before commanders can identify and correct problems with the response. This time period can define the success or failure of the response process, presenting a critical need for simple, inexpensive, pager-type devices that can reply to group messages.

0006However, public safety agencies still rely on 25-year old, 1-way paging technology as their core alerting solution. Many newer technologies are available, but for alerting, for a variety of reasons, these technologies do not provide a meaningful improvement over 1-way paging. Existing mobile data systems are too expensive and too bulky for continual personal use. Digital and analog 2-way voice systems are similarly impractical for widespread, continuous deployment to volunteer forces. Several contemporary PCS technologies have integrated voice, data, and paging, but their complete dependence on commercial networks runs counter to commonly accepted reliability standards (e.g., NFPA-1221). Private broadband solutions (such as IEEE 802.11 and 802.16) provide high-capacity data capabilities, but they lack the coverage, portability, and resilience required for wide-area alerting of large volunteer forces. Contemporary 2-way paging systems perhaps come closest to meeting the alerting needs of public safety agencies. Like 1-way systems, these pagers are small, inexpensive devices that operate for long periods on battery power. However, these systems have no ability to acknowledge group messages.

0007More importantly, beyond the limitations described above, none of these systems provide a network interface sufficient to support acknowledged group messaging. Requiring that the message originator individually alert each recipient adds considerable setup delay when alerting large groups. This delay is eliminated when using network-supported call group or common address messages, but the message originator must have prior knowledge of group membership. If a message originator does not know the membership of the paged group, there is no context to know whether enough manpower is responding, or whether key individuals have been mobilized. Manually maintaining accurate group membership rosters between networks and message originators would be impractical since this is time consuming, difficult, and prone to errors. For a communications system to provide usable, acknowledged group alerting capabilities to public safety agencies, the network interface must provide group membership details when the group message is sent. Even if the mobile devices were capable of acknowledging group messages, current systems do not provide message originators this membership information regarding the alerted group. Simply guaranteeing that a message will be eventually delivered to all recipients is insufficient for public safety alerting applications. The message originator (dispatcher, incident commander, etc.) needs immediate feedback as to who has been alerted and how they have replied, as well as information concerning those who cannot be reached.

0008A need therefore exists for a 2-way paging system that could be improved with group message acknowledgement and a suitable system interface. Such a system would address the current shortcomings of public safety alerting systems, and could also provide other benefits. For instance, it could act as an improved personnel accountability system (PAS) for on-scene communications. Incident commanders could instantly notify responders of imminent threats, such as impending chemical release or structure failure, and verify receipt by all personnel. Responses could be expanded to include location information and health or equipment status information. Such systems, made practical because of the high performance and low cost of 2-way pagers, would both obviate traditional problems with interoperable on-scene communications and enable central oversight of critical real-time safety data.

0009While public safety's need for a system capable of acknowledged group alerting system is clear and well documented in the public record, no such system yet exists but for the present invention described herein.

SUMMARY OF THE INVENTION

0010The above-described deficiencies in the prior art are overcome and a number of advantages are realized by the present invention. In accordance with an aspect of the present invention, a method of efficient and deterministic alerting of a group of recipients over a wireless network is provided. Each recipient comprises a mobile device capable of transmitting and receiving data. The method comprises the steps of: storing for each recipient an assigned primary identifying address and one or more group addresses that are shared with selected ones of the other recipients; receiving a communication from a network client requesting wireless transmission of a message to recipients sharing a selected one of the group addresses; transmitting a communication to the network client comprising group information relating to the selected group addresses, the group information comprising at least one of the number of the recipients having the selected group address and the identifying addresses of the recipients having the selected group address; broadcasting the message to the selected group address via a wireless network; receiving acknowledgment responses from the recipients sharing the selected group address via the wireless network; and providing the acknowledgment responses to the network client.

0011In accordance with another aspect of the present invention, an apparatus for efficient- and deterministic alerting of a group of recipients over a wireless network is provided. Each recipient comprises a mobile device capable of transmitting and receiving data. The apparatus comprises: at least one of a memory device and an interface to an external memory device for storing for each recipient an assigned primary identifying address and one or more group addresses that are shared with selected ones of the other recipients; a network client interface for receiving a communication from a network client requesting wireless transmission of a message to recipients sharing a selected one of the group addresses; a wireless communication network interface for communicating with the recipients via a wireless communication network; and a processing device connected to the memory device, the network client interface and the wireless communication network interface, the processing device being programmed to transmit a communication to the network client comprising group information relating to the selected group addresses, the group information comprising at least one of the number of the recipients having the selected group address and the identifying addresses of the recipients having the selected group address, broadcast the message to the selected group address via the wireless communication network and the wireless communication network interface, receive acknowledgment responses from the recipients sharing the selected group address via the wireless communication network, and provide the acknowledgment responses to the network client.

0012In accordance with yet another aspect of the present invention, a mobile device for efficient and deterministic alerting of a group of recipients over a wireless network is provided. Each recipient comprises a mobile device capable of transmitting and receiving data. The mobile device comprises: a memory device for storing an assigned primary identifying address for its corresponding recipient and one or more group addresses that are shared with selected ones of the other recipients; a wireless communication network interface for communicating with a switch via a wireless communication network to receive messages therefore and to transmit responses to the switch; and a processing device connected to the memory device and the wireless communication network interface, the processing device being programmed to receive a message broadcast by the switch to a selected group address via the wireless communication network, to determine if it shares the selected group address, and to transmit an acknowledgment response to the switch via the wireless communication network if it shares the selected group address.

BRIEF DESCRIPTION OF THE DRAWINGS

0013The present invention can be further understood with reference to the following description and the appended drawings, wherein like elements are provided with the same reference numerals:

0014<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0015<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of a database used in a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0016<figref idref="DRAWINGS">FIG. 3</figref> is an isometric view of a switch or server used in a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0017<figref idref="DRAWINGS">FIG. 4</figref> is a diagram of communication between a client and a server used in a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0018<figref idref="DRAWINGS">FIG. 5</figref> is a diagram of a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0019<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram of a group alerting system constructed in accordance with an exemplary embodiment of the present invention;

0020<figref idref="DRAWINGS">FIG. 7</figref> is a flow chart illustrating a sequence of operations for broadcasting a group message and group message acknowledgment in accordance with an exemplary embodiment of the present invention;

0021<figref idref="DRAWINGS">FIG. 8</figref> is a flow chart illustrating a sequence of operations for receiving, acknowledging and processing group message at a mobile receiver in accordance with an exemplary embodiment of the present invention; and

0022<figref idref="DRAWINGS">FIGS. 9A, 9B</figref> and <b>10</b> are views of mobile receivers constructed in accordance with exemplary embodiments of the present invention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

0023Overview

0024In accordance with the present invention, a system and method are provided for reliable, wireless group alerting in a system that comprises a database, switch, wireless network, and a plurality of intelligent mobile receivers, and employs a modified two-way paging protocol based on group messaging capability of the Motorola ReFLEX™ protocol and a novel ALOHA command for multicast acknowledgement (ACK) from mobile receivers. An encrypted message is broadcast to a group address. This message is received by a number of mobile receivers, each of which then acknowledges back to the system, decrypts the message, displays it to the user, and allows the user to respond, if they belong to the group address. The system employs centralized management to simplify the role of the mobile users and administrators, minimizing configuration and operational human errors that would otherwise result in confusion or lost messages. It also employs novel mechanisms to compress the responses from the receivers to use minimal airtime. The system is particularly relevant to public safety and critical infrastructure operators, where large group dispatches must be delivered quickly and deterministically to a heavily distracted mobile workforce, and their responses must be delivered to the dispatch center efficiently. As such, this system provides a comprehensive, meaningful solution to support distracted users with simple, resilient group messaging. It is to be understood that, while an exemplary embodiment is described herein that uses paging technology, the present invention can also be implemented using a cellular system, a wireless local area network or more specifically WiFi, or other wireless communication technology.

0025In accordance with an exemplary embodiment of the present invention, a system for group alerting employs a SPARKGAP™ network which utilizes a modified version of a protocol called ReFLEX™ developed by Motorola, Inc. for two-way paging and Narrowband PCS (NPCS). This system uses a 12.5 KHz channel pair operating in the 900 MHz band. It is to be understood, however, that the group messaging of the present invention can be implemented using other types of protocols and network devices.

0026In accordance with an aspect of the present invention, a SPARKGAP™ Dispatch Protocol (SDP) is provided as a streamlined means for a computer aided dispatch (CAD) system to communicate with two-way pagers on a SPARKGAP™ ReFLEX™ network. SPARKGAP™ is a ReFLEX™ network solution designed to control one or more base stations and provide two-way paging and mobile data coverage over an arbitrary geographical area. While this solution is similar in some ways to traditional one-way paging, two-way paging also differs significantly from its one-way counterpart. Two-way pagers acknowledge and reply to messages they receive, and they can originate their own messages. These additional capabilities outperform traditional paging input protocols (e.g., SNPP, TAP and TNPP). In addition, while more suitable second generation paging protocols exist (e.g., SMTP, SMPP, and WCTP), these newer protocols do not expose group membership information necessary for effective, acknowledged group messaging.

0027The SDP of the present invention is a transactional, TCP/IP protocol where the CAD system is the client and the SPARKGAP™ is the server. It features synchronous, client-initiated request/response transactions as well as asynchronous server-driven events, minimizing latency and complexity and delivering a rational solution to the public safety space.

0028A Dispatch/Response Layer (DRL) is also provided in accordance with the present invention as a layer above the ReFLEX™ Air Protocol to support group messaging. The SDP and DRL are analogized as book ends in that they operate on either side of the ReFLEX™ network.

0029ReFLEX™ supports personal and information service (IS) messages. Personal messages involve a single recipient, and ReFLEX™ enables the receiving pager to acknowledge reception, notify that the user has read the message, and relay multiple-choice responses from the user. IS messages involve an arbitrary group of recipients sharing common group addresses called IS addresses. ReFLEX pagers can be configured with one personal address and multiple IS addresses. IS messages are strictly one-way and ReFLEX™ does not support any response or acknowledgement from the recipient group. The present invention, however, adds message acknowledgement, message read notification, and multiple-choice response capability to IS messages, creating an infrastructure for reliable multicast messaging within the ReFLEX™ protocol. As described further below, the present invention implements two significant changes to conventional 2-way paging. First, it defines a new ALOHA command (‘Multicast ACK Command’) used by a pager to reply to an IS message. Second, it defines a flag to select which devices are allowed to use this feature.

0030System Description

0031A system <b>10</b> configured in accordance with an exemplary embodiment of the present invention is depicted in <figref idref="DRAWINGS">FIG. 1</figref>. With reference to <figref idref="DRAWINGS">FIG. 1</figref>, a central switching system (hereinafter referred to generally as ‘Switch’) <b>12</b> connects to a Wireless Network <b>14</b> and communicates with a number of subscriber devices (hereinafter referred to generally as ‘Receivers’) <b>16</b> such as pagers, cell phones, or wireless personal data assistants (PDAs), or portable computer running WiFi. Each Receiver is assigned one identifying Primary Address and one or more multiple Group Addresses, and is capable of receiving broadcast alert messages directed to any of its addresses. The Switch <b>12</b> comprises a Receiver Database <b>18</b> comprising stored information describing receivers, their group membership, and connects to a Wireless Network <b>14</b> such as a PCS network employing cell broadcast, a paging network, or a broadcast-capable data network employing group addressing.

0032With reference to <figref idref="DRAWINGS">FIG. 2</figref>, the Receiver Database <b>18</b> comprises an independent table of Receivers <b>22</b> and an independent table of Groups <b>24</b>. Each Receiver row in table <b>22</b> contains an identifying personal address, as well as other information specific to a single device <b>16</b> and its Wireless Network architecture. Each Group row in table <b>24</b> contains an identifying group address, an encryption key, and a symbolic name. A dependent table of Membership <b>26</b> provides the many-to-many relationship between Receiver and Group rows. Each Membership row assigns one receiver to one group. Membership rows contain GroupAddress and PersonalAddress columns, identifying a Group and Receiver row, respectively. Each Membership row also contains a ReceiverGroupNumber column, a small mnemonic value that uniquely identifies the Group from other Groups programmed into the same Receiver, and CC (‘carbon copy’) flag to define specific behavioral aspects of the Receiver. Receivers do not respond to messages received by group addresses if their CC flag is set, while they can respond to messages received by group addresses if their CC flag is clear. This mechanism allows users to monitor alerts to specific groups, without expectation by the source of the alerts for a response.

0033As administrative changes occur to the Receiver Database <b>18</b>, configuration transactions are executed over the air with individual Receivers <b>16</b> to synchronize their configuration memory with the corresponding data in the Receiver Database <b>18</b>. The system <b>10</b> therefore maintains an up-to-date image in the configuration memory of each Receiver <b>16</b>, including a list of Group addresses, their ReceiverGroupNumber values, their symbolic names, encryption keys, and CC flags.

0034With reference to the flow charts in <figref idref="DRAWINGS">FIGS. 7 and 8</figref>, a ‘Client’ (e.g., a computer-aided dispatch center, a human user, or other network client <b>20</b>) uses this system <b>10</b> to broadcast alert messages to groups of Receivers <b>16</b>. To do so, the client <b>20</b> composes a message, preferably including display content and a list of response strings. The Client <b>20</b> then connects to the Switch <b>12</b> and requests transmission of the message to a particular group name (block <b>50</b>). Depending on the architecture of the Wireless Network <b>14</b>, either the Client <b>20</b> or the Wireless Network <b>14</b> assigns an identifying field to the message such that user responses can be associated with the correct message.

0035Upon receipt of the message, the Switch <b>12</b> responds to the Client <b>20</b> with detailed information on the group such as a list or a count of group members (block <b>52</b>). It then encrypts the Group Message, assigns a cyclical message sequence number, and transmits the message to the Group Address (block <b>54</b>). As described in more detail below in connection with the SPARKGAP™ dispatch protocol (SDP), the Switch <b>12</b> receives group message acknowledgment responses from the receivers <b>16</b> (block <b>56</b>) that are associated with the broadcast group message (block <b>58</b>) and provided to the Client <b>20</b> (block <b>60</b>). Similarly, other types of responses generated as a result of the group message are associated with the broadcast group message (block <b>62</b>) and provided to the Client <b>20</b> (block <b>64</b>).

0036Upon receiving the Group Message (block <b>80</b>), the Receivers <b>16</b> decrypt the message and display the content, group name, and multiple choice options to the user. Receivers employing paging technology that are not addressed in the group do not receive the message. Alternatively, a system <b>10</b> employing cellular broadcast of the message can receive but ignore the message if it is not in the addressed group (block <b>82</b>). Each Receiver <b>16</b> with a CC flag of false transmits one or more acknowledgement codes through the Network <b>14</b> back to the Switch <b>12</b>, specifying message received, message read notifications, and enumerated multiple-choice responses (block <b>84</b>, <b>88</b> and <b>90</b>). The datagram carrying the acknowledgement code also includes the personal address of the receiver <b>16</b>, the ReceiverGroupNumber of the group address, and the message sequence number of the message, which together efficiently and uniquely identify the specific group message at the specific Receiver <b>16</b>. Each Receiver <b>16</b> in the group with a CC flag of true does not transmit an acknowledgment reply to the Switch <b>12</b> but rather merely displays the group message (blocks <b>84</b> and <b>86</b>).

0037Each receiver <b>16</b> provides a configuration display for the user. This display allows the user to specify, by group name, how notification should occur for messages received by each group address. Similarly, the Switch provides an administrative human interface that allows a system administrator to set up and maintain the Receivers <b>16</b> belonging to each Group.

0038An Exemplary Computer Aided Dispatch (CAD) System

0039The foregoing system description discusses the high-level organization and data flow of an exemplary group messaging system <b>10</b> that can use any of a variety of network types. With reference to <figref idref="DRAWINGS">FIGS. 3, 4</figref> and <b>5</b>, the following is a description of an exemplary type of network, that is, a ReFLEX™ two-way paging network that incorporates the new group messaging layer of the present invention. <figref idref="DRAWINGS">FIG. 3</figref> is a SPARKGAP™ network controller <b>12</b>′ which is configured to implement group messaging in accordance with an exemplary embodiment of the present invention. <figref idref="DRAWINGS">FIG. 4</figref> illustrates the use of a SPARKGAP™ network controller or server <b>12</b>′ in a system configuration <b>10</b>′ similar to <figref idref="DRAWINGS">FIG. 1</figref>. <figref idref="DRAWINGS">FIG. 5</figref> illustrates another system configuration <b>10</b>″ in accordance with another exemplary embodiment of the present invention.

0040The SPARKGAP™ network controller or server <b>12</b>′ in <figref idref="DRAWINGS">FIG. 3</figref> provides private two-way paging, mobile data, and wireless email over inexpensive channel pairs in the 900 MHz Enhanced Specialized Mobile Radio (ESMR) band or the Narrowband Personal Communication Services (N-PCS) band. Coverage can be configured for a single building, multiple counties, or state-wide service, for example, supporting small user devices such as pagers and personal data assistants (PDAs) with Motorola's proprietary ReFLEX™ protocol. Since the SPARKGAP™ server provides encrypted acknowledgement paging, responders reply immediately to CAD events and other messages directly from their pagers, and Advanced Encryption Standard (AES) encryption protects all transmissions. Since the SPARKGAP™ server <b>12</b>′ supports mobile applications, law enforcement officers can use PDAs as receivers <b>16</b> to connect wirelessly with municipal, state, and federal databases to run license checks, warrants, and other mobile applications. Further, the SPARKGAP™ server is useful for automatic vehicle location. Small, inexpensive GPS sending units can be used as receivers <b>16</b> to monitor vehicles and heavy equipment, sending real-time location and status information on a 24 hour per day, 7 day per week basis. The SPARKGAP™ server <b>12</b>′ can also support wireless e-mail. Users can send and receive secure, wireless email using pagers and PDAs.

0041The SPARKGAP™ server <b>12</b>′ can support one base station <b>15</b> or hundreds of base stations <b>15</b> in a network <b>14</b>′, each consisting of a standard 900 MHz paging transmitter and ReFLEX™ base receiver as shown in <figref idref="DRAWINGS">FIG. 5</figref>. A single station covers a 7-20 mile radius, and a network <b>14</b>′ can coordinate multiple stations using simulcast or cellular arrangements to optimize coverage and capacity. A single channel pair can serve thousands of users, and multiple channels can be aggregated for additional capacity. Even under worst-case peak conditions, the ReFLEX™ protocol uses centralized arbitration to prevent contention and channel overloading.

0042In accordance with an exemplary embodiment of the present invention, the SPARKGAP™ server <b>12</b>′ maintains a full packet data layer on top of paging, which is one of the most robust and most reliable communication technologies available, and leverages this foundation into a balanced set of features, coverage, and capacity. The SPARKGAP™ server <b>12</b>′ connects directly to computer-aided dispatch (CAD) systems, provides low latency messaging with virtually unbreakable security, and operates with the lowest cost-per-user and cost-per-coverage-area of any wireless data solution available. For additional resilience, redundant hot standby units maintain network operation even under catastrophic circumstances, keeping first responders connected when they are needed most.

0043As stated previously, the SPARKGAP™ protocol and associated server <b>12</b>′ provide a ReFLEX™ network solution designed to control one or more base stations <b>15</b> and provide two-way paging and mobile data coverage with user devices <b>16</b> over an arbitrary geographical area. While this solution is similar in some ways to traditional one-way paging, two-way paging also differs significantly from its one-way counterpart. Two-way pagers acknowledge and reply to messages they receive, and they can originate their own messages. These additional capabilities outperform traditional paging input protocols (e.g., SNPP, TAP and TNPP). In addition, while more suitable second generation paging protocols exist (e.g., SMTP, SMPP, and WCTP), these newer protocols do not expose group membership information necessary for effective, acknowledged group messaging.

0044Client <b>20</b>/Server <b>12</b> Protocol

0045In accordance with an aspect of the present invention, a SPARKGAP™ Dispatch Protocol (SDP) is provided as a streamlined means for a computer aided dispatch (CAD) system <b>20</b>′ to communicate with two-way pagers <b>16</b> in, for example, a SPARKGAP™ ReFLEX™ network <b>14</b>′. It is to be understood, however, that the group messaging of the present invention can be implemented using other types of protocols and network devices. The SDP of the present invention is a transactional, TCP/IP protocol where the CAD system is the client <b>20</b>′ and the SPARKGAP™ network controller <b>12</b>′ is the server. It features synchronous, client-initiated request/response transactions, as well as asynchronous server-driven events, to minimize latency and complexity and deliver a rational solution to the afore-mentioned issues relating to public safety and rapid response and communication. With reference to <figref idref="DRAWINGS">FIG. 6</figref>, the server or switch <b>12</b> or <b>12</b>′ comprises a memory device <b>32</b> and processor <b>34</b>, which can be programmed to implement the SDP, as well as an interface <b>30</b> to the network <b>14</b> or <b>14</b>′.

0046With further reference to <figref idref="DRAWINGS">FIG. 4</figref>, when employing SDP, the CAD system or client <b>20</b>′ connects to the SPARKGAP™ server <b>12</b>′ using TCP/IP on port 55000. The CAD system or client <b>20</b>′ initiates transactions with the SPARKGAP™ server <b>12</b>′ using a synchronous request/response model, that is, the CAD system <b>10</b>′ sends the SPARKGAP™ server <b>12</b>′ a request from a client <b>20</b>′, the SPARKGAP™ sever <b>12</b>′ takes an action, and then the SPARKGAP™ server <b>12</b>′ sends the CAD system client <b>20</b>′ a response. Additionally, in order to minimize latency in delivering responses from the pagers, the SPARKGAP™ server <b>12</b>′ also sends asynchronous event notifications to the CAD system client <b>20</b>′ regarding message progress and responses from individual pagers.

0047The SDP will now be described in further detail. A description of protocol data units, transactions and events follows.

00481. SDP Protocol Data Units

0049SDP requests, responses, and events are implemented as atomic protocol data units (PDUs) transmitted by the client <b>20</b> or <b>20</b>′ and server <b>12</b> or <b>12</b>′ using preferably a TCP/IP network. PDUs are serialized, and preferably always transmitted contiguously in their entirety. In other words, a node preferably never interrupts a partially transmitted PDU to begin another PDU. A PDU is preferably encoded using ASCII plain text, and consists of an identifying header followed by a collection of name/value attributes enclosed, as shown below, in curly brackets (braces).

00501.1 Syntax

0051PDUs are preferably encoded using ASCII plain text according to the following specification:

0052Client-to-server transmission syntax:

0053“request”<request-number><request-type>“{”<attribute-list>“}”

0054Server-to-client transmission syntax:

0055“event”<event-type>“{”<attribute-list>“}”

0056“response”<request-number>“{” attribute-list “}”

0057where, <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="133PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><request-number></entry><entry>: := <integer></entry></row><row><entry /><entry><request-type></entry><entry>::= token</entry></row><row><entry /><entry><event-type></entry><entry>: : token</entry></row><row><entry /><entry><attribute-list></entry><entry>: : <attribute> [<attribute-list I</entry></row><row><entry /><entry><attribute></entry><entry>: := attribute-name “” attribute-value “;”</entry></row><row><entry /><entry><attribute-name></entry><entry>: : token</entry></row><row><entry /><entry><attribute-value></entry><entry>: := <integer> <string></entry></row><row><entry /><entry><integer></entry><entry>: := Base 10 Integer Expression</entry></row><row><entry /><entry><string></entry><entry>: : string enclosed in double quotes</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0058An example PDU exchange is illustrated as follows: <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>request 5066 SendMessage</entry><entry /></row><row><entry>{</entry></row><row><entry>CadEventID=“#CTYF041820772”;</entry></row><row><entry>MessageID=“2004”;</entry></row><row><entry>DestinationID=Fire1;</entry></row><row><entry>Display=“Calling All Cars”;</entry></row><row><entry>AlertResponse=0;</entry></row><row><entry>ReadResponse=1;</entry></row><row><entry>MCR=“On My Way”;</entry></row><row><entry>MCR=“Busy”;</entry></row><row><entry>MCR=“On Scene”;</entry></row><row><entry>}</entry></row><row><entry /><entry>Response 5066</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>ResultCode=0;</entry></row><row><entry /><entry>ResultText=“Message Queued”;</entry></row><row><entry /><entry>};</entry></row><row><entry /><entry>Event PagerResponse</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>Timestamp=“07082004130553EST”;</entry></row><row><entry /><entry>MessageID=“2004”;</entry></row><row><entry /><entry>CadEventID=“#CTYF041820772”;</entry></row><row><entry /><entry>PagerID=“229030020”;</entry></row><row><entry /><entry>PagerName=“Doe, John”;</entry></row><row><entry /><entry>MessageRead=1;</entry></row><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

00591.2 Attribute Value Types

0060The SDP of the present invention preferably supports two attribute types, with string or integer values. Integer values are simply unsigned integers with no more than 32 significant bits, described using base-10 notation. Strings are simply printable ASCII strings contained in double quotes, and supporting the following escape sequences: <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>\n</entry><entry>New Line</entry></row><row><entry /><entry>\r</entry><entry>Carriage Return</entry></row><row><entry /><entry>\″</entry><entry>Double Quote</entry></row><row><entry /><entry>\\</entry><entry>Backslash</entry></row><row><entry /><entry>\###</entry><entry>An octal value</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

00611.3 The Timestamp Attribute

0062All events contain a timestamp attribute marking the creation of the event. A timestamp value contains a string in a specific format: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0063"> MMDDYYYYHHMMSST </li></ul></li></ul>

0064Where <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>MM</entry><entry>is the 2-digit month (1-12)</entry></row><row><entry /><entry>DD</entry><entry>is the 2-digit day of the month (1-31)</entry></row><row><entry /><entry>YYYY</entry><entry>is the 4-digit year</entry></row><row><entry /><entry>HH</entry><entry>is the 2 digit hour (0-23)</entry></row><row><entry /><entry>MM</entry><entry>is the 2 digit minute (0-59)</entry></row><row><entry /><entry>SS</entry><entry>is the 2 digit second (0-59)</entry></row><row><entry /><entry>T</entry><entry>is the 1-4 character time zone abbreviation</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

00651.4 Attribute Order

0066In some cases, attribute order is significant. For illustrative purposes, receiving nodes are expected to read and decode attributes from first to last in the PDU.

00672. Transactions

0068A transaction is exchanged on the network as a request from the client, some action by the server, and a response from the server. The SDP preferably includes three transactions described below: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0069"> Login </li><li id="ul0004-0002" num="0070"> SendMessage </li><li id="ul0004-0003" num="0071"> QueryMessage </li></ul></li></ul>

00722.1 Login

0073The Login transaction establishes the identity of the CAD client <b>20</b> or <b>20</b>′ for purposes of reconnection. Should a TCP/IP connection be terminated, the SPARKGAP™ sever <b>12</b>′ will queue events awaiting a reconnection.

00742.1.1 Request

0075The request PDU contains the following attributes:

0076User (string, mandatory): This value contains the name or identity of the CAD system client <b>20</b> or <b>20</b>′, which preferably must match an entry in a SPARKGAP™ CAD account database in the database <b>18</b>.

0077Password (string, optional): This value contains the access password for the CAD system client <b>20</b> or <b>20</b>′. If the CAD account is set up without a password, then this attribute is not required.

0078Version (integer, mandatory): This value specifies the protocol version that the CAD system client <b>20</b> or <b>20</b>′ is requesting for this session. The version is conveyed as the major number multiplied by 100 and added to the minor number. For illustrative purposes, this attribute value is 100.

00792.1.2 Response

0080The response PDU contains the following attributes:

0081ResultCode (integer, mandatory): This value contains the result code of the transaction.

0082ResultText (string, optional): This value contains a human readable message string describing the result of the transaction.

0083Version (integer, mandatory): This value specifies the protocol version that the SPARKGAP™ sever <b>12</b>′ is supporting for this session. The version is conveyed as the major number multiplied by 100 and added to the minor number. For illustrative purposes, this attribute value is 100.

0084System (string, optional): This value contains an identifying description of the SPARKGAP™-based system <b>10</b>′.

00852.1.3 Example

0086This example illustrates a CAD system client <b>20</b> or <b>20</b>′ logging into a SPARKGAP™ server <b>12</b>′ as user “ECD911,” requesting version 1.0 of the protocol. The SPARKGAP™ server <b>12</b>′ grants the login and acknowledges version 1.0 support. <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>request 5066 login</entry><entry /></row><row><entry /><entry>{</entry></row><row><entry /><entry>User=“ECD911”;</entry></row><row><entry /><entry>Password=“GHTy778”;</entry></row><row><entry /><entry>Version=100;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry /><entry>Response 5066</entry></row><row><entry /><entry /><entry>{</entry></row><row><entry /><entry /><entry>ResultCode=0;</entry></row><row><entry /><entry /><entry>Version=100;</entry></row><row><entry /><entry /><entry>ResultText=“Connection</entry></row><row><entry /><entry /><entry>Complete”;</entry></row><row><entry /><entry /><entry>System=“Sparkgap ESN 04000022”;</entry></row><row><entry /><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

00872.2 SendMessage

0088The SendMessage transaction queues a message for delivery for one or more pager recipients <b>16</b>. The transaction only queues the message for processing. As the message is processed and responses are received, a sequence of events will convey the results back to the CAD system <b>10</b>′.

00892.2.1 Request

0090The request PDU contains the following attributes

0091MessageID (string, mandatory): This value uniquely identifies the message from the client (CAD) <b>20</b> or <b>20</b>′ perspective. An identical MessageID attribute will be included in all subsequent events related to this message.

0092CadEventID (string, optional): This value uniquely identifies the precipitating CAD event. If present, an identical CadEventID attribute will be included in all subsequent events related to this message.

0093DestinationID (string, mandatory): This value specifies the target audience for the message. The DestinationID corresponds to the name of a group of pagers or an individual pager in the SPARKGAP™ database. The PDU may contain multiple DestinationID attributes, in which case the message will be directed to an aggregated group representing the net total of all recipients.

0094GroupDetail (integer, optional): This value conveys the client's desire to receive detailed information about group recipients in the transaction response. If this field is present and set to a non-zero value, then the response will include a PagerID and PagerName attribute for each constituent number of the group. If the GroupDetail attribute is not present or set to zero, then this information will not be included in the response.

0095Display (string, mandatory): This value contains the actual display message to be read by message recipients. Multiple Display attributes are arranged in the order they appear into a single unbroken message.

0096AlertResponse (integer, mandatory): If present and set to a non-zero value, this value instructs the SPARKGAP™ server <b>12</b>′ to notify the CAD client <b>20</b>′ as pagers <b>16</b> receive the message and alert their users.

0097ReadResponse (integer, optional): If present and set to a non-zero value, this value instructs the SPARKGAP™ server <b>12</b>′ to notify the CAD client <b>20</b>′ as users display the message on their pager.

0098MCR (string, optional): If present, MCR attributes specify “multiple-choice responses” to be presented to the user as reply options. Multiple MCR attributes may be included in the request. The first MCR encountered is number 0, the second is number 1, and so on. As users reply to the message, the SPARKGAP™ server <b>12</b>′ will relay appropriate PagerReply events to the CAD client <b>20</b>′.

00992.2.2 Response

0100The response PDU contains the following attributes:

0101ResultCode (Integer, mandatory): This value contains the result code of the transaction.

0102ResultText (string, optional): This value contains a human readable message string describing the result of the transaction.

0103GroupSize: This value specifies the total number or recipient members in the group.

0104PagerID (String, mandatory): This value contains the identification of one pager in the aggregate destination group. The presence of this attribute signifies that a corresponding PagerName attribute will follow. Together, these two fields are duplicated for each member of the total pager destination group.

0105PagerName (string, optional): The value contains the name of the pager user corresponding to the last PagerID value.

01062.2.3 Example

0107This example illustrates a CAD system or client <b>20</b>′ sending the message “Calling all cars” to two dispatch groups, Fire<b>1</b> and Fire<b>34</b>. The CAD system client <b>20</b> requests notification from each pager <b>16</b> when the users read the messages, but not when the pagers alert. The request includes a CadEventID and a MessageID so that the CAD system can properly categorize forthcoming events related to this message. The SPARKGAP™ server <b>12</b>′ queues the message and returns a successful result code in the response. <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>request 5066 sendmessage</entry><entry /></row><row><entry>{</entry></row><row><entry>CadEventID=“#CTYF041820772”;</entry></row><row><entry>MessageID=“2004”;</entry></row><row><entry>DestinationID=“Fire1”;</entry></row><row><entry>DestinationID=“Fire34”;</entry></row><row><entry>GroupDetail=1;</entry></row><row><entry>Display=“Calling All Cars”;</entry></row><row><entry>AlertResponse=0;</entry></row><row><entry>ReadResponse=1;</entry></row><row><entry>MCR=“On My Way”;</entry></row><row><entry>MCR=“Busy”;</entry></row><row><entry>MCR=“Already On Scene”;</entry></row><row><entry>}</entry></row><row><entry /><entry>Response 5066</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry>ResultCode=0;</entry></row><row><entry /><entry>ResultText=“Message Queued”;</entry></row><row><entry /><entry>GroupSize=892;</entry></row><row><entry /><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01082.3 QueryMessage

0109The CAD client <b>20</b>′ initiates a QueryMessage transaction to discover present status of a previously sent message. The transaction response provides details about the message status as well as the status of all message recipients.

01102.3.1 Request

0111MessageID (string, mandatory): This value identifies the message to be queried. It preferably must match the MessageID attribute of the SendMessage request that created the message.

01122.3.2 Response

0113The response includes a message status, and a number of member status values in the form of an attribute group, PagerID, PagerName, PagerStatus. These three attributes may appear multiple times in the response to convey the status of multiple pagers in the message's aggregate destination group.

0114ResultCode (integer, mandatory): This value contains the result code of the transaction. If this value is not zero, then the MessageStatus, PagerID, PagerName, and PagerStatus fields will not be present.

0115ResultText (string, optional): This value contains a human readable message string describing the result of the transaction.

0116MessageStatus (integer, mandatory): This value contains the present status of the message, as described in the table below.

0117PagerID (string, mandatory): This value contains the identification of one pager in the aggregate destination group. The presence of this attribute represents that a corresponding PagerName attribute may follow, and that a PagerStatus attribute will follow. Together, these two or three fields are duplicated for each member of the pager group total pager destination group.

0118PagerName (string, optional): This value contains the name of the pager user corresponding to the last PagerID value.

0119PagerStatus (string, mandatory): This value contains the status of the pager user corresponding to the most recent PagerID value in the PDU. PagerStatus values are enumerated in the table below.

0120PagerStatus and MessageStatus value enumerations are described below: <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>PagerStatus Values</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="161PT" align="left" /><tbody valign="top"><row><entry>Value</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>“Pending”</entry><entry>The message is pending for transmission.</entry></row><row><entry>“Sent”</entry><entry>The message has been sent to the device but not yet</entry></row><row><entry /><entry>acknowledged in any way.</entry></row><row><entry>“Received”</entry><entry>The message has been successfully received by</entry></row><row><entry /><entry>the device.</entry></row><row><entry>“Read”</entry><entry>The message has been read by the user.</entry></row><row><entry>“Answered”</entry><entry>The user has answered the message</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0121<tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>MessageStatus Values</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>Meaning</entry><entry>Description</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>“Pending”</entry><entry>The message is pending for transmission.</entry></row><row><entry /><entry>“Sent”</entry><entry>The message has been transmitted and is open</entry></row><row><entry /><entry /><entry>for replies.</entry></row><row><entry /><entry>“Closed”</entry><entry>The message is closed.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01222.3.3 Example

0123This example illustrates a CAD system client <b>20</b>′, querying for the message 2004. The SPARKGAP™ server <b>12</b>′ returns a MessageStatus of “Sent” to indicate that the message has been sent, and it returns individual deliver status codes on the four members of the group. <tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>request 5067 sendmessage</entry><entry /></row><row><entry /><entry>{</entry></row><row><entry /><entry>MessageID=“2004”;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry /><entry>Response 5067</entry></row><row><entry /><entry /><entry>{</entry></row><row><entry /><entry /><entry>Result=0;</entry></row><row><entry /><entry /><entry>MessageStatus=“Sent”;</entry></row><row><entry /><entry /><entry>PagerID=“229030020”;</entry></row><row><entry /><entry /><entry>PagerName=“Doe, John”;</entry></row><row><entry /><entry /><entry>PagerStatus=“Read”;</entry></row><row><entry /><entry /><entry>PagerID=“229030109”;</entry></row><row><entry /><entry /><entry>PagerName=“Doe, Jane;</entry></row><row><entry /><entry /><entry>PagerStatus=“Sent”;</entry></row><row><entry /><entry /><entry>PagerID=“229030043”</entry></row><row><entry /><entry /><entry>PagerName=“Orwell,</entry></row><row><entry /><entry /><entry>George”;</entry></row><row><entry /><entry /><entry>PagerStatus=“Read”;</entry></row><row><entry /><entry /><entry>PagerID=“229030025”;</entry></row><row><entry /><entry /><entry>PagerName=“Miller, Mark”;</entry></row><row><entry /><entry /><entry>PagerStatus=“Answered”;</entry></row><row><entry /><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01243 Events

0125SDP allows the SPARKGAP™ server <b>12</b>′ to send asynchronous events to the CAD system client <b>20</b>′ to notify it of message activity on the network. SDP includes two events: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0126"> PagerReply </li><li id="ul0006-0002" num="0127"> MessageComplete </li></ul></li></ul>

01283.1 PagerReply

0129This event informs the CAD system client <b>20</b>′ that a recipient pager <b>16</b> has responded in some way to a message. The event contains the following attributes

0130Timestamp (string, mandatory): This value specifies the time that the SPARKGAP™ server <b>12</b>′ received the information from the pager.

0131MessageID (string, mandatory): This value identifies the message, matching the MessageID attribute value of the SendMessage request that created the message.

0132CadEventID (string, mandatory): This field is preferably only present if a CadEventID attribute existed in the SendMessage request that created the message. If it is present, it matches the value in the SendMessage request.

0133PagerID (string, mandatory): This value contains the identification of the pager issuing the reply.

0134PagerName (string, optional): This value contains a descriptive name of the pager user.

0135UserAlerted (integer, optional): If this attribute is present and its value is non-zero, it means that the message was successfully received by the pager <b>16</b> and the user was alerted.

0136MessageRead (integer, optional): If this attribute is present, it means that the user displayed the message on the pager <b>16</b>.

0137McrValue (integer, optional): If this attribute is present, the user selected a multiple-choice reply value indicated by the value.

0138McrText (string, optional): If this attribute is present, it contains the actual text of the selected multiple-choice reply.

0139MessageText (string, optional): If this attribute is present, it contains a manually typed response from the pager.

0140The PDU preferably will not aggregate events, but rather it will contain either UserAlerted, MessageRead, McrValue (and McrText), or MessageText. It preferably will not contain a combination of these fields. Each distinct pager response will arrive in its own event PDU with its own timestamp value.

0141In the following example, Pager 229030020 (John Doe) has responded to message 2004 with multiple-choice response number 2. <tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry /><entry>Event PagerResponse</entry></row><row><entry /><entry /><entry>{</entry></row><row><entry /><entry /><entry>Timestamp=“07082004130553EST”;</entry></row><row><entry /><entry /><entry>MessageID=“2004”;</entry></row><row><entry /><entry /><entry>CadEventID=“#CTYF041820772”;</entry></row><row><entry /><entry /><entry>PagerID=“229030020”;</entry></row><row><entry /><entry /><entry>PagerName=“Doe, John”;</entry></row><row><entry /><entry /><entry>UserAlerted=1;</entry></row><row><entry /><entry /><entry>MessageRead=1;</entry></row><row><entry /><entry /><entry>McrValue=2;</entry></row><row><entry /><entry /><entry>McrText=“Already On Scene”;</entry></row><row><entry /><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01423.2 MessageComplete

0143This event informs the CAD system client <b>20</b>′ that a message has transitioned to the closed state. The message record will remain in memory <b>18</b> for some time, but the system will no longer accept pager responses for it. This event contains the following attributes:

0144Timestamp (string, mandatory): This value specifies the time that the SPARKGAP™ closed the message.

0145MessageID (string, mandatory): This value identifies the message, matching the MessageID attribute of the SendMessage request that created the

0146CadEventID (string, mandatory): This value is only present if a CadEventID attribute existed in the original SendMessage request that created the message, and if it is present, it matches the value in the SendMessage request.

0147In this example, SPARKGAP™ announces that Message 2004 is closed: <tables id="TABLE-US-00011" num="11"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>CAD to SPARKGAP ™</entry><entry>SPARKGAP ™ to CAD</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry /><entry>Event MessageComplete</entry></row><row><entry /><entry /><entry>{</entry></row><row><entry /><entry /><entry>Timestamp=“07082004130553EST”;</entry></row><row><entry /><entry /><entry>MessageID=“2004”;</entry></row><row><entry /><entry /><entry>CadEventID=“#CTYF041820772”;</entry></row><row><entry /><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0148Result Codes

0149SDP supports the following result codes: <tables id="TABLE-US-00012" num="12"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="char" /><colspec colname="2" colwidth="147PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>Transaction Completed Successfully</entry></row><row><entry>1000</entry><entry>Badly formed PDU</entry></row><row><entry>1001</entry><entry>Unknown recognized Request</entry></row><row><entry>2000</entry><entry>Invalid User/Password</entry></row><row><entry>3000</entry><entry>Message Queue Full - Try Again Later</entry></row><row><entry>3001</entry><entry>Unknown MessageID</entry></row><row><entry>3002</entry><entry>Unknown DestinationID</entry></row><row><entry>3003</entry><entry>Missing Required Attribute</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0150Server or Switch <b>12</b>/Mobile Receiver <b>16</b> Protocol

0151A Dispatch/Response Layer will now be described which is a layer above the ReFLEX™ Air Protocol that supports group messaging between a client <b>20</b> or <b>20</b>′ and a mobile device <b>16</b> in accordance with the present invention. The SDP and DRL are analogized as book ends in that they operate on either side of a ReFLEX network <b>14</b>′.

01521. Introduction

0153The present invention preferably provides for acknowledged group messaging support for the ReFLEX™ protocol. The ReFLEX™ protocol supports personal and information service (IS) messages. Personal messages involve a single recipient, and ReFLEX™ enables the receiving pager to acknowledge reception, notify that the user has read the message, and relay multiple-choice responses from the user. IS messages involve an arbitrary group of recipients sharing common group addresses called an IS addresses. ReFLEX pagers can be configured with one personal address and multiple IS addresses. IS messages are strictly one-way, and ReFLEX™ does not support any response or acknowledgement from the recipient group.

0154The present invention adds message acknowledgement, message read notification, and multiple-choice response capability to IS messages, creating an infrastructure for reliable multicast messaging within the ReFLEX™ protocol. To this end, the present invention defines a new ALOHA command (Multicast ACK Command), and defines a flag in the ‘Change Registration Command’ to select which devices are allowed to use this feature.

0155The Dispatch/Response Layer (DRL) provides efficient and high-performance group and personal messaging over a ReFLEX™ network <b>14</b>′ between the server <b>12</b>′ and the user devices or receivers <b>16</b>. DRL uses binary IS vectors and multicast ACK commands to deliver dispatch messages to groups of users and receive individual responses. It also provides a simple structure for personal messaging between individuals, and it is designed to operate over the Secure Paging Layer (SPL). SPL is an obvious, open-source encryption standard based on AES. This system <b>10</b> or <b>10</b>′, however, can be implemented with other encryption methods.

01562. Overview

0157DRL supports both group and personal messages.

01582.1 Group Messages

0159Group Messages are broadcast to a group of one or more pagers <b>16</b> using ReFLEX™ IS addresses. A Group Message includes a specially-formatted ReFLEX™ binary message broadcast by the network <b>14</b>′ to a group of pagers <b>16</b>, and a number of ReFLEX™ Multicast ACK Command responses from the pagers <b>16</b> back to the network <b>14</b>′. This type of message can contain a display message a supervisory command, or both.

01602.2 Personal Message

0161Personal messages are sent between a single pager <b>16</b> and the network <b>14</b>′ using a ReFLEX™ personal address. A Personal Message includes a specially-formatted ReFLEX™ binary message sent from the network to a pager, or a ReFLEX™ long inbound message from the pager to the network. Additionally, pagers may transmit ReFLEX™ ACK Responses, Multiple-Choice Commands, and Transaction Control Commands in response to forward messages.

0162The present invention provides for acknowledged group messaging support for ReFLEX™ protocol. The Multicast ACK command is a new ALOHA command used by a pager <b>16</b> to reply to an IS message. This command's MSN refers not to the device personal address, but instead to an IS address selected from the device codeplug with a 4-bit enumeration field. The 30-bit IS address itself is synchronized between the pager <b>16</b> and its home switch or server <b>12</b>′, using means similar to those provided by the open ReFLEX Exchange Protocol (RXP) and the Motorola Generic Over-The-Air Programming Protocol (GOTAP).

0163The ‘Multicast ACK Command’ contains a message sequence number (MSN), a 4-bit IS address identifier (ai) and a 7-bit reply identifier (mr). The IS address identifier specifies the IS address programmed into the pager, and MSN identifies the message being replied to, and the reply identified indicates the enumerated reply code.

0164The Multicast ACK Command reply identifier can specify responses pre-programmed in the pager (codes <b>0</b> through <b>63</b>), responses embedded in the group message (codes <b>64</b> through <b>111</b>), or supervisory messages, as follows: <tables id="TABLE-US-00013" num="13"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>124 Message received by pager</entry></row><row><entry /><entry>125 Message received by pager and read by user</entry></row><row><entry /><entry>126 Message received but could not be decoded</entry></row><row><entry /><entry>127 Message received with transmission errors</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0165The network <b>14</b>′ responds to the ‘MulticastACK Command’ with a ‘Standard ACK’ (Motorola ReFLEX 2.7.3 Specification, Section 3.10.9.2). In order to control where this feature is available (and which devices may use it,), bit d<b>4</b> of the ‘Registration Grant’ type ‘Change Registration Command’ (3.1 0.8.1) is redefined from ‘reserved’ to RM. An RM value of zero restricts the pager from transmitting the ‘MulticastACK Command’. An RM value of one enables the pager to transmit the ‘MulticastACK Command.’

0166On a per-message basis, the RE and RD bits (alphanumeric and binary vectors, respectively) determine whether the Multicast ACK Command may be transmitted for any particular IS message. If RE is 1 (or RD=0), and RM=1 during the last ‘Registration Grant’ seen by a device <b>16</b>, then it may transmit ‘Multicast ACK Command’ packets related to the message. Application protocols (such as Motorola FLEXSuite, and higher-level protocols) will determine which specific ‘Multicast ACK Command’ are appropriate for the message.

01672.3 Device <b>16</b> Capabilities And Behavior

01682.3.1 Multicast ACK Command

0169DRL uses ReFLEX™ IS addresses for personal messaging. Compliant DRL Devices <b>16</b> preferably support the Multicast ACK Command described above, and they support an additional non-volatile configuration bit for each IS address in their codeplug. This flag is called the ‘CC’ or “carbon copy” flag, and it serves to disable Multicast ACK Command responses on the specified IS address. The device <b>16</b> preferably supports at least 16 IS addresses and 16 CC bits, which are automatically synchronized over the air using GOTAP or similar means.

01702.3.2 Performance

0171DRL is designed to support public safety, law enforcement, and other applications where timely delivery of personal and group messages is paramount. DRL devices <b>16</b> preferably support ReFLEX™ protocol version 2.7.3 reduced latency operation, in which they will examine each frame for IS or personal messages.

01722.3.3 User Interface

0173DRL messages follow the ‘e-mail’ model and can include a from-address, a to-address, a subject and a message body. DRL devices <b>16</b> include one or more IS addresses configured for DRL group messaging, including a CC flag (set through GOTAP) and a group name (such as ‘Ladder46’, ‘Hazmat’, or ‘BerkelyEMS^T) maintained through DRL. Users can select alert options per IS address, using the symbolic name of the address to assist the user in organizing his in-box. Personal messages and group messages can appear in the same mailbox; group addresses preferably display the name of the group as the from address.

01743. Message Structure

0175DRL preferably uses ReFLEX™ long binary messages adhering to the Motorola Route to Alternate Host (RAH) protocol as described in the Motorola FlexSuite™ of Enabling Protocols Specification Document. Preferably all DRL messages include a Message Header followed by Message Content.

01763.1 Message Header

0177Headers can include the RAH SIF (Ox11) and RAH Address ID (0x2d), followed by a DRL message type, as follows <tables id="TABLE-US-00014" num="14"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>DRL Message Header</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Field Name</entry><entry>Byte Length</entry><entry>Description</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>SIF</entry><entry>1</entry><entry>RAH SIF (0x11)</entry></row><row><entry /><entry>Address ID</entry><entry>1</entry><entry>RAH Address ID (0x2d)</entry></row><row><entry /><entry>Type</entry><entry>1</entry><entry>DRL Message Type</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01783.2 Message Content

0179Content type is identified by the Type field, as follows: <tables id="TABLE-US-00015" num="15"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98PT" align="center" /><colspec colname="2" colwidth="119PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>Ignore Message</entry></row><row><entry>1</entry><entry>Group Message</entry></row><row><entry>2</entry><entry>Personal Forward Message</entry></row><row><entry>3</entry><entry>Personal Reverse Message</entry></row><row><entry>4</entry><entry>Personal Response Message</entry></row><row><entry>5-255</entry><entry>Reserved</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0180The message content consists of a sequence of octets following immediately after the Type field of the long message header.

01814. Group Message

0182A Group Message preferably consists of a one-to-many broadcast message with recipient confirmation and reply options. Group alerts are transmitted as ReFLEX™ 1-Way binary IS messages with a DRL Type code of 1.

01834.1 Forward Message

0184The group dispatch message initiates the group dispatch transaction, conveying a display message to a number of pagers. It is a DRL long message transmitted using a ReFLEX™ 1-way personal or IS address, and it contains a 1-byte Control field, and a Display field consisting of a number of null-terminated strings encoded according to the PACK7 format described in Appendix D of the Motorola FlexSuite™of Enabling Protocols Specification Document. <tables id="TABLE-US-00016" num="16"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Dispatch Message Content</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="42PT" align="center" /><colspec colname="3" colwidth="126PT" align="left" /><tbody valign="top"><row><entry>Field Name</entry><entry>Byte Length</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Control</entry><entry>1</entry><entry>Control Flags</entry></row><row><entry>Opcode</entry><entry>1</entry><entry>Execution opcode</entry></row><row><entry>Operand</entry><entry>Variable</entry><entry>Execution operand</entry></row><row><entry>Display</entry><entry>Variable</entry><entry>NULL-Terminated Display String List.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0185The Control field specifies how the pager <b>16</b> should respond. Opcode and Operand fields specify auxiliary action the device <b>16</b> should take in addition to or instead of displaying the message, and the Display field contains the actual display message.

01864.1.1 Control Field

0187The Control field provides guidance on how the pager <b>16</b> should respond to the message: <tables id="TABLE-US-00017" num="17"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Control Flag Definitions</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28PT" align="center" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="140PT" align="left" /><tbody valign="top"><row><entry>Bit</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>0</entry><entry>AckReceipt</entry><entry>Acknowledge receipt of the message</entry></row><row><entry>1</entry><entry>AckRead</entry><entry>Acknowledge reading of the message</entry></row><row><entry>2</entry><entry>UseMcr</entry><entry>Provide the user a multiple choice response</entry></row><row><entry>3-7</entry><entry>Reserved</entry><entry>Reserved flags (set to zero)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0188An AckReceipt value of 1 instructs the pager <b>16</b> to generate a ReFLEX™ Multicast ACK when the message is received, and an AckRead value of 1 instructs the pager to generate a Multicast ACK when the message is read by the user. A UseMCR value of 1 instructs the pager provide a multiple-choice response list to the user, including responses programmed into the pager as well as responses embedded into the message itself.

01894.1.2 Operand/Opcode Field

0190Opcode and Operand fields specify auxiliary action the device <b>16</b> should take in addition to (or instead of) displaying the message. The Opcode field is a one byte value divided into upper and lower 4-bit fields. The upper 4 bits specifies the octet length of Operand, and the lower 4 bits specifies the action to be taken. The lower 4 bits use the following enumerations: <tables id="TABLE-US-00018" num="18"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Operand Values</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="center" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry>Opcode</entry><entry>Operation</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>0</entry><entry>No Operation</entry><entry>Take no action</entry></row><row><entry>1</entry><entry>Assign Name</entry><entry>Assign Group Name to Address</entry></row><row><entry>2</entry><entry>Execute</entry><entry>Execute Alerting Sequence</entry></row><row><entry>3-15</entry><entry>Reserved</entry><entry>Reserved</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

01914.1.2.1 Opcode ‘0’—No Operation

0192This opcode specifies no operation and should be ignored.

01934.1.2.2 Opcode ‘1’—Assign Group Name to Address

0194This opcode instructs the receiver <b>16</b> to assign a symbolic group name to the IS address, which are contained as one character per byte in the next 0-15 bytes. An operand length of zero implies ‘no name,’ while a length of 1-15 bytes indicate a 1-15 character long name.

01954.1.2.3 Opcode ‘2’—Execute Alerting Sequence

0196This opcode instructs the receiver to execute a pre-programmed, external alerting sequence, such as a generating a public address tone, closing a relay contact or performing a sequence of relay closures, or printing the message. The first operand byte specifies the sequence to execute, which defaults to zero if no operand data is present. Operand data bytes <b>1</b>-<b>15</b>, if present, contain additional parameters specific to the sequence. Devices that do not support this feature should ignore this opcode.

01974.1.3 Display Field

0198The Display field is one continuous Pack7 field containing a list of null-terminated strings. These strings include, in order, the message subject, the message body, and up to 16 optional multiple-choice response strings. The subject and body are displayed to the user, and the response strings are presented as a list.

01994.2 Multicast ACK Command Response

0200Under certain circumstances, the device may respond to the message with one or more MulticastACK Commands. This behavior depends on 4 factors: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0201"> values of the RD bit in the message vector, </li><li id="ul0008-0002" num="0202"> the Control field of the message, </li><li id="ul0008-0003" num="0203"> the RM value of the last ‘Registration Grant’ seen by a device, and </li><li id="ul0008-0004" num="0204"> the Multicast Ack Enabled flag of the IS address used <br /> If RD=1 and RM=0, or Multicast Ack Enabled=0 then this command must not be used. Otherwise, the command should be sent under the following circumstances: </li><li id="ul0008-0005" num="0205"> Upon Message Receipt </li><li id="ul0008-0006" num="0206"> If AckReceipt of the Control field is 1, then the device <b>16</b> queues a Multicast ACK Command with mr=124 into its transmit queue when it receives a complete, error-free message. </li><li id="ul0008-0007" num="0207"> Upon the User Viewing the Message </li><li id="ul0008-0008" num="0208"> If AckRead of the Control field is 1, then the device <b>16</b> queues a Multicast ACK Command with mr=125 into its transmit queue when it receives a complete, error-free message. </li><li id="ul0008-0009" num="0209"> Upon the User Selecting a Reply </li><li id="ul0008-0010" num="0210"> If UseMcr of the Control field is 1, then the device <b>16</b> gives the user the option to select a reply string from an aggregated list including the replies programmed into the device and the replies embedded in the Display field. If the user selects a string, then the device <b>16</b> queues a Multicast ACK Command with mr=[0,111] into its transmit queue. Codes <b>0</b>-<b>63</b> are reserved for responses programmed in the pager, and codes <b>64</b>-<b>111</b> are reserved for any response strings in the Display field. The user may respond to the message multiple times. </li></ul></li></ul>

0211Subsequent Multicast ACK Commands associated with the same message can be optimized, and some of them can be overlooked without loss of information. For instance, an mr of 125 or an mr in the [0,111] range implies that the message has been received and viewed. Depending on how fast the user reads and/or responds to a message, and depending on the ALOHA randomization interval of the system, the pager <b>16</b> may be able to skip transmission of Multicast ACK Response commands with mr values of 124 and 125 and simply transmit the multiple-choice reply code [0,111]. When possible, this is desirable in order to reduce congestion of the return channel.

02125. Personal Message

0213A Personal Message is a human-readable message carried from one point to another. Personal Forward Messages are sent by the network <b>14</b>′ to one pager <b>16</b>, and Personal Reverse Messages are sent by the pager <b>16</b> to the network <b>14</b>′. The DRL model for Personal Messages is similar to an abbreviated version of SMTP.

02145.1 Personal Forward Message

0215A Personal Forward Message is transmitted by the network <b>14</b>′ to the pager <b>16</b>. It contains Display field consisting of a number of null-terminated strings in FlexSuite Pack7 format.

0216This message type can be delivered as a one-way or two-way long binary message to single pager <b>16</b>, with acknowledgement, read response, and multiple-choice replies transmitted back using the ReFLEX™ signaling layer. Display contains an ordered list of strings: a from-address, a subject, a body, and an optional list of multiple-choice replies.

02175.2 Personal Reverse Message

0218A Personal Reverse Message is transmitted by the pager <b>16</b> to the network <b>14</b>′. It contains Display field consisting of a number of null-terminated strings in FlexSuite Pack7 format.

0219This message is delivered as a ReFLEX™ long inbound binary message. Display contains an ordered list of strings: a to-address, a subject, and a body.

0220Exemplary Tactical Alerting System

0221ReFLEX pagers are not fixed on a single channel for service, but rather scan continuously for a better, stronger, or more appropriate signal to serve them. This background scanning facilitates the present invention since it is this ability that allows these devices to seek out the correct channel for temporary use at the scene of an event.

0222In accordance with an exemplary embodiment of the present invention, a pager <b>16</b> is provided as shown in <figref idref="DRAWINGS">FIGS. 6, 9A</figref>, <b>9</b>B and <b>10</b>. With reference to <figref idref="DRAWINGS">FIG. 6</figref>, the pager <b>16</b> comprises a processor <b>38</b> programmed to implement the DRL, among other operations, a memory <b>36</b> for storing, for example, group configuration information, a display <b>44</b> and an interface <b>40</b> to the network <b>14</b>. The pager <b>16</b> can be connected directly to a user interface <b>42</b> for facilitating customization of the group configuration information, for example, to allow the pager <b>16</b> to respond differently to messages directed to different group addresses. As shown in <figref idref="DRAWINGS">FIGS. 9A and 9B</figref>, the pager <b>16</b> has a display for displaying different screens and different options thereon. For example, the main screen shown on the display <b>44</b> in <figref idref="DRAWINGS">FIG. 9A</figref> indicates time and date and a menu listing such options as “VIEW RECEIVED MSGS”, “VIEW TRANSMITTED MSGS”, “SEND A MESSAGE” and “SERVICE SETTINGS”. As shown in <figref idref="DRAWINGS">FIG. 9B</figref>, the pager <b>16</b> can be provided with a charger console <b>100</b> which can also have an input to the user interface <b>42</b>. As shown in <figref idref="DRAWINGS">FIG. 10</figref>, the pager <b>16</b> can be provided with a QWERTY keypad <b>102</b>, among other buttons and controls.

0223The pager <b>16</b> can be used by responding personnel on a day-to-day basis as a wide-area alerting device, but also as a tactical alerting device at the scene of an incident. The pager preferably operates on any programmed ReFLEX™2.7.x network. If an on-scene SPARKGAP™ (for instance, mounted into a mobile communications center) is operating with its own base station and an RXP connection to the wide area system, the pager <b>16</b> can register with the on-scene SPARKGAP™ when the responder arrives. When the pager <b>16</b> arrives at the site of an event with an established on-scene network such as the switch <b>12</b>′ (e.g., the SPARKGAP™ server), the pager <b>16</b> automatically finds this system <b>10</b>, switches to the proper channel, and registers. As long as that pager <b>16</b> is in the coverage area of the on-scene SPARKGAP™ server <b>12</b>′, it will be a part of the community of pagers <b>16</b> receiving messages from the command post for that particular occurrence. Once the on-scene network is shutdown, or the responder leaves the coverage area, the pager <b>16</b> will re-register on the wide-area system.

0224The on-scene SPARKGAP™, and pagers, can be preloaded with one or more IS addresses reserved for tactical alerting. Incident commanders can send messages to these IS addresses to notify users on-scene of impending tactical issues, such as imminent structural failure or impending chemical release. In addition to the ability to automatically find the channel being used at the scene of a major event, the pager <b>16</b> is also equipped with louder than normal (>85 dB at 30 cm) alerting tone and strong vibrator to ensure the user is aware of an incoming message. With appropriate configuration, tactical alert messages can be sent to specific groups of user, or to all users on scene. Additionally, AES encryption is available to prevent inappropriate interception of tactical alerts.

0225Because the on-scene system is connected by RXP to the wide-area network, pagers also continue to send and receive normal personal and group messages from the wide area system. However, the pager can be configured with unique alert tones to allow personnel to recognize incoming tactical messages, and the on-scene SPARKGAP can even temporarily configure local devices so that they only alert the user when tactical messages are received.

0226Modern wide-area paging networks utilize the 900 MHz band of radio spectrum. Some of these channels are dedicated to the NPCS Radio Service (FCC Part 24) and others are found in Business and Industrial Radio Service (FCC Part 90) making them available to a wide range of system operators. The pager <b>16</b> uses frequencies in either or both of these channel segments based on programming within the paging device itself.

0227When a major public safety event occurs, it is normal for the involved agencies to establish a command post at or near the scene of the event. Many times this is a motor home-style vehicle equipped to resemble a control room with banks of computers, radios and a meeting area used for staff briefings. As a critical part of this command post, a SPARKGAP™ server <b>12</b>′ can be installed to control the ReFLEX™ paging devices <b>16</b> carried to the scene by various responders. Once this system <b>10</b>′ (<figref idref="DRAWINGS">FIG. 4</figref>) is activated, pagers <b>16</b> that are preprogrammed with the on-scene channels would lock onto the network at the scene and check in. A display of all registered paging devices could be used to monitor the presence of personnel as they arrive.

0228If it was necessary to call a general evacuation of the scene, this message would be sent via the server <b>12</b>′ and each device <b>16</b> would acknowledge receipt and reading of the message. Paging allows the message to be sent to multiple users at the same time. The site command personnel would have an instant view of those who did not respond to the alert and could take immediate alternative action to get the message to them.

0229In this way, paging is analogous to an electronic equivalent of a lifeline attached to each person at the scene. Notifying them to evacuate by sending an alert message would be like pulling on that line and getting a tug as a response. The structure of a paging network provides the highest efficiency when it comes to alerting multiple users to an important message. And more importantly, the system <b>10</b> or <b>10</b>′ of the present invention gives the incident commander a confirmed indication that the message was received and read by the personnel to whom it was sent.

0230It will be appreciated by those skilled in the art that the present invention can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restricted. The scope of the invention is indicated by the appended claims rather than the foregoing description and all changes that come within the meaning and range and equivalence thereof are intended to be embraced therein.