We use “pulling” style communication. That is, nodes are passive: they wait until the base station requests data and then reply. We follow the “thin servers, fat client” style. It is important to note that we target non-trivial-rate data streams, that is, about >30sps, typically 50-500sps, definitely >>1sps per node.  Plus, there may be a short latency requirement, preferably < 300ms.  This may be very different from the assumptions made by other WSN protocols that focus on ad-hoc or multi-hop communication but must assume trivial data rate or non-real-time. The advantages are:

1. •Nodes can be kept very simple!  No need to implement complicated mechanisms or policies.  The code size fits comfortably in 4KB with lots of room to spare.
   

2. •Collision-free:  the host effects performs arbitration
   

3. •Scalable to 50 nodes on one frequency channel
   

4. •Actually works!  If you are attending IPSN 2008 (St. Louis, Missouri, USA, April 22-24, 2008) come see a demo by Chongjing Chen
   

Critics may say this is wasteful with a lot of idle-listening power, which can be drawing about 20mA at 3V.  We don’t think this is a huge problem, because our nodes are busy most of the time.  We can also limit the listening time in ways similar to other approaches, except we don’t pay the TDMA time-sync overhead.

Some may also say that pulling takes away bandwidth from data that need to be sent from the nodes. This is true, but we can also amortize this overhead by doing multiple replies per packet per pull request, of course at the cost of increased latency.  Since the pull acts effectively as an ack, it is actually possible to consolidate the ack to a group of nodes instead of acking individually.

More details will be available as our conference papers get accepted (hopefully!).