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

From: "Ian Chakeres" <[email-masked]>
Date: Thu, 10 May 2007 07:04:14 +0530

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

---

From: "Kris Pister" <[email-masked]>
Date: Thu, 10 May 2007 17:30:29 -0700

Ian - motes today have between 2kB and 10kB of RAM typically, and 50kB to 128kB of flash.  Many have a separate flash with many hundreds of kB (slower, more energy intensive to access).  Cheap processors have come a long way since the first motes in 2000/2001 where we had 8kB of flash and 512B of RAM (but still did some pretty neat things, e.g. http://robotics.eecs.berkeley.edu/~pister/29Palms0103).
People are spoiled now, and it's only going to get worse.  I mean better.
Several companies have demonstrateded and/or announced motes with 32 bit processors and ten times more RAM and flash.  These 32 bit cores often burn less power per MHz than the cheesy 8 bit processors with which they compete.  You can assume that others will follow suit.  In 0.18um CMOS, you get about 10kB of SRAM per square millimeter, and 100kB of flash per square millimeter.  32 bit cores are around a half a square millimeter.  8 bit cores are only about half that size.  Radios and all of the analog peripherals are very very roughly 5mm2.  In volume, tested functional chips cost very very roughly $0.10/mm2 .  So today a 32bit core and 100kB of flash and 10kB of RAM is comparable in size to the radio+peripherals.  Radios and most of the peripherals don't scale much as you go to 0.13um or 90nm, but the digital does, so in a few years the cost of the core(s) and memory will have shrunk by 2..,4..,8..X, or more likely the relative die area will be about the same, but you'll just have a lot more memory.
 
Transmitted packets cost you a few milliseconds at roughly 20mA today, or roughly 100uC (microCoulombs).  The trick is receiving the packet - how do you know when it's coming?  There are several approaches:
* 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.
* 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.

Ian Chakeres

---

From: "Joe Polastre" <[email-masked]>
Date: Thu, 10 May 2007 23:48:50 -0700

> * 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 st…

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,

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 13 May 2007 09:03:26 +0530

adding RSN to the conversation

Ian Chakeres

---

From: "Timothy J. Salo" <[email-masked]>
Date: Sat, 12 May 2007 23:31:46 -0500

> use of 100's or 1000's of bytes of short term memory?

I believe that in some markets (e.g., home automation) vendors will
try to include the absolute minimum amount of memory in large-volume,
cost-sensitive (consumer-grade) products.  A few cents-per-device cost
reduction times a few tens-of-millions of units starts to add up to
(sort of) real money.

On the other hand, I suspect that there will also be classes of devices
sold into these very cost-competitive markets that are slightly less
cost sensitive.  For example, vendors might be convinced to put a bit
more memory in the wired/wireless gateways (are we allowed to say
that word?) if we can give them a good reason to.

Another strategy is to assume that the lowest-end devices
will have enough memory to support the ZigBee protocol stack, and
so we should ensure that we work with these devices.  After
we achieve that objective, we can use any leftover (RAM) memory
for buffers.

> Alternatively, energy though scarce does not have as hard a limit.

I think that there will be two classes of devices in most of these
networks: battery-powered and mains-powered.  For a battery-powered
device, energy consumption translates directly into product lifetime
(for some devices) or at least into mean-time-to-battery-replacement.
For mains-powered devices (e.g., wired/wireless gateways or home
automation controllers) energy will be essentially unlimited.

I believe that routing protocols that can more effectively accommodate
both energy-constrained devices and and energy-rich devices will better
meet the needs of these markets than will routing protocols that don't
differentiate between these classes of devices.

If nobody else beats me to it, I will go look up the characteristics of
some of the current 802.14.4/ZigBee SOC products.

-tjs

---

From: Anthony Schoofs <[email-masked]>
Date: Wed, 23 May 2007 16:31:02 +0200

Dear all,

In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet 
Draft, section Dispatch type and Header page 7, is mentionned that  ".. 
other non-LowPAN protocols that wish to coexist with LowPAN nodes should 
include a byte matching this pattern (00 xxxxxx) ..".

I had a look at the ZigBee network header and especially at the Frame Type 
sub-field (the 3 first bits after the 802.15.4 MAC header).
For acknowledgement and command frames, the Frame Type value is either 010 
or 011 (data frames start with 00).

Consequently, it might happen that you get a match with a LoWPAN pattern, 
and then a problem of coexistence between LowPAN nodes and ZigBee nodes.

I would like to know if this coexistence issue was raised before and if it 
is a matter for the 6LoWPAN WG.

Best regards,
Anthony

--
Anthony Schoofs
Philips Research
High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands
Email: [email-masked]

---

From: "Kris Pister" <[email-masked]>
Date: Sat, 26 May 2007 16:34:44 -0700

I don't understand why we care.  There are hundreds if not thousands of companies developing proprietary solutions with 15.4 radios that will not conform with 6lowpan, zigbee, HART, or any other 15.4-based wireless standard.  Perhaps more importantly, the crc16 fcs is not sufficient to guarantee the integrity of received frames - roughly one out of a million will be corrupted in major ways but still bear a valid fcs.
 
So what are we hoping that these bits in the dispatch will do for us?  No matter how well we coordinate between standards, I guarantee that our radios will receive the occasional bogus packet with a "correct" dispatch byte and length.  You can try to type-check the fields all you want, but occasionally you will execute on a payload that is at least partly pure noise.  One alternative is to build extra redundancy into the headers, but header compression moves us in the other direction: if we do our job right we squeeze all of that redundancy out by design.
 
The simplest way to deal with this problem is to use a MAC layer MIC-32 in conjunction with the fcs.  If we build secure networks, we need that anyway. If we want an "open" network with no security, then we can define a default (semi-random) MAC-MIC key that all 6lowpan devices will use.  For most applications this reduces the probability of undetected errors to an acceptably low level.
The alternative is to have our motes periodically do unpredictable things.  This is fine in a one hour demo or a one month pilot, but is generally frowned on in production.
 
ksjp

From: Anthony Schoofs [mailto:[email-masked]]
Sent: Wed 5/23/2007 7:31 AM
To: 6lowpan
Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN

Dear all, 

In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that  ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..". 

I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header). 
For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00). 

Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes. 

I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG. 

Best regards, 
Anthony