CA2778905A1

CA2778905A1 - Network and application merging and asset tracking

Info

Publication number: CA2778905A1
Application number: CA2778905A
Authority: CA
Inventors: Thomas Berger; Joseph E. Denny; David S. Robins; Stephen A. Wallace; Raymond T. Gurgone; Peter Lamonte Koop; Edward Allen Payne; Robert Twitchell; Rodney A. Hilton; Randy Edwards
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2008-10-29
Filing date: 2009-10-29
Publication date: 2010-08-26
Also published as: WO2010096127A1

Abstract

A method of merging wireless networks where, prior to execution of the method, each network includes a wireless communications device, and one or more nodes, and each node is configured for communications with one of the communications devices but not the other, includes reconfiguring one of the wireless communications devices or one or more of the wireless nodes such that the first and second networks merge into a single network. An asset monitoring system includes a message management and routing (MMR) system configured to facilitate communications between a radio network and a user application. The radio network includes a gateway controller, and remote sensor nodes (RSNs). Each RSN is configured to communicate information regarding an asset it is secured on or to to the user application via the gateway controller. The user application is configured to display information regarding tracked assets to a user via a user device.

Description

NETWORK AND APPLICATION MERGING AND ASSET TRACKING

CROSS-REFERENCE TO RELATED APPLICATION
[001] For purposes of the U.S., the present application is a U.S.
nonprovisional patent application of, and claims priority under 35 U.S.C. 119(e) to each of:
(a) U.S. Provisional Patent Application No. 61/140,887, filed 12-25-2008 , titled "UPDATING NODE PRESENCE BASED ON COMMUNICATION PATHWAY";
(b) U.S. Provisional Patent Application No. 61/109,500, filed 10-29-2008 , titled SYSTEMS AND APPARATUS FOR MANAGING AND MONITORING
EMERGENCY SERVICES SECTOR RESOURCES";
(c) U.S. Provisional Patent Application No. 61/109,505, filed 10-30-2008 , titled "SYSTEMS AND APPARATUS FOR MANAGING AND MONITORING
EMERGENCY SERVICES SECTOR RESOURCES";
(d) U.S. Provisional Patent Application No. 61/109,502, filed 10-29-2008 , titled "SYSTEMS AND APPARATUS FOR MANAGING AND MONITORING
EMERGENCY SERVICES SECTOR RESOURCES";
(e) U.S. Provisional Patent Application No. 61/140,880, filed 12-25-2008 , titled "MERGING AND UNMERGING WIRELESS AD HOC NETWORKS";
(f) U.S. Provisional Patent Application No. 61/140,881, filed 12-25-2008 , titled "AUTOMATED IDENTIFICATION OF RADIO CHANNELS FOR
INTEROPERABILITY CONNECTIONS";
(g) U.S. Provisional Patent Application No. 61/140,883, filed 12-25-2008 , titled "INPUT/OUTPUT ENHANCEMENTS FOR COMPUTER AIDED DISPATCH
AND AUTOMATED CALL-OUT SYSTEMS";
(h) U.S. Provisional Patent Application No. 61/141,021, filed 12-29-2008 , titled "METHODS, SYSTEMS, AND APPARATUS FOR PROVIDING NETWORK
SERVICES";
(i) U.S. Provisional Patent Application No. 61/147,917, filed 01-28-2009 , titled "ASCERTAINING PRESENCE IN CLASS-BASED NETWORKS";
(j) U.S. Provisional Patent Application No. 61/147,839, filed 01-28-2009 , titled "NETWORK BEACONING";
(k) U.S. Provisional Patent Application No. 61/151,185, filed 02-09-2009 , titled "SYSTEMS AND APPARATUS FOR MANAGING AND MONITORING
EMERGENCY SERVICES SECTOR RESOURCES";
(1) U.S. Provisional Patent Application No. 61/172,655, filed 04-24-2009 , titled "LOCALIZATION USING HOP-PATH INFORMATION"; and (m) U.S. Provisional Patent Application No. 61/254,126, filed 10-22-2009 , titled "PRE-ASSIGNMENT OF RESOURCES".

[002] The present application hereby incorporates herein by reference the entire disclosure of each of these above-noted provisional patent applications.

[003] Additionally, the present application hereby incorporates herein by reference each of the following identified U.S. patent applications-as well as any publications thereof and any patents issuing therefrom; the following identified U.S. patent application publications; and the following identified U.S. patents: 12/468,047; 12/367,544 (US 2009-0135000 Al);
12/367,543 (US 2009-0161642 Al); 12/367,542 (US 2009-0181623 Al); 12/353,197 (US 2009-0129306 Al);
12/352,992 (US 2009-0122737 Al); 12/343,865 (US 2009-0104902 Al); 12/343,822 (US 2009-0103462 Al);
12/271,850 (US 2009-0092082 Al); 12/140,253 (US 2008-0303897 Al); 11/930,797 (US 2008-0151850 Al); 11/930,793 (US 2008-0112378 Al); 11/930,788 (US 2008-0165749 Al);
11/930,785 (US 2008-0143484 Al); 11/930,782 (US 2008-0212544 Al); 11/930,779 (US 2008-0129458 Al);
11/930,777 (US 2008-0111692 Al); 11/930,770 (US 2008-0144554 Al); 11/930,761 (US 2008-0112377 Al); 11/930,753 (US 2008-0142592 Al) now 7,535,339; 11/930,749 (US

Al) now 7,538,658; 11/930,740 (US 2008-0150723 Al) now 7,538,657; 11/930,736 (US 2008-0143483 Al) now 7,538,656; 11/847,309 (US 2007-0291724 Al); 11/847,295 (US

Al); 11/832,998 (US 2007-0273503 Al) now 7,378,959; 11/832,991 (US 2007-0268134 Al) now 7,378,958; 11/832,979 (US 2007-0268126 Al) now 7,378,957; 11/610,427 (US 2007-0159999 Al);
11/618,931 (US 2007-0155327 Al); 11/555,173 (US 2007-0099629 Al); 11/555,164 (US 2007-0099628 Al); 11/465,466 (US 2007-0043807 Al); 11/465,796 (US 2007-0041333 Al);
11/460,976 (US 2008-0315596 Al); 11/428,536 (US 2007-0002793 Al); 11/428,535 (US 2007-0002792 Al);
11/425,047 (US 2007-0069885 Al) now 7,554,442; 11/425,040 (US 2006-0287008 Al) now 7,539,520; 11/424,850 (US 2007-0004331 Al); 11/424,849 (US 2007-0004330 Al) now 7,574,168;
11/424,847 (US 2007-0001898 Al) now 7,583,769; 11/424,845 (US 2006-0287822 Al) now 7,574,300; 11/423,127 (US 2006-0289204 Al) now 7,563,991; 11/422,306 (US 2006-0282217 Al) now 7,542,849; 11/422,304 (US 2006-0276963 Al) now 7,526,381; 11/422,321 (US

Al); 11/422,329 (US 2006-0274698 Al) now 7,529,547; 11/306,765 (US 2008-0136624 Al) now 7,394,361; 11/306,764 (US 2006-0237490 Al) now 7,391,321; 11/193,300 (US 2007-0024066 Al) now 7,438,334; 11/161,550 (US 2007-0002808 Al) now 7,430,437; 11/161,545 (US

Al) now 7,221,668; 11/161,542 (US 2006-0023679 Al) now 7,522,568; 11/161,540 (US 2007-0004431 Al) now 7,200,132; 11/161,539 (US 2006-0023678 Al) now 7,209,468;
10/987,964 (US
2005-0093703 Al) now 7,155,264; 10/987,884 (US 2005-0093702 Al) now 7,133,704;
10/604,032 (US 2004-0082296 Al) now 6,934,540; 10/514,336 (US 2005-0215280 Al) now 7,209,771; and 09/681,282 (US 2002-0119770 Al) now 6,745,027.

[004] Each of the foregoing patent application publications and patents is hereby incorporated herein by reference for purposes of disclosure of common designation (CD) technology (such as, e.g., class-based network (CBN) technology); wake-up (WV) technology; and networks that utilize such technologies (such as those of TeraHop Networks, Inc. of Alpharetta, Georgia), and systems employing such technologies including, inter alia: (1) implementations in the first responder context;
(2) implementations in container tracking and monitoring context; and (3) implementations in equipment tracking and monitoring, especially rental construction equipment and FEMA equipment.
It is intended that the CD/CBN and WU technologies, and related features, improvements, and enhancements, as disclosed in these incorporated references may be utilized in combination with various embodiments and implementations of the present invention.

COPYRIGHT STATEMENT

[005] All of the material in this patent document is subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in official governmental records but, otherwise, all other copyright rights whatsoever are reserved.

BACKGROUND OF THE INVENTION

[006] The present invention generally relates, in at least some implementations, to network and application merging and asset tracking.

[007] A need exists for improvement in these fields. This, and other needs, are addressed by one or more aspects of the present invention.

SUMMARY OF THE INVENTION

[008] The present invention includes many aspects and features. Moreover, while many aspects and features relate to, and are described in, the context of asset tracking, the present invention is not limited to use only in such context, as will become apparent from the following summaries and detailed descriptions of aspects, features, and one or more embodiments of the present invention.

[009] Accordingly, one aspect of the present invention relates to a method of merging first and second wireless networks. Prior to execution of the method, the first network includes a first wireless communications device and a first group of wireless nodes comprising one or more wireless nodes and the second network includes a second wireless communications device and a second group of wireless nodes comprising one or more wireless nodes. Each wireless node of the first group of wireless nodes is configured for wireless communications with the first wireless communications device, but is not configured for wireless communications with the second wireless communications device, and each wireless node of the second group of wireless nodes is configured for wireless communications with the second wireless communications device, but is not configured for wireless communications with the first wireless communications device. An exemplary such method includes reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes, such that the first and second networks merge into a single network.

[010] In a feature of this aspect of the invention, the method further includes, prior to said reconfiguring step, the step of determining that a coverage area of the first wireless network and a coverage area of the second wireless network are proximate one another. In another feature, the method includes, prior to said reconfiguring step, the step of determining that a coverage area of the first wireless network and a coverage area of the second wireless network overlap. In another feature, the method includes, prior to said reconfiguring step, monitoring, by the first wireless communications device, for the presence of another wireless communications device, determining, at the first wireless communications device, that the second wireless communications device is present, communicating, from the first wireless communications device to the second wireless communications device, information regarding the first wireless communications device, and communicating, from the second wireless communications device to the first wireless communications device, information regarding the second wireless communications device. In still another feature of this aspect of the invention said reconfiguring step includes reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that both the first wireless communications device and the second wireless communications device are configured for wireless communications with all of the wireless nodes. In a further feature of this aspect, prior to execution of the method, each wireless node of the first network is configured for wireless communications with each of the other wireless nodes of the first network, but is not configured for wireless communications with the wireless nodes of the second network, and each wireless node of the second network is configured for wireless communications with each of the other wireless nodes of the second network, but is not configured for wireless communications with the wireless nodes of the first network; and said step of reconfiguring comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that all of the wireless nodes are configured for wireless communications with one another.

[011] In yet another feature of this aspect of the invention, prior to execution of the method, the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to a first user application, and the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to a second user application. In another feature the method includes reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes, such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application. In a further feature, said step of reconfiguring such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that the second wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such data to the first user application. In still another feature the method further includes determining, by the first user application, whether to merge, determining, by the second user application, whether to merge, and wherein said reconfiguring step occurs as a result of a determination to merge by both the first and second user applications. In still an additional feature the method further includes determining, by the first user application, whether to merge with the second user application, determining, by the second user application, whether to merge with the first user application, and if both the first user application and the second user application determined to merge with one another, then merging the first and second user applications such that one of the user application is a master user application. In another feature following said step of merging the first and second user applications, the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to the master user application, and the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to the master user application. In still a further feature, said step of determining, by the first user application, whether to merge with the second user application comprises presenting, to a user via a user device, a query as to whether to merge and subsequently receiving an indication of whether to merge input by the user via the user device. In another feature the user device comprises a laptop. In another feature the user device comprises a personal digital assistant (PDA).

[012] In a feature of this aspect of the invention the first wireless communications device comprises a gateway controller. In another feature, the first wireless communications device comprises a mobile gateway system (MGS). In still another feature, each wireless node comprises a remote sensor node (RSN). In a further feature each wireless communications device comprises a mobile gateway system (MGS) secured on or to an emergency services sector asset, and each wireless node comprises a remote sensor node (RSN) secured on or to an emergency services sector asset.

[013] Another aspect of the invention relates to a method for facilitating the management of emergency services sector (ESS) resources at an incident. A exemplary such method includes arriving, at an incident, by a first ESS unit which includes an emergency services sector asset having a gateway controller (GC), one or more emergency services sector assets each having a remote sensor node (RSN); arriving, at the incident, by a second ESS unit which includes an emergency services sector asset having a GC, one or more emergency services sector assets each having a remote sensor node (RSN); detecting, by the GC of the first ESS unit, the GC of the second ESS unit; querying, via a user device associated with the GC of the first ESS unit and a user device associated with the GC of the second ESS unit, who will be incident commander (IC) going forward;
indicating, by a user, via one of the user devices, that the user will be IC; merging the GCs such that the GC associated with the user device used to indicate that the user will be IC becomes a master GC.

[014] Another aspect of the invention relates to a method for facilitating the management of emergency services sector (ESS) resources at an incident. An exemplary such method includes arriving, at an incident, by a first ESS unit which includes an emergency services sector asset having a gateway controller (GC), one or more emergency services sector assets each having a remote sensor node (RSN), one of the assets having a user device; arriving, at the incident, by a second ESS unit which includes an emergency services sector asset having a GC, one or more emergency services sector assets each having a remote sensor node (RSN), one of the assets having a user device;
detecting, by the GC of the first ESS unit, the GC of the second ESS unit;
querying, via the user device of the asset having a user device of the first ESS unit, whether to merge, querying, via the user device of the asset having a user device of the second ESS unit, whether to merge, if an affirmative response was received in response to each querying step, then merging together the GCs.

[015] Another aspect of the invention relates to an asset monitoring system.
An exemplary such system includes a radio network, the radio network comprising a gateway controller, one or more remote sensor nodes (RSNs); a user application; and a message management and routing (MMR) system configured to facilitate communications between the radio network and user application; a user device; wherein each RSN is secured on or to an asset to be tracked;
wherein each RSN is configured to communicate information regarding the asset it is secured on or to to the user application via the gateway controller; wherein the user application is configured to display information regarding tracked assets to a user via the user device.

[016] In a feature of this aspect the user device is a laptop. In another feature the user device is a personal digital assistant (PDA) or PDA-like device. In yet another feature, the radio network is configured to report the presence of RSNs, and thus the assets RSNs are secured to. In still another feature the user application comprises a presence server. In an alternative feature, a gateway of the gateway controller is configured to beacon at regular intervals to broadcast its presence to nearby RSNs. In still another feature, each asset to be tracked comprises an emergency services sector resource. In another feature each asset to be tracked comprises a container.
In an additional feature, each asset to be tracked comprises construction equipment. In a further feature, each RSN includes one or more sensors, and each RSN is configured to communicate sensor information to the user application via the gateway controller. In still a further feature, the system is configured to detect a location change of an RSN. In another feature, the system is configured to detect a status change of an RSN. In another feature, each RSN may be assigned to different tasks or profiles via the user application. In still another feature, each RSN is configured to change its behavior in response to a location change. In still a further feature, each RSN is configured to change its behavior in response to a state change. In another feature, each RSN is configured to change its behavior in response to sensor input. In an alternative feature, each RSN is configured to change its behavior in response to an assignment change. In another feature still, when a message communicated from an RSN to the gateway controller is hopped through other RSNs, a path the message travels is stored, and wherein, when an alert condition arises at an RSN, hop-path information is utilized to determine an RSN that might be proximate the RSN with the alert condition.

[017] Another aspect of the present invention relates to a method of merging first and second networks. Prior to execution of such a method, the first network includes a first wireless communications device, and a first group of wireless nodes comprising one or more wireless nodes, and the second network comprises a second wireless communications device, and a second group of wireless nodes comprising one or more wireless nodes. Furthermore, each wireless node of the first group of wireless nodes is configured for wireless communications with the first wireless communications device, but is not configured for wireless communications with the second wireless communications device, each wireless node of the second group of wireless nodes is configured for wireless communications with the second wireless communications device, but is not configured for wireless communications with the first wireless communications device, the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to a first user application, and the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to a second user application. An exemplary such method includes monitoring, by the first wireless communications device, for the presence of another wireless communications device, determining, at the first wireless communications device, that the second wireless communications device is present, communicating, from the first wireless communications device to the second wireless communications device, information regarding the first wireless communications device, communicating, from the second wireless communications device to the first wireless communications device, information regarding the second wireless communications device, and reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes, such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application.

[018] In a feature of this aspect of the invention, said step of reconfiguring comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that the first wireless communication device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application via an enterprise gateway server.

[019] An aspect of the present invention relates to a system which includes a plurality of wireless islands, a computer application, and a message management and routing (MMR) system. The MMR

system is configured to act as an intermediary for communication between one of the wireless islands and the computer application.

[020] In a feature of this aspect of the invention, one of the plurality of wireless islands comprises a radio network.

[021] In a feature of this aspect of the invention, the radio network comprises a plurality of remote sensor nodes (RSNs) that may be utilized to manage and locate resources (or assets) to which they are attached. Moreover, each RSN preferably includes one or more internal and external sensors. Using such sensors, for example, biometrics of a person or animal associated with an RSN can be monitored and/or the local environment of an RSN can be monitored for pathogens, gases, and/or radiation.
Other possible sensors and uses thereof are disclosed, for example, in the incorporated references.

[022] In a feature of this aspect of the invention, the radio network further comprises a gateway controller.

[023] In a feature of this aspect of the invention, some RSNs of the plurality of RSNs each is configured to be worn on one's person.

[024] In a feature of this aspect of the invention, some RSNs of the plurality of RSNs are configured to be attached to a vehicle.

[025] In a feature of this aspect of the invention, some RSNs of the plurality of RSNs are configured to be transported by a vehicle.

[026] In a feature of this aspect of the invention, an RSN of the plurality of RSNs is worn by a firefighter.

[027] In a feature of this aspect of the invention, an RSN of the plurality of RSNs is attached to a police vehicle.

[028] In a feature of this aspect of the invention, an RSN of the plurality of RSNs is attached to equipment used by emergency services sector (ESS) personnel.

[029] In a feature of this aspect of the invention, the gateway controller is attached to a fire engine or fire truck.

[030] In a feature of this aspect of the invention, the gateway controller is attached to a paramedic engine or rescue unit.

[031] In a feature of this aspect of the invention, the gateway controller is attached to a police precinct building.

[032] In a feature of this aspect of the invention, the gateway controller is attached to a fire station building.

[033] In a feature of this aspect of the invention, an RSN of the plurality of RSNs is worn by ESS
personnel, the gateway controller is mounted to an ESS vehicle, and the RSN is configured to wirelessly communicate with the gateway controller.

[034] Another aspect of the present invention relates to a radio network. The radio network includes a plurality of remote sensor nodes (RSNs), each RSN having stored therein a unique identifier (UID);

a gateway server corresponding to an Area ID; and one or more gateway routers;
wherein, each of the plurality of RSNs is in wireless communication with the gateway router via one or more gateway servers.

[035] In a feature of this aspect of the invention, RSNs of the plurality of RSNs are configured to hop messages from other RSNs.

[036] In a feature of this aspect of the invention, the messages include an Area ID.

[037] In a feature of this aspect of the invention, each RSN is configured to communicate periodic check-in messages to the gateway server.

[038] In a feature of this aspect of the invention, the radio network utilizes class based networking.

[039] In a feature of this aspect of the invention, each RSN includes a reduced complexity radio, and wherein an RCR wake-up message is transmitted before establishing node-to-node communication links.

[040] Another aspect of the present invention relates to a method for detecting the presence of ESS
resources. The method includes attaching an RSN to an asset; attaching a gateway controller to a mobile vehicle; dispatching, to an incident, the mobile vehicle; dispatching, to an incident, the asset;
and forming, at the incident, a wireless network between the RSN and the gateway controller.

[041] In a feature of this aspect of the invention, the method further includes communicating, by the gateway controller, an indication of the presence of the RSN at the incident to a computer application.

[042] In a feature of this aspect of the invention, the method further includes communicating, by the gateway controller via WiFi, information associated with the RSN to a computer application.

[043] An aspect of the present invention relates to a method for ascertaining the presence of a person or object via an RSN associated therewith. Features of this aspect pertain to network beacons;
formation of the network; management of the network; and network adjustments and changes.

[044] In another feature of this aspect, node presence status is updated by using incidental hop-routing data, wherein nodes that are in a hopping path make their presence known by appending their UIDs to the routing table of a hopped message, thereby making their presence known, rather than by requiring each node to update presence by sending a check-in message on some expected schedule.

[045] In another feature of this aspect, a method is utilized for minimizing RF pollution (the total number of transmissions) and battery conservation while maximizing network range, including using network nodes to repeat a network beacon in a semi-random way wherein networks announce their availability with a beacon, which invites nodes to join, thereby extending the range of the network's beacon by having nodes repeat the beacon, and thereby minimizing the number of nodes involved to achieve maximum range. Variations of this aspect are applicable to implementations in the first responder context, implementations in the container tracking and monitoring context, implementations in the equipment tracking and monitoring context, especially that of construction and rental equipment.

[046] Another aspect of the present invention relates to a method for merging a plurality of wireless ad-hoc networks into a single network, and un-merging (separating) a plurality of wireless ad-hoc networks out of a merged, single network. Features of this aspect include accommodating fixed and mobile gateways; each merging network sensing, via a gateway, the other networks and recognizing that the others are of their own class; automatically notifying a user application of the other networks;
offering a user, via user application, the option of merging; controlling, via user application, whether networks are merged; and nodes following their respective gateways with regard to the merging.
Variations of this aspect are particularly applicable to implementations in the first responder context, but are also applicable to implementations in the container tracking and monitoring context and implementations in the equipment tracking and monitoring context, especially that of construction and rental equipment.

[047] Another aspect of the present invention relates to a method for a plurality of independent (wireless) gateways to subordinate their operation to a single gateway of that plurality of gateways.
Features of this aspect include establishing one gateway, in a merging of networks, as a master gateway of the merged network; and controlling, via user application, which gateway becomes master.

[048] Another aspect of the present invention relates to a method for facilitating hopping when there is no continuous in-class path between a node and gateway by using both hard and soft (preferential) class-based networking, wherein hard class-based networking includes requiring all the nodes in the hopping path to have at least one class in common with the originating node in order for a message to get from an originating node to a gateway, and wherein soft (preferential) class-based networking includes requiring class commonality/continuity only for each hop, thereby greatly increasing the probability that messages of class-orphan nodes can get their messages through.

[049] Another aspect of the present invention relates to the use of mobile gateways that form networks both while in motion and after becoming stationary. In features of this aspect, the mobile gateways are carried on trucks, cars, boats, planes, trains, containers, construction equipment, and rental equipment. In other features of this aspect, no network is formed unless a gateway is present; a network forms immediately when nodes come within in-range; and until nodes become in-range, nodes make no transmissions and are stealthy.

[050] Another aspect of the present invention relates to a system for monitoring and managing accountability of objects that may change location and/or organization.
Features of this aspect include: basic network formation; merging nodes and networks; managing the subordination of nodes and networks; user application control of which nodes join a network; the use of commands from a user application to cause nodes to change behavior in response to sensor inputs; mobility of gateways;
totality of ad-hoc formation and configuration; accommodation of intermittent connectivity; and network beaconing.

[051] In addition to the aforementioned aspects and features of the present invention, it should be noted that the present invention further encompasses the various possible combinations and subcombinations of such aspects and features.

BRIEF DESCRIPTION OF THE DRAWINGS

[052] One or more preferred embodiments of the present invention now will be described in detail with reference to the accompanying drawings, wherein the same elements are referred to with the same reference numerals, and wherein:

[053] FIG. 1 illustrates a system in accordance with one or more preferred embodiments having a plurality of discrete wireless islands utilizing common message handling components.

[054] FIG. 2 illustrates point to multi-point networking where connectivity is determined by proximity in a conventional ad hoc network.

[055] FIG. 3 illustrates the same array of nodes depicted in FIG. 2, only networked using CBN
technology in accordance with the CBN technology of the incorporated patents and published patent applications.

[056] FIG. 4 illustrates a radio network comprising a gateway and four RSNs with an expanded coverage area, in accordance with a preferred embodiment of the present invention.

[057] FIG. 5 illustrates an expanded footprint of a gateway resulting from RSN
hopping in accordance with a preferred embodiment of the present invention.

[058] FIG. 6 illustrates a data communications network 110 having multiple user servers 128,130,132 and client applications as well as multiple locations, each having a presence server in accordance with a preferred embodiment of the present invention.

[059] FIG. 7 illustrates an exemplary network 210 including fifteen nodes 211-239 in accordance with a preferred embodiment of the present invention.

[060] FIG. 8 illustrates that a check-in message originating at node 219 requires three hops to get from node 219 to the gateway 241 in the exemplary network 210 of FIG. 7.

[061] FIG. 9 illustrates major functional elements which support customer interaction with a system in accordance with a preferred embodiment of the present invention.

[062] FIG. 10 illustrates a system comprising multiple radio networks, wherein each radio network includes a gateway controller, and further includes one or more gateways and RSNs, in accordance with a preferred embodiment of the present invention.

[063] FIG. 11 illustrates latency requirements of each corresponding logical subsystem, which generally corresponds to the vertical ordering of the blocks shown in FIG. 10, and FIG. 11 additionally illustrates the flow of data between a wireless island-in this example a radio network-and a customer application host, all in accordance with a preferred embodiment of the present invention.

[064] FIG. 12 illustrates that, in order to enable communication between a radio network and a customer application, the MMR system routes addresses to both a gateway controller of the radio network and an EGW associated with the customer application, at which point communications between the radio network and the user application will follow the primary data path shown, all in accordance with a preferred embodiment of the present invention.

[065] FIG. 13 is a detailed reference model illustrating logical subsystems of an exemplary MMR
system implementation in accordance with a preferred embodiment of the present invention.

[066] FIG. 14 is a detailed reference model illustrating logical subsystems of an exemplary mobile MMR system implementation in accordance with a preferred embodiment of the present invention.

[067] FIGS. 15-19 illustrate a preferred merging methodology in accordance with a preferred embodiment of the present invention.

[068] FIG. 20 is a diagram of components utilized in one or more merging implementations in accordance with a preferred embodiment of the present invention.

[069] FIG. 21 illustrates rerouting of communications from a slave EGW to a master EGW
following a merge in accordance with a preferred embodiment of the present invention.

[070] FIG. 22 illustrates the use of a bridge to route messages received by an EGW associated with a first user application to a second user application in accordance with a preferred embodiment of the present invention.

[071] FIGS. 23-28 illustrate an exemplary scenario demonstrating merging functionality in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION

[072] As a preliminary matter, it will readily be understood by one having ordinary skill in the relevant art ("Ordinary Artisan") that the present invention has broad utility and application.
Furthermore, any embodiment discussed and identified as being "preferred" is considered to be part of a best mode contemplated for carrying out the present invention. Other embodiments also may be discussed for additional illustrative purposes in providing a full and enabling disclosure of the present invention. As should be understood, any embodiment may incorporate only one or a plurality of the above-disclosed aspects of the invention and may further incorporate only one or a plurality of the above-disclosed features. Moreover, many embodiments, such as adaptations, variations, modifications, and equivalent arrangements, will be implicitly disclosed by the embodiments described herein and fall within the scope of the present invention.

[073] Accordingly, while the present invention is described herein in detail in relation to one or more embodiments, it is to be understood that this disclosure is illustrative and exemplary of the present invention, and is made merely for the purposes of providing a full and enabling disclosure of the present invention. The detailed disclosure herein of one or more embodiments is not intended, nor is to be construed, to limit the scope of patent protection afforded the present invention, which scope is to be defined by the claims and the equivalents thereof. It is not intended that the scope of patent protection afforded the present invention be defined by reading into any claim a limitation found herein that does not explicitly appear in the claim itself.

[074] Thus, for example, any sequence(s) and/or temporal order of steps of various processes or methods that are described herein are illustrative and not restrictive.
Accordingly, it should be understood that, although steps of various processes or methods may be shown and described as being in a sequence or temporal order, the steps of any such processes or methods are not limited to being carried out in any particular sequence or order, absent an indication otherwise. Indeed, the steps in such processes or methods generally may be carried out in various different sequences and orders while still falling within the scope of the present invention. Accordingly, it is intended that the scope of patent protection afforded the present invention is to be defined by the appended claims rather than the description set forth herein.

[075] Additionally, it is important to note that each term used herein refers to that which the Ordinary Artisan would understand such term to mean based on the contextual use of such term herein. To the extent that the meaning of a term used herein-as understood by the Ordinary Artisan based on the contextual use of such term-differs in any way from any particular dictionary definition of such term, it is intended that the meaning of the term as understood by the Ordinary Artisan should prevail.

[076] Furthermore, it is important to note that, as used herein, "a" and "an"
each generally denotes "at least one," but does not exclude a plurality unless the contextual use dictates otherwise. Thus, reference to "a picnic basket having an apple" describes "a picnic basket having at least one apple" as well as "a picnic basket having apples." In contrast, reference to "a picnic basket having a single apple" describes "a picnic basket having only one apple."

[077] When used herein to join a list of items, "or" denotes "at least one of the items," but does not exclude a plurality of items of the list. Thus, reference to "a picnic basket having cheese or crackers"
describes "a picnic basket having cheese without crackers", "a picnic basket having crackers without cheese", and "a picnic basket having both cheese and crackers." Finally, when used herein to join a list of items, "and" denotes "all of the items of the list." Thus, reference to "a picnic basket having cheese and crackers" describes "a picnic basket having cheese, wherein the picnic basket further has crackers," as well as describes "a picnic basket having crackers, wherein the picnic basket further has cheese."

[078] Referring now to the drawings, one or more preferred embodiments of the present invention are next described. The following description of one or more preferred embodiments is merely exemplary in nature and is in no way intended to limit the invention, its implementations, or uses.

[079] It will be appreciated that systems, methods, and apparatus relating to the management of assets are described herein. Systems, methods, and apparatus in accordance with one or more preferred embodiments of the present invention are described largely in the context of asset management systems, and frequently in the context of an asset management system for emergency services sector resources. It will be appreciated, however, that systems, methods, and apparatus described herein could equally apply, and have utility, in any of a number of other contexts as well.

[080] Turning now to the drawings, FIG. 1 illustrates a system in accordance with one or more preferred embodiments having a plurality of discrete wireless islands utilizing common message handling components. In FIG. 1, the system is illustrated as divided into three logical segments.

[081] The left logical segment comprises the plurality of discrete wireless islands. The term island is used to emphasize that each is separate and distinct logically, even if one or more islands physically overlap in coverage. Preferably, each island comprises a radio network, as described in detail hereinbelow. The radio networks preferably utilize class based networking, as described hereinbelow, and wake-up technology. In preferred embodiments, remote sensor nodes (RSNs, which may also be characterized as "nodes"), or tags, connected to a wireless island are attached to, and associated with, assets, or resources, to be tracked.

[082] The right logical segment comprises user connectivity elements, including user applications, as well as network management and configuration servers. In one or more preferred embodiments, RSNs attached to assets communicate information regarding those assets to one or more user applications.

[083] The final logical segment, the middle logical segment, comprises a message management and routing (MMR) system, which preferably facilitates this communication. The MMR
system thus preferably serves as an intermediary for communication between radio and complementary networks on the one hand, and user applications on the other.

Radio Networks [084] A radio network is typically defined by a single gateway server and gateway router (sometimes termed simply a gateway) connected thereto, which can be characterized as establishing an "island" of coverage.

[085] A radio network in accordance with one or more preferred embodiments preferably comprises a gateway server (GS), one or more gateways (GWs, and sometimes termed gateway routers) connected to the gateway server, and a plurality of RSNs connected to one of the gateways. Each RSN preferably includes CBN technology as described hereinbelow, and further preferably includes wake-up technology. The gateway server preferably comprises software and a computing device on which that software runs.

[086] A gateway that is connected to a gateway server is characterized as captured, while a gateway that is not connected to a gateway server is characterized as free. Similarly, an RSN that is connected to a radio network (e.g. to a captured gateway) is characterized as captured, while an RSN that is not connected to a radio network is characterized as free.

[087] When an RSN is captured by a radio network, the RSN can be characterized as a node of the radio network, and can function as both an end point and a routing device.
Further, each gateway includes a gateway RSN, which functions as a communication interface with other RSNs. Thus, in a radio network, each gateway, just like each RSN, can be characterized as a node.

[088] A gateway and gateway server together collectively comprise a gateway controller (GC).
Such a gateway controller can switch between functioning solely as a gateway, and functioning as a gateway controller. A gateway and gateway server that are integrated together can be characterized as an integrated gateway controller, while a gateway and gateway server that are physically separate, and preferably connected by a high-capacity, high-reliability data link, can be characterized as a logical gateway controller.

[089] Notably, multiple gateways can be connected to a single gateway server, and in fact multiple gateways can exist in close physical proximity to each other, all being connected back to a single gateway server. In this case, each gateway functions as a node which extends the coverage area of the radio network, and the entire radio network is associated with the Area ID of the gateway server.

[090] Additionally or alternatively, multiple gateways in close physical proximity can be connected to different gateway servers. In this case, each gateway is associated with a distinct Area ID (the Area ID of the gateway server it is connected to), and thus belongs to a distinct coverage island.
Specifically, because each gateway and RSN of a radio network is associated with the Area ID
corresponding to the gateway server of that radio network, although radio networks may overlap in physical area, they will still remain distinct, as nodes of each radio network will be associated with different Area IDs, and thus will not respond to communications utilizing a different Area ID.

[091] Each radio network in such a case is discrete in that each is controlled by a different gateway controller, which communicates with an MMR system through an application program interface (API). (Notably, however, radio networks may sometimes merge, as described hereinbelow.) [092] An overview of class based networking (CBN) technology preferably utilized in preferred radio networks will now be provided. Such description of CBN technology should be understood to be only a generalization provided for setting a contextual background in technology preferably used with embodiments and implementations of the current invention, but is not required in every such embodiment. Accordingly, such generalization should not be interpreted as applying literally to every possible embodiment or implementation.

Radio Networks - Class-Based Networking [093] In accordance with CBN technology, each node in a class-based radio network has at least one common designation, comprising a class designation, assigned to it. Wireless ad hoc hierarchical networks form using transceivers of these nodes. Preferably, the transceiver is a standards-based radio, and the node includes a second low-power radio (a reduced complexity radio, or RCR) for wake-up, and a controller. The controller operates per class-based networking protocols and per self-configuration protocols that are optimized for class-based networking. This combination enables autonomous reconfiguration and behavioral changes of the node in response to changes in the node's location, the presence of other nodes, changes in a battery level of the node, environmental changes, or other changes.

[094] In contrast to CBN networking, and as described above, older, more traditional ad hoc networks generally form based on physical proximity and/or an effective radio range of the nodes.
Only those nodes that are in radio range of one another (which typically means that they are physically close to one another) can communicate with each other and form a network. In FIG. 2, nodes are shown as including class, but the networks have been formed in accordance with such a more traditional methodology where connectivity is determined by proximity. It will be appreciated that nodes enclosed within each delineated dotted line in FIG. 2 are connected and comprise a network.

[095] In comparison, FIG. 3 shows the same nodes where the networks have formed based on the common class designations of the nodes. Thus, as shown in FIG. 3, nodes sharing a class in common (e.g., having membership in Class "A") communicate and form a network among themselves and are logically distinct and separated from nodes of other classes (e.g., transmissions within the class A
network do not cause any power consumption by the other nodes because the nodes of class B and C
do not receive and process or hop messages of class A). Of course, the nodes still must be within radio range of each other, or otherwise be able to communicate through hopping, in order to form such networks, but other nodes that may be in close proximity but are not of the same class are excluded from the class-based networks. The class designation of each node in FIGS. 2-3 is indicated by the letters "A", "B", and "C". A class may represent a customer, an agency, a type of asset, etc.
Notably, a node may be a member of multiple classes, but, for the sake of simplicity, FIGS. 2-3 illustrate nodes that belong to only a single class.

[096] Within various implementations, RSNs and gateways can be configured to allow only devices of certain classes to participate in certain networks, and RSNs and gateways can be configured into several classes, any of which can be invoked at any time to admit or to restrict participation.
Consequently, RSNs associated with assets of various owners or of various types can be monitored independently of all others that may be at a given locations, yet all share the same network infrastructure. That is, networks can be logically partitioned and segregated, and that partitioning can be used to enable or exclude hopping by certain RSNs.

[097] It will be appreciated that use of the CBN technology contributes to the reduction in battery consumption by minimizing an RSN's participation in networks that are of no value to the owners/custodians of the assets with which the RSNs are associated. CBN
technology further contributes to the reduction in RF noise/interference by reducing the total transmissions that otherwise would be made in a conventional ad hoc network configuration, such as a mesh network. Importantly, however, CBN technology enables an entity such as a governmental authority (e.g. FEMA or the Dept. of Homeland Security) to address any or all radios at a given location using an appropriate "super" class designation.

Radio Networks - Formation and Communications [098] In order to make a free RSN aware of a nearby radio network, a process known as beaconing is preferably used. A beacon is a radio signal that is periodically broadcast by a node, e.g. a gateway, that contains identification information (as well as a check-in period). The beacon effectively announces the presence of a gateway and identifies it. The identification information includes an address of a node that broadcast the beacon, a network class identifier, and the Area ID of the gateway server of the radio network the node that broadcast the beacon is connected to. This network class identifier may comprise all or part of a Class ID (as described hereinbelow), or may comprise a wholly different network class identifier.

[099] When a free RSN receives such a beacon, the network class identifier contained in the beacon is compared to one or more network class identifiers contained in the RSN, at the MAC layer of the RSN. If the network class identifier of the beacon matches any network class identifier contained in the RSN, information contained in the beacon is passed to the network layer of the RSN, which informs the application layer of the RSN of a detected radio network as well as information associated therewith, including the Area ID and node address. The RSN, at the application level, decides whether or not to activate the network layer of the RSN, i.e. attempt to join the radio network and transition the RSN to a captured state. If the RSN decides to join the radio network, the network layer will utilize transmit a communication (which preferably contains a network class identifier of the RSN, and if the RSN contains multiple network class identifiers then preferably includes a primary network class identifier, e.g. a primary Class ID, as described hereinbelow) to the node, for communication to the gateway server corresponding to the Area ID, to attempt to register with the gateway server. Upon attempting to register, the RSN enters a tentative capture state. During this tentative capture state, the tentatively captured RSN can communicate over the radio network, but no other RSN can hop messages through the tentatively captured RSN.

[0100] Registration is dependent upon the application layer, and the RSN
remains in the tentative capture state until an affirmative acknowledgment of registration is received, at which time the node transitions to being fully captured by the radio network. Each RSN stores the Area ID of the gateway server it is currently associated with. Notably, a negative acknowledgment (NACK) could be received instead, thus indicating that the RSN is not allowed to join the network. Each RSN stores a list of Area IDs that it is not allowed to attach to. If a node receives a negative acknowledgment upon an attempt to join a radio network corresponding to a particular Area ID, it places that Area ID within this list of Area IDs that it is not allowed to attach to. Notably, it is possible for registration to be dependent upon a human decision utilizing a customer application, and it is possible for an RSN to move directly into a full captured state without first utilizing a tentative captured state, if desired.

[0101] In at least some preferred implementations, functionality to allow only certain RSNs to access a private radio network is provided utilizing Class IDs. In such a preferred implementation, each RSN of a radio network is associated with a primary Class ID. This primary Class ID defines who owns the RSN and preferably further defines additional grouping information using entity and asset type sub-fields within the primary Class ID field. This primary Class ID
is sent to a gateway server with other information during a network registration process. A private radio network is established by restricting registration with a private gateway server to certain RSNs based on Class ID.

[0102] After being captured by a radio network, an RSN serves to expand the coverage area of the radio network. This is because RSNs are configured to retransmit, or hop, messages from other RSNs, such that the coverage area of the radio network is greater than just the coverage area of the gateway itself. FIG. 4 illustrates a radio network comprising a gateway and four RSNs with an expanded coverage area. The coverage area is expanded to include a coverage area of each of the four RSNs. This is because a message can be hopped through any of the four RSNs on its way to the gateway. FIG. 5 illustrates a larger radio network comprising a gateway and twelve RSNs. In such a radio network, messages from RSNs farther away from the gateway are hopped through intermediary RSNs on their way to the gateway.

[0103] When in a captured state, an RSN preferably ignores messages associated with other gateway servers, i.e. messages including other Area IDs.

[0104] Thus, in a preferred implementation, Class IDs are used to determine whether or not a node can join a given radio network, i.e. in network formation, while Area IDs are used to determine whether or not a given node can communicate with another node, i.e. network communications.

[0105] It will be understood that in such implementations, utilization of Class IDs, Area IDs, and/or network class identifiers can be characterized as an implementation of CBN
technology as described hereinabove, and can be used to determine formation of radio networks, can be used in a radio network to preferentially route messages to RSNs associated with a customer or customer group, entity, or asset type, and/or can be used to limit nodes that can be used to route messages.

[0106] In accordance with one or more preferred embodiments of the present invention, the regular determination of the presence of a node within a network, such as by use of a check-in message, is desirable in order that the location of the node at a location, such as, for example, an incident, may be confirmed and monitored on an ongoing basis. To accomplish this, each node is configured to communicate a check-in message to its gateway at predefined intervals of time.
This predefined interval of time, or check-in period, is communicated to each node via a beacon, as described hereinabove. Thus, "presence information" on each node can be gathered. The gateway communicates this presence information to the gateway server, which can then communicate it to one or more client applications.

[0107] A user application which keeps track of presence information of a plurality of nodes can be characterized as a presence server. A user application may serve as a presence server for all nodes of a network, or alternatively for a subset thereof. The gateway server also may function as a presence server for one or more of the nodes. FIG. 6 illustrates a data communications network 110 having multiple user servers 128,130,132 and client applications as well as multiple locations, each having a presence server. For example, a plurality of nodes associated with EMT assets may be tracked, and the presence information thereof maintained, by a first presence server, while a plurality of nodes associated with police resources may be tracked, and the presence information thereof maintained, by a second, different presence server, even though presence information (e.g., check-in messages) for both pluralities of nodes might be communicated over the Internet, or otherwise, by way of a single gateway server.

[0108] FIG. 7 illustrates an exemplary network 210 including fifteen nodes 211-239 (odd). In FIG.
7, a check-in message originating at node 219 requires three hops to get from node 219 to the gateway 241. The path for the three hops is from node 225 to node 233 via hop 214;
from node 233 to node 237 via hop 216; from node 237 to gateway 241 via hop 218. (Note that the initial transmission 212 by node 219 to node 225 is not considered or deemed a "hop" herein because it is the initial transmission, but this is a semantic difference.) [0109] After the message has been communicated to the gateway 241, the gateway 241 returns an acknowledgment (hereinafter, "ACK") of the check-in message to the initiating node 219. The pathway by which the ACK is communicated is the reverse of the pathway by which the check-in message is communicated, and includes transmission 228 with hops 230, 232, and 234.

[0110] In total, communication of a check-in message from node 219 to the gateway 241 requires four total node transmissions (the initial transmission and three hops), and communication of an acknowledgment from the gateway 241 to the node 219 requires three node transmissions (each a hop) with the initial transmission being by the gateway 241.

[0111] It will be appreciated from the above description and FIG. 7 that nodes 211,213,215 each require four hops in communicating a check-in message to gateway 241; nodes 217,219,221 each require three hops in communicating a check-in message to gateway 241; nodes 223,225,227 each require two hops in communicating a check-in message to gateway 241; nodes 229,231,233 each require one hop in communicating a check-in message to gateway 241. Nodes 235,237,239 do not require any hops in communicating a check-in message to gateway 241 as each directly communicates with the gateway 241.

[0112] The respective number of node transmissions for each of these sets of nodes is set forth in the table of FIG. 8. For example, nodes 211,213,215 each require eight hops or node retransmissions to communicate a check-in message and receive an acknowledgment back. Multiplying these eight required transmissions by the number of nodes, i.e., three, results in a total of twenty-four required node retransmissions for check-in messages from nodes 211,213,215 per check-in interval, e.g., every fifteen minutes.

[0113] It will be appreciated that having a large number of nodes with a pathway to the gateway router 241 including a large number of hops greatly increases the total number of node retransmissions required for check-in messages. As can be seen in the table of FIG. 8, the total number of node retransmissions required for a check-in message and corresponding acknowledgment for each of the fifteen nodes of network 210 is sixty.

[0114] This number can be reduced, however, by taking advantage of path information stored in inbound communications. Specifically, each communication of a check-in message preferably includes a UID of each node along the path the check-in message has actually been communicated along.

[0115] When the gateway 241 receives the check-in message from node 219, the gateway 241 identifies from the pathway the nodes along which the message has hopped, i.e., through intermediate nodes 225, 233, 237. In particular, the gateway 241 analyzes the message to determine the UID of each node along the pathway. Then, rather than only considering the check-in message of node 219, the gateway 241 further utilizes the UIDs of nodes along the path to determine the presence of these additional nodes. The presence information for each of these nodes consequently is updated.

[0116] Importantly, and as outlined hereinabove, the ACK that is sent to node 219 is sent along the reverse pathway by which the check-in message was sent to the gateway 241.
This insures that each intermediate node receives and retransmits the ACK for delivery to node 219.
In doing so, each intermediate node thereby receives its own acknowledgement that its presence, as indicated by the pathway information, has been acknowledged by the gateway 241.

[0117] In this respect, each intermediate node 225, 233, 237 remembers that it passed (hopped) an inbound check-in message from the initiating node 219 and, when it passes (hops) the ACK back to the initiating node 219, the intermediate node 225, 233, and 237 uses the ACK
as a positive indication that the inbound check-in message was delivered. Based on this, each of the intermediate nodes 225, 233, and 237 causes its check-in timer to be reset to zero as if the respective node had sent a check-in message itself and received back an ACK. As such, none of the intermediate nodes will send its own check-in message until its respective time interval for doing so (starting at the time of retransmitting the ACK for delivery to node 219) has passed.

[0118] This methodology is utilized by a node not just when hopping check-in messages, but when hopping any inbound message. Thus, the intermediate nodes 225,233,237 benefit from hopping inbound messages, as each resets its chronometer (clock or timer) for counting down, or up, its check-in interval, no node needs to send a check-in message as quickly as it otherwise would have done if there had been no message hopping. As an example, the outside nodes 211,213,215 may send check-in messages every 15 minutes, with each of all of the other nodes serving as intermediate nodes for the outside nodes 211,213,215, whereby check-in messages for such intermediate nodes would not be required to be sent. In this scenario, only twenty-four retransmissions or hops thus are required, instead of 60 hops as set forth in the table of FIG. 8 (a sixty-percent reduction!).

User Application Elements [0119] FIG. 9 illustrates major functional elements which support customer interaction with a preferred system. Each of these elements interfaces with the MMR system via an Enterprise Gateway Server (EGW). Like gateway controllers, each EGW communicates with the MMR
system through an API.

[0120] Each EGW provides for the mapping of an RSN or other tag associated with a certain UID to a customer-specified IP address. Further, each EGW also provides for the creation and enforcement of business rules relating to which personnel can access which subsystems within the system.

[0121] Each EGW can either be dedicated to a single customer, or shared by multiple customers. In a shared configuration, a shared application provides access to multiple customers. In an alternative shared configuration, a shared EGW provides access to applications of multiple customers.
Conversely, a single customer can utilize multiple EGWs, each tied to a single application, or to the same application implemented in different regions.

[0122] Another functional element illustrated in FIG. 9 is the User/Customer Application Host (HOST). User application hosts, or user applications, can vary widely from entity to entity and implementation to implementation. Generally, such user application hosts comprise a collection of different hardware and software systems supplied by, and used by, an entity or organization. User application hosts typically translate data collected from RSNs (that is then communicated through a gateway controller and an EGW to the user application host), such as, for example, presence and condition data, into useful business information to meet specific organizational needs. User applications hosts can also send outbound messages to an RSN, and, in at least some implementations, can reconfigure an RSN. Preferably, when a user application wishes to communicate a message to an RSN, it sends a request to an EGW. The EGW checks its policies to validate the request. Assuming that the request is an authorized and valid request, the EGW translates a customer device address associated with the RSN to a UID based on a stored registration table.

[0123] Notably, there may often be a significant amount of custom code required for an interface between a user application host and an EGW.

[0124] Another functional element illustrated in FIG. 9 is the Handheld Access Application (HHAA). This optional handheld access application supports basic interrogation and access functionality between RSNs, or tags, and a mobile device, such as, for example, a handheld PDA or PDA-like device. This application will allow users to utilize a PDA or PDA-like device to access the contents of an RSN, and possibly other tags as well, in the field.

Message Management and Routing System [0125] FIG. 10 illustrates an MMR system including four functional blocks, namely: a registration accounting and billing systems block; a network management and customer service block; an authentication block; and a message routing block. Each of these blocks represents a logical subsystem (which may itself be comprised of multiple logical subsystems), and each subsystem may reside on separate platforms or may be integrated. In some implementations, multiple instances of one or more of the subsystems are utilized.

[0126] Notably, the vertical ordering of the blocks in FIG. 10 generally indicates the latency requirements of each corresponding logical subsystem, as can be seen in FIG.
11.

[0127] FIG. 11 additionally illustrates the flow of data between a wireless island, in this example a radio network, and a user application host. These flows are illustrated in the bottom of the figure with the dual ended arrow that links the radio networks and user access. Note that the flow is illustrated as passing through a bottom portion of the message routing block, or functional layer, of the MMR
system. This depiction represents the idea that the MMR system is minimally invasive to data flow.
In this regard, the MMR system operates similarly to Session Initiation Protocol (SIP) in a VoIP
network by receiving a request to route information, validating the request, and then returning a routing address. After this process is complete, the MMR system is no longer involved in the actual data transaction. For example, in order to enable communication between a radio network and a customer application, the MMR system routes addresses to both a gateway controller of a radio network and an EGW associated with a user application, at which point communications between the radio network and the user application will follow the primary data path illustrated in FIG. 12. This approach minimizes latency and is highly scalable.

[0128] FIG. 13 is a more detailed reference model illustrating logical subsystems of an exemplary MMR system implementation. Gateway Controller Emulator (GCE) and EGW edge devices are shown for completeness. At each functional level, each subsystem, i.e. each labeled block, represents a logical element that may or may not be implemented as a standalone hardware system. Further, larger or more complex implementations will likely require multiple instances of one or more subsystems.

[0129] Notably, at least some MMR implementations will not require one or more of these subsystems, such as for example private systems which might not require a billing subsystem.

[0130] Further, as described hereinbelow, hardware (and software) can be collapsed onto a single hardware platform that contains all of the required functions so that the system can be used for dedicated on-site (at incident) deployments.

Mobile Gateways and Merging [0131] Although MMR systems have thus far been described in the context of a "global" MMR
system acting as an intermediary between a plurality of islands and user applications, in an alternative, preferred embodiment, an MMR system is implemented in association with a single gateway controller as a mobile gateway, or "mobile gateway system" (MGS). (Although described as a mobile gateway system, functionality described in the context of an MGS, and specifically merging functionality, could well be implemented fixed in place.) Such an MGS
preferably includes a collapsed MMR system, and thus includes some selected MMR system functionality, although alternatively an MGS may include all MMR system functionality. An MGS further includes one or more user applications, and a mobile EGW for interfacing with the one or more user applications. In at least some preferred embodiments a hand held application server is further included for communication with nearby hand held devices, e.g. PDAs.

[0132] FIG. 14 illustrates the components of an exemplary MGS, including a mobile gateway controller, a mobile MMR system, and a mobile PDA application server. Notably, the components of an MGS may be integrated together, or may be physically separated, or some combination thereof.

[0133] In a preferred implementation, an MGS includes a gateway controller which comprises a reduced complexity radio (RCR), a standards based radio (preferably Bluetooth), a WLAN standards based radio (preferably WiFi), and a gateway server. The RCR and standards based radio are used for communication between RSNs, while the WLAN standards based radio is used for communication between gateways, gateway servers, mobile MMRs, application servers, and application mobile computers.

[0134] Notably, an MGS can be in a different area (e.g. not within WiFi coverage), yet still be connected to other MGSs and applications through a Wireless Wide Area Network (WWAN) such as cellular or satellite.

[0135] It will be understood that MGSs which move from one place to another at times may become located in close proximity to one another. In a preferred embodiment, when two MGSs become located such that coverage areas of their respective gateway controllers overlap (which coverage area is preferably extended via hopping as described hereinabove), a determination is made as to whether to "merge" the two MGSs. Such merging can take place at a network level and/or an application level.

Merging - Network Level [0136] For example, in a simple methodology, network level merging can be accomplished by having one of the gateway controllers function simply as a gateway, as described hereinabove.

[0137] Additionally, or alternatively, network formation and/or communication algorithms and rules could be modified. For example, consider a network which includes "blue", "red", and "green"
RSNs, and "blue" and "green" radio networks. Prior to any network merge, the blue RSNs can only operate within the coverage area of the blue radio network, the red RSNs can only operate within the coverage area of the red radio network, and the green RSNs cannot operate within the coverage area of either radio network.

[0138] In a preferred merging implementations, the red and blue radio networks would merge such that red RSNs could additionally operate within the coverage area of the blue radio network, and the blue RSNs could additionally operate within the coverage area of the red radio network. Further, in at least some preferred implementations, the green RSNs, following the merge, might be allowed to operate within the coverage area of both the red and blue radio networks.

[0139] In at least some preferred implementations, a publication-subscription model is utilized.
Such a pub-sub model may be wholly utilized, or may be partially utilized only for RSNs which do not have any "natural" coverage, such as, for example, the green RSN in the example above. In situations where routing is unknown, a pub-sub model is preferably utilized for alternative routing. In a preferred implementation, subscription information is pushed to a configuration file, thus allowing for the elimination of any pub-sub code when it is not needed, while still preserving merging options.

[0140] In an implementation utilizing Area IDs and Class IDs, the blue network might comprise a gateway controller associated with an Area ID of "blue" that is configured to allow RSNs having a Class ID of "blue" to connect, while the red network might comprise a gateway controller associated with an Area ID of "red" that is configured to allow RSNs having a Class ID of "red" to connect.

[0141] In a first preferred merging methodology, the blue gateway controller might be reconfigured to allow RSNs having a Class ID of "blue", "red", or "green" to connect.
Additionally, or alternatively, the RSNs might be reconfigured to hop communications having a "blue" Area ID or a "red" Area ID.

[0142] In at least some preferred implementations, merging at the network level allows radio networks associated with gateway controllers to merge such that an RSN is able to connect to either gateway controller and still have messages routed to an appropriate user application.

[0143] A high-level methodology for merging two MGSs is now described hereinbelow in the context of MGSs utilizing Bluetooth and WiFi.

[0144] First, MGSs are constantly monitoring a WiFi network for other MGSs.
When two MGSs initially detect each other, they pass information about themselves to each other, including information on if they are allowed to merge together. Assuming they are allowed to merge, the MGSs interconnect their gateway controllers and MMR systems (e.g., mobile MMR
systems) such that an RSN could communicate through either gateway controller and have their information routed to the appropriate functions within the mobile MMR and the user applications.
Notably, once two MGSs connect via WiFi, they continue to communicate with each other so they can sense if they lose wireless connectivity.

[0145] If an MGS loses WiFi connectivity with another MGS, it return its connections to the pre-merge situation within its MGS and alerts applications, through its EGW, that connectivity was lost (this is referred to as un-merging). The MGSs remember this prior connection so that if the same two MGSs re-connect at a later time, they can quickly return their connections to the prior merge configuration.

Merging - Application Level [0146] When multiple MGSs are merged together at the network level, the MGSs send network merge information to their local applications. Further, however, in at least some preferred implementations, merging at the application level allows user applications of each MGS to communicate with one another.

[0147] Specifically, in some preferred implementations, after MGSs merge at the network level and send the network merge information to their respective local applications, the local applications can decide if they want to merge at the application level, and, if so, which application is the controlling, or "master" application for possible RSN behavior changes or other tag data exchanges.

[0148] Although there is preferably only one master application per RSN, RSN
information can be routed to multiple applications running simultaneously, thereby allowing for robust management of RSNs in a large coverage area.

[0149] From an application perspective, one of the MGSs/applications will become a master MGS/application. The decision on which MGS/application becomes the master is controlled by the user application.

[0150] In a more detailed, preferred merging methodology, a mobile MMR system of a MGS
broadcasts a beacon with information allowing a receiving mobile MMR system of another MGS to determine if it should attempt to merge. The receiving mobile MMR system receives the broadcast and checks a stored list of authorized mobile MMR systems to determine if the broadcasting mobile MMR is in a "white list" of mobile MMR systems it is allowed to merge with. If the remote mobile MMR system is in the white list, the local mobile MMR system starts a merging "handshake", as can be seen in FIG. 15.

[0151] Upon completion of this merging handshake, each mobile MMR system forwards a merge authorization request to a local EGW to be forwarded to a local application, as can be seen in FIG. 16.
Each local application must acknowledge, accept the merge, and specify whether it will be a master or slave before the merging process is completed. In at least some preferred implementations, such a decision may be presented to, and made by, one or more users via a user application, such as, for example, being presented to a user via a mobile device such as a PDA. If either application responds negatively, the merge process will terminate. If both applications respond to the request specifying that they should be the master, then the process will repeat. The process repeats until one of the applications decides not to merge, or one application elects to become a master mobile MMR system and the other elects to become a slave mobile MMR system. At this time, portions of application data from the slave application are transferred to the master application, as illustrated in FIG. 18.

[0152] Once this application level handshake has completed, the master mobile MMR will provide the slave mobile MMR with information necessary for the slave mobile MMR to route RSN data to the EGW associated with the master mobile MMR, as illustrated in FIG. 17.
Notably, however, the gateway server of the gateway controller of the slave mobile MMR's MGS
preferably still routes registration requests to a local name location server (NLS), and the local NLS
provides routing and security information to the local GS and remote EGW, i.e. the EGW associated with the master mobile MMR, as illustrated in FIG. 19. All other events are then routed from the local gateway server through a proxy to the remote EGW.

Merging Alternatives [0153] It will be appreciated that one or more possible implementations of merging have thus far been described. However, additional other merging possibilities are contemplated as well. FIG. 20 is a diagram of components utilized in one or more merging implementations.

[0154] It will be appreciated that, in some preferred implementations described herein, prior to merging, inbound messages from an RSN may be routed through a GC of a radio network the RSN is a part of, and then, via an introduction by an MMR system, through an EGW, and to a user application. It will be appreciated that, subsequent to a merge, inbound messages from an RSN
received at a GC might instead be routed to a different user application. This rerouting can be accomplished at any level along the path of the inbound message. For example, this rerouting could be accomplished via use of a proxy as described hereinabove, e.g. routing of inbound messages from a local GC through a proxy to a remote EGW. Alternatively, or additionally, this rerouting could occur at an EGW itself, as illustrated in FIG. 21, or subsequent to being routed through an EGW, for example at a messaging layer or merge layer prior to reaching a user application, as illustrated in FIG.
22. More specifically, FIG. 22 illustrates the use of a bridge to route messages received by an EGW
associated with a first user application to a second user application.

[0155] In at least some preferred implementations, a messaging bus design will be utilized, while in at least some other implementations, one or more messaging queues will be utilized. In a preferred implementation, an MMR system includes a merge administration queue and a messaging distribution queue. Preferably, the merge administration queue is used for administrative tasks associated with merging radio networks and/or applications, while the messaging distribution queue is used to queue messages ready for distribution.

[0156] Overall, in systems including one or more islands, e.g. radio networks, one or more MMR
systems, and one or more customer applications, merging of each of these elements can be accomplished independently or in combination with merging of each other element. This merging can include, or not, merging of user applications such that a master application is elected, and include, or not, merging of radio networks such that messages from nodes of one radio network can be hopped through nodes of what was previously a distinct radio network.

First Responder Implementations [0157] One or more preferred implementations of an asset management system in a first responder context for the management and monitoring of emergency services sector (ESS) resources will now be described. Such a system preferably comprises RSNs, which are worn by first responders, such as firefighters; radio network hardware including one or more of gateways, gateway servers, gateway controllers, and MGSs; user applications for tracking the RSNs and other radio network hardware;
and user devices, such as PDAs or laptop computers.

First Responder Implementations - RSNs [0158] The RSNs preferably generally correspond in size to a cigarette pack, weigh about four ounces, and are powered by an internal power source, e.g., one or more batteries. When used by personnel, RSNs are preferably worn (by clip, pouch, or pocket). In addition to being utilized with personnel, RSNs can be associated with, and attached to, either permanently or temporarily, equipment or assets of interest, such as a police cruiser. Preferably, backup RSNs are kept in a vehicle for use at an incident if required.

[0159] A 1-to-I correspondence of RSN to asset is made with a customer software application communicating with the RSN via radio network infrastructure. An RSN preferably includes fully enclosed antennas for communication with radio network infrastructure.
Further, each RSN
preferably includes an internal clock that is automatically updated/synchronized when the RSN
encounters radio network infrastructure.

[0160] Identification and descriptive data about the asset an RSN is attached to is stored within the RSN and may also be stored in a remote database. For example, personnel, e.g., firefighters, are permanently assigned a particular RSN having a particular UID, which RSN
contains information stored in a memory therein regarding that personnel, such as, for example, profile data including a name, badge number, assignment, agency qualifications, etc. A customer application can subsequently read this data when a given RSN is in communication with network infrastructure.

[0161] It will be appreciated from the above description that each RSN is capable of detecting radio network infrastructure and deciding whether to communicate with that infrastructure as part of that network.

[0162] Further, each RSN is accurately termed a remote sensor node in that each RSN is preferably capable of detecting motion, vibration, and shock, and sensing whether motion, vibration, or shock exceeds certain pre-set conditions, or whether a magnetic reed switch changes state. More preferably, each RSN is capable of sensing Shock (mechanical), Vibration, Motion, No-motion (absence of motion), Magnetic switch state-change, Temperature, Gas concentrations, Radiation, Wind speed &
direction, Biometrics (e.g., respiration & heart-rate), Geographic position (e.g., GPS), Humidity and moisture, Atmospheric pressure, Battery condition (of RSNs), and the passing of a sensor threshold.

[0163] Further, RSNs may communicate with external/separate sensors, either by electro-mechanical connection directly to the RSN (e.g., a "sled") or wirelessly.
External sensors may be mounted anywhere, so long as they can communicate with an RSN. Data from these external sensors are treated the same as data from an RSN's internal sensors.

[0164] RSN sensors can be configured to indicate stress of an asset they are attached to (e.g., an unconscious person). For example, for a firefighter a lack of motion may indicate such stress and a sensed no-motion condition may be indicative thereof. On the other hand, for a law enforcement officer, a mechanical shock (slap) of an RSN that is sensed could be indicative of stress. Such sensor and/or sensor profiles can be configured to become active only when an assets has been assigned a dangerous task, e.g., venturing inside a burning building. A customer application is used to record an assignment of an asset, which causes a command to be sent to the associated RSN to engage an appropriate configuration profile for that asset. In the case of a firefighter entering a burning building, this would cause the no-motion sensing capability to tune on, to await a potential no-motion condition.

[0165] Each RSN is capable of storing/recording (buffering) data related to what it detects and communicating those data to customer applications, via radio network infrastructure, as described hereinabove. Moreover, each RSN preferably appends date/time stamps to all recorded events that it detects and appends a date/time stamp to all communications.

[0166] Each RSN is preferably capable of changing its behavior per sensed conditions (using its suite of sensors) and/or per detected events. The changes are in what events it reports and in the manner with which it interacts with other RSNs and with network infrastructure, including: a check-in frequency, sensor thresholds & conditions, message hopping behavior, a network class identifier, which may comprise a Class ID, and whether to engage certain sensors.

[0167] These changes may be triggered by commands that originate from a customer application or from the network infrastructure, or they may be autonomous. The changes may be triggered by a combination of. date/time, a type-signature signal from network infrastructure, a location of the infrastructure, a location of the RSN, a status of the RSN, a functional mode that the RSN may be in at the time, sensor inputs, and/or a battery level.

[0168] Such changes may be implemented using operational parameter sets or behavioral profiles.
Preferably, each RSN maintains a profile comprising one or more operational parameter sets that include such information as sensor thresholds for triggering an event. A
particular operational parameter set is preferably implemented as a function of location, assignment, or common/class designation.

[0169] As described hereinabove, a radio network can be configured to cause RSNs attached thereto to send quasi-periodical check-in messages to indicate to the radio network that the RSN is still present. The radio network preferably knows when to expect such messages. If a certain number of these messages are not received within some defined period, then the infrastructure preferably sends a message to a customer application that the asset associated with the RSN that failed to check-in is unaccounted for.

First Responder Implementations - Infrastructure [0170] In addition to RSNs, such a system preferably includes radio network infrastructure to effect formation of radio networks utilizing the RSNs. Gateways, gateway controllers, and mobile gateways, as described hereinabove, can be utilized at various fixed sites, such as hospitals, fire houses, or precinct stations, and mounted on mobile vehicles, such as fire trucks or police cruisers, to facilitate formation of radio networks utilizing the RSNs. Preferably, mobile gateways are mounted on mobile vehicles to facilitate the formation of radio networks with nearby RSNs, and to allow radio networks, gateway controllers, and/or mobile MMR systems which come into close proximity with one another to merge together as described hereinabove.

First Responder Implementations - Customer Applications and Devices [0171] Such a system preferably further includes one or more customer applications configured to respond to sensor data received from RSNs and/or configured to issue commands to RSNs. Such customer applications are preferably run on one or more customer devices, such as PDAs or laptop computers.

[0172] Depending on management preference, all or some of the data collected by RSNs of a radio network can be displayed and commands (to RSNs) given via a customer application. For example, when a distress message is received from a first RSN, thus suggesting the distress of an asset the first RSN is attached to, hop-path data, i.e., path information, of the distress message is preferably analyzed to determine a second RSN that was the first RSN to hop the distress message, thereby localizing the position of the asset in distress.

[0173] RSN data can also be stored at other locations, such as at district or mobile command centers.
Stored data can be used later for analysis and process improvement.

[0174] For example, when a gateway controller equipped vehicle returns to its station, all data in the gateway controller's event data record (EDR) memory is automatically uploaded via Wi-Fi link to a fixed gateway controller at the station. The fixed gateway controller then relays the data via broadband data link to an EDR Archive Server located at the Dispatch Center.
Once the Archive Server acknowledges receipt of all EDRs from that gateway controller, the Archive Server will then send a message to the fixed gateway controller to flush/purge its EDR file.
The fixed gateway controller then sends a flush/purge message to the vehicle gateway controller.
Since it is likely that on-scene GC interconnectivity will vary during an incident (i.e., a master, or command, GC will not be able to coordinate all EDRs of a given incident, at every moment), it is likely that multiple copies of the same EDR will be generated and uploaded to the Archive Server. The Archive Server, therefore, periodically reviews all EDRs and purges duplicates. The data of each incident and/or multiple incidents is analyzed later for ways to improve performance. The incident-management application software segregates set-up-and-configuration from operations. This separation permits only authorized/qualified people to set system parameters, such as ping (or PAR) and no-movement alarm intervals. It also prevents others, even ICs, from accidentally changing critical parameters and disabling the system when at an incident (when seconds lost trying to re-establish functionality can mean life or death). All communications are secured by Class ID and encryption. Access to command and control functions is limited to those who have login credentials for customer devices, e.g., various PDAs and laptops, running software such as, for example, AIMSonScene.

[0175] As described above, each RSN interacts with radio network infrastructure such that the following information is available to users via a customer application: a presence of the RSN (and the asset to which it is attached) at a specific location defined by the network infrastructure at that location, when the RSN arrived at that location, when an RSN was last heard from at that location, that an RSN failed to check in, descriptive information about the asset the RSN is associated with, and sensor data or status sensed by the RSN.

[0176] Preferably, the identity of an arriving asset is automatically populated into a user asset-management application, enabling the user to see a corresponding ID and act on it (make an assignment) immediately. This ID data corresponds to a UID stored within the RSN and reported when the RSN connects to the network, although it may comprise a customer identifier translated via an EGW. Such customer applications can also be used to display changes in asset state or condition (e.g., distress), as reported by associated RSNs.

[0177] Further, the user asset-management application preferably can also serve to deny/allow an asset to be included in the record-keeping and asset-management activities facilitated by the user asset-management application (i.e., participate in an incident). The user application may also be used to force a given RSN to disconnect from the local network.

[0178] The system also preferably includes a user application that may be used to display to a large audience the number and assignments of assets and keep those numbers and assignments updated as they change, as a user manipulates the asset-management application on a separate user device.

[0179] To enable a user to view a graphical representation of where assets are when called out to an incident, the system preferably also includes a feed to commonly-available Geographic Information System (GIS) and some Automatic Vehicle Locating (AVL) applications. The GIS/AVL application resides on a customer device at a dispatch center (or elsewhere, such as in command vehicles or at mobile command centers) and is linked to gateway controllers using the same mobile data link that gateway controllers use for incident data. Via this link, the gateway controllers share their own ID
(which may comprise, or corresponds to, an Area ID) and GPS data, as well as the IDs of resource RSNs that are in communication with each gateway controller. Using this data, the GIS/AVL
application displays an accurate map of vehicle locations and, by clicking vehicle icons on the map, reveals what other resources are associated with that vehicle. This functionality is available while vehicles are in motion and stationary, provided their gateway controllers are on, and their gateway controllers have a reliable view of GPS satellites.

[0180] In a preferred embodiment, an AIMSonScene customer application is utilized.
AIMSonScene is NIMS-compliant incident management software available from FieldSoft, Inc. of Chandler, AZ. AIMS can be characterized as premier incident management software, having a full suite of incident management, reporting, and documentation tools, all manipulated in point-and-click fashion. The license is for the Peer-to-Peer (single user) version. In preferred implementations, AIMSonScene is loaded on one or more customer devices, such as a laptop or a Command Vehicle's pull-out work station computer.

[0181] In addition to computers and laptops, PDAs and PDA-like devices are preferably utilized as customer devices. A PDA is preferably equipped with a First Responder Incident Command System (ICS) application which provides basic asset awareness and distress alert capabilities to a user. Such PDAs preferably include a barcode scanner, and RSNs preferably include a barcode, representing a UID of the RSN, to be read by the barcode scanner.

First Responder Implementations - Input/Output Enhancements [0182] Computer Aided Dispatch Systems and Automated Call-Out Systems (CAD/CALL systems) are used by dispatch personnel to assign and request individuals and units (combinations of individuals) to respond to an event or incident. Although most commonly used by public safety agencies involved in fire/rescue and law enforcement activities, these systems are also used by non-public sector organizations as well. Other usage examples include the dispatching of field service personnel, news reporters, customer service personnel and other people and equipment that may be required on an "on call" basis. These systems, using a variety of manual, pre-planned, or automated techniques, determine who or what should be called ("dispatched") to respond to an event or incident.
The actual contacting of the individual may be by voice radio, data dispatch, land line or cellular voice, paging, email or some other alerting technique including public broadcasting or area-wide sirens. The individuals that are called may be called individually or in groups. Each called person may respond directly to the "dispatch" by some means or may simply travel to a meeting point or incident as directed. In many instances, the calling party or system (referred to as "the Dispatcher"
hereinbelow) may not receive positive or negative confirmation that the person actually received the dispatch request or has actually arrived at the prescribed location. The Dispatcher may have to rely on some other means to obtain positive or negative confirmation of each individual's presence (or lack thereof).

[0183] Similarly, on-site Command Officers or others tasked with coordinating the personnel or equipment that has been dispatched may not be aware of who/what was dispatched. Typically, the on-site Command Officers (or others) have to use some other means to determine who/what is at the incident. In many instances, the dispatched individuals "check-in" with the on-site Command Officers either in-person, by radio or phone, or with some other technique such as sign-in boards. In turn, Dispatchers commonly do not know who or what has arrived at an incident, much less when they actually arrived at the incident in response to their dispatch. Dispatchers and on-site Command Officers are commonly in a quandary as whether to request additional personnel/assets to respond or to simply wait for the original personnel/assets to respond.

[0184] In a preferred implementation utilizing radio networks, a CAD/CALL
system is enhanced to download to an on-site Command Officer or a designated coordinator the names, units, or equipment that has been dispatched to provide the Command Officer with a-priori knowledge of who and what to expect to arrive at the scene. This information is downloaded to the Command Officer through the use of a backbone link from the CAD/CALL system to an ESS system that is either en route or already on site. Alternatively, the information is downloaded to an application that provides similar functionality to the ESS system that is used to monitor the presence and condition of assets in non-public safety applications. With the advanced knowledge of who/what has been dispatched, the Command Officer will be better equipped to manage the resources and activities that are or will be involved in the incident.

[0185] As resources arrive at the incident and radio network architecture associated with each resource is detected, this presence information is stored and/or transmitted back to the CAD/CALL
system to confirm that the dispatched resources actually did arrive at the incident. Their arrival time, as automatically detected, is preferably also forwarded. Using this information, the CAD/CALL
dispatch then determines if additional or alternative resources should be dispatched. The on-site stored information or the information transmitted back to the CAD/CALL system is also be used for post-incident analysis to determine when dispatched resources actually arrived.
Preferably, the dispatched personnel responded to the dispatch with an estimated time of arrival, and this time is compared to the actual time and presence status of the personnel to determine if a commitment has been made, if an estimated interval until arrival has not been exceeded, or if the estimated interval until arrival has been exceeded, to help the Dispatcher make timely decisions.

[0186] Most CAD/CALL systems maintain a "call out" list of available resources. These lists may be static, pre-planned lists that, for example, assume that a resource is located at some pre-determined location (for example: a fire truck stationed at a fire station). For individuals, these systems may contain a call-out priority number listing. For example, between 10:00 PM and 7:00 AM, use the person's home phone number, and between 7:00 AM and 6:00 PM, use the person's work number.
These listings may be manually updated either by the individual or dispatch personnel when they receive new information regarding the actual location of the asset. The CAD/CALL systems themselves may update the information if the asset has already been dispatched to another location. In all of these cases, there is no or very limited real time information regarding the actual whereabouts of the asset. To address this situation, gateway controllers are placed at locations where assets are commonly present. This information is then sent to the CAD/CALL system to provide a last known location update that is used in-place of the static, predetermined location information normally used by the dispatch algorithms. As an example, consider an ambulance, equipped with an RSN, parked at a hospital emergency room instead of at a fire station. If the hospital is equipped with a gateway controller, then the ambulance's presence is forwarded to the CAD/CALL system to provide more timely location information to enhance the system's dispatch logical choices.

First Responder Implementations - Using Hop-Path Information [0187] One or more preferred systems in which nodes hop messages have been described hereinabove. Preferably, a record of the path a given message travels is stored, e.g., at a management element of a respective network. Such a record includes an identification of each node along the path, including an identification of the first node that handled the message after communication by the originating node. There is a strong likelihood that this first node is nearer to the originating node than are the other nodes along the path, although, due to the vagaries of radio propagation, this may not always be the case. However, as this first node often will be the nearest node to the originating node, and at other times will likely still be located generally proximate the originating node even if not the nearest to the originating node, it is advantageous in many applications to identify this first node.

[0188] In a preferred implementation, hop-path information is used in a first responder context to identify a first responder who is in a position to assist another first responder. More specifically, RSNs are uniquely assigned to first responders, and each first responder wears his or her assigned RSN. Each RSN is configured to originate a distress-alert message when it detects that the person to whom it is assigned might be incapacitated. When an RSN originates such a distress-alert message, the path along which the message traveled is recorded and stored. Preferably, the distress-alert message includes an identification of the originating RSN (and/or the person in distress), a type of the distress-alert, and hop-path information for the message (e.g., an identification of each RSN, and possibly each gateway as well, along the path). A user application, such as for example a first-responder software application available to an incident commander via a PDA, can read a record which stores this hop-path information, and thus identify one or more RSNs along the path.
Preferably, the application identifies the first RSN that handled the node after the originating RSN.
As each RSN is uniquely assigned to a first responder, the first responder associated with that first RSN can be identified, i.e., a likely closest responder. Preferably, the application is able to access information regarding the association of each RSN, and performs such identification of the likely closest responder. Once the likely first responder is identified, that person can be contacted, such as by the incident commander via voice radio or automatically by the application.

First Responder Implementations - Using GPS Information [0189] In one or more preferred implementations, network elements, such as, for example, routers, gateways, and/or RSNs, have GPS capability, and GPS information is utilized, preferably in conjunction with hop-path information. Furthermore, records storing hop-path information also store an identification of a first gateway that collects a given message from an RSN
network. A user application is configured to display a GPS-derived map of the geographical position of such first gateway. In the above example of an incident commander, this would be advantageous in providing a coarse geographical indicator of where a distressed first responder might be located, and, which other first responders might be located proximate the distressed first responder.

First Responder Implementations - Personal Alert Safety System (PASS) [0190] In a preferred implementation, first responders utilize Personal Alert Safety Systems (PASS), or RSNs implementing PASS functionality, that cause a distress-alert to be sent to an incident commander (e.g., via his PDA) at the same time that a local alert, i.e., an audible and visual indication that can be seen and/or heard by other persons in close proximity, is activated.

[0191] As noted hereinabove, RSNs are configurable devices. Similarly, PASSs utilized in preferred implementations are preferably configurable devices as well. Either configurable device preferably includes configuration profiles that can be selected based upon the activity a wearer is engaged in, or the task assignment a wearer has been given. These configuration profiles can further be selected based on both whether a distress-alert is engaged or disengaged, and whether a distress-alert is currently being actively originated from that device. Further, these devices are preferably configurable to select an amount of time which elapses between a distress event and notification of an incident commander. It is believed that such configuration will both help to obviate false alerts to incident commanders, and that it is more likely that an incident commander will be notified only after enough time has elapsed for nearby assistance to be rendered. Notably, however, this period must be short enough so that he will be notified soon enough that assistance he calls in will still be effective.
First Responder Implementations - Pre-Assignment [0192] In at least some preferred implementations, pre-assignment enables the association of specific individual assets to specific units prior to the commencement of an incident. Preferably, this pre-association data is automatically available for use by a user application when an incident is started, thus helping minimize an incident commander's (IC's) burden of manually assigning people to units on-scene. Preferably, a "unit" is a group of people having a common designation (e.g., Engine 12) that is managed and assigned as that group. Such a unit usually includes a permanently associated vehicle for transport and executing assigned tasks. Who or what is part of a unit is established prior to and survives a given action or incident. A "team" is a group of people having a common designation (e.g., Rapid Intervention Team) that is managed and assigned as that team.
However, a team usually does not include a permanently associated vehicle for transport and executing assigned tasks. Who or what is part of a team is usually established for a given action or incident and may not survive it.

[0193] Conventionally, assignments are sometimes made using hook and loop fastener tags. One or more preferred implementations may be designed or configured to mimic such assignments.

[0194] In a preferred implementation, a user, utilizing a pre-assignment application, can use a fire-agency-supplied roster of standing available assets/resources to create/store appropriate data about the standing available resources in a database (a master resource database, e.g., a PADB) for use with/by the pre-assignment application, across the entirety of a given agency.
Preferably, this database also records to which station and shift each resource belongs. A designated user for each station, battalion, and/or the agency uses the pre-assignment application to associate individual assets to units per the schedule of assets and units assigned by station/agency authority for each shift.

[0195] Preferably, each MGS maintains a copy of the PADB, and at scheduled times, and once at the start of each incident, this copy is updated (assuming connectivity can be established with the PADB). The best-available data from that copy is used by the one or more user applications at active incidents.

[0196] In at least some preferred implementations, at the start of an incident, the MGS queries the PADB for pre-assignment data for only those units whose RSNs register with that MGS, and the copy of the PADB that is maintained by each MGS is updated via a cellular or other wireless data link between the MGS and the PADB.

[0197] At an event scene, as individual assets actually arrive (e.g., their RSNs register with a local MGS), in a user application, they are automatically associated with the unit to which they were pre-assigned, as read from the PADB data.

[0198] The pre-assignment data retrieved from the PADB by each MGS is preferably used by a user application (as presented on a PDA or laptop) to automatically associate/organize the units, and those assets that were pre-associated with those units. In this way, the Incident Commander is relieved of the task of making those associations himself on-scene (and of needing to have any knowledge of them), thus enabling him to assign units to tasks and have the individual assets automatically track the units' assignments, yet the accountability of the individual assets is preserved.

[0199] At an event scene, the presentation of pre-assigned individual assets are distinguished on a resource manager's (e.g. an IC's) user interface (PDA or laptop) as being confirmed or unconfirmed, as determined by the registration (actual arrival) of each asset's RSN with the local wireless network established by the MGS. That is, an asset is a confirmed asset once it has arrived (as evidenced, for example, by registration of an RSN associated with a resource with an MGS).

[0200] In preferred implementations, one or more mobile gateways, such as, for example, an MGS
on a Battalion Command Vehicle (BCV), will be present at an incident.
Preferably, the MGS stores a local copy of the PADB, and, when the MGS is on, it updates its copy of the PADB at least once every 24 hours.

[0201] When an incident begins, the MGS queries for an update. The IMS uses the association data for the applicable shift to populate a user application on a PDA (or laptop) for the units that arrive on-scene. Individual assets that are on-scene and that have RSNs are automatically assigned with the units to which they were pre-assigned, if any. Pre-assigned assets that are not on-scene are shown in their unit's Assets-on-Board as unconfirmed. When they arrive, they are shown as confirmed. On-scene assets with RSNs that have no pre-assignments, must be assigned singly.
An IC may attach/detach and re-assign any asset to/from any unit regardless of whether that asset was pre-assigned. Preferably, however, any such changes expire with incident termination and have no effect on the PADB.

[0202] It will be appreciated that BCVs often serve multiple stations to provide incident command at all but small incidents. In at least some preferred implementations, only BCVs will have MGSs, and there will be no GWs at stations. A given BCV may encounter vehicles in its battalion only at incidents and will encounter vehicles of other battalions and mutual aid resources only at incidents.

[0203] In preferred implementations, to make pre-assignment data available for an incident -regardless of an asset's home station or agency - each station uploads pre-assignment data of its assets to a database-in-the-sky (e.g., a PADB), and MGSs download this data via cellular/wireless link. In at least some preferred implementations, a system requires a cellular modem and service.

[0204] In one or more preferred implementations, drag-and-drop making of assignments are enabled, multi-station & multi-shift assignments are accommodated, auto shift synchronization is included, auto query & updates from a database are included, auto DST
synchronization is included, temporary shift assignments are accommodated, merging is accommodated, mutual aid is accommodated, assignments may be printed, assets may be added, transferred, or deleted, units may have either RSNs, MGSs, or a mix, assets may be auto-matched to units on scene, confirmed vs.
unconfirmed assets may be distinguished, and/or plumbing for third party applications is included.

[0205] In one or more preferred implementations, a PADB is stored on one or more servers that may be located at a central point or that may be distributed among multiple physical servers at one or more locations, owned/operated by multiple separate entities.

[0206] In one or more preferred implementations, barcode-reading, RFID, and other wireless technologies may be employed to identify and enter asset and unit data into the pre-assignment user application to make associations between assets and units.

[0207] In one or more preferred implementations, association data that is entered into a pre-assignment user application, rather than being entered manually by a person using the pre-assignment user application, is entered automatically through a software linkage (e.g. an API - Application Program Interface) between a system that is used specifically for assigning people/assets to groups and the pre-assignment user application.

[0208] In one or more preferred implementations, a magnetic switch in an RSN
is configured to allow a user to run an RSN associated with that user over a wall-mounted sensor at a station that corresponds to the user's assignment, which causes an association to be made.
Additionally, or alternatively, the station may include a gateway, and an administrator may load assignments to appropriate vehicle gateways.

First Responder Implementations - En-Route Pre-Assignment [0209] In a preferred implementation, pre-assignment is supported en route to an incident. If a vehicle includes a MGS, and a mobile device such as a PDA or laptop with an appropriate user application loaded thereon, a user on-board can utilize the mobile device to associate the assets on board to that unit. Via their RSNs, the presence of resources (including people and equipment) on board could be automatically presented on the mobile device, and the resources could be assigned to the unit. Preferably, when that unit arrives on scene, the IC would be immediately notified of the unit's arrival, and would automatically be provided a list of resources on board. Additional data regarding the unit or its resources could be queried with a single click.

[0210] In a preferred implementation, assignments, including en route pre-assignments, are possible via a barcode scanner. Preferably, a mobile device such as a PDA includes a barcode scanner, each resource is associated with an RSN which has a barcode thereon, and association of that RSN can be accomplished via scanning of the RSN's barcode. Alternatively, or additionally, RFID technology may be utilized.

First Responder Implementations - Exemplary Scenario [0211] An exemplary scenario illustrating the use of a preferred first responder implementation is now described. Notably, the following exemplary scenario will be understood as describing the merging of gateway controllers and user applications. The following exemplary scenario will also be understood as describing gateway controllers, but, notably, some or all described gateway controllers could be a part of an MGS, which could additionally include a mobile MMR, as described hereinabove.

[0212] At 00:37 on a Saturday morning in late January, an automatic alarm is received by the Benson PSAP regarding a fire at a small storage warehouse located in one of Benson's industrial parks. Just seconds later, a single call is received by the Benson E-911 PSAP
from a citizen returning from a late-shift job about a possible fire near that same location.

[0213] The E-911 Operator, via online records and a GIS system that maps the caller's and the automatic alarm's locations, can confirm that the incident is in an industrial park, that this industrial park has flammable liquids stored there, and that the park borders an interstate highway.

[0214] The E-911 Operator immediately connects provides this information to the Dispatch Center and connects the incoming call to the Dispatch Center. This information is additionally provided, via data link, to Benson's CAD system. The Dispatch Center, following SOP for the apparent magnitude of the fire, voice-dispatches police, fire fighting units (two pumpers and a ladder), and an on-duty Fire Commander, using a simu-select function on the Dispatcher's radio console.
Given the time of day and day of week, the Dispatcher assumes that few if any civilians will be in danger, and that any first-aid treatment that may be needed can be handled by the fire fighting units;
so, no EMS unit is dispatched.

[0215] The night-duty Sheriff's Dispatcher and the local Highway Patrol officer on duty hear the call-out, but they take no action. The first to arrive at the scene is a Benson Police cruiser that happened to be nearby on regular rounds. The one police officer of that cruiser reports his arrival to Dispatch and to his supervisor (via radio), confirms that there is a fire in the small warehouse, and establishes initial incident command. He also requests the presence of the Police Shift Supervisor.
The Shift Supervisor responds on the Dispatch channel that she is responding, turns on her vehicle-mounted gateway controller (using her PDA), and immediately proceeds to the scene.

[0216] That gateway controller self-initializes and immediately logs the presence of the Shift Supervisor (via the RSN she is wearing). The activation of the gateway controller, the presence of the Shift Supervisor, and the GPS coordinates of her vehicle are relayed back to the Dispatch Center via cellular modem.

[0217] En route, the Police Shift Supervisor requests two additional Police patrol units, which she plans to use for traffic and perimeter control. When she arrives at the scene, an RSN attached to the police cruiser of the first police officer connects to her gateway controller, which automatically detects and logs the presence of the first police officer. Within a few minutes, the two additional Police units arrive. Their presence is also automatically detected and logged as RSNs associated with each connect to the gateway controller associated with the Police Shift Supervisor. All of the presence updates are automatically recorded as EDRs, are visible on the Shift Supervisor's PDA, and are relayed to the Dispatch Center. The Police Shift Supervisor is briefed, then assumes incident command. She then sends one of the police officers to secure the interstate highway. The remaining two are assigned to establish a perimeter.

[0218] A few minutes later, the two pumpers, each including a gateway controller, the ladder, and the Fire Commander's vehicle arrive together. The Fire Commander is accompanied by a Communications Officer (i.e., Command Technician). All three gateway controllers are turned on (en route, the Fire Commander turned on a gateway controller mounted to his vehicle using an AIMSonScene-equipped laptop).

[0219] Each of these gateway controllers, as well as the Police Shift Supervisor's gateway controller, automatically detect and recognize each other. The customer device associated with each, i.e., the Police Shift Supervisor's PDA, the Fire Commander's laptop, and PDAs of personnel of each pumper, prompt their users to confirm who will be incident commander (IC) going forward. A
briefing conference among the four (including the then-IC) results in the Fire Commander being selected as the IC going forward. He uses his laptop to so indicate (and preferably each other user utilizes their PDA to indicate this as well), which results in his gateway controller being deemed the Command, i.e., master, gateway controller, and, preferably, the associated mobile MMR system being deemed the master mobile MMR system. The other customer devices, i.e., PDAs and laptops associated with the gateway controllers of the other vehicles display this event, those customer devices become view-only, the associated gateway controllers become slaved to the new Command gateway controller, as described hereinabove, and data is synchronized. All the units (gateway controllers) then on-site, Police and Fire, are displayed on all user devices, and all RSNs are logged.

[0220] Viewing his laptop, the IC sees at a glance what emergency services sector (ESS) resources are present and can query profile data (including identification information originally stored in each RSN and sensor acquired data) of any of those resources. Using point-and-click commands, he can log and track assignment of units and of individual personnel, corresponding to his actual (voice) commands.

[0221] As part of the initial detection of presence, gateway controllers have automatically downloaded the centrally-stored profiles of each ESS resource and compared each profile to the profile read from each resource's RSN by the gateway controllers. This comparison allows the IC (or other authorized users) to verify credentials and make changes to Class/group assignments, as needed.

[0222] The IC refers to his laptop, checks the resources on-site, makes an initial assessment of the situation, declares and notifies Dispatch that he has a Working Fire, makes his initial plan of attack, and begins to assign units (by voice/radio and on his laptop). Per his initial plan, the IC assigns the two pumpers to the A-Division (the IC's side or A-side of the building). Those vehicles are positioned accordingly, and the firefighters pile out of their vehicles and begin to unload their gear and pull hoses, as one pumper proceeds to a water source. The ladder is assigned to search and rescue, as well as ventilation. The IC has also determined that, as a precaution, another pumper is needed on the far side of the warehouse (C-side), and that he will need additional units for relief. So, he has his Communications Officer call for an additional pumper and a ladder, directing that the additional pumper report to the C-side and the additional ladder to the A-side. He also decides that he will need more illumination than the vehicles provide, so he also has the Communications Officer call for a light unit. Dispatch has meanwhile filled out the working fire, full-alarm assignment by dispatching an EMS unit for rehab and standby, and a Safety Officer.

[0223] A few minutes later, the Safety Officer (SO) arrives and turns on his (Wi-Fi-equipped) PDA.
The Command gateway controller automatically detects the presence of the SO
and his PDA, reporting the SO's presence on the IC's laptop. The SO's presence is logged (and displayed at the Dispatch Center as a resource on-site), and the SO's PDA downloads from the Command gateway controller information regarding the presence of personnel and equipment then on-site. Like the other PDAs, the SO's PDA is updated as resources arrive, assignments are made, and alerts occur. (The SO
was automatically dispatched to the scene when the IC declared that he had a Working Fire.) [0224] The firefighters assigned to the A-Division begin to apply water to the building. The seat of the fire appears to be some distance in the interior. So, as the perimeter flames subside, a unit from the A-Division is assigned to attack the fire in the interior, and that unit enters the burning building.
Using a customer application, AIMSonScene, the IC moves a unit label on his laptop's screen to indicate that they are assigned to the Interior Division and that they are a fire-attack unit (as opposed to some other task). An Interior assignment has been configured by the Benson FD as a hot-zone assignment. Consequently, the assignment of this unit to Interior (in the user application) has automatically caused the RSNs of the firefighters associated with that unit (one of the pumpers) to engage their no-motion sensors. These sensors automatically cause an alert to appear on all customer devices if any of those RSNs, and thus those firefighters, is stationary for more than 2 minutes. Such an alert could be indication of distress, affording the IC remote notification should a PASS device fail or not be heard, or if others nearby are unable to help. Meanwhile, the Command gateway controller has automatically been keeping track of the periodic check-ins of all RSNs, and has received check-ins from all that were logged in. Had any RSN failed to check in, an alert would have appeared on the IC's laptop (and on all other customer devices). Twenty minutes after the IC
arrived, the warehouse manager arrives. He informs the IC that there had been two night-watchmen in the warehouse, and that he has not heard from them (on their private, on-site radio system).
Since no one else is supposed to be in the building, the warehouse manager does not know whether the radio system has failed, the watchmen are disabled, or they are simply out of range. The IC immediately tells his Communications Officer to call for an additional EMS unit. Then, using his tactical fire radio channel, re-tasks the Interior Division unit to search for the night-watchmen.
Using his laptop, he changes the unit's assignment to Rescue. A few minutes later, the third pumper arrives, on the C-side of the warehouse, out of sight. The gateway controller mounted on this third pumper is turned on.
The third pumper's gateway controller merges with the Command gateway controller, the RSNs of the firefighters on that pumper are logged in, and the IC notes the unit's arrival on his laptop. Using his laptop, he calls up the asset data (stored in the RSNs) of the firefighters onboard and notes that two of the firefighters on the third pumper have hazmat qualifications. The IC
assigns this unit to hosing down the far-side interior of the building, to help cool the structure and minimize the risk of the fire's spreading to the flammable liquids he suspects are stored on the adjacent property.

[0225] The fire has been burning for almost an hour, and the crews of the first two pumpers have been in action for about 30 minutes and need relief, when the second ladder arrives, with the light unit right behind. The IC has heard the ladder, but, due to the noise and darkness, he initially knows that the light unit has arrived only by its "Present" status having been reported on his laptop. (RSNs mounted to the second ladder and light unit have been automatically detected by a gateway controller, that gateway controller has reported it to the Command gateway controller, which reported it to the IC's laptop.) The IC calls the light unit operator over and gives him instructions where to set up and what lighting he needs.

[0226] The IC has already designated an area for Rehab, and he now has two relief crews (the two ladders now on scene).

[0227] He makes a radio call to the original pumper unit that is still working outside (the A-Division) that relief is coming up. He also calls the unit inside the building, but both members fail to respond. Using his laptop, he manually sends a ping to the RSNs of that unit.
The RSNs respond, but another radio call fails to get a response. A few seconds later, the IC's laptop gives an alert that both RSNs of the crew inside the building have not moved in the past 2 minutes. The IC immediately tasks the RIT (Rapid Intervention Team) to search for the unit inside. (The RIT was automatically dispatched to the scene when the IC declared that he had a Working Fire.) [0228] The relief unit replaces the original pumper unit of the A-Division.
The original pumper unit goes to the designated Rehab area. On the way, the unit's members check in with the IC, and he changes the unit's status on his laptop, so as to disable no-movement sensors of their RSNs (because they are no longer in a hot-zone assignment). The assignment of the relief unit is similarly changed to indicate its status as working the fire, in the A-Division, activating the no-movement sensors of the RSNs of that unit's members. A couple of minutes later, the warehouse manager races up to the IC to tell him that he remembers that some hazardous chemicals were recently stored on the far side of the warehouse. The IC, having earlier noted the hazmat qualifications of two of the firefighters of the C-Division, via radio tasks that unit to find and report the condition of the hazardous material. Using his laptop, the IC changes their status to indicate that they are in the building, and on a hazmat detail (e.g., in the hot zone). The IC then has the Communications Officer call Dispatch and tell them about the presence of hazardous material on-site. The Dispatcher initiates a DCC
call-out scenario to alert other City workers and public officials that a hazmat incident may be occurring. The DCC system starts its automated call-out sequence, to have the appropriate resources standing by and ready to come to the incident site.

[0229] As this is going on, the additional EMS unit arrives. The RSN attached to the vehicle and the personal RSNs of the responders are automatically detected and logged in.
These events are seen by the IC on his laptop. The Command gateway controller also sends a message to the Dispatch Center via a cellular connection (preferably using the mobile MMR system as an intermediary for an EGW to GCE communication as described hereinabove) that the additional EMS unit has arrived. The ID of this unit, along with all of the other vehicles that are already on-site appear on the GIS display at the Dispatch Center. The GIS display is also used to keep others apprised of the resources at the incident.
Other Dispatch Center personnel relay the information to other agencies and jurisdictions, and by monitoring dispatch traffic, keep others (including PSAP Operators, Sheriff, Highway Patrol, etc.) informed.

[0230] For example, when the Communications Officer requested the additional EMS unit, Dispatch also notified Mercy Hospital's ER via landline that an additional EMS unit had been dispatched to a major fire and that some unknown hazardous material may be involved. When that EMS unit later arrived on-scene, that unit confirmed its arrival and assignment with the hospital via HEAR (Hospital Emergency Alerting Radio).

[0231] Moments after the arrival of the additional EMS unit, the IC's laptop alerts him that the RSNs of the Interior Division unit that had earlier not been moving are now moving. He makes a radio call to that unit but stills gets no response. So, he makes a radio call to the RIT, and they respond that they have both the other unit and the two night-watchmen in hand and are making their way out. The IC sends two of the EMS personnel and two firefighters who have been resting to help bring the six who are in the building out.

[0232] As they leave to enter the building, on his laptop, the IC makes the required assignment changes for those in the building and grouped with the first rescue team.

[0233] About that time, the team detailed to hazmat reports via radio that the hazardous material is secure and that their side of the building is not in danger. So, the IC re-assigns the entire unit to the A-Division (to the IC's or A-side of the building) to fight the fire from there. In doing so, he uses his laptop to record the assignment accordingly. The IC also has the Communications Officer call Dispatch to give them an update that the hazmat situation is under control and that no danger exists.
Dispatch sends an alert for the hazmat response teams to stand down.

[0234] While the re-assigned crew and pumper are in transit to A-side of the warehouse, the IC
receives a call from his Assistant Fire Chief. Both the Assistant Chief and the Watch Commander have been following the incident - the Assistant Chief from his laptop at the station, and the Watch Commander from his command post. The Fire Chief, however, has been notified at home and is also following the incident on his laptop. Due to the reporting from the Command gateway controller, all know that all dispatched assets have reported at the site, but the Assistant Chief has nonetheless called to inquire about status and whether county resources may be needed. The IC
replies that the fire is under control, but that there may be some injuries, about which he will know more momentarily. The fire is out. Equipment is being collected and loaded. One EMS unit has left for the hospital with a night-watchman who has a sprained ankle and first-degree burns on his hands and forearms.
Resources that have left have been manually logged out of the IC's laptop, as well as having automatically disappeared as their gateway controllers and RSNs move away from the gateway controller attached to the IC's vehicle. The EMS unit communicates directly with the hospital that they are en-route and provides particulars regarding the patient's injuries and their ETA. Upon arrival at the ER, a local, fixed gateway controller at the hospital detects the EMS
vehicle's arrival and reports the unit's presence to the Dispatch Center, where it is displayed on the GIS system. Before releasing responding units and using the data and logs generated by the TeraHop system and AIMSonScene, the IC conducts a short, informal de-brief of the incident among the commanders on-scene, i.e., the personnel with PDAs. Among other things, during that de-brief, the IC learns that the first rescue team had stopped moving because they had come to a dead end and then were immediately blocked from retreat by falling debris.

[0235] They did not respond to radio calls because there was no radio coverage in the confined basement area in which they were trapped. They were rescued by the second rescue team, and together they found the night-watchmen in a secure room.

[0236] As the last resource leaves (a Police cruiser), the IC makes one last check that all RSNs and resources have logged out before closing the incident and uploading all appropriate data to Benson's data center (Archive Server). The warehouse manager is left to deal with fire inspectors, his insurance agent, and the owner. As each Fire vehicle returns to its station, a gateway controller permanently located at each station communicates with each vehicle-mounted gateway controller.
This communication automatically uploads all stored incident data to Benson's Archive Server, checks each vehicle-mounted gateway controller for a correct software version (and downloads needed updates), resets temporary settings, and reports resource status to Central Dispatch.

[0237] Two weeks later, Benson's Fire Chief, as part of his regular practice, conducts a formal review of the incident, to look for ways to improve performance. The data and logs generated by the TeraHop system and AIMSonScene that night, which were transferred by the Command gateway controller to the Benson Archive Server, are instrumental in reconstructing the incident and how the Benson ESS units responded to it. AIMSonScene was particularly useful in generating the incident narrative and populating NIMS and other official forms.

[0238] Two months later, in preparing his budget figures for the coming year, the Benson Fire Chief prepares a proposal for funds to expand the implementation of the managing entity system to include all of the City's fixed ESS locations. He figures that having gateway controllers at every fixed ESS
location will be particularly useful when logging resources back in when they return from an incident, for better management of multiple demands. He is also assisting the Police Department and the Emergency Management Director prepare similar funding requests for their respective systems.

First Responder Implementations - Exemplary Merging Scenario [0239] As a supplement to the exemplary scenario provided hereinabove, an exemplary merging scenario will now be described. As with the above scenario, the following exemplary scenario will be understood as describing gateway controllers, but, notably, some or all described gateway controllers could be a part of an MGS, which could additionally include a mobile MMR, as described hereinabove.

[0240] In response to an incident, emergency services sector resources are dispatched. A fire engine, Engine 42, is first to arrive on-scene, as illustrated in FIG. 23. As the first on-scene, the on-board unit commander assumes incident command.

[0241] By the time the engine arrives on-scene, the unit commander will have already launched a user application, for example via his PDA, and started an incident number. The GC on-board the engine will have already logged the RSNs of three firefighters on-board and reported their presence via the PDA. The GC may have already communicated with dispatch and uploaded incident data, GPS coordinates, etc. Dispatch will likely have given the unit commander an incident number.

[0242] Assignments are made to the firefighters by radio/voice. These assignments are then entered by the now-IC via his PDA, which sends corresponding messages to the RSNs of the firefighters.

[0243] Next, a ladder, Ladder 12, arrives with a crew of 3, as illustrated in FIG. 23. Ladder 12 has a user application already running and has reported presence/status data on the unit commander's PDA.

[0244] The GC's of Engine 42 and Ladder 12 recognize each other and cause the encounter to be displayed on the separate instances of a user application loaded on both PDAs.
Each user confirms acceptance of the other unit as a member that they want to connect to.

[0245] The instances of the user application on the PDAs respectively ask both the IC and the arriving unit commander whether he is the IC going forward. The two commanders confer (by radio/voice) to decide who is going to be the IC going forward. The agreed-to IC indicates that he is going to be the IC going forward via his PDA.

[0246] The GC to which the agreed-to IC's PDA is communicating becomes a master GC, with the other GC slaved to it (acting at least as a GR). The other PDA becomes a view-only device, and can neither issue commands nor make assignments. Records from the now-slaved GC
are copied to the master GC's DB, and combined presence/status data is displayed on both PDAs.
All subsequent changes in assignment and alert messages are also displayed on all present user devices.

[0247] Thus, the incident island network expands to encompass the two GCs and 6 RSNs, as illustrated in FIG. 24. This happens automatically without noticeable delay, and without further attention by the IC, once the who-is-the-IC button is pressed on one PDA. To the IC, the two formerly separate islands now behave as if they are a single island, and unit RSN associations are preserved.

[0248] Next, a battalion commander, BC 2, arrives (i.e. a crew of 1), as illustrated in FIG. 25. The battalion commander has already started a user application that has already reported presence/status data on the BC's laptop.

[0249] Once the battalion commander arrives, a GC attached to BC 2 and the other GC's recognize each other and display the encounter on both command-active user devices.
Since only the BC's GC
and Eng. 42's GC are command-active, only the user devices associated with those GCs will present shall-we-connect and who-is-IC queries. The BV and IC indicate mutual acceptance and confer to decide who will be the IC from this point forward. The agreed-to IC indicates such via his user device.

[0250] The GC to which the agreed-to IC's user device is communicating becomes a master GC, with the other GC slaved to it (acting at least as a GR). All other user devices become, or stay, view-only devices. Records from the now-slaved GC are copied to the master GC's DB, and combined presence/status data are displayed on all (3) user devices, as are all subsequent assignment changes and alerts.

[0251] The network expands to encompass the 3 GCs and 7 RSNs, as illustrated in FIG. 26. This happens automatically, without noticeable delay, and without further attention by the IC, once the who-is-the-IC button is pressed on a user device. To the IC, all GCs and RSNs appear to behave as if they are a single island, and unit RSN associations are maintained.

[0252] Next, for whatever reason, communications with Engine 42's GC are lost, for example as a result of failure of the GC or RF problems, etc. Since Engine 42 has not been released from the incident, the network and THN IC application continue to carry Engine 42 as part of the incident, but out of contact.

[0253] The IC's GC and a user application cause an alert to be displayed on all present user devices.
This alert message persists until acknowledged by the IC. The alert is repeatedly redisplayed at a predetermined interval until the condition is rectified.

[0254] The network must attempt to reform automatically to maintain coverage with RSNs 1-3.
However, RSNs 1-3 continue to be administratively associated with Engine 42, regardless of which GC they may be communicating with. Notably, all of this happens automatically and without noticeable delay, and without any other action by the IC.

[0255] Subsequently, communications with Engine 42's GC are re-established.
Upon such re-establishment, there is no who-is-IC exchange since that has already been established among the same GCs, and there have been no changes/additions with the incident.

[0256] The network automatically adjusts to the re-establishment. All of this happens automatically, without noticeable delay, and without any action by the IC. In fact, preferably, re-establishment of contact does not even cause a corresponding message to be displayed on the present user devices.

[0257] Next, Engine 42, as well as the 3 firefighters of that unit, are released from the incident by radio/voice command of the IC. Notably, these 3 RSNs have stayed administratively associated with Engine 42 throughout the incident, regardless of actual RF effects, although the IC could have administratively detached any of them, using his user device, had he chosen to do so.

[0258] The IC indicates, via his user device, that Engine 42's GC and, by association, its 3 RSNs, are released from the incident.

[0259] This one message causes Engine 42's GC to revert to a full-function GC
and also automatically causes RSNs 1-3 to be released from the incident. These 3 RSNs and Engine 42's GC
ignore the IC's GC's beacon for some period. Engine 42 and RSNs 1-3 become an independent island again, as illustrated in FIG. 27, and Engine 42's user device becomes fully functional again.

[0260] The IC's incident network automatically adjusts to this release. In fact, once the release command has been issued by the IC into his user device, all of this happens automatically, without noticeable delay, and without any further action by the IC.

[0261] Thereafter, the IC/BC relinquishes command to the unit commander of Ladder 12, and informs him of such via radio/voice command. The IC uses his user device to relinquish command, which causes his GC to transfer control to Ladder 12's GC. Prior to such transfer, all event data records (EDRs) stored in the IC's GC are transferred to Ladder 12's GC.
Duplicates are discarded.

[0262] At this point, the BC's GC becomes independent again, establishing an island that includes the BC's GC and RSN 7, as illustrated in FIG. 28. Similarly, Ladder 12's GC
reverts to a full-function GC, taking over the incident, with its GC and RSNs ignoring the BC's GC, and Ladder 12's RSNs immediately attempting to register with Ladder 12's GC. Ladder 12's user device becomes fully functional again.

[0263] Any other units (for example, units having GCs) or RSNs still associated with the incident that are still present automatically adjust to join Ladder 12's network. All of this happens automatically, without noticeable delay, and without any further action by the IC/BC, once he issues the transfer-command command.

[0264] Next, using his user device, the IC assigns Engine 42 to a hot-zone task. This one assignment command causes a message to be sent to RSNs 1-3 to engage their no-movement sensors.

[0265] Any subsequent no-movement message from RSNs 1-3 causes a no-movement alert to appear on all user devices. When Engine 42 is later assigned to a non-hot-zone task, the no-movement sensors of RSNs 1-3 automatically disengage.

Alternative Asset Tracking Contexts [0266] One or more preferred implementations of an asset management system in a first responder context for the management and monitoring of emergency services sector resources has been described hereinabove. It will be appreciated, however, that such a first responder context is not the only context in which technologies and methodologies described herein might be useful. Two additional, exemplary contexts are now described.

Alternative Asset Tracking Contexts - Shipping Container Implementations [0267] In a shipping container context, an RSN is integrated with a security bolt, which is applied as a security seal through the container door hasp. Gateway controllers are located at origin and destination sites, and at various intermediate locations along a shipping route (e.g., ports, truck stops, weigh stations).

[0268] At the shipper's location, sealing of the door is automatically reported to a gateway controller at the shipping dock and, via a user application, associated with a shipment number. After leaving the shipper's location, a lack of presence would automatically be reported.

[0269] Arrival of the RSN at a port would automatically be detected and reported by gateways at the port. Even from inside a stack of containers, messages from an RSN could reach a gateway, and vice-versa, due to the high-powered data radios and the hopping that is facilitated by autonomous network configuration, which is enabled by class-based networking. If a container is moved when it should not be (indicating theft), or if a container is jarred enough to damage its contents, the event is reported immediately and automatically. Similarly, an RSN preferably reports dangerous fluctuations in a container's temperature or the presence of dangerous vapors, if connected to appropriate external sensors.

[0270] Aboard ship, the presence of the container is known to a gateway controller on the ship, which reports via satellite link. Similarly, sensor inputs are known. The location of the container is also known, from the GPS capability of the shipboard gateway controller.

[0271] Once the container reaches its destination, or at any location subsequent to the original sealing, every opening or closing of the seal is recorded. If the opening or closing occurs at a location covered by a radio network, the event is reported immediately. If the opening or closing occurs at a non-covered location, the event is stored and reported immediately upon encountering a radio network.

[0272] In such an application, class-based networking provides more than enough battery life to complete multiple door-to-door transoceanic shipments. It also enables different shippers or different shipping companies to share a radio network infrastructure at ports and other shared locations without interfering with each other's traffic, while still allowing for hopping of others' messages when needed.

[0273] For example, XYZ Shipping may configure its RSNs to communicate, under normal circumstances, with only other XYZ Shipping RSNs, but to assist hopping for RSNs of other companies when needed. Under those ordinary circumstances, wake-up and data traffic from other companies' RSNs would be ignored by XYZ Shipping's RSNs. However, if ABC
Shipping has a container deep in a stack, and its RSN needs a hop-assist to reach a gateway controller, the RSNs of XYZ Shipping could make the assist. Preferably, the ABC Shipping RSN
automatically makes a request for an assist after failing to reach a gateway controller using only its own class of RSNs. In this manner, class-based networking accommodates thousands of containers at a single location.

[0274] The area-coverage capability of the radio network means, for example, that an entire port facility may be covered. Consequently, the presence of an RSN (and thus its associated container) can be known at any time (via a query), and special detection lanes or choke points are not needed.

Alternative Asset Tracking Contexts - Construction Equipment Implementations [0275] In a construction equipment context, an RSN is attached to a backhoe, dozer, crane, or other piece of equipment. In this application, gateway controllers are located at equipment rental yards and construction sites. A rental company then uses presence data generated by the RSN network to know in real-time which of multiple yards specific equipment is located that is needed to meet customer needs. Preferably, improper movement data triggers a theft alarm. Such a theft alarm could be associated with gates and perimeter fencing.

[0276] At a renter's construction site, a gateway receives engine-hours data from RSNs associated with equipment at that site and reports back to the rental company. The rental company uses the data to determine whether the renter is exceeding his contract and/or whether the equipment is being abused. Preferably, for sites that do not have a gateway controller, the rental company uses a truck-mounted gateway controller to periodically visit all such sites to collect data from the RSNs at each such site. The data is collected quickly and automatically, and is immediately uploaded via cellular link to the rental company's headquarters.

[0277] A construction company can similarly use the system to keep track of and monitor its own equipment, both in storage yards and on construction sites. For construction sites that have both rental and owned equipment, classes are set such that a rental company can "see" its equipment via the site's gateway, but see nothing of the equipment owned by the construction company.

Conclusion [0278] Based on the foregoing description, it will be readily understood by those persons skilled in the art that the present invention is susceptible of broad utility and application. Many embodiments and adaptations of the present invention other than those specifically described herein, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the foregoing descriptions thereof, without departing from the substance or scope of the present invention. Accordingly, while the present invention has been described herein in detail in relation to one or more preferred embodiments, it is to be understood that this disclosure is only illustrative and exemplary of the present invention and is made merely for the purpose of providing a full and enabling disclosure of the invention. The foregoing disclosure is not intended to be construed to limit the present invention or otherwise exclude any such other embodiments, adaptations, variations, modifications or equivalent arrangements, the present invention being limited only by the claims appended hereto and the equivalents thereof.

Claims

1. A method of merging first and second wireless networks, (a) wherein, prior to execution of the method, (i) the first network comprises (A) a first wireless communications device, and (B) a first group of wireless nodes comprising one or more wireless nodes, (ii) the second network comprises (A) a second wireless communications device, and (B) a second group of wireless nodes comprising one or more wireless nodes, (iii) each wireless node of the first group of wireless nodes is configured for wireless communications with the first wireless communications device, but is not configured for wireless communications with the second wireless communications device, (iv) each wireless node of the second group of wireless nodes is configured for wireless communications with the second wireless communications device, but is not configured for wireless communications with the first wireless communications device, (b) wherein the method comprises reconfiguring at least (A) the first wireless communications device, (B) the second wireless communications device, or (C) one or more of the wireless nodes, such that the first and second networks merge into a single network.

2. The method of claim 1, wherein the method further comprises, prior to said reconfiguring step, the step of determining that a coverage area of the first wireless network and a coverage area of the second wireless network are proximate one another.

3. The method of claim 1, wherein the method comprises, prior to said reconfiguring step, the step of determining that a coverage area of the first wireless network and a coverage area of the second wireless network overlap.

4. The method of claim 1, wherein the method comprises, prior to said reconfiguring step, (a) monitoring, by the first wireless communications device, for the presence of another wireless communications device, (b) determining, at the first wireless communications device, that the second wireless communications device is present, (c) communicating, from the first wireless communications device to the second wireless communications device, information regarding the first wireless communications device, and (d) communicating, from the second wireless communications device to the first wireless communications device, information regarding the second wireless communications device.

5. The method of claim 1, wherein said reconfiguring step comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that both the first wireless communications device and the second wireless communications device are configured for wireless communications with all of the wireless nodes.

6. The method of claim 1, wherein, (a) prior to execution of the method, (i) each wireless node of the first network is configured for wireless communications with each of the other wireless nodes of the first network, but is not configured for wireless communications with the wireless nodes of the second network, and (ii) each wireless node of the second network is configured for wireless communications with each of the other wireless nodes of the second network, but is not configured for wireless communications with the wireless nodes of the first network; and (b) said step of reconfiguring comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that all of the wireless nodes are configured for wireless communications with one another.

7. The method of claim 1, (a) wherein, prior to execution of the method, (i) the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to a first user application, and (ii) the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to a second user application.

8. The method of claim 7, wherein the method comprises reconfiguring at least (a) the first wireless communications device, (b) the second wireless communications device, or (c) one or more of the wireless nodes, such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application.
8. The method of claim 8, wherein said step of reconfiguring such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that the second wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such data to the first user application.

9. The method of claim 7, (a) wherein the method further comprises (i) determining, by the first user application, whether to merge, (ii) determining, by the second user application, whether to merge, and (b) wherein said reconfiguring step occurs as a result of a determination to merge by both the first and second user applications.

10. The method of claim 7, wherein the method further comprises (a) determining, by the first user application, whether to merge with the second user application, (b) determining, by the second user application, whether to merge with the first user application, and (c) if both the first user application and the second user application determined to merge with one another, then merging the first and second user applications such that one of the user application is a master user application.

11. The method of claim 10, wherein, following said step of merging the first and second user applications, (a) the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to the master user application, and (b) the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to the master user application.

12. The method of claim 10, wherein said step of determining, by the first user application, whether to merge with the second user application comprises presenting, to a user via a user device, a query as to whether to merge and subsequently receiving an indication of whether to merge input by the user via the user device.

13. The method of claim 12, wherein the user device comprises a laptop.

14. The method of claim 12, wherein the user device comprises a personal digital assistant (PDA).

15. The method of claim 1, wherein the first wireless communications device comprises a gateway controller.

16. The method of claim 1, wherein the first wireless communications device comprises a mobile gateway system (MGS).

17. The method of claim 1, wherein each wireless node comprises a remote sensor node (RSN).

18. The method of claim 1, wherein (a) each wireless communications device comprises a mobile gateway system (MGS) secured on or to an emergency services sector asset, and (b) each wireless node comprises a remote sensor node (RSN) secured on or to an emergency services sector asset.

19. A method for facilitating the management of emergency services sector (ESS) resources at an incident, the method comprising (a) arriving, at an incident, by a first ESS unit which includes (i) an emergency services sector asset having a gateway controller (GC), (ii) one or more emergency services sector assets each having a remote sensor node (RSN);
(b) arriving, at the incident, by a second ESS unit which includes (i) an emergency services sector asset having a GC, (ii) one or more emergency services sector assets each having a remote sensor node (RSN);
(c) detecting, by the GC of the first ESS unit, the GC of the second ESS unit;
(d) querying, via a user device associated with the GC of the first ESS unit and a user device associated with the GC of the second ESS unit, who will be incident commander (IC) going forward;
(e) indicating, by a user, via one of the user devices, that the user will be IC;
(f) merging the GCs such that the GC associated with the user device used to indicate that the user will be IC becomes a master GC.

20. A method for facilitating the management of emergency services sector (ESS) resources at an incident, the method comprising (a) arriving, at an incident, by a first ESS unit which includes (i) an emergency services sector asset having a gateway controller (GC), (ii) one or more emergency services sector assets each having a remote sensor node (RSN), one of the assets having a user device;
(b) arriving, at the incident, by a second ESS unit which includes (i) an emergency services sector asset having a GC, (ii) one or more emergency services sector assets each having a remote sensor node (RSN), one of the assets having a user device;
(c) detecting, by the GC of the first ESS unit, the GC of the second ESS unit;
(d) querying, via the user device of the asset having a user device of the first ESS unit, whether to merge, (e) querying, via the user device of the asset having a user device of the second ESS unit, whether to merge, (f) if an affirmative response was received in response to each querying step, then merging together the GCs.

21. An asset monitoring system, comprising (a) a radio network, the radio network comprising (i) a gateway controller, (ii) one or more remote sensor nodes (RSNs);
(b) a user application; and (c) a message management and routing (MMR) system configured to facilitate communications between the radio network and user application;
(d) a user device;
(e) wherein each RSN is secured on or to an asset to be tracked;
(f) wherein each RSN is configured to communicate information regarding the asset it is secured on or to to the user application via the gateway controller;
(g) wherein the user application is configured to display information regarding tracked assets to a user via the user device.

22. The asset monitoring system of claim 21, wherein the user device is a laptop.

23. The asset monitoring system of claim 21, wherein the user device is a personal digital assistant (PDA) or PDA-like device.

24. The asset monitoring system of claim 21, wherein the radio network is configured to report the presence of RSNs, and thus the assets RSNs are secured to.

25. The asset monitoring system of claim 21, wherein the user application comprises a presence server.

26. The asset monitoring system of claim 21, wherein a gateway of the gateway controller is configured to beacon at regular intervals to broadcast its presence to nearby RSNs.

27. The asset monitoring system of claim 21, wherein each asset to be tracked comprises an emergency services sector resource.

28. The asset monitoring system of claim 21, wherein each asset to be tracked comprises a container.

29. The asset monitoring system of claim 21, wherein each asset to be tracked comprises construction equipment.

30. The asset monitoring system of claim 21, wherein each RSN includes one or more sensors, and each RSN is configured to communicate sensor information to the user application via the gateway controller.

31. The asset monitoring system of claim 21, wherein the system is configured to detect a location change of an RSN.

32. The asset monitoring system of claim 21, wherein the system is configured to detect a status change of an RSN.

33. The asset monitoring system of claim 21, wherein each RSN may be assigned to different tasks or profiles via the user application.

34. The asset monitoring system of claim 21, wherein each RSN is configured to change its behavior in response to a location change.

35. The asset monitoring system of claim 21, wherein each RSN is configured to change its behavior in response to a state change.

36. The asset monitoring system of claim 21, wherein each RSN is configured to change its behavior in response to sensor input.

37. The asset monitoring system of claim 21, wherein each RSN is configured to change its behavior in response to an assignment change.

38. The asset monitoring system of claim 21, wherein, when a message communicated from an RSN to the gateway controller is hopped through other RSNs, a path the message travels is stored, and wherein, when an alert condition arises at an RSN, hop-path information is utilized to determine an RSN that might be proximate the RSN with the alert condition.

39. A method of merging first and second wireless networks, (a) wherein, prior to execution of the method, (i) the first network comprises (A) a first wireless communications device, and (B) a first group of wireless nodes comprising one or more wireless nodes, (ii) the second network comprises (A) a second wireless communications device, and (B) a second group of wireless nodes comprising one or more wireless nodes, (iii) each wireless node of the first group of wireless nodes is configured for wireless communications with the first wireless communications device, but is not configured for wireless communications with the second wireless communications device, (iv) each wireless node of the second group of wireless nodes is configured for wireless communications with the second wireless communications device, but is not configured for wireless communications with the first wireless communications device, (v) the first wireless communications device is configured to receive data from each wireless node of the first group of wireless nodes and communicate such received data to a first user application, and (vi) the second wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such received data to a second user application; and (b) wherein the method comprises (i) monitoring, by the first wireless communications device, for the presence of another wireless communications device, (ii) determining, at the first wireless communications device, that the second wireless communications device is present, (iii) communicating, from the first wireless communications device to the second wireless communications device, information regarding the first wireless communications device, (iv) communicating, from the second wireless communications device to the first wireless communications device, information regarding the second wireless communications device, and (v) reconfiguring at least (A) the first wireless communications device, (B) the second wireless communications device, or (C) one or more of the wireless nodes, such that the first wireless communications device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application.

40. The method of claim 39, wherein said step of reconfiguring comprises reconfiguring at least the first wireless communications device, the second wireless communications device, or one or more of the wireless nodes such that the first wireless communication device is configured to receive data from each wireless node of the second group of wireless nodes and communicate such data to the second user application via an enterprise gateway server.