Download MiLAN Middleware: Enhancing Sensor Network Applications with Proactive Network Management and more Thesis Computer Science in PDF only on Docsity!
6 0890-8044/04/$20.00 © 2004 IEEE IEEE Network • January/February 2004
or several decades, distributed computing has been both an enabling and a challenging environment in which to build applications. Initially, the major diffi- culty in implementing such systems was simply exchanging data across distances and among heterogeneous components. Today these problems are essentially solved, and research is turning its focus to higher-level concerns such as improved fault tolerance through replication, optimal data access via distributed object placement, and methods of enabling high-level communication abstractions such as event dispatching and remote invocation. The end result of this research into distributed systems is an expanding set of mid- dleware platforms that reside above the operating system and below the application, abstracting lower-level functionality such as network connectivity and providing a high-level coor- dination interface to the application programmer. Often the combination of characteristics from the environ- ment and application drive the design of the middleware. For example, consider the new class of applications for sensor net- works with the following features:
- Inherent distribution. The sensors are distributed throughout a physical space and primarily connected wirelessly.
- Dynamic availability of data sources. Either mobility through space, addition of new sensors, or loss of existing sensors causes the set of available sensors to change over time.
- Constrained application quality of service demands. Sensor
network applications require a minimum quality of service (QoS); this level must be maintained over an extended peri- od of time. There may be many ways to achieve the QoS (e.g., different sensors may offer data or services that meet the applications’ QoS requirements). Furthermore, the required QoS and the means of meeting it can change over time, as the state of the application or availability of sensors changes.
- Resource limitations. Both network bandwidth and sensor energy are constrained. This is especially true when consid- ering battery-powered sensors and wireless networks.
- Cooperative applications. Sensor network applications share available resources (e.g., sensor energy, channel bandwidth) and either cooperate to achieve a single goal or, at the very least, do not compete for these limited resources. One unique feature of sensor network applications with these properties is that simply responding to the changing environment is insufficient to achieve the required QoS over time. Instead, the applications must be proactive , actively affecting the network. Most existing middleware systems do not support such a proactive approach with respect to the net- work, leaving reactivity as the only choice and sacrificing application quality over time. We believe a middleware that enables applications to affect the network and the sensors themselves is needed to support this new and growing class of applications for sensor networks.
F F
Wendi B. Heinzelman, Amy L. Murphy, Hervaldo S. Carvalho, and Mark A. Perillo
University of Rochester
Abstract
Current trends in computing include increases in both distribution and wireless con- nectivity, leading to highly dynamic, complex environments on top of which appli- cations must be built. The task of designing and ensuring the correctness of applications in these environments is similarly becoming more complex. The unified goal of much of the research in distributed wireless systems is to provide higher- level abstractions of complex low-level concepts to application programmers, eas- ing the design and implementation of applications. A new and growing class of applications for wireless sensor networks require similar complexity encapsulation. However, sensor networks have some unique characteristics, including dynamic availability of data sources and application quality of service requirements, that are not common to other types of applications. These unique features, combined with the inherent distribution of sensors, and limited energy and bandwidth resources, dictate the need for network functionality and the individual sensors to be controlled to best serve the application requirements. In this article we describe different types of sensor network applications and discuss existing techniques for managing these types of networks. We also overview a variety of related middle- ware and argue that no existing approach provides all the management tools required by sensor network applications. To meet this need, we have developed a new middleware called MiLAN. MiLAN allows applications to specify a policy for managing the network and sensors, but the actual implementation of this policy is effected within MiLAN. We describe MiLAN and show its effectiveness through the design of a sensor-based personal health monitor.
Middleware to Support
Sensor Network Applications
This article presents an overview of related research in the areas of sensor net- works and middleware, highlighting how existing approaches to the management of sensor networks could benefit from a mid- dleware abstraction and showing that exist- ing middleware does not meet the specific needs of all sensor network applications. Based on this observation, we propose a new middleware for sensor networks called Middleware Linking Applications and Net- works (MiLAN). MiLAN allows sensor network applications to specify their quali- ty needs and adjusts the network character- istics to increase application lifetime while still meeting those quality needs. Specifi- cally, MiLAN receives information from:
- The individual applications about their QoS requirements over time and how to meet these QoS requirements using dif- ferent combinations of sensors
- The overall system about the relative importance of the dif- ferent applications
- The network about available sensors and resources such as sensor energy and channel bandwidth Combining this information, MiLAN continuously adapts the network configuration (e.g., specifying which sensors should send data, which sensors should be routers in multihop net- works, which sensors should play special roles in the network) to meet the applications’ needs while maximizing application lifetime. Figure 1 shows a high-level diagram of a system that employs MiLAN. Next we describe several sensor network applications that could benefit from a middleware like MiLAN that proactively affects different characteristics of the network. Following this, we discuss existing sensor network management and middle- ware approaches. Finally, we describe MiLAN and show how the design of a health monitor sensor application can be sim- plified using MiLAN.
Sensor Network Applications
As stated in the introduction, sensor network applications rep- resent a new class of applications that are:
- Data-driven, meaning that the applications collect and ana- lyze data from the environment, and, depending on redun- dancy, noise, and properties of the sensors themselves, can assign a quality level to the data
- State-based, meaning that an application’s needs with respect to sensor data can change over time based on previ- ously received data Typically sensors are battery-operated, meaning they have a limited lifetime during which they provide data to the applica- tion. A challenge of the design of sensor networks is how to maximize network lifetime while meeting application QoS requirements. For these types of applications, the needs of the application should dictate which sensors are active and the role they play in the network topology. To further illustrate this point, we discuss some specific sensor network applica- tions and how they can benefit from this form of interaction.
Environmental Surveillance
Consider an environment where multiple sensors (e.g., acous- tic, seismic, video) are distributed throughout an area such as a battlefield. A surveillance application can be designed on top of this sensor network to provide information to an end user about the environment. The application may require a
minimum percentage of sensor coverage in an area where a phenomenon is expected to occur. The sensor network may consist of sensors with overlapping coverage areas providing redundant information. If the application does not require all this redundant information, it would be desirable to conserve energy in some sensors by allowing them to sleep, thereby lengthening the lifetime of the network. For example, as sen- sors use up their limited energy, the application would like to use different sets of sensors to provide the required QoS (in this case, minimum sensor coverage area). This requires that the application manage the sensors over time. Such manage- ment can be as simple as turning sensors on and off, or as complex as selecting the routes for data to take from each sensor to the collection point in a multihop network. Further- more, the needs of the surveillance application may change as a result of previously received data. For example, if the appli- cation determines that an intrusion has occurred, the applica- tion may assume a new state and require more sensors to send data to more accurately classify the intrusion. The imple- mentation of these tasks can be complex, and they are diffi- cult to incorporate into applications.
Home/Office Security Home/office security systems are becoming increasingly com- plex, monitoring for not only intrusion into the space but also the occurrence of substances such as fire or carbon monoxide gas. To be able to monitor the application variables, the secu- rity system must obtain data from heterogeneous sensors such as acoustic, motion, heat, and vibration sensors scattered throughout the home/office. Making these sensors wireless and battery-powered allows them to easily be placed in exist- ing homes without major household modifications. To make the sensor network last as long as possible, the application may only want a subset of the sensors activated at any time. Once a sensor’s activation has been triggered through some event, the application must analyze the data and decide how to change the configuration of active sensors. This can be modeled as the application changing state based on received data. For different application states, different sets of sensors should be activated to provide the greatest benefit to the security application. Thus, the application needs to be able to control which sensors are activated over time. At the same time, to allow the application to work as long as possible, the set of sensors activated for a given application state should be chosen wisely to reduce energy dissipation and maximize sys- tem lifetime. Furthermore, sensors whose data are very
Figure 1. A system that employs MiLAN. Each sensor runs a (possibly scaled down) version of MiLAN. MiLAN receives information from applications about their QoS requirements, a system user about the desired interaction among the applications, and the network about available components and resources. MiLAN then decides how best to configure the network to support the applications.
Data
Data
QoS
QoS
System
QoS
App 1
App n
Network MiLAN
M
M M
M
M
M M
energy constraints of sensor networks, and their supporting protocols are heavyweight when compared to protocols tai- lored to sensor networks. Some middleware acknowledge the changing properties of wireless networks and attempt to modify their own behavior to match the conditions detected within the network. For example, both Limbo [17] and FarGo [18] reorder data exchanges or relocate components to respond to changing network conditions such as bandwidth availability or link relia- bility. At a lower level, Mobiware [19] supports various levels of QoS by adapting streams within the network with active fil- ters deployed in the routers. Other middleware systems pro- vide hooks to allow the applications to adapt. For example, applications built on the Odyssey platform [20] can register for notification of changes in the underlying network data rate. Similarly, the Spectra [21] component of Aura [22] moni- tors the network conditions and the accessible computation resources, deciding where computation should be performed based on the network transmission required to complete them as well as the expense of the computation on mobile versus fixed nodes. These advances are applicable to wireless sensor networks; however, they do not integrate any of the specific data aggregation protocols of sensor networks, nor do they consider the details of the low-level wireless protocols. Among existing distributed computing middleware, QoS- Aware Middleware [23] provides the closest example of a middleware that can support sensor network applications. This middleware is responsible for managing local operating system resources based on application requirements specified to the middleware. The application’s QoS information is com- piled into a QoS profile to guide the middleware in making resource use decisions.
Middleware for Sensor Networks
Recently, much work has targeted the development of middle- ware specifically designed to meet the challenges of wireless sensor networks, focusing on the long-lived and resource-con- strained aspects of these systems. Both the Cougar [24] and SINA [25] systems provide a dis- tributed database interface to the information from a sensor network with database-style queries. Power is managed in Cougar by distributing the query among the sensor nodes to minimize the energy consumed to collect the data and calcu- late the query result. To support the database queries, SINA incorporates low-level mechanisms for hierarchical clustering of sensors for efficient data aggregation as well as protocols that limit the retransmission of similar information from geo- graphically proximate sensor nodes. AutoSec [26], Automatic Service Composition, manages resources in a sensor network by providing access control for applications so that QoS requests are maintained. This approach is similar to middleware for standard networks because resource constraints are met on a per-sensor basis, but the techniques for collecting the current resource utiliza- tion are tailored to the sensor network. DSWare [27] provides a similar kind of data service abstrac- tion as AutoSec, but instead of the service being provided by a single sensor, it can be provided by a group of geographical- ly close sensors. Therefore, DSWare can transparently man- age sensor failures as long as enough sensors remain in an area to provide a valid measurement. While these middleware for sensor networks focus on the form of the data presented to the user applications, Impala [28], designed for use in the ZebraNet project, considers the
Figure 3. Relationships among different middleware. In this figure, “middleware reactive” refers to middleware that reacts itself to changes in network behavior, whereas “middleware proactive” refers to middleware that proactively changes the network functionality. Similarly, “enables reactive applications” refers to middleware that provides hooks so that applications can react to changes in the envi- ronment, whereas “enables proactive applications” refers to middleware that accepts information from the application about how to respond to changes in the network.
Reactive
Static environment
Middleware reactive
Middleware proactive
Proactive
Middleware
Enables reactive applications
Limbo Fargo
Specialized network protocols
DSWare Cougar SINA
Flexible to existing network protocols
MiLAN
Sensor network middleware
AutoSec
QoS aware middleware
Data/resource management
Impala
Code management
Odyssey Spectra
Non-adaptive
Enables proactive applications
Adaptive
LIME Jinl
Dynamic environment
Corba Linda
application itself, exploiting mobile code techniques to change the functionality of the middleware executing at a remote sen- sor. The key to energy efficiency for Impala is for the sensor node applications to be as modular as possible, enabling small updates that require little transmission energy. Although each of these middleware is designed for efficient use of the wireless sensor network, they largely ignore the properties of the network itself. In other words, most of these approaches do not attempt to change the properties of the network in order to manage energy, and they are not flexible enough to support different protocol stacks or different appli- cations’ QoS requirements.
MiLAN Middleware
As the summary of related work in the previous section shows, most sensor network research has focused on designing new network-level protocols (e.g., MAC layer, routing layer, topology control), without considering existing standards or how applications use the protocols. We argue that sensor net- work applications may be built on top of existing protocols, and thus some coordination framework is needed to leverage the flexibility that exists in both standardized and nonstandardized network protocols. However, to make these protocols more use- ful, application designers would benefit from a middleware that encapsulates the protocols, pro- viding a high-level interface. Although the mid- dleware systems discussed provide reasonable APIs, they either invent their own energy man- agement protocols or provide limited mecha- nisms to adapt to the constraints of the wireless network. We argue that additional savings can be achieved if the middleware varies the actual parameters of the network over time while simul- taneously meeting the requirements of the appli- cation, thereby increasing the lifetime of the network. We are developing a new middleware named
Middleware Linking Applications and Networks (MiLAN) that receives a description of applica- tion requirements, monitors net- work conditions, and optimizes sensor and network configurations to maximize application lifetime. To accomplish these goals, appli- cations represent their require- ments to MiLAN through specialized graphs that incorporate state-based changes in application needs. Based on this information, MiLAN makes decisions about how to control the network as well as the sensors themselves to bal- ance application QoS and energy efficiency, lengthening the lifetime of the application. Unlike traditional middleware that sits between the application and the operating system, MiLAN has an architecture that extends into the network protocol stack, as shown in Fig. 4. As MiLAN is intended to sit on top of multiple physical networks, an abstraction layer is provided that allows net- work-specific plugins to convert MiLAN commands to proto- col-specific commands that are passed through the usual network protocol stack. Therefore, MiLAN can continuously adapt to the specific features of whichever network is being used for communication (e.g., determining scatternet forma- tions in Bluetooth networks or coordinator roles in Span [6]) in order to best meet the applications’ needs over time. Figure 5 shows an overview of the interactions among MiLAN, the applications, and the sensors, together with a partial API. This figure makes a distinction between the net- work plugins and the core of MiLAN, emphasizing the sepa- ration of computation that is specific to the selected network type vs. the computation that always occurs, but the API spec- ifies only the application- and sensor-level operations. To make the description of the MiLAN API and network plugin abstraction more concrete, we use the personal health moni- tor application from earlier as a running example.
Application Performance Many sensor network applications are designed to receive data input from multiple sensors and to adapt as the available sensors change over time, as either new sensors come within
Figure 4. Milan components (shaded). Milan presents an API through which the application represents its requirements with regard to different sensors that may be available. Milan also presents an abstraction from the network-level functionality through which it issues com- mands to determine available sensors and configure the network.
Application/sensors
MiLAN
MiLAN API
Plugin abstraction
HCI
L2CAP
Bluetooth- specific local network control
Remote network control
Data channels
Bluetooth stack
Bluetooth radio
Bluetooth network
IP/Ad Hoc routing
TCP/UDP
802.11- specific local network control
Remote network control
Data channels
802.11 MAC
802.11 radio
IEEE 802.11 network
Routing
Transport
Network- specific local network control
Remote network control
Data channels
MAC
Physical
Generic network
Table 1. Feasible sets F (^) A for the personal health monitor application for a patient in medium stress with high heart rate, normal respiratory rate, and low blood pressure.
1 Blood flow, respiratory rate
2 Blood flow, ECG (3 leads)
3 Pulse oxymeter, blood pressure, ECG (1 lead), respiratory rate
4 Pulse oxymeter, blood pressure, ECG (3 leads)
5 Oxygen measurement, blood pressure, ECG (1 lead), respiratory rate
6 Oxygen measurement, blood pressure, ECG (3 leads)
Set # Sensors
application’s minimum acceptable QoS for each variable (e.g., blood pressure or respiratory rate) based on the current state of the patient. For example, the figure shows that when a patient is in a medium stress state and the blood pressure is low, the blood oxygen level must be monitored at a quality level of .7 and the blood pressure at a quality level of .8. For a given application, the QoS for each variable can be satisfied using data from one or more sensors. The application specifies this information to MiLAN through the Sensor QoS graph (Fig. 7a). When multiple sensors are combined to pro- vide a certain quality level to the variable, we refer to this as a single virtual sensor. Figure 7b shows the Sensor QoS graph for the personal health monitor. This graph illustrates the important variables to monitor when determining a patient’s condition and indicates the sensors that can provide at least some quality to the measurement of these variables. Each line between a sensor (or virtual sensor) and a variable is labeled with the quality the sensor (or virtual sensor) can provide to the measurement of that variable. For example, using data from a blood pressure sensor, the heart rate can be deter- mined with a .7 quality level, but combining this with data from a blood flow sensor increases the quality level to 1.0. Given the information from these graphs as well as the cur- rent application state, MiLAN can determine which sets of
sensors satisfy all of the application’s QoS requirements for each variable. These sets of sensors define the application fea- sible set FA, where each element in FA is a set of sensors that provides QoS greater than or equal to the application-speci- fied minimum acceptable QoS for each specified variable. For example, in the personal health monitor, for a patient in medium stress with a high heart rate, normal respiratory rate, and low blood pressure, the application feasible sets in FA that MiLAN should choose to meet the specified application QoS are shown in Table 1. MiLAN must choose which element of FA should be provided to the application. This decision depends on network-level information.
Network The properties of specific network types as well as the current condition of the network can constrain the set of feasible sets to a subset of those in FA. As shown in Fig. 5, it is the network plugin’s job to determine which sets of nodes (sensors) can be supported by the network, as well as other protocol-specific information, such as what role each node must play. MiLAN uses a service discovery protocol (such as SDP [30] or SLP [31]) to find new nodes and learn when nodes are no longer accessible (due to mobility or exhausting their energy resources). The service discovery protocol must return impor-
Figure 6. The State-based Variable Requirements graph for specifying the variables and required QoS when the application is in vari- ous states: a) abstract example; b) example for the personal health monitor application. This graph illustrates only a subset of the appli- cation’s possible states.
User stress state None
High Norm
Blood pressure Low High/ Norm low
High/ low
High Norm (+ECG)
Heart rate
Respiratory rate
Norm
Blood pressure
Blood pressure
Resp rate
Blood O
Heart rate
Blood O
ECG diag.
Blood pressure (b)
Blood O
BP
.
.8 (^) .8. .3.
.3 .8.
.3 .3 1.0 1.
.3 (^). .3.
Norm
HR
.
Low Med
(a)
V (^) i
q 1 q 2 q 3 q 4
q 5
V (^) j V (^) k
A
System state S (^) S=1 S (^) S =2 S (^) S =
System state SV1 =1 (^) S (^) V2=
V 2 state B S (^) V1=2 S (^) V1 = M S (^) V2 = N
C
High
Heart rate
Figure 7. The Sensor QoS graph for specifying which sensors, or sets of sensors, can provide what level of QoS for each variable: a) abstract example; b) example for the personal health monitor application. This graph illustrates only a subset of the variables that should be considered by the application.
.9.
Resp sensor ECG*
Resp rate
1.0 (^) .7. .
Blood press
*ECG can be used with 3, 5, or 12 leads **ECG can be used with 1, 3, 5 or 12 leads
ECG** Bloodflow Pulseoxy
Heart rate
.7 (^) 1.0 .8.
Blood press
Blood pulse
Pulse oxy
Blood flow
Blood press
. . .
EMG
Virtual sensor
Accel. Camera EEG
(b)
Body activity
.1 (^) .5.
ECG1 ECG3 ECG5 ECG
ECG diag.
. 1.0 .6.
Blood press
Oxygen sensor
Blood flow
Pulse Oxy
Blood O
qs (^4) v a
qs (^5) v a
qs (^6) v a
qvs
1 v (^) a
(a)
S 1 S 2
Va
VS 1
S 3 S 4 S 5 S (^6) 1.
tant information about the node, such as the type of data that can be provided by that node, the modes in which the node can operate, transmission power levels, and the current resid- ual energy level. Using this information from each currently available node, the network plugin must determine which sets of nodes can be supported by the network. If we assume that all nodes are on a single-hop centralized network, bandwidth constraints place limitations on the total amount of data that can be transmitted to the application. For example, if all nodes are on a Bluetooth piconet or an 802. network operating in infrastructure mode, all nodes transmit data directly to the application (residing at the master in Bluetooth or the access point in 802.11). Therefore, the net- work constraint is the total rate and schedulability of all data transmitted. However, in more complex environments such as Blue- tooth scatternets, 802.11 multihop networks, or hybrid net- works, network topology plays an important role in determining network feasibility and power costs. For exam- ple, in Bluetooth it is necessary to choose a feasible scatter- net topology, where nodes selected in the feasible set allow the network to be fully connected. In addition to ensuring the feasibility of a network configuration, we must also consider how the power costs of nodes are affected by their roles in the network (e.g., piconet masters or bridge nodes in Blue- tooth scatternets, data aggregators in Directed Diffusion [2], coordinators in Span [6]). The power cost of using a node is a combination of the power to run the device, the power to transmit its data, the power to forward the data of other nodes in the set, and the overhead of maintaining its role in the network. These costs can be influenced by MiLAN through techniques such as transmission power control, effi- cient traffic scheduling, and the setting of different sleep states. In multihop networks, routing data from nodes to the application also becomes an important factor. The plugin should know all of the network’s protocol-specific features that can be modified and choose how to set these features to make sets feasible and energy-efficient. The subsets of nodes that can be supported by the network define a network feasible set FN. As only sets in FA provide the required application QoS, we can combine these two con- straints to get an overall set of feasible sets: F = FA ∩ FN. For the personal health monitor, suppose that the sensors and processors communicate using an IEEE 802.11b network. As these networks can support overall throughput of nearly 11 Mb/s, the network is able to support the transmission of all data from each of the sensor sets in FA from Table 1 in real time. However, if other applications (e.g., video gait monitor- ing [32]) are running simultaneously on the network and the personal health monitor application can only utilize 100 kb/s of the throughput, the network would not be able to support the transmission of data from the ECG sensor with either 3, 5, or 12 leads. Thus, the set of network feasible sets FN will only partially overlap with FA. This overlap is the set of feasible sets F and consists of sets 1, 3, and 5 in Table 1. MiLAN must choose a set of sensors from one of the sets in F based on the trade-offs discussed in the next section. If FA is empty, MiLAN should raise an exception to the application, allowing it to decide the appropriate action.
Trade-offs Among the elements in F, MiLAN chooses an element f (^) i that represents the best performance/cost trade-off. How should “best” be defined? This depends on the application; the MiLAN framework supports any method of deciding how to
choose an element of F. In most sensor network applications, we want to allow the application to last as long as possible using the limited energy of each of the sensors. Simple approaches to choosing sensor sets may yield the set f (^) i that consumes the least power or will run for the maximum life- time before the first sensor dies. However, if we want to ensure that the application can run at the required QoS level as long as possible, we should instead optimize the total life- time by intelligently choosing how long to use each feasible sensor set [33]. In some cases there are multiple ways to schedule sensors so that the same total network lifetime is achieved. In these cases we may want to maximize the average quality of the sensor sets over time. For some applications the goal may be to maximize some combination of lifetime and quality. MiLAN is flexible enough to incorporate any of these or other optimization criteria. In Fig. 5 we show this trade-off computation occurring in the core MiLAN component. After the computation is com- plete and the first set of sensors is chosen, the MiLAN core informs the plugin of the selection, and the plugin configures the network accordingly, using information about the role each sensor should play.
Conclusions Current research trends suggest the power of middleware to ease the application development task in complex environ- ments. While conventional middleware operates above the networking layer, for sensor network applications that rely on multiple and varying sensors it is not a viable approach to manage the network completely independent of the needs of the application. We have argued that the needs of the applica- tion should be integrated with the management of the net- work into a single unified middleware system. Through this tight coupling, the middleware can trade application perfor- mance for network cost, while still retaining the separation between the policy specifying how to react to a dynamic envi- ronment (obtained from the application) and the mechanisms to implement the policy (performed in the middleware). We have shown that MiLAN, a sensor network middleware we are developing to meet these goals, can aid the development of sensor network applications. For more details on the MiLAN project, including references to related papers, please visit the project Web page at http://www.futurehealth.rochester.edu/ milan/.
References [1] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “Energy-Efficient Communication Protocol for Wireless Microsensor Networks,” IEEE Trans. Wireless Commun. , vol. 1, no. 4, Oct. 2002, pp. 660–70. [2] C. Intanagonwiwat, R. Govindan, and D. Estrin, “Directed Diffusion: A Scal- able and Robust Communication Paradigm for Sensor Networks,” Proc. ACM MobiCom ’00 , Aug. 2000. [3] S. Singh and C. Raghavendra, “PAMAS: Power Aware Multi-Access Protocol with Signalling for Ad Hoc Networks,” ACM Comp. Commun. Rev., vol. 28, no. 3, July 1998, pp. 5–26. [4] Y. Wei, J. Heidemann, and D. Estrin, “An Energy-Efficient MAC Protocol for Wireless Sensor Networks,” Proc. INFOCOM 2002 , June 2002. [5] A. Cerpa and D. Estrin, “ASCENT: Adaptive Self-Configuring Sensor Net- work Topologies,” INFOCOM 2002 , June 2002. [6] B. Chen et al. , “Span: An Energy-Efficient Coordination Algorithm for Topol- ogy Maintenance in Ad Hoc Wireless Networks,” ACM Wireless Networks , vol. 8, no. 5, Sept. 2002. [7] C. Schurgers et al. , “Optimizing Sensor Networks in the Energy-Latency-Density Design Space,” IEEE Trans. Mobile Comp. , vol. 1, no. 1, Jan. 2002, pp. 70–80. [8] R. Ramanathan and R. Rosales-Hain, “Topology Control of Multihop Wireless Networks Using Transmit Power Adjustment,” Proc. INFOCOM 2000, Mar. 2000, pp. 404–13. [9] E. Lloyd et al. , “Algorithmic Aspects of Topology Control Problems for Ad Hoc Networks,” Proc. MobiHoc 2002 , June 2002, pp. 123–34. [10] V. Rodoplu and T. Meng, “Minimum Energy Mobile Wireless Networks,” IEEE JSAC , vol. 17, no. 8, Aug. 1999, pp. 1333–44.
