[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