[SensorNetArch] packet scheduling, receiption and timestamping

[Jerry Zhao]

I was not able to attend the meeting two weeks ago but was in the
meeting before that when we talked about interlacing both periodic
traffic and "random" traffic. Here is some comments , as my late
homework submission, after reading so many great write-ups and enjoying
today's discussion.

1. I feel that scheduling (particular for periodic messaging) is very
important but should not be placed inside SP nor requires explicit
interface.  SP still tries its best to aggregate traffic to minimize
energy expenditure. IMO, bottom up in the network stack in one single
node, the functionality decomposition to support  transmission (periodic
or burst) can be

	*MAC Layer: arbitrate media access with peer nodes, lower power
listening, TX/RX, TDMA sync/scheduling, CSMA/CA etc. i.e. It supports
inter-node coordination on medium access
	*SP: best-effort aggregate local TXs to minimize energy cost. i.e it
opportunistically aggregates local outgoing traffic.	
	*Network layer and up: do its own scheduling by tweaking its timer
(including phase/lead/jitter/period, or even fancier parameters) with
the information from SP or the schedule/msg meta data "pool" proposed by
Joe.  i.e. They _optionally_ coordinate local TXs (using cross-layer
service) and/or cross node traffics(from the semantics defined in those
upper layer protocols).  

More specifically, SendSP interface is some simplified version to Phil
and Rodrigo's proposal but with a cancel command. 

	interface SendSP{
		command error_t send(addr, msg, max_delay); 
		command error_t cancel(msg); 
		event void sendDone(msg, delay, status);
	}

send(addr, msg, max_delay): I want to send msg to addr "now", as Scott
suggested. "Now" is quantified as a hint of max_delay that the caller
_wish_ tx happen within max_delay. Note that max_delay is only provided
to SP as a "hint" but not a deadline: If there are enough number pkt TX
requests within max_delay to aggregate, it is great. If max_delay has
elapsed, SP will send it out even with higher cost.  If max_delay is far
expired e.g. due to busy channel or long queue, SP will still continue
to send it out asap (until it is sent or canceled). Default max_delay is
0, which is back compatible to most LinkLayer/MACLayer semantics. 

Cancel(msg): With SP doing its best effort to deliver the message, the
caller can optionally have finer control over TX. The caller can cancel
the message anytime (before or after max_delay), when the content of pkt
is out of date. For example, to support periodic messages at rate of
1/T, the caller calls SP with send(addr, msg, jitter). After jitter
sconds, if the pkt is not sent and the caller can decide whether to
cancel it or reschedule a new one according to how time-sensitive the
payload is etc.

sendDone(msg, delay, status). After the msg is cleared from SP's buffer,
sendone returns if msg is sent or not (status). If it is sent, what is
the actual delay from calling of send() till it is sent out...  delay
can provide fairly rich information for the caller to adapt to new
schedules or assess channel condition etc. 

Congratulations! This email is more than two pages, glad you are here.
To attract more readers, I will start another email to continue. 

Many thanks,
Jerry