introduction to xmesh
DESCRIPTION
Introduction to XMesh. Objectives: Topology types XMesh routing modes Route discovery algorithm Upstream data collection The XMesh build environment Building an XMesh application. Hybrid Star. Wireless Network Topologies. Peer-to-Peer “Mesh”. Star (also Bluetooth). - PowerPoint PPT PresentationTRANSCRIPT
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 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 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 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
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 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 costEach 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 13 Feb 2007
Any-to-Base Routing Illustrated (1)
PCCost:
Cost: 0Parent: PC
Cost:
Cost:
Cost:
WSN Training: Introduction to XMesh 14 Feb 2007
Any-to-Base Routing Illustrated (2)
PCCost:
Cost: 0Parent: 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 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
upst
ream 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”)
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 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 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/<specific app name>/
The Makefile for XMeshCountToLeds is shown below
include Makefile.componentinclude ../../MakeXbowlocalinclude $(MAKERULES)GOALS += power,max route,hp freq,868
GOALS syntax: GOALS += <service1,parameter service2, parameter, … serviceN,parameter>
WSN Training: Introduction to XMesh 23 Feb 2007
XMesh Environment – Makefile GOALS
Syntax: GOALS += <service1,parameter service2,parameter, … serviceN,parameter>
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,<freq> or freq,<channel #>
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,<group #>
power Sets the radio power and acts as an override of the RADIO_POWER parameter set in the MakeXbowlocal file. Usage is: power,<power #>
route Sets the XMesh power operating mode. Usage is: route,<operating mode> where <operating mode> 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 <platform> route,hp
To force a build of a base station application for a Mote and XMesh high power routing : make <platform> base route,hp
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=XMeshCountToLedsMSG_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 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 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 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 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 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 provides the address of the receiver
in this case the BASE_STATION_ADDRESS. It also provides the send mode.
Remember: The upstream mode is used. There are no reliability guarantees as shown by the parameter MODE_UPSTREAM.
After XMesh has attempted send the message it informs the application of the result through the MhopSend.sendDone() event.
WSN Training: Introduction to XMesh 36 Feb 2007
Install XMeshCountToLeds on a Mote
Once all the correct parameters are set for an application, build XMeshCountToLeds by executing the make command from the application directory. 1. Building and install the code:
make <platform> route,hp install,<#>
Reminder: <platform> corresponds to a hardware platform mica2 mica2dot micazHelpful tip: Use temporary labels to identify your Motes
WSN Training: Introduction to XMesh 37 Feb 2007
Making a Base Station and an RF Sniffer Mote
Making a Base Station Mote Compile and flash a Mote (as node ID = 0) with the
XMeshBase app in /MoteWorks/apps/XMesh/XMeshBase make <platform> route,hp make <platform> reinstall,0
Programming a Sniffer Mote Compile and flash the last Mote with the TOSBase app
in /MoteWorks/apps/general/XSniffer/ make <platform> make <platform> reinstall
Helpful tip: Use temporary labels to identify your Motes
WSN Training: Introduction to XMesh 38 Feb 2007
Deploy the Mote Network – A Mini Testbed
Turn on all MotesUse plug the Mote with TOSBase to the gateway
board Use the XSniffer to monitor the network activity This allows users to monitor the mesh formation, route
update packets, and all upstream and downstream traffic. After you have seen the routing packets being exchanged
using XSniffer, you are able to view the individual packets arriving through the base station.
Remove the Mote with TOSBase and plug the Mote with XMeshBase to the gateway board. Use XServe to view the raw data packets coming from the
base station.
Feb 2007WSN Training: Introduction to XMesh 39
Q & A: Intro to XMesh
Topics covered Topology types XMesh routing modes Route discovery algorithm Upstream data collection The XMesh build environment Building an XMesh application