03_Building_XMesh

WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 1 Feb 2007WSN Training: Introduction to XMesh 1 Introduction to XMesh Objectives: ƒ Topology types ƒ XMesh routing modes ƒ Route discovery algorithm ƒ Upstream data collection ƒ The XMesh build environment ƒ Building an XMesh application WSN Training: Introduction to XMesh 2 Feb 2007 Peer-to-Peer “Mesh” Star (also Bluetooth) Wireless Network Topologies Hybrid Star Coordinator/Sink Node (e.g., ZigBee FFD) Beacon/Router Node (e.g., ZigBee FFD) Leaf, Edge, Data Source Node (e.g, ZigBee RFD) WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 2 WSN Training: Introduction to XMesh 3 Feb 2007 Sensor Network Topologies -- Terminology Endpoints (aka, “edge” or “leaf”) • Integrate with sensors, UI devices, and actuators • For ZigBee networks these are referred to as RFDs (Reduced Functional Devices). • RFDs cannot forward network messages upstream or downstream. XMesh- ELP Motes behave as RFD devices. Routers • Extend network area coverage, route around obstacles, and provide backup routes in case of network congestion or device failure. • For ZigBee networks routers are referred to as FFDs (Full-Function Devices) • Note: All versions of XMesh, except XMesh-elp Motes act as FFDs. WSN Training: Introduction to XMesh 4 Feb 2007 Sensor Network Topologies -- Terminology Gateways (aka, “base” or “base station” or “sink”) • Aggregate the data from the network, interface to the host, LAN, or the Internet, and act as a portal to monitor performance and configure network parameters. System Software (aka, “XMesh” or “Network stack”) • Provides the networking protocol to enable the self-configuring, self-healing, ad hoc network. WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 3 WSN Training: Introduction to XMesh 5 Feb 2007 MoteWorks XMesh 2.0 Features TrueMesh™ ƒ Self-organizing, self-healing ƒ The nodes build a routing tree based on the link estimates of the particular radio environment Multiple Messaging Services ƒ Upstream ƒ Downstream ƒ Single hop Quality of Service (QoS) ƒ Link-level acknowledgement ƒ End-to-end acknowledgement Multiple power modes ƒ High power (“hp”) ƒ Low power (“lp”) ƒ Extended low power (“elp”) Health Diagnostics ƒ Node health (includes parent health) ƒ Neighbor health Time Synchronization ƒ Primarily to support lp modes Over the Air Programming ƒ Directed downstream strategy ƒ Serial flash memory support … = Highlights the topics covered or reviewed in this session WSN Training: Introduction to XMesh 6 Feb 2007 Xmesh -- Star and Hybrid Star Networks Star network: Simple topology that can support very low power operation of the edge nodes. (Green links are edge to router comms.) Hybrid-star network: Use additional Motes to create a powered backbone (yellow links) or hybrid-star network. Good where power available for routing Motes. = line powered, routing Mote = edge, battery powered, non-routing Mote WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 4 WSN Training: Introduction to XMesh 7 Feb 2007 XMesh -- TrueMesh Networks Mesh is self-forming, self-healing and provides maximum flexibility. The network strengthens as nodes are added due to have multiple paths to route data. = line powered, base/sink Mote = edge, battery powered, routing Mote WSN Training: Introduction to XMesh 8 Feb 2007 XMesh -- Routing Power Modes High Power (hp) ƒ TrueMesh capability ƒ Every node in the network can route data ƒ High bandwidth, low latency (full channel utilization) ƒ Mote radios are always powered. Low Power (lp) ƒ TrueMesh capability ƒ Every node in the network can route data ƒ Low bandwidth, high latency (ideal for low data rate applications) ƒ Mote radios are normally in a low power sleep state and wake periodically to check for radio traffic. Extended Low Power (elp) ƒ Used only for end nodes of the network ƒ Nodes cannot route data ƒ Uses hybrid star mesh configuration WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 5 Feb 2007WSN Training: Introduction to XMesh 9 Introduction to XMesh Objectives: ƒ Topology types ƒ XMesh routing modes ƒ Route discovery algorithm ƒ Upstream data collection ƒ The XMesh build environment ƒ Building an XMesh application WSN Training: Introduction to XMesh 10 Feb 2007 Key Function: How to Get From “A” to “B”? B A B A B A Discover & characterize connectivity Neighbor management •keep the good ones •build a connectivity graph Select a good route and change as needed WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 6 WSN Training: Introduction to XMesh 11 Feb 2007 Any-to-Base Routing Algorithm (1) Goal 1: Maximize expected success rate ƒ A function of link quality of 1) Mote-to-parent and 2) parent-to- base Link quality is a measure of the packet delivery success rate and is a function of ƒ The ratio of received to expected packets ƒ An exponentially weighted moving average (EWMA) Each Mote reports its receive link quality from each neighbour ƒ Each Mote monitors up to 16 neighbours and counts valid packets per unit time Data packets are acknowledged by parents ƒ Child node reTX up to 6× prior to switching to another parent WSN Training: Introduction to XMesh 12 Feb 2007 Any-to-Base Routing Algorithm (2) Goal 2: Minimize total cost Each node broadcasts its cost ƒ Node cost = Parent’s cost + Link’s cost to parent “Cost” is an abstract measure of distance ƒ Various metrics based on a) hop count, b) transmissions and retries, c) reconfigurations over time XMesh uses the Minimum Transmission (MT) cost metric: ƒ Link’s cost to parent = ƒ(1/send quality × 1/receive quality) ƒ Parent’s cost = total routing cost of all hops to base station or ∑(MT) WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 7 WSN Training: Introduction to XMesh 13 Feb 2007 Any-to-Base Routing Illustrated (1) PC Cost: ∞ Cost: 0 Parent: PC Cost: ∞ Cost: ∞ Cost: ∞ WSN Training: Introduction to XMesh 14 Feb 2007 Any-to-Base Routing Illustrated (2) PC Cost: ∞ Cost: 0 Parent: PC Cost: ∞ Cost: ∞ Cost: ∞20 15 15 10 18 15 28 20 15 30 4340 25 Parent cost Link cost Node cost WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 8 WSN Training: Introduction to XMesh 15 Feb 2007 Upstream Communication Deliver messages from edge to base station (“sink”) Collection routing to a single point Base/sink/gateway Node sends to parent with lowest cost up st re am Parent Child Unlike us child nodes choose parents WSN Training: Introduction to XMesh 16 Feb 2007 Upstream Link-level Acknowledgments Link-level acknowledgements are enabled by default ƒ Provides a best-effort type of QoS Child will re-TX up to 6 times before switching parent ƒ After 6 re-TX will switch to next best parent and re-TX up to 2x before dropping the packet. Useful for non-critical data Base/sink/gateway Parent Child Link-level acknowledgement (“ack”) WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 9 Feb 2007WSN Training: Introduction to XMesh 17 Introduction to XMesh Objectives: ƒ Topology types ƒ XMesh routing modes ƒ Route discovery algorithm ƒ Upstream data collection ƒ The XMesh build environment ƒ Building an XMesh application Feb 2007WSN Training: Introduction to XMesh 18 Building XMesh Objectives: ƒ Review the XMesh build environment. ƒ Lab: Building an XMesh application. ƒ Deploying and testing a small network. ƒ Using binaries to build an application. Applications: ƒ XMeshCountToLeds ƒ XMeshBase WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 10 WSN Training: Introduction to XMesh 19 Feb 2007 XMesh Build Environment XMesh is compiled and built in the MoteWorks environment. 3 files to check, create, edit for building XMesh-enabled apps 1. MakeXbowlocal 2. Makefile 3. Makefile.component ƒ For any XMesh enabled application it is necessary to set the correct parameters in each of these files. WSN Training: Introduction to XMesh 20 Feb 2007 XMesh Environment – MakeXbowlocal (Review) The MakeXbowlocal file contains global parameters which are applicable across all applications Location: /MoteWorks/apps Parameter Description RADIO_CLASS This parameter defines the radio band in which the network communicates for MICAz, MICA2, and MICA2DOT radios. The operating band is defined by the mote’s radio hardware. This should correspond to the label on the board. The availabile classes for the MICAz is 2.4 GHz. The available classes for MICA2/MICA2DOT are 916 MHz, 433 MHz and 315 MHz. RADIO_CHANNEL This parameter defines the radio channel the network is operating on. Each band has multiple channels upon which it can operate. The user should choose a channel which is not being used by other wireless devices in the network (including other sensor networks). See table below for MICAz settings. RADIO_POWER This parameter defines the power level for the radio. DEFAULT_LOCAL_GROUP The local group is the group id upon which each node in your network will communicate on. The group id is a way for multiple networks to operate on the same radio band and channel yet filter communication by group id. WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 11 WSN Training: Introduction to XMesh 21 Feb 2007 MakeXbowlocal – XMeshCountToLeds App As an example the MakeXbowlocal file for XMeshCountToleds might have these parameters Parameters MICA2 MICAz RADIO_CLASS 916 n/a RADIO_CHANNEL 10 13 RADIO_POWER 0xff TXPOWER_0DBM DEFAULT_LOCAL_GROUP Use your group ID on your badge Use your group ID on your badge WSN Training: Introduction to XMesh 22 Feb 2007 XMesh Environment – Makefile (Review) The Makefile contains build specific parameters. ƒ Most importantly it defines high level services which should be included for the particular application by way of a list of GOALS. ƒ Location: /MoteWorks/apps// The Makefile for XMeshCountToLeds is shown below include Makefile.component include ../../MakeXbowlocal include $(MAKERULES) GOALS += power,max route,hp freq,868 GOALS syntax: GOALS += WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 12 WSN Training: Introduction to XMesh 23 Feb 2007 XMesh Environment – Makefile GOALS Syntax: GOALS += Service Description basic Responsible for including the standard Crossbow services. This service should be included in all XMesh applications. Usage is simply basic. There are no parameters with this service. freq Sets the radio channel for the application. This feature acts as an application specific override of the RADIO_CHANNEL parameter set in the MakeXbowlocal file. Usage is: freq, or freq, group Sets the group id for the application and acts as an override of the DEFAULT_LOCAL_GROUP parameter set in the MakeXbowlocal file. Usage is: group, power Sets the radio power and acts as an override of the RADIO_POWER parameter set in the MakeXbowlocal file. Usage is: power, route Sets the XMesh power operating mode. Usage is: route, where is one of the three options: 1) hp, 2) lp, or 3) elp. • hp to build XMesh high power. • lp to build XMesh low power: This will build the time-synchronized MICA2 mesh or asynchronous MICAz mesh. • elp to build XMesh extended low power base The base goal sets the application image as the base station node in XMesh. This should only be used for building XMeshBase. Usage is simply base. WSN Training: Introduction to XMesh 24 Feb 2007 XMesh Environment – Makefile (Review) Note: Compiling an application in a Cygwin/Programmer’s Notepad command line will override any parameters set in the Makefile. To force XMesh high power routing for a Mote ƒ make route,hp To force a build of a base station application for a Mote and XMesh high power routing : ƒ make base route,hp WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 13 WSN Training: Introduction to XMesh 25 Feb 2007 XMesh Environment – Makefile.component (Review) The Makefile.component contains application specific parameters. The parameters defined in the Makefile.component file are applicable to the particular application and are provided by the application itself. Example: in apps/examples/XMeshCountToLeds/ Parameter Description COMPONENT The component parameter tells the build system which application is being made and also can include #defines to configure XMesh. The component listed here should be the top level application component in the application. # $Id: Makefile.component,v 1.2 2006/01/09 17:17:31 abroad Exp $ COMPONENT=XMeshCountToLeds MSG_SIZE = 49 Feb 2007WSN Training: Introduction to XMesh 26 Building XMesh Objectives: ƒ Review the XMesh build environment. ƒ Lab: Building an XMesh application. ƒ Deploying and testing a small network. ƒ Using binaries to build an application. Applications: ƒ XMeshCountToLeds ƒ XMeshBase WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 14 WSN Training: Introduction to XMesh 27 Feb 2007 Lab Preparation – Heads Up To build this application we will need the following equipment: ƒ 3 MICA2 or MICAz Motes ƒ Mote Interface Board (MIB) ƒ MIB510, MIB520, or MIB600 and associated cables and power adaptors ƒ Notebook PC ƒ Windows 2000 or XP ƒ MoteWorks installed ƒ No sensor boards needed WSN Training: Introduction to XMesh 28 Feb 2007 A Simple XMesh-hp Application The application we will develop is XMeshCountToLeds ƒ Location: MoteWorks/apps/examples/XMeshCountToLeds/ What does XMeshCountToLeds do? ƒ Each node in the network will increment its individual count every second and will send the value back the base station for viewing. ƒ In each Mote the LEDs will display the count value What makes this a “simple” XMesh app? 1. No sensors needed (We’ll continue later with MyApp_Sensor.) 2. The application sends upstream messages with no end to end acknowledgments WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 15 WSN Training: Introduction to XMesh 29 Feb 2007 XMeshCountToLeds.nc – Configuration configuration XMeshCountToLeds{ provides interface StdControl; } implementation{ components Main, XMeshCountToLedsM, LedsC, TimerC, MULTIHOPROUTER; StdControl = XMeshCountToLedsM.StdControl; Main.StdControl -> TimerC.StdControl; Main.StdControl -> MULTIHOPROUTER.StdControl; Main.StdControl -> XMeshCountToLedsM.StdControl; XMeshCountToLedsM.Leds -> LedsC.Leds; XMeshCountToLedsM.Timer -> TimerC.Timer[unique("Timer")]; XMeshCountToLedsM.MhopSend -> MULTIHOPROUTER.MhopSend[10]; XMeshCountToLedsM.health_packet -> MULTIHOPROUTER; } WSN Training: Introduction to XMesh 30 Feb 2007 GraphViz – XMeshCountToLeds Configuration WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 16 WSN Training: Introduction to XMesh 31 Feb 2007 XMeshCountToLedsM.nc – Code Excerpt XMeshCountToLedsM.nc ƒ Runs a one second timer which increments a count variable on every fire. ƒ The count variable is then displayed using the LEDs. ƒ The number is displayed as a 3-bit binary number with the yellow led being most significant bit and the red led being the least significant bit. void displayCount(uint16_t value){ if (value & 1) call Leds.redOn(); else call Leds.redOff(); if (value & 2) call Leds.greenOn(); else call Leds.greenOff(); if (value & 4) call Leds.yellowOn(); else call Leds.yellowOff(); } event result_t Timer.fired(){ g_count++; displayCount(g_count); post sendMsg(); return SUCCESS; } Once we have displayed the count value to the LEDs the application attempts to send the count value and node id to the base station PC using the XMesh multihop network. Once we have displayed the count value to the LEDs the application attempts to send the count value and node id to the base station PC using the XMesh multihop network. WSN Training: Introduction to XMesh 32 Feb 2007 XMeshCountToLeds.nc – Config Excerpt The XMesh service is implemented by the XMeshRouter component. ƒ Provides a sending interface in MhopSend which sends packets into the network. ƒ A receiving interface is also implemented but will be described later. implementation{ components Main,XMeshCountToLedsM,LedsC,TimerC,XMeshRouter; StdControl = XMeshCountToLedsM.StdControl; Main.StdControl -> TimerC.StdControl; Main.StdControl -> XMeshRouter.StdControl; Main.StdControl -> XMeshCountToLedsM.StdControl; XMeshCountToLedsM.Leds -> LedsC.Leds; XMeshCountToLedsM.Timer -> TimerC.Timer[unique("Timer")]; XMeshCountToLedsM.MhopSend -> XMeshRouter.MhopSend[10]; } WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 17 WSN Training: Introduction to XMesh 33 Feb 2007 XMeshCountToLeds.nc – Config Excerpt Each application which links into the XMesh send interface attaches with its own application id. ƒ XMesh uses this application id to multiplex packets from different applications in the network. ƒ In this example we chose application id 10 to interface with XMesh. ƒ The id value is important, in that each application on XMesh should have a unique id and both the send and receive interface for an application should use the same id. implementation{ components Main,XMeshCountToLedsM,LedsC,TimerC,XMeshRouter; StdControl = XMeshCountToLedsM.StdControl; Main.StdControl -> TimerC.StdControl; Main.StdControl -> XMeshRouter.StdControl; Main.StdControl -> XMeshCountToLedsM.StdControl; XMeshCountToLedsM.Leds -> LedsC.Leds; XMeshCountToLedsM.Timer -> TimerC.Timer[unique("Timer")]; XMeshCountToLedsM.MhopSend -> XMeshRouter.MhopSend[10]; } WSN Training: Introduction to XMesh 34 Feb 2007 XMeshCountToLedsM.nc – Sending Messages TOSMsg g_msg; task void sendMsg(){ uint16_t bufferLength = 0; CountMsg_t* countMsg = (CountMsg_t*) MhopSend.getBuffer(&g_msg,&bufferLength); countMsg->nodeId = TOS_LOCAL_ADDRESS; countMsg->nodeCount = g_count; call MhopSend.send( BASE_STATION_ADDRESS, MODE_UPSTREAM,&g_msg, sizeof(CountMsg_t)); } The application declares a TOSMsg which it will fill with application specific messaging information. ƒ In this case the information is the local node id and the current count value. Though the message object is owned by the application, XMesh will fill out the initial portion of the message with its own mesh information. To retrieve the area of message buffer that is for use by the application the code uses the MhopSend.getBuffer() method. ƒ The method returns a pointer to the location in the buffer where the application can insert its information. The basic messaging structure in TinyOS is the TOSMsg object. The basic messaging structure in TinyOS is the TOSMsg object. WSN Training: Introduction to XMesh Feb 2007 Crossbow Technology, Inc. Proprietary 18 WSN Training: Introduction to XMesh 35 Feb 2007 XMeshCountToLedsM.nc – Sending Messages TOSMsg g_msg; task void sendMsg(){ uint16_t bufferLength = 0; CountMsg_t* countMsg = (CountMsg_t*) MhopSend.getBuffer(&g_msg,&bufferLength); countMsg->nodeId = TOS_LOCAL_ADDRESS; countMsg->nodeCount = g_count; call MhopSend.send( BASE_STATION_ADDRESS, MODE_UPSTREAM,&g_msg, sizeof(CountMsg_t)); } Once the packet is filled out the application must hand the message to XMesh to send. ƒ The MhopSend.send() method provides the sending interface. The application provid