[SensorNetArch] Notes on the first meeting

[Rodrigo Fonseca]

Notes on the first SNA meeting
09-20-2004
Rodrigo Fonseca

It was a good start in getting to a common ground on the issues
and assumptions underlying the Sensornet Architecture (SNA). Since
many different issues were briefly discussed, I will try to
itemize this minute with the different questions raised at each
one.

What would go into a Case For SNA paper... Our assumptions should
be stated, what we hope to get out of it, and why we believe there
is the need for this new architecture.

Data Collection/Control
=======================

The first point raised was the main use of a sensor network
deployment. The main use so far is unquestionably data collection,
and that tends to shape much of the design decisions and
assumptions about, for example, traffic. Control has been proposed
also, but not much or nothing has been really done, even
throughout the entire NEST program.

The usual life cycle of an application/deployment is a first phase
in which there is collection of data no one knows the
characteristics of, then a second phase in which the data is
processed offline and understood, and then possibly a later phase
in which some control is injected back into the system. (please
let me know if this is not what was meant)

In any case, there is fabulous work to be done, according to
David, and there are some difficulties that control theoretic
people are not used to, such as loss, jitter, and latency bounds
that have to be imposed.

 >>> If control is to be a first class concept in the architecture,
we should establish ways to deal with (requirements, guarantees,
levels) of loss, jitter, latency, noise, reliability, etc.

Also, an important aspect is the asymmetry of the scenarios: if
you have a really complex (be it expensive, energy or computation
demanding) actuator/control mechanism, what are really the
constrains, if any, needed on the sensing components?

Examples of these are the door opening on a sound, shades on a
building, HVAC systems, morphing orbital telescopes, etc.

Mobility
========

Stationary data collection was the first big focus of Sensor
Networks research, as it was clear that a lot could be learned and
also, if it failed there, it would hardly do anything else on the
more complicated ubi-comp type of applications.

Some of these more complicated applications require in-network
processing and involve mobility.

It seems to be the case that we want to tackle problems here in
which the mobility of the sensors (at least in relation to each
other) is not the dominant one. As Scott pointed out, there is the
movement of the sensors, and of the sensed objects.

 >>> The answer to the question of whether we want to support
substantial sensor movement was  a categorical no. There is an
assumption on a minimum density at which the networks should
operate, and it was pointed out that there should be some
assumption that a node should at least always have a neighbor.

We may have cases of mobile networks over static objects, mobile
objects on static networks, and cases with some mobile nodes among
a majority of more stationary nodes. In this latter case, there
may be a distinction between mobile and stationary nodes in their
role in the various protocols: the latter would be part of a
backbone, and the former would attach to this backbone to
communicate, without being part of it.

I don't see the strict need for an assumption that the network
should always be connected, and for me the distinction of sensor
networks and delay tolerant networking is not entirely clear to
the point of ignoring temporary disconnection of even patches of
the network. I think the network should accommodate some form of
delay tolerant / custody transfer semantics as well. Temporary
connectivity may be scheduled by base stations coming into range,
or as part of larger scale time division transmission protocols
that optimize energy consumption.

 >>> Interference should be a first class network concept as well,
according to Scott.

Fundamental Constraints and the case of the size of packets
============================================================

The case for small packets: are small packets a fundamental
characteristic of the sensor networks environment, or an artifact
of technology constraints?

This has a lot to do with the argument of Moore's law going in the
reverse direction in sensor networks. Instead of its usual sense
of increasing speed and number of transistors, sensor networks use
the fact that the same computational power can be made smaller,
cheaper, and to consume less energy. What is the right point in
the architectural trade offs between processor speed, bus width,
memory, radio power and bandwidth. Are the embedded processors
manufacturers concerned with the cost, the power consumption, the
yield? Are these valid/desirable for the SNA applications?

It is important to lay down what constraints we are working on,
and if they always apply: for example, what energy consumption
would be considered good or acceptable? The answer may very well
be bimodal: there are applications in which indoor nodes can
function with unlimited power, for example, while some other
deployments may only work with energy harvested from the
environment or with a limited life-span battery.

Culler's position on this is that the architecture should not be
restricted to working with the unconstrained situations (such as
the unlimited power nodes), but the relaxation of such constraints
ought to simplify the solutions.

Back to the size of the packets: the size of the packets today,
O(100b), is much smaller than the size of packets in the Internet,
O(Kb's). Why?

Reasons for small packets: devices have small memory footprints
(buffers), bandwidths are low, the radio is simple (cheap, low
energy, not a whole lot of sophisticated error correction), which
also implies that the bit error rate may be large. Another
argument is that the radio wastes energy, and you want to have it
on for as short a period of time as possible.

The fact is, if you want to transmit X amount of bytes, the radio
will have to be on for that period. Ion was arguing that the
header overhead in the small packets would mean more bytes and
more energy, while Joe was with the position that you can always
emulate the large packets with the small ones, by even sending
packets with no header subsequent to ones with enough information.
 
There is also the contention issue, of the granularity with which
you want to divide up the channel, etc. More on this is to be
discussed in the next meeting. Reliability, fragmentation, etc,
should be discussed.

Heterogeneity
=============

Ee raised the question of how heterogeneity should shape the
design of the SP? Nodes with the same link technology, how should
bridges between different radio technologies fit in the overall
architecture? SP should sit above some abstraction than is an
umbrella over different radios/MACs, and in this case, how would
these talk to each other.

There was some discussion of nodes with two types of radios, and
also how this could be done with one radio at different frequency
and time slots.

Also, should there be a separation of control plane and data
plane, as is common in the mesh networking community? David seems
to think that this is an artificial separation in the case of the
sensor networks.


Robustness
==========

 >>> Assumption: nodes fail frequently, and the "gray zone" of
connectivity is apparently inherent

Should SP be responsible for handling that? As originally
proposed, a "best-effort one hop broadcast primitive", it probably
shouldn't. But still, applications should make use of very simple
algorithms with little state.

Another point is that the more parameters there are in SP, and in
the architecture in general, the more there is opportunity for
misconfigurations. We should tune the number of knobs in the
systems.

System Size
============

This is an important one: how large systems should the SNA
accommodate? Will there be systems of more than 100 nodes? This has
enormous impact on the types of protocols that may be designed.

 >>> Should the architecture assume that the systems will never get
larger than X, without a hierarchical structuring? In other words,
should that hierarchical structure be part of the architecture
itself?

This brings another question: that of addressing. There seems to
be great value in the use of variable size addresses: addresses
should be small when they are used globally, and large when global
uniqueness is needed. 802.15.4 addresses are variable. There are
interesting questions on how to manage address assignment,
uniqueness, etc, in small namespaces.

David raised the question that even if there is a set of more
powerful nodes in a higher tier, these may face some of the same
problems of connectivity, for example. If there is such a
hierarchical organization, should we assume that the higher tiers
are well connected?

Next meeting
============

We should continue with the discussion on some of the issues.
Joe is going to make the case for small packets.