[SensorNetArch] Meeting Minutes: 9/27

[Cheng Tien Ee]

Hi,

The minutes for today's meeting is attached below. Is there a website 
where we can put slides (like Joe's) and/or minutes up?

I think that using FEC may be good for certain situations and not for 
others. The problem with FEC is that it expands the payload thus 
increasing power consumption, and may not be necessary if the links are 
of high quality. On the other hand if the links are really lossy then 
FEC may not be sufficient to recover the long packet. I'm not sure if 
anyone's done something like Reed-Solomon, but the computation costs may 
also be significant.

Does anyone know if there's a summary of all (or most) applications 
implemented, with details like project goals, infrastructure, type of 
data gathered etc. I know there's a project page in TinyOS but am 
wondering if there's more sites elsewhere. I'm also wondering if there 
are people who had interesting applications but who, upon finding that 
the technology doesn't quite support what they want to do, gave up on 
implementing them.

The minutes are below, do let me know if there're any mistakes, thanks.


Sensor Architecture Meeting 9/27
--------------------------------

Joe gave a presentation on the current microcontroller trends
and lead the discussion on packet sizes. It was agreed that
packets are considered small when they have sizes on the order
of 128bytes.

Important points raised during slide presentation
(for detailed information, refer to slides)
-------------------------------------------------
1. The refreshing of RAM imply that power consumption will
increase with RAM size even when the mote is put to sleep
flash increases at higher rate than RAM. That is part of the
reason why manufacturers are adding more ADCs rather than
RAM.

2. Having small amounts of RAM also imply that packet sizes
have to be small, since storage is required just before the
packets are sent and when they are received.

3. The sensor motes' radio quality is unlike that of 802.11,
in that it has transitional regions where the link quality
is poor and fluctuates over time.

4. It was also agreed that losses are in general bursty,
and is prone to environmental changes. For instance, link
quality is generally observed to be lower when people
are around.

5. Jason Hill experimented and found that (re)transmissions
can be done across time and space (i.e. to different neighbors).
Retransmitting to different neighbors increase the chances that
the packet ultimately gets to the destination. Rodrigo noted that
backtracking and trying another path when a packet can no longer
make progress on the current one can increase the chances of
successful routing. In response Ion mentioned
that in such a situation the nodes along the path will need to
have a buffer window to store packets that were sent.

Discussion after slide presentation
-----------------------------------
1. There was some discussion on how to go about determining
optimal packet sizes. Factors considered include packet
header length, transmission rate etc. It was agreed that the
packet size would be dependent on the underlying radio
technology.

2. Scott brought up the question of whether the architecture
should handle long packets. Phil mentioned that fragmentation
and reassembly of long application packets should not be
transparent to the application itself. While it is possible
to force all fragments to traverse the same path, it may
not be the case in general (e.g. BVR has packets traversing
different paths). It would be interesting to note the
impact of multiple-path routing on system performance.
Finally, Ion noted that occasional fragment drops may be
tolerable if redundancy (e.g. erasure codes can be used).

3. Next, Joe said that having smaller packets translates
into having more memory for the application to use. Also,
the overhead of transmitting a packet includes not only
the packet header but also the cost of and time to turn
on the radio. Phil added that having smaller packets would
also mean that buffer management becomes more flexible.