[SensorNetArch] Global Congestion Definition

[Cheng Tien Ee]

>I'm not sure that S-MAC or TRAMA are applicable for what we want to do.  The
>idea is if you have some configurable set of parameters in SP
>
I guess I should have said: B-MAC configured to behave like S-MAC or TRAMA.

>, in other
>words B-MAC plus some of the S-MAC primitives but in a configurable manner,
>then FPS could use SP
>
So whatever's running above SP should be the guy configuring it? Then 
again, there could be multiple applications running above SP, and each 
of them have different requirements of the MAC. How would we decide 
which application controls B-MAC's configuration? Should applications be 
written to work regardless of the underlying interface, or should they 
tune the interface as much as they can (I guess the answer's both, but 
see previous question)? Also, I would think that in general what the MAC 
protocol is like has some amount of dependency on the physical layer: 
for 802.11 the packet sizes are larger and it makes more sense to have 
RTS/CTS (less relative overhead).

I also feel that there is a need to be able to handle network-wide 
traffic flows across a heterogenous network. FPS seems somewhat tied to 
the characteristics of the radio, in terms of slot length, cycle time 
and packet size. If there is a need to accomodate various types of 
technologies, then I think there should be a layer somewhere that is 
independent (to some extent) of the going-ons in the MAC.


>, perhaps transparently, to achieve efficient
>end-to-end transfer.  S-MAC and TRAMA, as published, are (IMHO)
>inappropriate for sensor nets due to their lack of control.
>
Agreed.

>  The B-MAC paper
>pointed out that S-MAC could do significantly better by allowing a little
>bit of control from higher layer protocols.  In turn, S-MAC and TRAMA as is
>are not appropriate, but a version of them that interacts well with the
>control and configuration ideas of B-MAC and SP may be appropriate.
>
>Does that make sense?
>  
>
Totally...

Ee