Feb 2007WSN Training: XMesh Services1 Lab6 Objectives:  Route Control Interface  Understand XMesh transport services 1.Upstream 2.Upstream with end-to-end.

Slides:



Advertisements
Similar presentations
Nucleus Network Management System Gilman Tolle UC Berkeley.
Advertisements

OSPF Header OSPF HEADER OSPF HEADER for this project Types we will use
Part 2: Preventing Loops in the Network
RIP V2 CCNP S1(5), Chapter 4.
Packet Switching COM1337/3501 Textbook: Computer Networks: A Systems Approach, L. Peterson, B. Davie, Morgan Kaufmann Chapter 3.
Feb 2007WSN Training: First Steps in nesC Programming1 First Steps in TinyOS and nesC Programming Topics  Timer Application: MyApp  Application directory.
1 Lab 3 Objectives  Case study: “Hello world” program on motes  Write you first program on mote.
CCNA – Network Fundamentals
1 Semester 2 Module 4 Learning about Other Devices Yuda college of business James Chen
1 Lab4 Objectives  Learn to read light sensor data from sensor board  Learn to transmit a message containing the sensed data  through Mote serial port.
Report on Sensor Networks By Ganesh Godavari Tuesday, Feb 17, 2004.
Cs4411 – Operating Systems Practicum November 4, 2011 Zhiyuan Teo Supplementary lecture 4.
7/13/2007AIIT Summer Course - D#1 Wireless Embedded Systems and Networking Lab Day 5: Part 1: TinyOS Programming on Open Source Distribution Jaein Jeong.
1 Relates to Lab 4. This module covers link state routing and the Open Shortest Path First (OSPF) routing protocol. Dynamic Routing Protocols II OSPF.
Surge: A Network Analysis Tool Crossbow Technology.
Hands-On Microsoft Windows Server 2003 Networking Chapter 7 Windows Internet Naming Service.
Design and Implementation of a Server Director Project for the LCCN Lab at the Technion.
WXES2106 Network Technology Semester /2005 Chapter 8 Intermediate TCP CCNA2: Module 10.
TOSSIM: Visualizing the Real World Philip Levis, Nelson Lee, Dennis Chi and David Culler UC Berkeley NEST Retreat, January 2003.
Report on Sensor Networks and Degrading DOS By Ganesh Godavari Tuesday, January 27, 2004.
1 Lab 3 Objectives  Case study: “Hello world” program on motes  Write you first program on mote.
1 Relates to Lab 4. This module covers link state routing and the Open Shortest Path First (OSPF) routing protocol. Dynamic Routing Protocols II OSPF.
Cisco Public © 2013 Cisco and/or its affiliates. All rights reserved. 1.
ICMP (Internet Control Message Protocol) Computer Networks By: Saeedeh Zahmatkesh spring.
© Janice Regan, CMPT 128, CMPT 371 Data Communications and Networking Network Layer ICMP and fragmentation.
1 Lab 5 Objectives  Use XMesh multi-hop networking service to send sensing data to a base station  Using XServe to display the sensor data message on.
Lecture 2 TCP/IP Protocol Suite Reference: TCP/IP Protocol Suite, 4 th Edition (chapter 2) 1.
ICMP : Internet Control Message Protocol. Introduction ICMP is often considered part of the IP layer. It communicates error messages and other conditions.
NetSim ZigBee Simulation Code Walkthrough in 10 steps
April 15, 2005TinyOS: A Component Based OSPage 1 of 27 TinyOS A Component-Based Operating System for Networked Embedded Systems Tom Bush Graduate College.
PA3: Router Junxian (Jim) Huang EECS 489 W11 /
1 IP Forwarding Relates to Lab 3. Covers the principles of end-to-end datagram delivery in IP networks.
6.1. Transport Control Protocol (TCP) It is the most widely used transport protocol in the world. Provides reliable end to end connection between two hosts.
IP Forwarding.
Cisco S2 C4 Router Components. Configure a Router You can configure a router from –from the console terminal (a computer connected to the router –through.
Module 4: Configuring ISA Server as a Firewall. Overview Using ISA Server as a Firewall Examining Perimeter Networks and Templates Configuring System.
Digital Multimedia, 2nd edition Nigel Chapman & Jenny Chapman Chapter 17 This presentation © 2004, MacAvon Media Productions Multimedia and Networks.
HW2: Q&A Oct. 02, Lab Machine TinyOS is installed in one machine (531AB). But, you have to bring your kit. There is a sign up sheet. Please sign.
1 CMPT 471 Networking II IGMP (IPv4) and MLD (IPv6) © Janice Regan,
Wireless Software R&D Group, IITP RAS Kirill Andreev, Aleksey Kovalenko, Dmitriy Lakontsev Realization of IEEE802.11s draft standard in NS-3.3 Institute.
COP 4930 Computer Network Projects Summer C 2004 Prof. Roy B. Levow Lecture 3.
Simulation of Distributed Application and Protocols using TOSSIM Valliappan Annamalai.
Part 2 TinyOS and nesC Programming Selected slides from:
Feb 2007WSN Training: MICA2/z Radio Stack1 MoteWorks Radio Stack Objectives  Background  Radio Stack API  MICA2 radio stack  MICAz radio stack  Configure.
Feb 2007WSN Training: XMesh Services1 Lab6 Objectives:  Route Control Interface  Understand XMesh transport services 1.Upstream 2.Upstream with end-to-end.
802.11n Sniffer Design Overview Vladislav Mordohovich Igor Shtarev Luba Brouk.
Agilent Technologies Copyright 1999 H7211A+221 v Capture Filters, Logging, and Subnets: Module Objectives Create capture filters that control whether.
AODV: Introduction Reference: C. E. Perkins, E. M. Royer, and S. R. Das, “Ad hoc On-Demand Distance Vector (AODV) Routing,” Internet Draft, draft-ietf-manet-aodv-08.txt,
Data Collection and Dissemination. Learning Objectives Understand Trickle – an data dissemination protocol for WSNs Understand data collection protocols.
Multimedia and Networks. Protocols (rules) Rules governing the exchange of data over networks Conceptually organized into stacked layers – Application-oriented.
McGraw-Hill©The McGraw-Hill Companies, Inc., 2004 Connecting Devices CORPORATE INSTITUTE OF SCIENCE & TECHNOLOGY, BHOPAL Department of Electronics and.
Digital Multimedia, 2nd edition Nigel Chapman & Jenny Chapman Chapter 17 This presentation © 2004, MacAvon Media Productions Multimedia and Networks.
Guide to Networking Essentials Fifth Edition Chapter 2 Network Design Essentials.
Active Message Application: CONNECT Presented by Xiaozhou David Zhu Oommen Regi July 6, 2001.
TinyOS Sandeep Gupta. Operating System (OS) What is an OS? Main functions  Process management  Memory management  Resource management Traditional OSs.
HANBACK ELECTRONICS CO., LTD. 저자권 보호됨 Gossiping Protocol.
LSNDI RMRA 1 Design and troubleshooting M Clements.
Feb 2007WSN Training: XMesh Enabled Sensor App1 Lab 5 Objectives  Use XMesh multi-hop networking service to send sensing data to a base station  Using.
TCP/IP1 Address Resolution Protocol Internet uses IP address to recognize a computer. But IP address needs to be translated to physical address (NIC).
Why does it need? [USN] ( 주 ) 한백전자 Background Wireless Sensor Network (WSN)  Relationship between Sensor and WSN Individual sensors are very limited.
TinyOS Sandeep Gupta. TinyOS basics TinyOS is  Single tasking OS  Interrupt driven Written using a Component based language A set of components put.
1 Relates to Lab 4. This module covers link state routing and the Open Shortest Path First (OSPF) routing protocol. Dynamic Routing Protocols II OSPF.
Wireless Sensor Networks by Craig Young and Chris Theodoridis
Simulation of Distributed Application and Protocols using TOSSIM
WSN Training: XMesh Enabled Sensor App
Ad Hoc Networking using Flooding protocol
Chapter 6: Network Layer
Wireless Sensor Networks
Multimedia and Networks
Presentation transcript:

Feb 2007WSN Training: XMesh Services1 Lab6 Objectives:  Route Control Interface  Understand XMesh transport services 1.Upstream 2.Upstream with end-to-end acknowledgement 3.Downstream 4.Downstream with end-to-end acknowledgement  Lab: Guaranteed QoS with upstream acknowledgement

Feb 2007WSN Training: XMesh Services2 XMesh Advanced Services Objectives:  Route Control Interface  Understand XMesh transport services 1.Upstream 2.Upstream with end-to-end acknowledgement 3.Downstream 4.Downstream with end-to-end acknowledgement  Lab: Guaranteed QoS with upstream acknowledgement  XMesh Health Packets  Extended Low Power Mode (ELP)  Lab: Health Packet

WSN Training: XMesh Services3 Feb 2007 RouteControl Interface User can make application level decisions based on network conditions. RouteControl interface extracts information from the routing component. Example Wiring: MyAppM.RouteControl -> XMeshRouter; Example Usage: parent = call RouteControl.getParent();

WSN Training: XMesh Services4 Feb 2007 RouteControl Interface Interface: command uint16_t getParent() Description: Returns parent’s address (0xffff for broadcast) Interface: command uint16_t getDepth() Description: Number of hops away the mote is from the base station. Interface: command uint16_t getSender(TOS_MsgPtr) Description: Returns address of the mote that sent the message Interface: command uint8_t getOccupancy() Description: Returns the length of the routing forwarding queue

WSN Training: XMesh Services5 Feb 2007 RouteControl Interfaces Interface: command uint8_t getQuality(uint8_t type) Description: Gets a measure of goodness for the current parent. Returns value between 0 to 255, where 255 represents that 100% of messages has been heard.  Type = 1: Send goodness  Type = 2: Receive goodness Interface: command result_t setUpdateInterval(uint16_t Interval) Description: Sets the routing component’s internal route update interval = interval duration in seconds.

WSN Training: XMesh Services6 Feb 2007 XMesh Service Identifier: AM type Predefined AM types  QoS Service Types: 1.UPSTREAM 2.UPSTREAM_ACK 3.DOWNSTREAM 4.DOWNSTREAM_ACK Explanation of the predefined AM types  See tos/types/Messages.h for predefined AM types.  All these predefined AM types have been wired to the GenericComm by XMesh  Note: Application must not wire it again.

WSN Training: XMesh Services7 Feb 2007 Link Level Retransmission Perform link level retransmission for up to 8 times  Number of retransmission is user configurable.  Empirical result shows 8 is optimal in terms of reliability/energy trade-off Switch parent at 6 th retransmission of upstream packets. Link Level Acknowledgement

WSN Training: XMesh Services8 Feb 2007 Upstream Communication Deliver messages up to base station Collection routing to a single point Base node (Network sink) Node sends to parent with lowest cost Server Client

WSN Training: XMesh Services9 Feb 2007 Upstream Service API nesC Wiring AppM.MhopSend -> XMeshRouter.MhopSend[appID]; Call send command. call MhopSend.send ( BASE_STATION_ADDRESS, MODE_UPSTREAM, &gMsgBuffer, sizeof(UpStream_t) ); Implement the sendDone event: event result_t Send.sendDone (TOS_MsgPtr pMsg, result_t success) { // clear your flag here return SUCCESS; }

WSN Training: XMesh Services10 Feb 2007 Upstream with Acknowledgment Provides Guaranteed Delivery to nearest Base Node Set timeout; retry until end-to-end acknowledgement received Used for critical data Base E2E Ack Server Client

WSN Training: XMesh Services11 Feb 2007 Upstream Ack Service API nesC Wiring AppM.MhopSend -> XMeshRouter.MhopSend[appID]; AppM.RcvAck -> XMeshRouter.ReceiveAck[appID]; Call the send command call Send.send ( BASE_STATION_ADDRESS, MODE_UPSTREAM_ACK, &gMsgBuffer, sizeof(UpStream_t) ); Start a timer in sendDone event event result_t Send.sendDone (TOS_MsgPtr pMsg, result_t success) { call TimerAck.start(TIMER_ONE_SHOT, 20); //for HP stack return SUCCESS; }

WSN Training: XMesh Services12 Feb 2007 Upstream Ack Service API - continued Receive the end2end Ack event TOS_MsgPtr RcvAck.receive (TOS_MsgPtr pMsg, void* payload, uint16_t payloadLen) { call TimerAck.stop(); // stop the timer return pMsg; } No end2end Ack received event result_t TimerAck.fired() { // make decision as whether to resend the packet // usually increment a counter here // and retry x numbers of time; if ( NUM_RETRY != num_retry++) { // send again } else { // reach retry limit num_retry = 0; } return SUCCESS; }

WSN Training: XMesh Services13 Feb 2007 Downstream Communication Deliver messages from client > server > base station node to a node in the network Used for Command and acknowledgement delivery Base Mote Node sends to next hop found in its downstream table Server Client e2e Ack

WSN Training: XMesh Services14 Feb 2007 Downstream Use Cases Send from the base station mote: call XMesh downstream service APIs. Send from a server that is connected to a base station mote 1.Constructs the TOS_Msg packet on the server side, according to the API requirement. 2.Send the packet to the base station mote

WSN Training: XMesh Services15 Feb 2007 Send from the base mote: Downstream no Ack API nesC Wiring AppM.MhopSend -> XMeshRouter.MhopSend[appID]; Call the send command call Send.send ( Downstream_node_id, MODE_DOWNSTREAM, &gMsgBuffer, sizeof(DownStream_t); Implement the sendDone event: event result_t Send.sendDone(TOS_MsgPtr pMsg, result_t success) { // clear your flag here return SUCCESS; }

WSN Training: XMesh Services16 Feb 2007 Send from the Basestation Mote: Downstream Ack API nesC Wiring AppM.MhopSend -> XMeshRouter.MhopSend[appID]; AppM.RcvAck -> XMeshRouter.ReceiveAck[appID]; Call the send command call Send.send(remote_node_id, MODE_DOWNSTREAM_ACK, &gMsgBuffer, sizeof(DownStream_t); Start a timer in sendDone event event result_t Send.sendDone(TOS_MsgPtr pMsg, result_t success) { call TimerAck.start(TIMER_ONE_SHOT, 20); //for HP stack return SUCCESS; }

WSN Training: XMesh Services17 Feb 2007 Send from the base mote: Downstream Ack API Receive the end2end Ack event TOS_MsgPtr RcvAck.receive (TOS_MsgPtr pMsg, void* payload, uint16_t payloadLen) { call TimerAck.stop(); // stop the timer return pMsg; } No end2end Ack received event result_t TimerAck.fired() { // make decision as whether to resend the packet // usually increment a counter here // and retry x numbers of time; if ( NUM_RETRY != num_retry++) { // send again } else { // reach retry limit num_retry = 0; } return SUCCESS; }

WSN Training: XMesh Services18 Feb 2007 Downstream Service API: Send From the Server Side Put the downstream node id to the address field of the TOS_Msg header  tos_msg.addr = downstream_id; Put 0x0C (downstream no ack) or 0x0E (downstream with ack) into the type field of the TOSMsg header  tos_msg.type = 0x0C; // sending downstream no ack Initialize length of the application payload  tos_msg.length = len; Copy application data to the packet  memcpy(&tos_msg.data, &app_data, len); Send to base mote  Send_to_serial(&tos_msg); // to serial port or serial forwarder

Feb 2007WSN Training: XMesh Services19 Lab: MyApp_MeshAck  Review Moteworks/apps/tutorials/lesson5  Add required end-to-end acknowledgement code  Deploy guaranteed delivery network  Analyze traffic using XSniffer

WSN Training: XMesh Services20 Feb 2007 Lab – MyApp_MeshAck Outline Write application to send upstream packet, requesting end- to-end ack  Use of XMesh UpstreamAck service wirings and APIs  Send data packet to base station every minutes, set end-2-end time out as 20 msec (XMesh hp), retransmit for up to 3 times. Test it with XMeshBase application  Use of XSniffer to visualize the data traffic.  Receive upstream packets via Xserve.

WSN Training: XMesh Services21 Feb 2007 Lab – MyApp_MeshAck - step 1 Prepare your application  Work on apps/tutorials/lesson_5  The following enhancements have been made:  Code modified to use the MOTE_UPSTREAM_ACK transport mode to request an acknowledgement back from the base station  Yellow LED toggles when an acknowledgement message is received back from the base station  Please note that we have intentionally taken out the end2end retransmission code, it is part of your exercise to fill in the time- out based retransmission.  Hints: 1.Start a one-shot timer at the sendDone event 2.Stop the timer at the reception of the end2end packet 3.Schedule retransmission at the timer.fired event

WSN Training: XMesh Services22 Feb 2007 Lab: MyApp_MeshAck MyApp_MeshAck.nc  The ReceiveAck interface is required to implement an event callback function that will be generated by XMesh when the acknowledgment message has arrived from the base station. configuration MyApp_MeshAck { } implementation { //… MyApp_MeshAckM.RouteControl -> MULTIHOPROUTER; MyApp_MeshAckM.Send -> MULTIHOPROUTER.MhopSend[AM_XMULTIHOP_MSG]; MyApp_MeshAckM.ReceiveAck -> MULTIHOPROUTER.ReceiveAck[AM_XMULTIHOP_MSG]; MULTIHOPROUTER.ReceiveMsg[AM_XMULTIHOP_MSG] -> Comm.ReceiveMsg[AM_XMULTIHOP_MSG]; } The only change to the configuration file is the addition of the ReceiveAck interface wiring.

WSN Training: XMesh Services23 Feb 2007 Lab: MyApp_MeshAck MyApp_MeshAckM.nc  The first change is the transport mode of MODE_UPSTREAM_ACK. This tells XMesh to send an acknowledgement message back to the message originator when the message is received at the base station.  The second change is the addition of the ReceiveAck.receive event function. This is the event called by XMesh when the acknowledgement message has arrived from the base station for the most recently sent message. The yellow LED is toggled upon receiving this acknowledgment message. void task SendData() { … if (call Send.send(BASE_STATION_ADDRESS, MODE_UPSTREAM_ACK, &msg_buffer, sizeof(XDataMsg)) != SUCCESS) … event TOS_MsgPtr ReceiveAck.receive(TOS_MsgPtr pMsg, void* payload, uint16_t payloadLen) { call Leds.yellowToggle(); … Add handling of end-to-end acknowledgement received from base station. Switch service type to MODE_UPSTREAM_ACK

WSN Training: XMesh Services24 Feb 2007 Lab – MyApp_MeshAck - step 2 1.Compile with designated radio frequency in MakeXbowlocal and typing make Or by typing make route,hp 2.Program the remote nodes with lesson5 by typing make reinstall,1, 3.Compile and program a separate base station with XMeshBase by typing make install,0,

WSN Training: XMesh Services25 Feb 2007 Lab – MyApp_MeshAck - step 3 Prepare the base station application with XMeshBase in apps/XMesh/XMeshBase  Compile the code by typing make base route,hp freq,x  Program the base station by typing make reinstall.0,

WSN Training: XMesh Services26 Feb 2007 Lab – MyApp_MeshAck, Step 4 Visualize the traffic in the Mesh: Use the XSniffer GUI.  Program a mote with application (TOSBase) found in MoteWorks/apps/general/XSniffer.  Start XSniffer GUI, connect it to the gateway board with the XSniffer (i.e., TOSBase) mote. Receive upstream packet from your PC  Start XServe  Connect it to the base station mote.

WSN Training: XMesh Services27 Feb 2007 XSniffer Color Coding Packets are colored by type  Upstream data = blue  AckDwn = turquoise Also note for next lab  Health = orange

Feb 2007WSN Training: XMesh Services28 XMesh Services Objectives:  Health statistics  ELP  Lab: View health packets in XSniffer

WSN Training: XMesh Services29 Feb 2007 Health Statistics Health Packet  Sensor network health monitoring  Field debugging Can be configured to send out periodic health packets  Application can enable/disable the health packet on the fly  Default health packet interval is 60 seconds for high power, 10 minutes for low power.  API usage  To enable health packet, set health packet interval to 60 seconds call health_packet(TRUE, 60);  To disable health packet call health_packet(FALSE, 60);

WSN Training: XMesh Services30 Feb 2007 Health Packet types Two types of health packets 1.Neighbor health  Contains RSSI, link quality, cost of each neighbor etc 2.Statistics health  Contains the following information:  number of packets generated locally  number of packets forwarded  number of packets dropped  number of packets retransmitted  voltage reading  sequence number

WSN Training: XMesh Services31 Feb 2007 Health Packet Interval Only one health packet is sent every interval Alternates between statistics packet and neighbor packet Then neighborhood packets cycle through neighbor list until all neighbors in table are described. Defaults:  Each neighborhood packet has room for three (3) neighbors  Neighborhood table has fifteen (15) entries. Health Int Statistics Pkt Neigh Statistics Pkt

WSN Training: XMesh Services32 Feb 2007 Health Packet Structure Health Packet Header Bytes: 50/ TinyOS Header XMesh Header XHealth Header type_nodeversiontype…CRC Health Payload Data Fields Description uint8_t type_nodeThis is for backward compatibility. The value of the first 4 bits for XMesh2 will always be 0xF. Any other value means this is an XMesh1 health packet. uint8_t versionThis is the health packet version number. In XMesh2 the version number is 0x20 uint16_t typeThe value of this field indicates if the packet is a statistics packet or a neighbor packet. Statistic packets have a type of 0x01 and neighbor packets have a type of 0x02

WSN Training: XMesh Services33 Feb 2007 Health Payload – Statistics Packet TypeData FieldsDescription uint16_t seq_numThis is the sequence number of the health packet. uint16_t num_node_pktsNumber of application packets that have been generated locally. uint16_t num_fwd_pktsNumber of radio packets that the mote has forwarded in the mesh. uint16_t num_drop_pktsNumber of radio packets that the mote has dropped due to failed link level retransmissions. uint16_t num_rexmitsThis is the number of times that the message was re-transmitted. uint8_t battery_voltageBattery reading. uint16_t power_sumPower statistics for the low power radio stack (not used) uint8_t rsvd_app_typeReserved Crossbow field for identifying sending application. hn_quality nodeinfoA record containing information about the link to the present parent uint16_t node_id Parent’s ID uint8_t link_quality Link quality to parent (high 4 bits send quality and low 4 bits receive quality). uint8_t hop_count The number of hops the parent is from the base station uint8_t radio_link_indicator The rssi or lqi value of the parent

WSN Training: XMesh Services34 Feb 2007 Neighborhood Health Packet TypeData Fields Description uint8_t type_node This field is in the Health header. The bottom 4 bits will contain the number of neighbors sent in the packet. hn_quality nodeinfoRecords containing information about the link quality of the neighbor. Each record consist of the following elements: uint16_t node_id Parent’s ID uint8_t link_quality Link quality normalized to 255 (100%). 100% indicates that both the parent and child hear 100% of each other’s messages. uint8_t path_cost Hop count uint8_t radio_link_indicator The rssi or lqi value of the parent

Feb 2007WSN Training: XMesh Services35 XMesh Services Objectives:  Health statistics  ELP  Lab: View health packets in XSniffer

WSN Training: XMesh Services36 Feb 2007 ELP (Extended Low Power) Locate at the edge of the mesh and sleep most of the time  Need to have a high power node as its parent  Conceptually similar to RFD in ZigBee  50  A on average Doesn’t participate in the routing and forwarding  Not forwarding packets  Broadcast cost as infinity so no one else chooses it as parent

WSN Training: XMesh Services37 Feb 2007 Hybrid Star Network with ELP XMesh network using High Power mode for nodes that make up the backbone and Extended Low Power mode for nodes along the edge.

WSN Training: XMesh Services38 Feb 2007 ELP Operational Theory  Use health packet to keep in touch with the base station  User has full control on sleep duration (via API)

WSN Training: XMesh Services39 Feb 2007 ELP Interfaces ElpControlI interface  enable() Enables ELP mode  disable() Disables ELP mode  isActive() Query if in ELP mode ElpI Interface  route_discover(uint8_t rui) Join within given # of route updates  route_discover_done (bool success, uint16_t parent) Returns result of join attempt  wake() Wake a node into full power  wake_done() Signals node leaves ELP mode  sleep( uint16_t duration, Sleep an ELP node uint16_t health_interval, uint8_t iRetries, uint8_t force_sleep)  sleep_done() Signals sleep interval is over

WSN Training: XMesh Services40 Feb 2007 ELP Operational Theory (cont.)

Feb 2007WSN Training: XMesh Services41 XMesh Services Objectives:  Health statistics  ELP  Lab: View health packets in XSniffer

WSN Training: XMesh Services42 Feb 2007 Lab: Health Packet Start with MoteWorks/apps/examples/XMeshCountsToLeds Enabling Health Packets XMesh exports a command called health_packet that enables health packet reporting during run time: command void health_packet(bool enable, uint16_t interval); if enable is TRUE, the health packet will be sent out periodically every interval seconds. Interval is usually set to several minutes in order not to impact the overall mesh message rate. Typical values for interval are: XMesh-HP : 1 minute or more XMesh-LP : 10 minutes or more

WSN Training: XMesh Services43 Feb 2007 Lab: Health Packet -- Overview  EXAMPLE // In the App.nc wiring file add: AppM.health_packet -> XMeshRouter; //In AppM.nc, the user can enable the // health packet reporting: // in the AppM.nc uses{ section add: command void health_packet (bool enable, uint16_t intv); // in the AppM.StdControl.start section add: call health_packet(TRUE, 600); // 10 min interval // This will disable the health packet reporting: call health_packet(FALSE,0);

WSN Training: XMesh Services44 Feb 2007 Lab: Health Packet – XMeshCountToLedsM.nc XMeshCountToLedsM.nc  Sends health packet every 30 seconds.  StdControl.start includes code to initiate this  call health_packet(TRUE,30); XMeshCountToLeds.nc  Includes line to wire health_packet command to XMeshRouter  XMeshCountToLedsM.health_packet -> MULTIHOPROUTER;. module XMeshCountToLedsM { provides{ interface StdControl; } uses { interface Timer; interface Leds; interface MhopSend; command void health_packet(bool enable, uint16_t intv); } Application must add the command to control health_packet to the specification block.

WSN Training: XMesh Services45 Feb 2007 Lab: Health Packet Prepare the Network 1.Compile MoteWorks/apps/examples/XMeshCountsToLeds 2.Flash XMeshCountsToLeds to Node 1 3.Compile and Flash XMeshBase to Node 0 4.Compile and Flash XSniffer to a third Node View the Health Packets 5.Open XSniffer GUI and view health packets Other things to try 6.Open XServe and view health packets via XMeshBase

WSN Training: XMesh Services46 Feb 2007 Lab: Health Packet Use XSniffer GUI through xserve 1.Keep XSniffer node on gateway 2.Connect xserve to gateway. Note: sniffer firmware is at higher baud rate  Using MIB510 type: xserve –s=COM# -b=  Using MIB600 type: xserve-i=#.#.#.#  View data via xserve 3.Connect XSniffer GUI to xserve  Select TCP/IP Socket connection  Set host to localhost  Set port to 9001  Click CONNECT  View packets in GUI

Feb 2007WSN Training: XMesh Services47 Q & A: XMesh Advanced Services Objectives:  Understand XMesh transport services 1.Upstream 2.Upstream with end-to-end acknowledgement 3.Downstream 4.Downstream with end-to-end acknowledgement  Lab: Guaranteed QoS with upstream ack  XMesh Health Packets  Extended Low Power Mode (ELP)  Lab: Health Packet