The present invention relates generally to ad-hoc networks, and in particular, to a method and apparatus for deploying an ad-hoc network.
Wireless ad-hoc communication systems allow a number of data devices (nodes) to communicate with each other. Such communications are normally confined to about 10 meters in all directions, whether the node is stationary or in motion. Because of the short-range nature of any communication, typical ad-hoc networks comprise a number of piconets that overlap to create a logical communication backbone underpinned by the physical radio connections that exist between devices in the various piconets. All piconets usually have a single piconet controller (PNC), or coordinator. The coordinator is responsible for timing synchronization of the devices within its piconet, for assigning unique network addresses, for routing messages, for broadcasting device discovery and service discovery information, and possibly for power control.
Recently, it has been proposed to utilize such ad-hoc networks to aide in emergency services. For example, ad-hoc networking can be employed within a fireground to aide communications between emergency service providers (e.g., firemen, policemen, . . . , etc). However, existing deployment algorithms make it extremely difficult to rapidly deploy such a network and still guarantee that the network will self-assemble in a “fully connected” fashion to provide ubiquitous coverage. For example, existing deployment algorithms utilize exploration and map building with aid of robots, stored maps, and stored sensory data; and thus cannot be built entirely “real time”. Additional algorithms require physical placement of the sensor nodes in a precise (“optimal”) location for the algorithms to work (which means they require some sort of fixed infra structure, defying the purpose of ad-hoc network).
For mission critical situations, emergency service providers cannot afford the time to precisely distribute nodes to achieve connectivity, nor can they depend on stored maps to deploy nodes. Hence, a need exists for a method and apparatus for deploying an ad-hoc network in real time that assures connectivity at all times.
To address the above-mentioned need a method and apparatus for real-time ad-hoc network deployment is provided herein. During deployment, nodes that make up the network are periodically dropped in a serial fashion. During deployment, a node will immediately determine if it will become a network coordinator by determining if a piconet coordinator beacon is heard. If, during deployment, a beacon isn't heard, the node will become a piconet coordinator and will assume those responsibilities immediately.
Because network coordinators are elected immediately upon deployment, and without contention, every other node that is deployed after a coordinator (and in its transmission range) immediately knows its role in the network (it will become a regular device 102). This feature eliminates all communications overhead, allowing fast deployment without initialization contention. Additionally, because piconets overlap, and many devices are deployed within the overlap region, the network is fully connected.
The present invention encompasses a method for deploying an ad-hoc network. The method comprises the step of serially dropping a plurality of ad-hoc nodes throughout a geographic area, where the plurality of ad-hoc nodes automatically become a piconet coordinator based on a threshold.
The present invention additionally encompasses a method comprising the steps of determining that a node has been deployed, determining if a beacon has been heard, and becoming a piconet coordinator if the beacon has not been heard otherwise becoming a standard node within an ad-hoc communication system.
The present invention additionally encompasses an apparatus comprising a sensor determining that a node has been deployed, and logic circuitry determining if a beacon has been heard and instructing the node to become a piconet coordinator if the beacon has not been heard, otherwise instructing the node to become a regular node within an ad-hoc communication system.
The present invention additionally encompasses an apparatus comprising a sensor determining that a node has been dropped and logic circuitry determining whether or not to become a piconet coordinator based on if the node has been dropped, wherein the logic circuitry determines whether or not to become a piconet coordinator based on a statistic.
Turning now to the drawings, wherein like numerals designate like components,
During typical transmission, a device (or node) 102 will schedule a time period to transmit, and to receive. Additionally, each coordinator will periodically broadcast a beacon, identifying it as a coordinator and providing system information to nodes in communication with the coordinator's range. Thus, as known in the art each coordinator 101 has a time window (reservation window) to receive its neighbors' 102 communication requests (for both unicast and broadcast) in each period. Each coordinator 101 additionally has a time window (beacon window) to broadcast the beacon comprising necessary information for the piconet in each period, to its neighbors 102. The necessary information comprises information such as, but not limited to information necessary for assigning unique network addresses to nodes, for routing messages, for broadcasting device discovery and service discovery information, and information necessary for power control.
The established network structure allows all neighboring nodes 102 to synchronize with its coordinator's beacon window. Thus, all nodes 101 and 102 should wake up in a beacon window to receive piconet information.
As discussed above, it has been proposed to utilize such an ad-hoc network to aide in emergency services. However, existing deployment algorithms make it extremely difficult to rapidly deploy such a network and still guarantee that the network will self-assemble in a “fully connected” fashion to provide ubiquitous coverage. In order to address this issue, in the preferred embodiment of the present invention nodes are deployed in a serial fashion (i.e., one at a time). During deployment, a node will immediately determine if it will become a PNC by determining if a PNC beacon is heard or not. If, during deployment, a PNC beacon isn't heard, the node will become a PNC 101 and will assume those responsibilities immediately. Thus, a node will automatically become a PNC if it is out of range of any other PNC.
Because PNC devices are elected immediately upon deployment, and without contention, every other node that is deployed after a PNC and in its transmission range immediately knows its role in the network (it will become a regular device 102). This eliminates all communications overhead, allowing fast deployment without initialization contention. Additionally, because piconets overlap, and many devices are deployed within the overlap region, the network is fully connected.
There are various ways to deploy each node, and are even more options as to how many to deploy and when to deploy them. In the preferred embodiment of the present invention nodes are periodically deployed serially from a backpack that is equipped to randomly (i.e., random in time) drop nodes as a firefighter (or any personnel) traverses the environment. As discussed, after deployment from the backpack, a node immediately determines its role (i.e., as that of a coordinator or not) and begins network communication.
The logic flow begins at step 201. At step 203 a node is deployed. As discussed above, once a node is deployed (e.g., dropped onto the ground), it immediately determines if a beacon is heard from any PNC 101 (step 205). If, at step 205 a beacon is heard, the logic flow continues to step 207 where the beacon assumes the role of a standard device 102, otherwise the logic flow continues to step 208 where the beacon assumes the role of PNC 101. At step 211 a determination is made to whether or not any more nodes need to be deployed, and if so the logic flow returns to step 201, otherwise the logic flow ends at step 213.
It should be noted that although the above procedure may be employed by hand, in the preferred embodiment of the present invention an individual is equipped with a node-distributing device that is capable of performing the aforementioned four-part process. Because of the short-range nature of communication between devices, any node distribution must be such that no node lies more than a predetermined distance from any other node. In order to accomplish this task, the node-distributing device can deploy based on the following criteria: walking speed, transmitted signal strength, node density measures, battery life of existing network nodes, channel congestion, or a combination of the former attributes with environmental parameters like temperature, moisture or humidity.
For example, a system that is deployed based on walking speed can calculate the distance between the most recently deployed node and the current position of the deployment mechanism by using velocity and time. When the calculated distance is greater than the maximal device separation threshold, another node will be deployed. If a new node is deployed and is not in range of a PNC, it will assume PNC responsibilities and start another piconet.
As discussed, there are a variety of characteristic that can be used to determine when a node is deployed.
If a beacon is received by receiver 502, then the logic flow continues to step 605, otherwise the logic flow continues to step 607. At step 605 logic circuitry 503 instructs node 500 to perform standard ad-hoc communications, participating within the ad-hoc network as a regular node. Thus, node 500 will identify the node 500 as a coordinator by broadcasting a beacon that provides system information to nodes in communication with the node's range. At step 607 logic circuitry 503 instructs node 500 to perform standard ad-hoc communications, participating within the ad-hoc network as a network controller.
Although the above description was given with a node determining if it should become a piconet coordinator based on whether or not a beacon was detected, other techniques for becoming a piconet coordinator may be used. For example, once dropped, a node may determine whether or not to become a piconet coordinator based on the signal strengths of neighboring nodes. For example, if the signal strengths of all neighboring nodes are below a threshold, then there exists a good chance that the node may have trouble in communicating with already deployed piconet coordinators. The node may then become a piconet coordinator.
A node may additionally determine whether or not to become a piconet coordinator based on a perceived node density. For example, if a node determines that there exists a high density of nodes within a given area (e.g., 5) the node may decide to become a coordinator in order to reduce the service burden on the existing coordinators, even though at least one piconet coordinator is heard.
A node may additionally determine whether or not to become a piconet coordinator based on battery life of it or other nodes. For example, nodes serving as piconet coordinators utilize higher power consumption than regular nodes. Because of this, a node will not want to become a piconet coordinator if its battery reserve is low. In a similar manner, a node may wish to become a piconet coordinator if the existing coordinator has low battery reserves. Therefore, if a node is dropped and has little battery reserve, it will not become a piconet coordinator. In this situation, the next node dropped should become the piconet coordinator if its battery reserve permits. In a similar manner, if it is dropped and has good battery reserves, and the existing coordinator has poor reserves, it may choose to become a coordinator.
Finally, a node may additionally determine whether or not to become a piconet coordinator based on channel congestion. If, when dropped, neighboring nodes are indicating the existence of throughput delays based on the bottlenecks with existing coordinators, the next node that is dropped may elect to be a coordinator in order to reduce the traffic load on the existing piconet coordinators.
In summary, once deployed a node may utilize any one or any combination of several statistics/thresholds to determine whether or not to become a piconet coordinator. These thresholds include, but are not limited to:
While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention. For example, while the above description was given with respect to a NeuRFon ad-hoc communication system, one of ordinary skill in the art will recognize that other communication system protocols may be utilized. For example, communication system 100 may utilize a Bluetooth, IEEE 802.11, or HyperLAN protocol. It is intended that such changes come within the scope of the following claims.
This invention was made with United States Government support under Agreement No. 70NANB2H3001 awarded by the National Institute of Standards and Technology (NIST). The United States Government has certain rights in the invention.