ZigBee vs. 6LoWPAN

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

for an inhouse sensor network I'm looking for the right point to start. There are several free solutions around (Contiki, TinyOS, BitCloud,...). I know that these three are OS but they all provide communication methods. They all share more or less the same hardware (M128*, RF230) but when to use what?

The demands for my project are:
I would like to transfer mesaured values every 10 second from 5 motes for a small network to 50 / 100 motes for a big network. The motes might communicate directly with the data sink, but do not have to - routing / caching is necessary. To correlate the measured values a real-time timestamp is necessary. Update over the air is currently not planned.
Any idea?

Cheers,
Knut

Last Edited: Fri. Oct 16, 2015 - 02:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your requirements didn't say if you must have a mesh network (relays) or not. Zigbee is the mesh network routing protocol layers, and application profiles, that are atop of IEEE 802.15.4. The IEEE stack are the MAC and PHY layers. Many / most applications don't need meshing and use an applicatiom messaging that employs 802.15.4 for sending and receiving 100 byte (or so) data frames, with error detection and correction attempts.

6LoWPAN is an attempt to move IP packets which are 10-fold larger than 802.15.4 frames. IMO, 6LoWPAN hasn't gone beyond academic curiosity.

There's also ISA 100.11a, another meshing standard, but focused on industrial controls with latency management.

And there are any number of proprietary meshing protocols.

So perhaps you need to decide on the network topology, then choose the network layer or DIY as most do, using basic 802.15.4. You can even do your own packet forwarding to neighbor nodes if they are immobile and you can have design-time routing choices. This is infinitely easier than the struggles with real self-forming/self-healing meshes like ZigBee.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One approach to bring 6LowPan from the higher academic level down to ground level is RUM (route under mac, Atmel Appnote AVR2070, ... not the bottled liquid)

Its a fairly simple networking approach to start with. IMHO good for upto 32 nodes, maybe more (this number is just my guess, not a measurment result), later on there is always a way to switch to BitCloud, in case if the network reaches a size that overburdens RUM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Your requirements didn't say if you must have a mesh network (relays) or not.

Two things I did not mention: My motes are powered by mains. There is no need to watch the power consumtion.
Second: Using 2.5GHz might raise problems in RF connections if there serveral floors between mote and data-destination. A routing must be possible. For the data the logical structure is a star network, but physically the motes must be able to handle dynamic routing.

Maybe I mix up things, but for me routing sounds to be a meshed net or is a meshed net only when the motes have to exchange data locally without a central data sink?

stevech wrote:
6LoWPAN is an attempt to move IP packets which are 10-fold larger than 802.15.4 frames. IMO, 6LoWPAN hasn't gone beyond academic curiosity.
:shock:
There was a project by BSD collecting power consumption data via motes, TinyOS, 6LoWPAN and transfering them to a Google data-collection service. Googles service retired mid Sep. 11.

Thanks,
Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems that you're describing a tree topology network so RUM may be an option indeed, especially if your nodes do not require sleeping capabilities.

Quote:

IMO, 6LoWPAN hasn't gone beyond academic curiosity.

It may be heavily driven by academia, but companies like Archrock (which was acquired by Cisco) and Sensinode seem to believe otherwise.

So, now I know how ICs work:
they work with smoke.
Cause every time you let the smoke come out of an IC, it stops working.
I can prove it, too...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kschwiRG wrote:
Using 2.5GHz might raise problems in RF connections if there serveral floors between mote and data-destination. A routing must be possible. For the data the logical structure is a star network, but physically the motes must be able to handle dynamic routing.

In that case, you will need the dynamic mesh-routing capabilities of a protocol such as Zigbee (BitCloud). You can have all your motes as Zigbee routers because they are powered from the mains and you do not care about battery life. If you use Zigbee, as you increase the number of devices, you will have to proportionally increase the time interval between successive packets from each device. I guess one packet every 10 seconds is okay for a network of about 10 nodes. For time synching, you can periodically send heat-beat (keep-alive or whatever) packets from the data sink (coordinator). These packets can also be used to figure out whether the coordinator is alive and in the network.

I haven't used RUM so I do not know much about its routing capabilities..

hth