Lecture Notes in Computer Science 4837
Lecture Notes in Computer Science 4837
Lecture Notes in Computer Science 4837
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
4 M. Kuty̷lowski<br />
receiver should not be switched on all the time, so <strong>in</strong>evitably some messages<br />
broadcasted could be unnoticed by the sensor, despite that the sensor was <strong>in</strong> the<br />
proper range.<br />
This problem is particularly visible when we concern warn<strong>in</strong>g function of sensors.<br />
Detect<strong>in</strong>g anomalies (which are the most crucial ways of detect<strong>in</strong>g critical<br />
situations) is not always equivalent with detect<strong>in</strong>g certa<strong>in</strong> numeric values, sometimes<br />
it is their gradient or an abnormal pattern of values <strong>in</strong> some area. How to<br />
detect abnormal patterns by a set of sensors without large communication is an<br />
<strong>in</strong>terest<strong>in</strong>g question that <strong>in</strong>volves issues of game theory, distributed algorithms<br />
and communication complexity.<br />
Heterogeneous Networks. In many practical applications we could share<br />
the basic <strong>in</strong>frastructure composed by sensors. This helps to reduce deployment<br />
costs and compose many virtual sensor networks out of the same set of devices.<br />
Inevitably, we may come to a situation when a virtual sensor network consists<br />
of devices that are deployed by more than one provider. Consequently, sensor<br />
type and their configuration may differ, sometimes quite significantly.<br />
S<strong>in</strong>ce sensors are weak devices, it might be an uneasy for them to emulate<br />
different configurations <strong>in</strong> order to serve the needs of diverse virtual networks.<br />
Therefore, algorithms and protocols designed for sensor networks should to certa<strong>in</strong><br />
degree disregard particular features of the sensors - a good algorithm should<br />
be as <strong>in</strong>dependent of the features of the sensors as possible. At the same time,<br />
it should make use of any additional features available at certa<strong>in</strong> nodes of the<br />
network.<br />
Standard algorithm design is not focused on such a situation: usually it is assumed<br />
that <strong>in</strong> a distributed system all network units have comparable properties.<br />
Therefore most of the algorithms for distributed systems have to be redesigned<br />
or at least reconsidered before be<strong>in</strong>g deployed for sensor networks.<br />
Network Evolution. Heterogenuity may arise for yet another important reason:<br />
after some time new sensors become deployed <strong>in</strong> order to upgrade its functionality<br />
or to replace malfunction<strong>in</strong>g or dead units. Location, functionality and<br />
purpose of strong units may change as well. So f<strong>in</strong>ally we are faced with many<br />
compatibility problems: new devices should work well with<strong>in</strong> an old network,<br />
however, they have to take adventage of newer technology <strong>in</strong> order to improve<br />
the network performance.<br />
The problem is a more difficult than <strong>in</strong> the classical networks. Sometimes it<br />
is impossible to exchange fully the old units. Sometimes we share sensors with<br />
another provider who can decide to make a replacement without our accord. The<br />
problem is that communication protocols for sensor networks are not that stable<br />
as for the classical networks, so a replacement may have profound consequences.<br />
S<strong>in</strong>ce we have to assume that changes with<strong>in</strong> the network may be frequent<br />
and quite significant, and <strong>in</strong>volve dramatically different hardware, we have to<br />
design self-organization paradigms yield<strong>in</strong>g algorithms that are robust to these<br />
changes. We have to design algorithmic schemes (and not only data framework!)<br />
that support upwards and downwards compatibility.