[Tinyos-contrib-commits] CVS: tinyos-1.x/contrib/rincon/apps/MeshCollect readme.txt, NONE, 1.1 MeshCollect.h, NONE, 1.1 MeshCollectC.nc, NONE, 1.1

dmm rincon at users.sourceforge.net
Thu Jul 27 16:38:27 PDT 2006


Update of /cvsroot/tinyos/tinyos-1.x/contrib/rincon/apps/MeshCollect
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv18715/contrib/rincon/apps/MeshCollect

Added Files:
	readme.txt MeshCollect.h MeshCollectC.nc 
Log Message:
Added the MeshCollect component to CVS; Testing will continue on this component

--- NEW FILE: readme.txt ---
A demo app is provided in /apps/TestMeshCollect
Make sure your radio's ack's are enabled!

/**
 * This Mesh Network component is based on MultiHopLQI, with updates:
 *
 *  > Built on top of Transceiver, which provides a publically shared 
 *    message pool that's application-wide and managed automatically.
 *
 *  > QuickJoin functionality allows the mote to quickly 
 *    connect to its surrounding network.  QuickJoin is run when 
 *    the mote is first turned on, and when it loses communication.
 *
 *  > MultiHop and SingleHop Transceivers allow an application
 *    to either transmit data out to the base station through the network,
 *    or communicate directly with a nearby mote.
 * 
 *  > Collect message signatures allows an application to know for sure
 *    if a sent/received message is really a multihop message.
 *
 *  > Increased simplicity by removing Snoop and Intercept - which does
 *    decrease functionality to some degree, but makes the overall component
 *    more of a no-brainer. The SinglehopTransceiver makes up for this somewhat.
 *
 *  > Mesh Analysis provides the ability to find out how the network is doing.
 *    At the moment, custom implementation is involved to do anything
 *    useful with the locally heard or multihop collected analysis packets.
 *
 *  > Multiple base stations are allowed, and it's easy to force a mote
 *    to be a base station at compile time by setting the FORCE_BASE_STATION
 *    preprocessor variable to 1
 *
 *  > Ability to dynamically turn a mote into a base station mote and back,
 *    if you ever need that functionality.
 *
 * 
 * This is not a replacement for Drain, it's something a little different
 * with its roots still more toward automated tree maintenance. I also
 * changed some of the names and references from 'MultiHop' to 'MeshCollect'
 * to emphasize the fact that we are not multihopping packets to and from
 * any location in the network; we're specifically collecting data from the 
 * network and removing it using the base station node.  I'm sure that's why
 * Drain got the name it has as well.
 *
 * Some files were renamed from MultiHopLQI, but maintain similar functionality:
 * MultiHopC became MeshCollectC
 * MultiHopEngineM became MeshTransferM
 * MultiHopLQIM became MeshManagerM
 *
 * According to Phil Levis's comments in TinyOS devel (6/8/2006)
 * the history of this protocol goes something like:
 *
 * Berkeley:
 * MHOP -> BLESS -> lib/Route -> lib/MintRoute -> lib/MultiHopLQI -->
 *    --> Drain
 *    --> MeshCollect
 *
 * So you see, Drain and MeshCollect are on two different branches from
 * MultiHopLQI.  Phil writes, "The change between MultiHopLQI and Drain was that
 * Drain produces a static tree, which can be regenerated from the tree root,
 * while MultiHopLQI, following the MintRoute approach, has a continuously
 * updated tree."
 *
 * This component, MeshCollect, follows the MintRoute/MultiHopLQI approach
 * in that the tree is continuously updated. It uses the same
 * parent selection algorithms as MultiHopLQI.  The QuickJoin functionality
 * and deployment analysis were added after gaining experience from
 * actual deployed networks, and the code was completely revamped to make
 * it easier to debug and hack. Flexibility is provided by 
 * altering the compile time preprocessor variables.
 * 
 * @author David Moss - dmm at rincon.com
 */
 

--- NEW FILE: MeshCollect.h ---
// $Id: MultiHop.h,v 1.5 2004/11/16 21:09:22 gtolle Exp $

/*									tab:4
 * "Copyright (c) 2000-2003 The Regents of the University  of California.  
 * All rights reserved.
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation for any purpose, without fee, and without written agreement is
 * hereby granted, provided that the above copyright notice, the following
 * two paragraphs and the author appear in all copies of this software.
 * 
 * IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
 * DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT
 * OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF
 * CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 * 
 * THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
 * AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE PROVIDED HEREUNDER IS
 * ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATION TO
 * PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
 *
 * Copyright (c) 2002-2003 Intel Corporation
 * All rights reserved.
 *
 * This file is distributed under the terms in the attached INTEL-LICENSE     
 * file. If you do not find these files, copies can be found by writing to
 * Intel Research Berkeley, 2150 Shattuck Avenue, Suite 1300, Berkeley, CA, 
 * 94704.  Attention:  Intel License Inquiry.
 */

/**
 * @author Philip Buonadonna
 * @author David Moss
 */


#ifndef _TOS_COLLECT_H
#define _TOS_COLLECT_H

#include "AM.h"

/**
 * The number of seconds between sending out a beacon update
 * Increasing this number makes the network more volatile and
 * able to adapt, but decreases battery life of the whole network.
 */
#ifndef BEACON_PERIOD_SECONDS
#define BEACON_PERIOD_SECONDS 30
#endif

/**
 * The number of beacon messages that have to be missed
 * from the parent before this mote is disconnected from
 * the network and tries to QuickJoin again.
 */
#ifndef BEACON_TIMEOUT
#define BEACON_TIMEOUT 3
#endif

/*
 * We can use a compile define to force a mote to become a base station
 * which allows other mote ID's to play the role if necessary
 */
#ifndef FORCE_BASE_STATION
#define FORCE_BASE_STATION 0
#endif

/**
 * Size of the queue that contains info about the last few messages
 */
#ifndef COLLECT_HISTORY_SIZE
#define COLLECT_HISTORY_SIZE 4
#endif


typedef struct TOS_CollectMsg {
  uint16_t signature;
  uint16_t sourceaddr;
  uint16_t originaddr;
  int16_t seqno;
  int16_t originseqno;
  uint16_t hopcount;
  uint8_t data[(TOSH_DATA_LENGTH - 12)];
} TOS_CollectMsg;

typedef struct BeaconMsg {
  uint16_t parent;
  uint16_t cost;
  bool requestReply;
} BeaconMsg;

enum {
  AM_BEACONMSG = 0xFB,
};

enum {
  COLLECT_SIGNATURE = 0xC011,    // C011EC7 :)
};


#endif /* _TOS_COLLECT_H */


--- NEW FILE: MeshCollectC.nc ---

/**
 * This Mesh Network component is based on MultiHopLQI, with updates:
 *
 *  > Built on top of Transceiver, which provides a publically shared 
 *    message pool that's application-wide and managed automatically.
 *
 *  > QuickJoin functionality allows the mote to quickly 
 *    connect to its surrounding network.  QuickJoin is run when 
 *    the mote is first turned on, and when it loses communication.
 *
 *  > MultiHop and SingleHop Transceivers allow an application
 *    to either transmit data out to the base station through the network,
 *    or communicate directly with a nearby mote.
 * 
 *  > Collect message signatures allows an application to know for sure
 *    if a sent/received message is really a multihop message.
 *
 *  > Increased simplicity by removing Snoop and Intercept - which does
 *    decrease functionality to some degree, but makes the overall component
 *    more of a no-brainer. The SinglehopTransceiver makes up for this somewhat.
 *
 *  > Mesh Analysis provides the ability to find out how the network is doing.
 *    At the moment, custom implementation is involved to do anything
 *    useful with the locally heard or multihop collected analysis packets.
 *
 *  > Multiple base stations are allowed, and it's easy to force a mote
 *    to be a base station at compile time by setting the FORCE_BASE_STATION
 *    preprocessor variable to 1
 *
 *  > Ability to dynamically turn a mote into a base station mote and back,
 *    if you ever need that functionality.
 *
 * 
 * This is not a replacement for Drain, it's something a little different
 * with its roots still more toward automated tree maintenance. I also
 * changed some of the names and references from 'MultiHop' to 'MeshCollect'
 * to emphasize the fact that we are not multihopping packets to and from
 * any location in the network; we're specifically collecting data from the 
 * network and removing it using the base station node.  I'm sure that's why
 * Drain got the name it has as well.
 *
 * Some files were renamed from MultiHopLQI, but maintain similar functionality:
 * MultiHopC became MeshCollectC
 * MultiHopEngineM became MeshTransferM
 * MultiHopLQIM became MeshManagerM
 *
 * According to Phil Levis's comments in TinyOS devel (6/8/2006)
 * the history of this protocol goes something like:
 *
 * Berkeley:
 * MHOP -> BLESS -> lib/Route -> lib/MintRoute -> lib/MultiHopLQI -->
 *    --> Drain
 *    --> MeshCollect
 *
 * So you see, Drain and MeshCollect are on two different branches from
 * MultiHopLQI.  Phil writes, "The change between MultiHopLQI and Drain was that
 * Drain produces a static tree, which can be regenerated from the tree root,
 * while MultiHopLQI, following the MintRoute approach, has a continuously
 * updated tree."
 *
 * This component, MeshCollect, follows the MintRoute/MultiHopLQI approach
 * in that the tree is continuously updated. It uses the same
 * parent selection algorithms as MultiHopLQI.  The QuickJoin functionality
 * and deployment analysis were added after gaining experience from
 * actual deployed networks, and the code was completely revamped to make
 * it easier to debug and hack. Flexibility is provided by 
 * altering the compile time preprocessor variables.
 * 
 * @author David Moss - dmm at rincon.com
 */
 
includes MeshCollect;

configuration MeshCollectC {
  
  provides {
    interface StdControl;
    interface Transceiver as MultihopTransceiver[uint8_t id];
    interface Transceiver as SinglehopTransceiver[uint8_t id];
    interface Packet as MultihopPacket;
    interface Packet as SinglehopPacket;
    interface RouteControl;
  }
}

implementation {

  components MeshTransferM, 
      MeshManagerM,
      MeshAnalysisC,
      TransceiverC,
      StateC,
      TimerC;

  StdControl = MeshTransferM;
  StdControl = MeshManagerM;
  StdControl = MeshAnalysisC;
  StdControl = TransceiverC;

  MultihopTransceiver = MeshTransferM;
  MultihopPacket = MeshTransferM;
  RouteControl = MeshManagerM;
  
  SinglehopPacket = TransceiverC.Packet;
  SinglehopTransceiver = TransceiverC.Transceiver;
  
  MeshTransferM.RouteControl -> MeshManagerM;
  MeshTransferM.RouteSelect -> MeshManagerM;
  MeshTransferM.SubTransceiver -> TransceiverC;
  MeshTransferM.SubPacket -> TransceiverC;
  
  MeshManagerM.NormalBeaconTimer -> TimerC.Timer[unique("Timer")];  
  MeshManagerM.QuickJoinTimer -> TimerC.Timer[unique("Timer")];
  MeshManagerM.BeaconTransceiver -> TransceiverC.Transceiver[AM_BEACONMSG];
  MeshManagerM.State -> StateC.State[unique("State")];
  
}



More information about the Tinyos-contrib-commits mailing list