Patent Application
20070286136
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures can be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to energy-efficient techniques for discovering a peer node in an autonomous ad hoc network. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
In this document, relational terms such as first and second, and the like can be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
It will be appreciated that embodiments of the invention described herein can be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions for discovering a peer node in an autonomous ad hoc network as described herein. The non-processor circuits can include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions can be interpreted as steps of a method for discovering a peer node in an autonomous ad hoc network. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. All of the embodiments described in this Detailed Description are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention which is defined by the claims.
In ad hoc networks where the number of nodes in a given area is relatively low (e.g., a low density population of nodes), it is undesirable to keep the ad hoc interface continuously active since the likelihood of being proximately located with another user for communication purposes is relatively low. Likewise, it is undesirable to allow a human user of a node, if any, to directly decide when to turn on the ad hoc interface or start a service or peer discovery process. Accordingly, there is a need for improved techniques for discovering other nodes within that population as they are encountered (i.e., as the node comes within transmission range of other nodes). Moreover, there is a need in such networks, to decrease the amount of current an ad hoc interface consumes hence increasing the amount of time between recharging the battery or the practical lifetime of an exhaustible power supply.
By identifying key sources of power drain for ad hoc operation, embodiments of the present invention provides energy-efficient discovery and interaction techniques which can allow battery power to be conserved. Embodiments of he present invention provide techniques which can allow the ad hoc interface (e.g., IEEE 802.11 or IEEE 802.15 interface) to learn of another node's presence without consuming large amounts of battery resources. According to these techniques, an ad hoc interface of one node can operate in a continuous full power mode only when it is in the proximity of another node, and operates in an inactive or shutdown mode as soon as the nodes separate from each other (e.g., are outside the proximity of one another). In other words, peer discovery runs passively in the background during predetermined or per-node randomized intervals. During other intervals the ad hoc interface of a node falls back into a low duty-cycle discoverable mode so that battery power can be conserved. As such, these techniques allow the node to communicate with other nodes in its presence while reducing the amount of battery power consumed when no application-level service is required or no prospective peers are in proximity. Before describing these techniques in detail, a brief description of an exemplary autonomous ad hoc communication network (
The nodes 120A-120C can be wireless devices capable of transmitting and receiving packetized audio, video and/or data information. Some of the components in an exemplary node, such as a processor, transmitter, receiver and antenna, are described below in
The nodes 120A-120C can communicate information packets over wireless carrier frequencies, each of which includes one or more wireless communication channels depending on the multiple access scheme utilized in the network 100.
The nodes 120A-C can also communicate with infrastructure components, such as APs, which are typically, but not necessarily required to be, coupled to a wired network (not shown) and can provide one or more sources of audio, video and/or data information. The APs can be a cellular base station, a wireless access point that complies with the IEEE 802.11 Standard or other wireless local area network (WLAN) Standards, a Bluetooth access point, or the like.
The ad hoc communication network 100 can implement routing intelligence, which is typically distributed among nodes 120A-120C to help improve overall network performance. In the ad hoc network 100, communications to or from nodes 120A-120C can “hop” through each other to reach other nodes 120A-120C in the network. In other words, nodes in close proximity can receive transmissions from nearby nodes utilizing the ad hoc air interface and relay these transmissions to other nodes, including access points or nodes with links to other wired or wireless networks.
When access to a wired network is desired, communications from nodes 120A-C can hop to a WLAN AP. Although not shown in
The processor 201 preferably includes one or more microprocessors, microcontrollers, DSPs (digital signal processors), state machines, logic circuitry, or any other device or devices that process information based on operational or programming instructions. Such operational or programming instructions are preferably stored in the program memory 209. The program memory 209 can be an IC (integrated circuit) memory chip containing any form of RAM (random-access memory) or ROM (read-only memory), a floppy disk, a CD-ROM (compact disk read-only memory), a hard disk drive, a DVD (digital video disc), a flash memory card, external subscriber identity module (SIM) card or any other medium for storing digital information. One of ordinary skill in the art will recognize that when the processor 201 has one or more of its functions performed by a state machine or logic circuitry, the memory 209 containing the corresponding operational instructions can be embedded within the state machine or logic circuitry. The operations performed by the processor 201 and the other elements of the node 200 are described in detail below.
The transmitter circuitry 203 and the receiver circuitry 205 enable the node 200 to communicate information packets to and acquire information packets from the other nodes. In this regard, the transmitter circuitry 203 and the receiver circuitry 205 include appropriate, conventional circuitry to enable digital or analog transmissions over a wireless communication channel. The transmitter circuitry 203 and the receiver circuitry 205 can operate over an ad hoc networking air interface (e.g., Bluetooth, IEEE 802.11, IEEE 802.15, and the like).
The implementations of the transmitter circuitry 203 and the receiver circuitry 205 depend on the implementation of the node 200. For example, the transmitter circuitry 203 and the receiver circuitry 205 can be implemented as an appropriate wireless modem, or as conventional transmitting and receiving components of two-way wireless communication devices. In the event that the transmitter circuitry 203 and the receiver circuitry 205 are implemented as a wireless modem, the modem can be internal to the node 200 or insertable into the node 200 (e.g., embodied in a wireless radio frequency (RF) modem implemented on a Personal Computer Memory Card International Association (PCMCIA) card). For a wireless communication device, the transmitter circuitry 203 and the receiver circuitry 205 are preferably implemented as part of the wireless device hardware and software architecture in accordance with known techniques. One of ordinary skill in the art will recognize that most, if not all, of the functions of the transmitter circuitry 203 and/or the receiver circuitry 205 can be implemented in a processor, such as the processor 201. However, the processor 201, the transmitter circuitry 203, and the receiver circuitry 205 have been artificially partitioned herein to facilitate a better understanding.
The receiver circuitry 205 is capable of receiving RF signals from at least one frequency band and optionally multiple frequency bands, if the communications with the proximate device are in a frequency band other than that of the network communications. The receiver circuitry 205 can optionally comprise a first receiver and a second receiver, or one receiver capable of receiving in two or more bands. The receiver 205, depending on the mode of operation, can be tuned to receive, for example, Bluetooth or wireless local area network (WLAN), such as IEEE 802.11, communication signals. The transceiver 202 includes at least one set of transmitter circuitry 203. The at least one transmitter 203 can be capable of transmitting to multiple devices potentially in multiple frequency bands.
The antenna 206 comprises any known or developed structure for radiating and receiving electromagnetic energy in the frequency range containing the wireless carrier frequencies.
The buffer memory 211 can be any form of volatile memory, such as RAM, and is used for temporarily storing received information packets in accordance with the present invention.
The physical (hardware) layer 210 includes a control interface 212 and an ad hoc network interface 216 (e.g., wireless local area network (WLAN) adapter). The control interface 212 provides the methods required to power up or power down the network interface, as well as methods to query the interface for state information (e.g., is the network idle or active) and configure the interface as required (e.g., switch to ad hoc mode, set a service set identifier (SSID) or security parameters). The control interface, for example, can be mapped onto device-specific control interfaces, or can exploit a more generic control interface as provided by /proc on the Linux operating system.
The JAVA virtual machine (JVM) layer 220 includes one or more modules and Application Programming Interfaces (APIs). The modules in the JVM layer 220 can include, for example, a peer finder module 226, and an application finder module 227, and a power management module 229. The APIs can include, for example, a device discovery API 224, a service discovery API 225, and a power management API 228. The device discovery API 224 allows applications on the node to initiate a peer discovery operation and be notified of the identities (Internet Protocol (IP) addresses) of devices that are currently in the device's vicinity. The service discovery API 225 allows applications on the node to initiate a service discovery operation and be notified of the services available on nearby devices in aggregate, or on a per-device basis. The device and service discovery modules update this device's transmitted beacon with the relevant device IP address and service information, and also extract this information from detected beacons transmitted by their peers. The results are accumulated over each discovery period (Ymax) and returned to the requesting application and any registered nodes. The power management API 228 is the interface from the JVM that enables applications to request tuning of the power management parameters (e.g., duration for power-on and power-off). In turn, the power management module 229 computes and establishes power management parameters that reflect the collective requests of all resident applications.
The software developer's kit (SDK) layer 230 provides one or more APIs for use by application programmers when writing an application and interfacing it to the JVM 220. Applications can be developed to directly use the lower-level interfaces for discovery 224, 225 and power management 228. Alternatively, they can use application programming interfaces 221, 222, 223 that provide default behaviors for specific classes of applications 242, 244, 246.
Federation applications 242 reflect short-term synchronous queries from the application (e.g., for immediate data-sharing) while encounter applications 244 reflect long-term asynchronous queries (e.g., for alerts to future peer discovery). Unlike federation or encounter applications, tribal applications 246 reflect interactive sessions of longer duration (e.g., a multiplayer game or chat). Each class of applications thus requires a different power management strategy for efficient operation, that can be provided by the related federation, encounter and tribal modules.
In the following description, a “provider” node is a node that can provide services or content to peers, and a “client” node is a node that is searching provider nodes of a specific service or content. A single node can be both a client node and a provider node depending on the context of its different interactions. A discovery process involves enabling a client node to locate a nearby provider node that can satisfy a pending user or application request.
When a particular client node enters an area and needs a particular service, it is desirable to be able to quickly discover which peer nodes are within its transmission range and which services those peer nodes can provide. This way, a particular client node seeking a particular service can determine quickly whether or not the service is available in its area via other nodes in its proximity. Network activity consumes battery power. For energy efficiency, it is desirable to minimize the network activity required for discovery at both client nodes and provider nodes.
Embodiments of the present invention provide push-based prospective peer discovery techniques for use in an ad hoc network. Provider nodes transmit advertisement messages to periodically advertise or announce their presence and related service information on the network. These advertisement messages use application-level beacons (as opposed to Media Access Control (MAC)-level beacons) that contain the relevant addressing and service information. Client nodes can remain off the network (e.g., in an inactive state) until an application/user request for discovery is made. Potential client nodes can discover the provider node by listening for a duration or finite interval (e.g., typically equal to one period of the provider node's advertising duty cycle) to detect the provider node.
Because provider nodes can potentially service many client nodes (i.e., are involved in more interactions and communication than the average client node), it is desirable that provider nodes have a relatively long battery life. The disclosed discovery techniques favor provider nodes over client nodes by making the client node responsible for a higher percentage of the energy burden for discovery since the client node ultimately benefits from the discovery process. By contrast, provider nodes are rewarded for their efforts with a reduced energy burden.
Deploying an ad hoc networking interface in idle mode (e.g., where no useful transmission/reception work is done) unnecessarily wastes battery power. Ideally, the ad hoc interface should be turned off during these idle intervals in order to conserve power. However, if the ad hoc interface is powered-off, then the node cannot be opportunistically “discovered” by a peer. At the same time, if the ad hoc interface is kept powered-on, the node risks substantial power depletion without benefit when there are no active peer nodes in the vicinity. The disclosed push-based prospective peer discovery techniques strike an appropriate balance between the always-on and the always-off modes of operation to prevent power usage during idle periods. The disclosed techniques can provide energy savings while automatically and passively running absent any user interaction.
According to one embodiment of the present invention, energy-efficient discovery techniques are provided for a client node to discover at least one peer provider node in an autonomous ad hoc network. According to these techniques, a first ad hoc interface in the client node can be turned on while in a discovery mode to establish a channel for a first “discovery” time period (Ymax). Typically, during this first time period, channel beacons would be periodically transmitted by the client node.
A second ad hoc interface of the prospective peer provider node(s) can be turned on for a second time period (α) to listen for channel beacons or other indications of an established channel from other potential client nodes. In some implementations, the second ad hoc interface would be turned off as soon as it was determined that no established channel was present. The second ad hoc interface can be turned on, for example, at regular, yet unsynchronized with respects to the rest of the node population, predetermined time intervals. It can also vary based on the related node's current application set (further broken down into varying based on the set loaded upon the device or the set currently running). It can also vary based on the current operation mode of the applications currently running on the related node. The second time period (α) is less than or equal to the first period of time. At least one of the prospective peer provider nodes (and possibly multiple prospective peer provider nodes) can transmit its own application (service) level beacon at the beginning of the second time period (α) to advertise services which the prospective peer provider node can provide to other potential client nodes within the transmission range of the prospective peer provider node.
The prospective peer provider node can transmit a first beacon comprising a first field indicating the second time period (α) the prospective peer provider node will stay on the channel or keep the second ad hoc interface on for, and a second field indicating a service the prospective peer provider node is providing. The second time period is of sufficient duration to ensure that a client node within the transmission range of the prospective peer provider node can detect and respond to the first beacon, and that, if a response message is transmitted by a client node, the prospective peer provider node will detect a response message within the second time period. During the second time period, the prospective peer provider node also listens for a response message from at least one client node within the transmission range of the prospective peer provider node. This allows the client node to acquire service information and service from prospective peer provider node(s) within the transmission range of the client node. The client node turns off the first ad hoc interface and enters sleep mode if the client node does not receive a first beacon from a prospective peer provider node at the end of the first time period. The beacon from the prospective peer node comprises a service extension field comprising a list of services that are currently running on the prospective peer provider node or that the node prospective peer provider node is capable of running. This allows the prospective peer provider nodes to communicate information associated with a service potentially requested by the client node. Once a prospective peer provider node has communicated the information associated with the service requested by the client node, the prospective peer provider node turns off the second ad hoc interface. Moreover, if any prospective peer provider node does not receive a response message from the client node, then it turns off its second ad hoc interface at the end of the second time period (α), and remains off for a third time period (β). Thus, the duration of the second time period (α) and the duration of the third time period (β) define a duty cycle (Y) for the ad hoc interface of a particular prospective peer provider node.
The client node can analyze information in the beacon from the prospective peer provider node to determine if the prospective peer provider node offers (or is capable of offering) the service the client node is requesting so the client node can then transmit a response message to the prospective peer provider node so that the prospective peer provider node keeps its second ad hoc interface on for an additional time period (e.g., more time in addition to the second time period).
A specific exemplary implementation of these techniques will now be described with reference to
In
As shown in timing diagram 410, when node A attempts to acquire information from other nodes in its proximity, node A turns on (“ON”) its ad hoc interface at the leading edge of a first “discover” time period (Ymax) to establish a channel. Because node A is trying to learn the information from other users, node A will keep the channel (its ad hoc interface) turned on (e.g., active) for the discovery time period (Ymax). The first beacon 414 is coincidentally shown to be transmitted at the leading edge of the first time period. This is shown because all client nodes can be a prospective peer node concurrently. A client node can use a beacon 414 to advertise the start of the discovery time period (Ymax). However, this is not required. The client node need only establish an ad hoc channel to allow other prospective peer nodes to communicate with it during the first discovery time period (Ymax).
This beacon 414 can be implemented, for example, as a User Datagram Protocol (UDP) datagram, IEEE 802.11 frame or even tied to the RF-level beacon process. The first beacon 414 advertises the first discovery time period (Ymax) to other nodes (nodes B and C in this example) during which node A will keep the channel turned on. Among other information, the beacon 414 also includes an alpha (α) parameter which specifies a first time period which the node keeps its ad hoc interface ON for, a beta (β) parameter which specifies a second time period following the first time period which the node turns its ad hoc interface OFF for, and any registered service advertisement payload. Each node selects an alpha (α) value and a beta (β) value that sum up to less than the first discovery time period (Ymax). The sum of alpha (α) and beta (β) represents the expected time until the next beacon will be transmitted from this node. For the stability reasons, the node should transmit a beacon at least once every the first discovery time period (Ymax).
The node A listens for the first discovery time period (Ymax) for beacons from any prospective peer nodes that might be in its vicinity. The first discovery time period (Ymax) is a system-wide constant that is known by all nodes which utilize this particular protocol. The first discovery time period (Ymax) is the amount of time that a particular node must turn on and listen for prospective service beacons, and after one the first discovery time period (Ymax), a client node A is guaranteed to have heard a beacon from every nearby neighbor.
While the channel is turned on during the first discovery time period (Ymax), either node B or node C can begin communicating with node A. In this example, node C begins communicating with node A. It should be noted that if no other node attempted to communicate with node A during the first discovery time period (Ymax), then at the end of the first discovery time period (Ymax) node A shuts down its ad hoc interface and returns to sleep mode during which the ad hoc interface is completely shut off. In other words, the ad hoc interface is turned on for a certain minimal amount of time that is adequate to advertise the presence of node A to other nodes (such as node B and node C) which might be in the vicinity or transmission range of node A, and to receive a response beacon from a prospective peer node.
If one of the neighbor nodes in proximity of node A responds with a beacon of its own, then node A can receive that beacon, analyze the information presented in that beacon, and determine whether or not one of the other nodes is providing a service or offering a service which node A has interest in.
For example, in
By contrast, node B sends information in its application service level beacon 424 which node A is not interested in. The application service level beacon 424 can be sent whenever node B wakes up or receives a beacon from another node in its proximity. The application service level beacon 424 can include, for example, the minimum second time period (α) that node B will leave the channel (its ad hoc interface) “ON” so that it can receive responses to the beacon that it sent (e.g., the amount of time that node B will listen for possible communication partners or other units that are interested in the services node B is offering), a third time period (β) after which node B will turn its ad hoc interface “OFF,” and the services being offered by node B. As shown in the graph 420 corresponding to node B, node B does not receive a response 416 from node A and, therefore, only keeps its ad hoc interface on for a second minimum time period (α) in the graph 420 corresponding to node B. This second minimum time period (α) corresponds to an idle or listening mode during which node B will keep the channel turned on in order to determine whether or not a prospective client node is interested in the service being offered by node B. This second minimum time period (α) is defined to preserve battery life and prevent battery drain in node B. Node B turns off its ad hoc interface for the third time period (β) if node B does not receive another beacon in response to its beacon 424.
Notably, by using these peer discovery techniques, the client node A which is looking for a service pays the higher cost since it stays awake for the entire first discovery time period (Ymax) and therefore must consume more of their own battery resources. Client node A consumes much more energy than prospective peer nodes B,C since client node A is on for a much longer period while it is listening. (The amount of energy consumed over first discovery time period (Ymax) is essentially the area under the curve and is substantially for node A than for prospective peer nodes B, C.) Thus, because node A is the particular node that is looking for service, node A pays more of the cost in terms of energy expended because it is seeking the service, whereas node B and node C are merely advertising services and, therefore, can leave their ad hoc interfaces off for a greater percentage of the time and expend less battery resources.
Although not shown in
As noted above, each node can set its own duty cycle based on alpha (α) and beta (β) and advertise that particular duty cycle to its neighbors. The parameter alpha (α) specifies how long the node will listen, i.e., how long the node will turn its ad hoc interface on, and beta (β) is the amount of time that the interface is off or “down”. The values of the time period alpha (α) and the time period (β) can change from time to time since each node has the ability to individually tune values of time period (α) and time period (β) which are used depending on the particular implementation of the network that a user is in.
For instance, in one implementation, each prospective peer provider node can independently set the duration of its second time period (α) and the duration of its third time period (β) based on the particular service(s) being offered by the particular node. The durations of these time periods are variable and can be set independently by each prospective peer provider node.
In another implementation, the duration of the second time period (α) can be adjusted based on the particular radio protocol being used, and the duration of the third time period (β) can be adjusted based on the real time requirements of the particular service(s) being offered by the particular node.
For client nodes, the values chosen for alpha (α) and beta (β) can be tweaked depending on the type of application that a particular client node is looking for. In other words, the window for which the client node stays awake can be tuned by that client node up to the first discovery time period (Ymax) (the system-wide constant that is known to all nodes utilizing this protocol). If a client node stays awake for this first discovery time period (Ymax), the client node is guaranteed that nodes in its vicinity operating in accordance with this particular protocol have received its service request.
For peer provider nodes, the values of alpha (α) and beta (β) can be determined by the services that are running on the node. Y is the total duty cycle for a particular peer provider node and is equal to the sum of alpha (α) plus beta (β) for that peer provider node. For a particular peer provider node, the value of Y can vary based on the particular values of alpha (α) and beta (β). In all cases, the value of Y has an upper bound (Ymax) which specifies the maximum value that the value of Y can take. Thus, different nodes within the population can have a different alpha (α) and beta (β) value depending on the particular service that they offer.
Thus, the alpha (α) parameter can be tuned based on a number of different variables. The value of alpha (α) is generally dictated by the characteristics of the particular node protocol being used; for example, an IEEE 802.11 protocol would utilize one value of alpha (α). The value chosen for alpha (α) in a particular scenario can also depend on factors such as round trip delay in the hardware platform. It is desirable to keep alpha (α) as small as possible since this helps conserve energy since the higher the value of alpha (α), then the higher the cost is in terms of battery resources to the node. However, the node will also be more likely to be able to offer services to other nodes in the network with the higher value of alpha (α).
The factors or parameters that help determine the value of beta (β) include constraints in the node itself. The value of beta (β) can be determined, for example, based on the real time requirements of the application service that the particular node is offering (e.g., is the application delay tolerant, how many different applications are running in a particular instance that the node will potentially need to send out responses to, and the relative importance of the data being transmitted). The amount of power which remains on the node is also another factor that can influence the value of beta (β) so that as the battery drains the value of beta (β) would increase to conserve the remaining battery power, i.e., utilize less power as battery capacity decreases. The value of beta (β) can be determined based on the minimum initial request service time required for all active applications running on the related node. The value of beta (β) can be determined based on the minimum initial request service time required by all applications loaded on the related node.
For instance, referring back to
The federated phone book application 242 is a data-sharing application to which a query is sent for a piece of data and a response is sent back to the client node A. In this situation, the client node A making the request for the data would send the request for one full Ymax duration and if any neighbor nodes are within the proximity of the client node A, then those neighbor nodes can grab the piece of data that is requested, send it, and then fall back asleep immediately. As such, in this context the value of alpha (α) would be relatively small and the value of beta (β) would be relatively large. In other words, the neighbor node only needs to stay on long enough to receive the request, and send a response, and can then immediately go to sleep and does not need to stay on for any extra period of time.
By contrast, in an application called encounter alerts 244, the user of node A, for example, could enter a request into the node to determine when a user of a particular node is in their vicinity so they can communicate with them (e.g., client node A would be looking around periodically for prospective peer node C). In this scenario, alpha (α) can be tuned over time. For example, if node A would like to find node B by Friday and it is currently Monday, the value of alpha (α) can change over that time period until node A contacts node B. For example, on Monday, the duration of alpha (α) can be relatively short, but if node B is still not found, then as the week progresses, the duration of alpha (α) could be increased since it has become more urgent to find node B. This way as the deadline approaches, the node A would stay on or active longer advertising their presence to increase the likelihood of reaching node B.
According to another embodiment of the present invention, techniques are provided for choosing between two prospective beaconers who offer to provide a service to a requesting node (e.g., resolving a conflict when two prospective peer provider nodes respond with a first beacon). According to these techniques, when the client node receives a first beacon from a first prospective peer provider node and a second prospective peer provider node. In addition to a service extension field, the second beacon can further comprise a first field specifying a duration of the second time period (α) during which the second ad hoc interface will be on and a duration of the third time period (β) during which the second ad hoc interface will be off, a MAC beacon field which specifies the IEEE 802.11 MAC beacon; an IP extension field which specifies the IP address of the particular node that is transmitting the second beacon; and a second field comprising a number of neighbor nodes a particular prospective peer provider node has seen recently within a particular time period. The client node evaluates each of the second beacons, and chooses either the first prospective peer provider node or the second prospective peer provider node based on the fields specified in each of the second beacons. One implementation of these fields will now be described below with reference to
Each node, including the prospective peer provider node 501, transmits an advertisement packet 521 to advertise the services that node can potentially provide, and describes what the particular node is capable of. The advertisement packet 521 comprises a MAC beacon field 505 which specifies an IEEE 802.11 MAC beacon of the node, an IP extension field 509 which specified the IP address of the particular node that is transmitting the advertisement packet 521, a service extension field 507 which contains a list of services that are currently running on the node or that the node is capable of running, a seen extension field 517 which describes how many neighbors a particular node has seen recently within a particular time period and allows a node to describe the density of nodes which are presently running a particular protocol, and a stay extension field 519 which includes the parameters alpha (α) and beta (β) for that prospective peer provider node 501. The service extension field 507 allows a service requesting node A 503 to initiate a service against the prospective peer provider node 501 if they know that the prospective peer provider node 501 has a service running or could potentially offer it even if it is not currently running.
Upon receipt of a beacon 521 at time 511 from he prospective peer provider node 501 the client node 503 decides whether the service being offered by node 501 matches its application requirements. If so, before timer 513 (related to the alpha (α) parameter specified in the stay extension field 519 of the received beacon 521) expires, the prospective peer provider node 501 opens a service port SI on the prospective peer provider node 501. For instance, in one implementation, a Transmission Control Protocol (TCP) SYN packet 515 would be sent.
As shown in
By contrast, a prospective peer node B keeps its ad hoc interface on for a time period (α) during which it sends beacon 624B and listens for beacons from potential client node(s), and then turns its ad hoc interface off for a time period (β). The sum of time periods (α+β) is equal to the time period (Y2), and in this example time period (Y1) is equal to time period (Y2); however, the time period (Y1) and time period (Y2) are not synchronized in time. For example, the leading edge of time period (Y1) where the ad hoc interface of the client node A turns on, does not occur at the same time as the leading edge (Y2) where the ad hoc interface of the prospective peer node B turns on. Similarly, the falling edge of time period (Y1) where the ad hoc interface of the client node A turns off, does not occur at the same time as the falling edge where the ad hoc interface of the prospective peer node B turns off (at the end of the time period (α)).
In a typical IEEE 802.11 network in IBSS mode, nodes are not synchronized since nodes are assumed not to have the benefit of a central controller such as an internet access point or base station. However, many nodes have access both to the cellular network and the ad hoc network. If particular nodes subscribe to the same service provider for its cellular service, the nodes can use the synchronization that is provided via the cellular network in the context of the ad hoc network to achieve timing synchronization that would otherwise not be possible. For example, in a time division multiple access (TDMA) system all base stations are synchronized in time to within milliseconds (using global positioning system (GPS) satellites), and every cell in a network transmits a universal time constant that is the same across cells in the network. This universal time constant is transmitted to all nodes in the network as part of the network protocol.
In idle mode, a client node A still consumes substantial amount of energy in comparison to peer nodes. According to another embodiment of the present invention, techniques are provided in which the nodes in the ad hoc network are time synchronized based on a time constant provided, for example, from a cellular network or service. Synchronizing nodes operating in an ad hoc mode can allow the nodes to turn their ad hoc interface “on” and “off” at predefined intervals to help reduce the energy consumption of the client nodes.
As shown in
Both the client node A and the prospective peer node B keep their ad hoc interfaces on for a relatively short time period (α) between t0 and t3 during which they send beacons 724A, B and listen for response beacons from other node(s), and then turn their ad hoc interfaces off for a time period (β) between t3 and t0′. The sum of time periods (α+β) is equal to the time period (Y), and the time periods (Y) for both the client node A and the prospective peer node B are substantially synchronized in time. For example, at both the client node A and the prospective peer node B, the leading edge (t0) of time period (α) where the ad hoc interface turns on, and the falling edge (t3) of time period (α) where the ad hoc interface turns off, both occur at substantially the same time. Similarly, at both the client node A and the prospective peer node B, the time periods (β) where the ad hoc interface turns off (between t3 and t0′) both occur at substantially the same time.
The sub-graph 720 shows a timeline (t1,t2) within the time period (α) during which the beacon 724A can be positioned. The particular location for the beacon within the time period (α) can vary between the times t1 and t2. This is done to provide a compensation window that allows for the different nodes to account for drift in the synchronization between those nodes and thereby provide a sufficient overlap between the beacons of different synchronized nodes when the node's clocks drift slightly apart from one another. The precise timing of the beacon can be randomly chosen anywhere between the interval t1 to t2. Randomly choosing the location of the beacon reduces the amount of contention on the channel.
In this embodiment, each node follows the following protocol. At time t0, the node turns its ad hoc interface “on” and starts listening for beacons. Time t0 is determined by the universal time synchronization constant. For example, t0 could be every 0-th second and every 30-th second when the time period (Y) is one minute. The time period (Y) is the time period between t0, t0′. If the node wants to send a beacon the node computes a time X at which it will send the beacon. The time X is computed to be a random time in the interval (t1, t2). The randomization is optional and can be implemented to avoid collision. Times t1 and t2 can be selected such that t1−t0>“maximum time drift”, t3−t2>“maximum time drift” and t1−t0=t3−t2. The selection of the time interval (t1, t2) is designed in order to account for the maximum time drift between two nodes. This guarantees that every node will be listening during the time when another node will be sending its beacon. At time t3, each node turns its ad hoc interface “off.” If a node is not interested in receiving beacons but just sending beacons, then the node can further save energy by staying “off” for the duration of (t0, t1) and then staying “on” for some short interval so that a beacon response can be received. Using this protocol, the energy conservation is proportional to the percentage of time the node is in state “off”. The longer the node remains “off”, the higher the energy saving will be. On average, the time to discover existing peers is measured by (Y−α)/2. Moreover, the node knows the next time t0 at which another discovery might be possible and this information can be passed to the upper layer applications.
Thus, by time synchronizing the nodes, every node in the ad hoc network can effectively use a TDM-like protocol in which they send their beacons within a specific time slot that is common to all of the nodes that belong to that particular network. The various nodes in the ad hoc network can then use this time synchronization to agree in advance on particular time period or interval (α) during which those nodes will be listening or idle and transmitting their beacon message, and also agree on the particular time period or interval (β) during which those nodes will be completely off. This can reduce energy consumption of the nodes since they will only need to keep their ad hoc interface “on” for a predetermined period or interval (α). This way, if other nodes are in proximity (e.g., transmission range) of a node, then that node should always be able to detect a beacon within a very, very short interval in comparison to a situation where the nodes are not synchronized.
The continuous beacon sender process 800 comprises a number of states 810-830 and a number of arcs 815, 825, 827, 828 between those states 810-830. Arcs between the different states 810 through 830 can be read either as the expiration of a timer or a signal that has been detected by the engine that is running or processing the state machine 800.
During a pending entry/Radio.on( ) state 810 the ad hoc interface of the node enters an “on” state and is turned on. The channelDetected arc 827 is a signal from the hardware (or ad hoc device driver) which asserts the presence of an RF level beacon. The after (maxDetectTime) arc 828 is the per hardware time to discover an RF level beacon on the current channel. This represents the maximum time the node will look for another beacon on the same channel from another node.
During a beacon entry/sendServiceBeacon( ) state 820, the ad hoc interface of the node enters a “beacon” state and sends a service beacon. The after(α) arc 825 is a timer waiting for a timeout related to the alpha value.
During the idle entry/Radio.off( ) state 830, the ad hoc interface of the node enters an “idle” state and is turned off. The after(β+α-lastRadioOnTime) arc 815 represents the behavior of each node in the population of nodes when those nodes have nothing else to do. lastRadioOnTime is for synchronization to the last beacon sent by this unit (or could alternatively be used to synchronize the entire population).
The application-driven beacon receiver process 900 comprises a number of states 910-930 and a number of arcs 915, 925, 932, 935 between those states 910-930.
The states 910-930 include an idle entry/Radio.off( ) state 910 during which the ad hoc interface is turned off. During the pending entry/Radio.on( ) state 920 the ad hoc interface is turned on. The scanForPeers( ) arc 915 initiates a Y cycle during which the particular node will scan for peers by turning the ad hoc interface on at pending entry/Radio.on( ) state 920, and then, as indicated by arc 925, attempting to detect or establish a channel. The scanForPeers( ) is a function API exposed to the higher layer which can be implemented as sync (with sync callback on caller's frame), deferred sync (as was done via future object style with jSIP) or async (standard listener model of Java). The channelDetectedOrEstablished arc 925 is a signal from the hardware which asserts the presence of an RF level beacon (seen or created).
During a receive state 930, the node listens for beacons from peer nodes and continues to receive those and to determine whether or not one of those peer nodes is offering (or is capable of offering) a service which the node would like to receive Once in the receive state 930, the node attempts to receive, and as indicated by scanForPeers( ) arc 932, this process continues until the node receives a response from at least one other node. After(Y) 935, the ad hoc interface of the node returns to state 910 where the ad hoc interface is turned off.
Thus, a node typically stays in the idle state 910 unless the application wants to looks for nodes in its transmission range, at which point the node transitions to radio on state 920 where the radio is turned on to scan for peers per arc 932.
At idle entry state/Radio.off( ) 1010 the node is in an idle state where the ad hoc interface is off. From state 1010, the node can For example, when there is a prospective peer node that a client node would like to communicate with, the hold( ) function ensures that the ad hoc interface is left on for the time that the application remains in a servicing mode (e.g., the time during which it is trying to service requests from another party). Once all the requests have been satisfied or taken away at appX_peered entry/Radio.on( ) state 1020, the application calls a release function at arc 1025 allows the hold 1015 to be turned off, and the node reenters an idle state 1010 in which the ad hoc interface is turned off.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that can cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
