Ian Chakeres wrote:
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?
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.
My understanding was that memory is scarce and very hard limited. 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 _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
