Subject: RE: [6lowpan] Re: 6lowpan devices constraints

From: "Kris Pister" <[email-masked]>
Date: Fri, 11 May 2007 08:23:56 -0700

Joe - sorry, I meant to be informative, not antagonistic.  I know that
some very nice work on time synchronized channel polling (SCP) has been
done by Ye et al. at USC/ISI.  It sounds like we are in agreement that
there are a number of MAC-layer "tools", including TSMP, SCP, and LPL.
Since these protocols have wildly different performance characteristics,
I think that it's important for RSN and 6lowPAN to have at least a high
level abstraction of how they work and what the performance tradeoffs
are.  I think that my numbers for TSMP and LPL are correct.  Maybe you
could give us some numbers and insight for synchronized LPL (either SCP
or something similar)?

ksjp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Joe Polastre
Sent: Thursday, May 10, 2007 11:49 PM
To: Kris Pister
Cc: Ian Chakeres; 6lowpan; [email-masked]; Charles E. Perkins (work)
Subject: Re: [6lowpan] Re: 6lowpan devices constraints

> * If you're time-synchronized, then the receiver can turn on for a
couple of milliseconds and cost you maybe 50 uC if there's no packet,
and 100uC if there is one.  If you do this once a second, that's 50uA to
get 1/2 second average latency when idle, or 100uA to receive one packet
per second.  That's TSMP (time synchronized mesh protocol).
> * If you don't want to time synchronize, you can do preamble sampling.
You still turn your receiver on regularly, and listen to hear if anyone
is transmitting a long preamble.  If they are, you stay awake until the
packet shows up.  This is LPL (low power listening) if you're a tinyOS
person.  You burn less charge on the listens - maybe only 20uC if
there's nothing to hear - but you probably want to do them more often.
If you sample once per second, then maybe you only burn 20uA to get the
same 1/2 second latency, but...now the transmitter of a packet has to
send a 1 second long preamble before each packet so that you stay awake,
meaning a TX now costs 20,000uC, not 100uC.  The receiver on average is
going to have to listen to half of the preamble, which is going to cost
10,000uC if you only sample once a second.  So you probably sample a lot
more often, and burn a lot more power on idle listening.  Not very
efficient, but hey, at least it's easy.

This is a very naive approach, and Kris, we've talked about this.
Many protocols can detect when others are sampling the channel (I
believe you call this "time synchronization", although really it can
be done with LPL) and detect when to receive a packet based will be
received on this information.  If you can setup a purely peer-to-peer
network (please take out that horrible server) and give us an ability
to interact with ANY sensor network at any point, a ton of our
customers would love to see that functionality.

Time synchronization is not the answer, NOR is low power listening.
Both are TOOLS, which is what many people forget.  We need these tools
to enable a networking system that CUSTOMERS (yes, I said it),
customers are looking to use.  Most of our customers couldn't care
less whether a TSMP (WTF is that?) or an LPL (WTF did you say?) is
used, they care about how to get alerts to their personnel (an
application).  This is what we should be focused on, not whose random
networking junk is better than the other random startup's networking
junk.

-Joe,

> * If you're lucky enough to have a powered infrastructure, then use
WiFi.  Hmm.  Try again: if you're lucky enough to have a powered
infrastructure, and for some reason are still interested in using
802.15.4, then transmit whenever you want, and listen immediately after
your transmitions to see if the local powered router has anything to say
to you in return.
>
> ksjp
> --
> Prof. EECS, UC Berkeley
> Founder & CTO, Dust Networks
>
> ________________________________
>
> From: Ian Chakeres [mailto:[email-masked]]
> Sent: Wed 5/9/2007 6:34 PM
> To: 6lowpan; [email-masked]
> Cc: Charles E. Perkins (work)
> Subject: [6lowpan] Re: 6lowpan devices constraints
>
>
>
> Also, I'm adding RSN.
>
> It appears that my question might have been misinterpreted or more
> likely I  presented the two choices inappropriately. Let me try pose
> the question in another way.
>
> How much short term memory can we expect these devices to have? And
> how much can we use for routing functions? Can a routing function make
> use of 100's or 1000's of bytes of short term memory?
>
> My understanding was that memory is scarce and very hard limited.
> Alternatively, energy though scarce does not have as hard a limit.
>
> Ian Chakeres
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan