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
1
Feb 2007
Wireless Network Topologies
Peer-to-Peer
Star
Hybrid Star
“Mesh”
(also Bluetooth)
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
2
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. XMeshELP 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
3
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
4
Feb 2007
MoteWorks XMesh 2.0 Features
TrueMesh™
Multiple power modes
 Self-organizing, self-healing
 The nodes build a routing tree
based on the link estimates of
the particular radio
environment
 High power (“hp”)
 Low power (“lp”)
 Extended low power (“elp”)
Health Diagnostics
 Node health (includes parent
health)
 Neighbor health
Multiple Messaging Services
 Upstream
 Downstream
 Single hop
Time Synchronization
 Primarily to support lp modes
Quality of Service (QoS)
Over the Air Programming
 Link-level acknowledgement
 End-to-end acknowledgement
 Directed downstream strategy
 Serial flash memory support
 = Highlights the topics covered or reviewed in this session
WSN Training: Introduction to XMesh
5
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
WSN Training: Introduction to XMesh
= edge, battery powered, non-routing Mote
6
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
WSN Training: Introduction to XMesh
= edge, battery powered, routing Mote
7
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
8
Feb 2007
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
9
Feb 2007
Key Function: How to Get From “A” to “B”?
A
A
A
B
Discover & characterize
connectivity
WSN Training: Introduction to XMesh
B
Neighbor management
•keep the good ones
•build a connectivity graph
10
B
Select a good route
and change as
needed
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-tobase
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
11
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
12
Feb 2007
Any-to-Base Routing Illustrated (1)
Cost: 
Cost: 
PC
Cost: 
Cost: 0
Parent: PC
Cost: 
WSN Training: Introduction to XMesh
13
Feb 2007
Any-to-Base Routing Illustrated (2)
Node cost
28
43
Cost: 40
Link cost
25
Cost: 15
15
10
15
15
Parent cost
PC
20
18
Cost: 0
Parent: PC
Cost:  30
Cost: 20
WSN Training: Introduction to XMesh
14
Feb 2007
Upstream Communication
Deliver messages from edge to base station (“sink”)
Collection routing to a single point
Node sends to
parent with
lowest cost
upstream
Base/sink/gateway
Parent
Unlike us child
nodes choose
parents
Child
WSN Training: Introduction to XMesh
15
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
Link-level
acknowledgement
(“ack”)
Parent
Child
WSN Training: Introduction to XMesh
16
Feb 2007
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
17
Feb 2007
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
18
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
19
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
20
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
21
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.component
include ../../MakeXbowlocal
include $(MAKERULES)
GOALS += power,max route,hp freq,868
GOALS syntax: GOALS += <service1,parameter service2,
parameter, … serviceN,parameter>
WSN Training: Introduction to XMesh
22
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
23
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
24
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.
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.
Example: in apps/examples/XMeshCountToLeds/
# $Id: Makefile.component,v 1.2 2006/01/09 17:17:31 abroad Exp $
COMPONENT=XMeshCountToLeds
MSG_SIZE = 49
WSN Training: Introduction to XMesh
25
Feb 2007
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
26
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
27
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
28
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
29
Feb 2007
GraphViz – XMeshCountToLeds
Configuration
WSN Training: Introduction to XMesh
30
Feb 2007
XMeshCountToLedsM.nc – Code Excerpt
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);
Once we have displayed the count value to the
post sendMsg();
LEDs the application attempts to send the count
return SUCCESS;
value and node id to the base station PC using the
}
XMesh multihop network.
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.
WSN Training: Introduction to XMesh
31
Feb 2007
XMeshCountToLeds.nc – Config Excerpt
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];
}
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.
WSN Training: Introduction to XMesh
32
Feb 2007
XMeshCountToLeds.nc – Config Excerpt
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];
}
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.
WSN Training: Introduction to XMesh
33
Feb 2007
XMeshCountToLedsM.nc – Sending
Messages
The basic messaging structure in TinyOS is
the TOSMsg object.
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.
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));
}
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
35
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
 micaz
Helpful tip: Use temporary labels to identify your Motes
WSN Training: Introduction to XMesh
36
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
37
Feb 2007
Deploy the Mote Network – A Mini Testbed
Turn on all Motes
Use 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.
WSN Training: Introduction to XMesh
38
Feb 2007
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
WSN Training: Introduction to XMesh
39
Feb 2007