Introduction to XMesh

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)


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.


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.


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


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


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


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


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


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


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)


Any-to-Base Routing Illustrated (1)

PCCost:

Cost: 0Parent: PC

Cost:

Cost:

Cost:


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


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


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”)


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


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.


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.


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


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>


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.


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


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


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


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


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


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;

}


GraphViz – XMeshCountToLeds Configuration


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.


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];}


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];}


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.


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.


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


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


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.


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

Introduction to XMesh

Documents

Transcript of Introduction to XMesh