Contents Dear readers, welcome to the July 2008 issue of IEEE Network Maybe it's just nostalgia, but I will admit to finding programming sensor nodes (those with a few dozen kilobytes worth of memory) an interesting form of intellectual challenge, even “fun” at times. Nostalgia, because it brings back memories of programming a Commodore 64. Or maybe it is just the sense of detoxification from today's bloated “mainstream” platforms. While I was warned sensor network software development is subject to all the complications of embedded systems development, it includes some unique problems as well. Precisely because they are supposed to fulfill the criteria of being cheap to build, cheap to develop, and cheap to deploy, one cannot call them a success unless all three criteria are satisfied. I think most of us are convinced that building them (i.e., their hardware) is not as much an issue, except maybe as related to their power source. Also, being cheap to deploy is determined by numerous factors, but we can take solace that at least wireless sensor networks appear to be cheaper to deploy than wired ones. Think of it this way: even when the possibility for wired deployment exists (say at the top of a light pole), one still has to account for the labor involved in retrofitting or extending a wired infrastructure. It simply does not fulfill the cost considerations if a$20 sensor gets wired up using labor and equipment worth$300. Deployment for cheap sensors should be cheap and casual to make economic sense.
This brings us to the third, and rather underestimated, facet: cheap (which invariably means quick) development. I think many will agree that, outside sensor networks, good examples of cheap development are simple IP-based client-server applications. The sockets interface has survived and flourished, and allows one to develop applications even with a sketchy understanding of the concepts that make it work. Simply put, we lack the luxuries of a good conceptual framework and corresponding application programming interface (API) when we are dealing with very simple and cheap devices. In fact, even a printf() is often absent or trimmed down. More to the point, the “feeding and care” of such devices (e.g., at the level of what amounts to a “device driver”) is usually directly handled by user code. Certainly one could argue that all we have to do is wait, and with Moore's law working on our side, soon enough those cheap platforms will be quite capable; and, why not, maybe we will have a sockets interface or any other worthy API. This may very well be true, but the observation fails to acknowledge that, at the same time the capabilities for constant cost improve, it is also the case that for constant capabilities, the cost decreases. The lowering of cost for “reasonable” capabilities enhances the ability of a technology to become ubiquitous. Ever decreasing cost devices become an important component of the cyber infrastructure just because of their ubiquity. Of course, applications can be conceived around even the smallest capabilities. I, for one, would like to own shirts where the buttons check on the rest, and alert me if one of them is absent! It shouldn't be hard to program my buttons to behave in this simplistic manner, right? (Of course, I would also be concerned about a malicious zipper hijacking my shirt buttons.)
Overall, while it is nice to read the literature on sensor networks, hands-on experience is an eye opener. Cheap development is a concern when one wishes to try out a variety of schemes found in the literature. Getting even one scheme, be it routing, scheduling, or something else, to work on a sensor network testbed is a demanding labor-intensive task. For literature that is becoming congested with ideas and proposals, an apparent bottleneck is evaluating them in practice. Trying out concepts on real platforms has long been recognized as a challenge; it is a significantly bigger challenge for wireless sensors when the average student or developer may be quite capable of using high-level APIs and concepts, but inadequately prepared for the vagaries of sensors. In other words, sensor networks are forcing embedded programming to become more “mainstream”, and now that many eyeballs are concentrated on it, maybe it is a good idea to consider more suitable programming methodologies and abstractions. To suggest that the problem is the collapse of the layers misses the point. It is not a binary issue: layering vs. chaos. Layering is one elegant way to (de)com-pose systems, but by no means the only one. Consider, for example, alternatives to describ-
ing systems (e.g., using communicating finite state machines). One can still describe complicated systems this way, and truth be told, many protocols are already described in some state machine form (and if they are not, they should be). The intent would be to make programming sensor networks accessible to more developers. The realization that a change in methodology is warranted when the nature of what is being programmed changes can also be witnessed in more exotic designs such as cellular automata in the “programmable matter” of Toffoli and Margolus [1].
Making platform(s) accessible to “program” by a large constituency of engineers, scientists, and anyone interested for that matter, is an accelerating force of the kind that con-tribu tes to exponential growth, like the one that brings us closer to Kurzweil's “singularity” [2]. Another facet of ubiquity, this time related to the end-user experience, is that in order to benefit from the heterogeneity of sensors and mobile devices that inhabit the same space (in all its transience), we have to somehow be able to compose useful (from the user perspective) services “on the fly.” Clearly, the more automated the service composition and delivery, the easier the life of the user. More over, the integration of rich sensor information enable: the composition of services to occur in a context-depen dent fashion, which therefore matches the available resources and expectations as provided by the space inhabited by the user. The current special issue of IEEE Network on Composable Context-Aware Services, editee by Raj Yavatkar, Andrew Campbell, Lakshman Krishna murthy, and Tarek Abdelzaher, is a review of the state O: the art and innovations in dealing precisely with the problem of context-based service composition, and alse reveals its multifaceted nature, ranging from network and protocol architecture considerations to social net working applications.
As always, your feedback regarding the direction ane substance of the magazine is invaluable and always appre ciated. Please contact me, by email, at yannis@cs.ualber· ta.ca, to let me know what you think about the editoria comments, what type of content might be more interesting to you, and in what ways the magazine'S distinct charactei could be improved or further publicized.