1 / 39

Introduction to XMesh

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

monifa
Download Presentation

Introduction to XMesh

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Hybrid Star Wireless Network Topologies Peer-to-Peer “Mesh” Star (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

  3. 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. 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. 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 MoteWorks XMesh 2.0 Features = Highlights the topics covered or reviewed in this session WSN Training: Introduction to XMesh

  6. = line powered, routing Mote = edge, battery powered, non-routing Mote 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. WSN Training: Introduction to XMesh

  7. 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. 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

  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. Key Function: How to Get From “A” to “B”? A A A B B B • Neighbor management • keep the good ones • build a connectivity graph Select a good route and change as needed Discover & characterize connectivity WSN Training: Introduction to XMesh

  11. 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. 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

  13. Any-to-Base Routing Illustrated (1) Cost:  Cost:  Cost:  PC Cost: 0Parent: PC Cost:  WSN Training: Introduction to XMesh

  14. Node cost Link cost Parent cost Any-to-Base Routing Illustrated (2) 28 43 Cost:  40 25 10 Cost:  15 15 15 15 20 Cost:  30 PC 18 Cost: 0Parent: PC Cost:  20 WSN Training: Introduction to XMesh

  15. Upstream Communication • Deliver messages from edge to base station (“sink”) • Collection routing to a single point Node sends to parent with lowest cost Base/sink/gateway Parent Unlike us child nodes choose parents upstream Child WSN Training: Introduction to XMesh

  16. 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

  17. 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

  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. XMesh Build Environment • XMesh is compiled and built in the MoteWorks environment. • 3 files to check, create, edit for building XMesh-enabled apps • MakeXbowlocal • Makefile • 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. XMesh Environment – MakeXbowlocal (Review) • The MakeXbowlocal file contains global parameters which are applicable across all applications • Location: /MoteWorks/apps WSN Training: Introduction to XMesh

  21. MakeXbowlocal – XMeshCountToLeds App • As an example the MakeXbowlocal file for XMeshCountToleds might have these parameters WSN Training: Introduction to XMesh

  22. 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

  23. XMesh Environment – Makefile GOALS • Syntax:GOALS += <service1,parameter service2,parameter, … serviceN,parameter> WSN Training: Introduction to XMesh

  24. 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 forceXMesh high power routing for a Mote • make <platform> route,hp • To force a build of a base station application for a Mote andXMesh high power routing : • make <platform> base route,hp WSN Training: Introduction to XMesh

  25. 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/ # $Id: Makefile.component,v 1.2 2006/01/09 17:17:31 abroad Exp $ COMPONENT=XMeshCountToLeds MSG_SIZE = 49 WSN 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. 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. A Simple XMesh-hpApplication • 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? • No sensors needed (We’ll continue later with MyApp_Sensor.) • The application sends upstream messages with no end to end acknowledgments WSN Training: Introduction to XMesh

  29. 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. GraphViz – XMeshCountToLeds Configuration WSN Training: Introduction to XMesh

  31. 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; } XMeshCountToLedsM.nc – Code Excerpt 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. 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 WSN Training: Introduction to XMesh

  33. 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]; } XMeshCountToLeds.nc – Config Excerpt WSN Training: Introduction to XMesh

  34. 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. XMeshCountToLedsM.nc – Sending Messages The basic messaging structure in TinyOS is the TOSMsg object. WSN Training: Introduction to XMesh

  35. 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. XMeshCountToLedsM.nc – Sending Messages WSN Training: Introduction to XMesh

  36. 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. • 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

  37. 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. 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

  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 WSN Training: Introduction to XMesh

More Related