Subject: [RSN] 6lowpan devices constraints

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

adding RSN to the conversation

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

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

---

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: "dculler" <[email-masked]>
Date: Tue, 22 May 2007 15:24:03 -0700

For devices built upon microcontrollers, memory is quite limited.  You can
get a handy picture of this for one vendor from
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?familyId=911&secti
onId=95&tabId=1527&family=mcu.  These devices range from 128B to 10KB of RAM
and from 1 KB to 60 KB of flash.  Similar ranges are available for
microcontrollers from Atmel, Microchip, Freescale, and other vendors.  From
the table you can see that the marginal cost of additional storage ($/KB) is
surprisingly high. This is only part of the story.  When devices are
operating at low duty cycle the energy budget is dominated by the sleep
current.  And, the sleep current is in large part leakage from SRAM.  Thus,
the bigger the memory, the shorter the lifetime on a fixed amount of energy.
A number of microprocessors have down moved into the microcontroller market
with 32-bit processors and MBs of RAM.  Generally, what you see there is
that the sleep current is quite high, unless you discard the contents of
SRAM.  Unfortunately, if you do that, you pay a large energy cost when you
wake up again.

The memory constraint is important for routing because it implies that there
are limits on the size of the data structures, such as any neighbor tables,
route tables, route caches.  Take, for example, a simple problem like link
estimation.  A certain amount of storage is required per neighbor to record
any statistics on the link, such as error rate.  Let's say we have 1,000
nodes that can hear each other.  The vast majority may have weak links and
only hear each other's packets infrequently.  What fraction of the few KBs
of memory are we willing to devote to link estimation?  It is attractive to
only keep statistics on the good links.  However, when a packet arrives from
a node not in the table, how do we know if the link is good or bad?  We have
no stats, and we won't have any unless we invest an entry in the table.  

More generally, the storage limitations can impact the routing algorithm
itself.  Many algorithms start from a concept such as "all 1-hop neighbors"
or "all 2-hop neighbors" and then proceed to select a routing subgraph from
this distributed topology representation.  In general, it may not be
possible to record "all the neighbors" in the space available in a node.  

This is an issue that has been often overlooked in many of the mesh routing
proposals, but it is, of course, a basic scalability concept that goes back
to the earliest days of IP routing.  The routing information per node must
scale slowly with the number of nodes in the network.  Thus, we pay great
attention to route summarization and routing in the presence of partial
information.  In many cases, this is addressed by hierarchical techniques.
In the wireless case, there is the additional complication that the degree
of the connectivity graph is determined by the proximity of the nodes
(relative to the communication range of the radios) rather than the physical
connection of wired links.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: Saturday, May 12, 2007 8:33 PM
To: [email-masked]
Cc: 6lowpan
Subject: [RSN] 6lowpan devices constraints

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?

Ian Chakeres