[SensorNetArch] Meeting notes

Rodrigo Fonseca rfonseca at cs.berkeley.edu
Tue Feb 15 13:58:56 PST 2005


Notes from the Feb. 7th meeting
Please complete these if you were there and find that I missed something.
---

In the previous meeting, we tried to define what cross-layer services 
are, and we looked at the example of scheduling.

SP should not depend on a specific mac protocol, such that what it 
exposes should work on top of CSMA, TDMA, ....
It this possible?

So, instead of setting B-MAC's switches, it should expose classes of 
traffic:
    App: I need to send this packet [now| in at most 5 minutes | today]
    SP: Ok, this will cost you X, or 'Sorry, can't do it.'

SP could also expose 'energy counters' of what it had spent. Joe thought 
of mAh, Phil thought of a bit of information.
In any case, this interface should be in terms of requirements of
    - fairness
    - latency
    - energy
    - reliability
    ...

There are cross-layer issues, and also cross-node issues: for example, 
if you want to be unfair, and use no CSMA, SP should send a packet 
informing other nodes.

In terms of scheduling and energy, we discussed regular(periodic) and 
irregular traffic. Irregular traffic is always expensive, but regular 
can be made less expensive.
If the routing layer needs a packet with period 5s, and the sensing 
application needs to send a packet with T=20s, SP can accomodate both, 
making the application packets be sent clustered with the routing 
protocol packets.

This brings us to the discussion below.


Rodrigo

> Phil
>
> -----
>
> Review of ideas on what "cross layer services" mean wrt SNA. How much
> should SP provide? Grad students talked about SP giving feedback on when
> it could send packets at what cost.
>
> Scott: Give 'em little: people whined, but it works in the Internet!
> Scott: Perhaps measures should be rough: orders of magnitude
>   David C: Yeah, I agree, Low, Medium, High
> Ion: What about TDMA? Having TDMA means having to allocate
>      Something like RSVP, but uses TDMA... tries to resolve natural
>      Are these guarantees? Can I build something at l3?
> Phil: SP's interface should be MAC independent: CSMA or TDMA need to 
> be able to express SP things
>
>
> David: Let's start with a simple app:
>   1) Low rate convergecast.
>   2) What's consumed?
>   3) What's delay?
>   4) Can we do this without hosing it?
>
>   Convergecast, data generation of period P
>    - E2E delay of P or aP
>   What would a network protocol need from SP?
>
>
> Ion: What will SP provide that will help this?
>      How much better can we do if we provide more information to SP?
>
> 4 algorithms, what would then mean to the interface?
> 1) Emulated TDMA (e.g., FPS)  Ee
> 2) Random (MintRoute) pal, Rodrigo
> 3) TinyDB (Epoch/bulk synch) Joe and Jonathan
> 4) ReliableRoute + TimeSynch Scott
>   - Network level scheduling
>   - Data-link level scheduling
> 5) Completely scheduled network (global) Prabal`
>
> SP controls when radio is on/off for transmit, receive
> Network guides SP
>
> Homework for 2/21: Send email describing what your protocol needs from SP
> Homework for 2/28: Have a proposal for SP's interface, based on all 
> protocols




More information about the SensorNetArch mailing list