[SensorNetArch] FPS and the SP interface

[Cheng Tien Ee]

Here's what I think FPS needs from the SP interface, let me know if I 
missed out something.

------------------------------------------------------------------------


Flexible Power Scheduling (FPS) is developed with the assumption that a 
CSMA MAC runs underneath. FPS does not provide any sort of latency 
guarantees to the application, it does its best to reserve a slot in its 
immediate parent before transmitting the packet itself in the next 
available reserved slot.

A major point is that a slot in FPS should be able to handle the 
transmission of at least two packets, for instance the request and 
confirmation of slot packets occur within 1 time slot. Thus the length 
of a slot should at least be as long as the effective time to send two 
packets at the MAC layer. For a TDMA scheme, the maximum time for a 
request and confirmation is the duration of an entire TDMA cycle, during 
which each mote in the one-hop neighborhood can transmit once. Thus, a 
reasonable common denominator would be the effective rate at which the 
MAC can send packets. The acquiring of this rate can also be obtained by 
the network component as well: it can time how long it takes to transmit 
and receive acknowledgement for a packet. It is probably the case that a 
good estimate of this rate is possible only after the network has warmed 
up, so the network protocol may want to take this into account.

The second major point is that FPS shuts down the radio during idle 
periods, which is not an issue in the case of a CSMA MAC, but is one 
with TDMA due to its periodic synchronization requirements. A solution 
would be to propagate beforehand the intention and when the shutdown 
will occur, as well as its duration. A CSMA MAC can ignore this, whilst 
a TDMA MAC may need to send the information to the neighborhood, so that 
neighbors do not assume that the mote has died when it has not been 
heard from for a while (or the MAC may think this is no big deal if it 
can handle churn well). This flow of information might also originate 
from above, when the application decides that the entire stack can be 
shut down for some time. Prolonged periods of shutdown may also affect 
the neighbor tables, which probably will be updated from time to time. 
It may be a good idea to have a central component interacting with the 
various levels communicate with the corresponding component in the 
neighboring motes, rather than having a separate logical communication + 
control channel for each different layer's power management component.

So, in summary:
1. SP -> network protocol: effective transmission rate, in packets per 
second
2. network protocol -> SP: when, and duration, of shutdown, if any