[SensorNetArch] Two idea for today

Gilman Tolle gilman.tolle at gmail.com
Mon Mar 7 16:17:04 PST 2005


Because this is such a popular idea (I've worked on it also), the
question then becomes "why aren't we using it?".

Establishing the names is easy -- just build a tree and set up the
numbering. Adaptation is hard. Responding to the fact that changing a
parent requires renaming all descendants, and changing the number of
bits used to represent children requires renaming all children's
descendents.

Also, using this sort of naming to define a set of nodes becomes very
similar to building a binary decision diagram, which can potentially
take space equal to the size of the network times the size of the
name.

Gil

On Mon, 07 Mar 2005 12:43:50 -0800, Cheng Tien Ee
<ct-ee at eecs.berkeley.edu> wrote:
> 
> > (2) Non-formatted tree naming
> >
> > Given a tree rooted anywhere in the network, I can assign a routable
> > name from the root.  Each node numbers its immediate children and
> > determines the field size for its immediate children
> > ceiling(log(number of children).  The name for node i is [parent_name
> > | child#].  The assignment scheme is much more general than the ZIGBEE
> > scheme, which requires determine max number of hops and max children
> > at each hop.  It allows a single tree formation to number the network
> > in parallel.  A node can tell if a packet is for itself, its children
> > or its parent. However, given a string of bits, it is not possible to
> > determin how to parse them.
> 
> I worked on this about 2 years ago, it was the main part of my CS268
> project (http://www.eecs.berkeley.edu/~ct-ee/cs268/). I called it prefix
> routing at that time.
> 
> Ee
> _______________________________________________
> SensorNetArch mailing list
> SensorNetArch at Millennium.Berkeley.EDU
> http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/sensornetarch
>


More information about the SensorNetArch mailing list