1 / 53

Reliable Transmissions in Large Scale Sensor Networks for Medical Monitoring Applications

Reliable Transmissions in Large Scale Sensor Networks for Medical Monitoring Applications. 曾俊元 C. Henry Tseng. Academia Experience. Degree University of California, Davis, PhD in Computer Science, 2006 Current position NTPU CSIE, Assistant Professor, 2009~

misae
Télécharger la présentation

Reliable Transmissions in Large Scale Sensor Networks for Medical Monitoring Applications

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. Reliable Transmissions in Large Scale Sensor Networks for Medical Monitoring Applications 曾俊元 C. Henry Tseng

  2. Academia Experience • Degree • University of California, Davis, PhD in Computer Science, 2006 • Current position • NTPU CSIE, Assistant Professor, 2009~ • NTPU Information Center, Section Chief of System, 2012~ • Experience • NTPU MIS, Joint Appointment Asst. Prof., 2010~2011 • NTPU Office of R&D, Section Chief of Planning, 2010~2011

  3. Industrial Experience • Telcordia Taiwan Research Center, 2009 • Senior Research Scientist • Telmatics projects with III & ITRI • Cisco Systems Inc., 2006~2008 • Software Engineer III, IOS OSPF Developer • Core Campus, San Jose, CA, USA • McAFee Software Engineer, 2001 • IntruShield IDS prototype development

  4. Security research topics • Past • Intrusion detection for MANET Routing • Malicious Domain name detection • Current • Rootkit detection & prevention • Malware sample collection, analysis & evaluation • Automation for web logs of intrusions • HoneyPod of SQL injection attacks • Future • Online game anti-bot detection & prevention at server side

  5. Outline of Zigbee research • Zigbeestack • Issues of Zigbee stack • Solutions • New monitoring applications

  6. 1. Zigbee Stack • 1.1 Introduction • 1.2 Applications

  7. Overview • Zigbeenetwork • Nodes：Coordinator, Router, End device • PAN: Personal Area Network • End devices send sensor data to Coordinator • Coordinator forwards data to sink node (backend data server)

  8. Zigbee Sample network S Sink C Coordinator R S R End devices R C R R Router Data

  9. PAN address • Join PAN • Coordinator broadcasts joining messages with its PAN ID • Routers join PAN and forward the joining messages • End devices join PAN by forwarded messages • PAN address assignment • Network address of Zigbee stack • Coordinator’s PAN address is always “0” • Coordinator assigns others’ PAN addresses in random

  10. Sensor data delivery • Zigbee stack layers • MAC: IEEE 802.15.4 • Network: Mesh routing, a modified version of AODV • APS: application sub-layer, management of application data transmission • Data delivery • End devices(EDs) transfer data to Coordinator periodically • Each ED builds a “binding” for data transmission session • ED can support multiple sensors by “End Point”, which is similar with port in TCP

  11. Reliable transferring • Acknowledgement • MAC ACK • APS ACK • MAC ACK • Each link transmission requires a MAC ACK • Ensure reliability of each wireless link transmission • APS • Each remote transmission of a binding requires a APS ACK • Ensure reliability of each remote transferring • Independent from MAC ACK

  12. Example data delivery Coordinator End Device Router [3] Send the data [1] Send the data [2] MAC ACK [4] MAC ACK [7] APS ACK [5] APS ACK [8] MAC ACK [6] MAC ACK

  13. 1. Zigbee Stack • 1.1 Introduction • 1.2 Applications

  14. 1.2 Capabilities for applications • Light weight sensor data collection • Usually < 1 k bps • Transmission radio power: 0 dbm • Theoretical speed 250 k bps • Realistic max speed without lost in one hop: 20 k bps • Support wide range of data collection • Each PAN can support a large Mesh topology with several hops of network dialog • Transmission reliability reduces a lot while forwarding 2 or more hop away: max speed becomes < 15 k bps for 2 hop • Indoor obstacles effect the performance a lot

  15. Implementation • TI CC2530 embedded system • Enhanced 8051, 256k flash memory • 8 bit CPU with 32 M Hz speed • Support RS232 UR connection to PC/NB • Modified version for USB & Bluetooth connections • Very small, low power consumption, low ratio power • Software development environment • IAR for firmware development • Sample development codes for applications • Codes of APS and NWK layers can be modified

  16. Current applications • Temperature • Green house, Fish farm • Light control • Digital home • Medical data monitoring • Temperature • Pulse of human blood system • Wearable medical device • Body sensor network

  17. 2. Issues of Zigbee stack • 2.1 Limitation of Coordinator • 2.2 Transport Layer • 2.3 Load balance • 2.4 Scalability

  18. Role of Coordinator • PAN management • Coordinator (CO) must be unique in a PAN • Node joining relies on CO • IEEE802.15.4 can hardly be modified • Data transmission • EDs send data to CO by default • Manual binding setting is costly • Failure of CO

  19. Failure of CO • PAN network services collapse • PAN management fails • Data transmission may completely stop • No solution for CO failure • A PAN cannot have 2 COs • No automatic solution

  20. 2. Issues of Zigbee stack • 2.1 Limitation of Coordinator • 2.2 Transport Layer • 2.3 Load balance • 2.4 Scalability

  21. Transport Layer • Included functions in APS • ACK service • Binding • End port • ID of data packet • Between UDP & TCP • UDP is too simple • TCP is too heavy for Zigbee • Sufficient but limited functions

  22. New demands • Issues • Cannot send a large data message • No flow control • Resent times is fixed (3 times) • RTT is fixed • Desirable functions • Data fragmentation & re-assembling • Receive window • Enhanced timeout & resending strategy • Sequence number

  23. 2. Issues of Zigbee stack • 2.1 Limitation of Coordinator • 2.2 Transport Layer • 2.3 Load balance • 2.4 Scalability

  24. Load Balance • First ring nodes • Nodes directly connected to Sink or Coordinator • Can directly forward data to Sink or Coordinator • Usually accumulate large amount of data traffic • Can be network bottleneck or die out easily • Balancing traffic of whole PAN • Local balance vs. global balance

  25. Flow control • Sending rate control • Queuing delay grows exponentially • Signal interference also grows exponentially • Limit the sending rate to avoid traffic jamming • Find out the upper bound dynamically • Top down vs. bottom up • Data sending behavior is bottom up approach • PAN management is top down approach • Both approaches should be used in different aspects

  26. 2. Issues of Zigbee stack • 2.1 Limitation of Coordinator • 2.2 Transport Layer • 2.3 Load balance • 2.4 Scalability

  27. Scalability • Old Tree based approach • Can support limited global routing optimization • Support only several dozens of node • New mesh topology • Same as MANET routing • Can support up to 200 nodes • Still need a new hierarchical routing control for large networks

  28. Measure metrics • Number of nodes • Tree level • Topology dialog • Node density • Number of neighbors • Routing load • Signal interference

  29. 3. Solutions • 3.1 CDTS • 3.2 Backup Coordinator

  30. Coordinator Data Traffic Shunt (CDTS) • CDTS Router • Helper node of Coordinator traffic forwarding • Connect sink node with Direct Communication Link (DCL) • RS232, Bluetooth, USB • CDTS Group • CDTS routers nearby the sink node • Absorb traffic toward the sink node without going through Coordinator

  31. Example Topology

  32. CDTS Layer • Low cost design • Insert a layer between NWK & MAC layer • Require modification in CDTS router only • Maximize compatibility • No modification of Coordinator, applications, end devices, routers • No modification of MAC layer, IEEE 802.15.4 • Slight medication of NWK layer

  33. Address modification CDTS layer in Zigbeestack Address Modification

  34. CDTSrouter Reuse APS functions End-device [1] Send the data [2] APS ACK CDTS

  35. Experiments • Embedded system • TI CC2530 development board • Simple topology: • ED->R->C->Sink • ED->R->CDTS Router->Sink • Use real ECG medical sample data as testing network traffic • Ns2 • Testing in large scale node topology • Tests of several ED traffic flows

  36. Deliver ratio vs. Sending rate threshold 80% Embedded system

  37. Coordinator loading vs. Sending rate 60% Embedded system

  38. Deliver ratio vs. number of nodes 80%

  39. Achievement • TBME • ChinyangHenry Tseng, "Coordinator Traffic Diffusion for Data-Intensive Zigbee Transmission in Real-time Electrocardiography Monitoring", IEEE Transactions on Biomedical Engineering, to appear. • ICS 2012 • Chinyang Henry Tseng, ShiauHuey Wang, Bor-Shing Lin, Tong-Ying Junag, Xiao-RuJi, "CDTS: Coordinator Data Traffic Shunt model for Zigbee networks", International Computer Symposium (ICS 2012)

  40. 3. Solutions • 3.1 CDTS • 3.2 Backup Coordinator

  41. Back Coordinator • Back Coordinator group • BC1, BC2, … • Compatible with CDTS group • Automatic Coordinator recovery • Monitoring Coordinator network status • Detection of Coordinator failure • Replace Coordinator automatically

  42. Problem statement R Bc2 Bc1 sink node E E E E E E coordinator Bc E E S other Bc Backup Coordinator Group C Bc1 R Bc2 BC router Backup Coordinator 2 Backup Coordinator 1

  43. Coordinator recovery E E E E E E E E S Backup Coordinator Group R Bc1 Bc1 Bc2 R C Bc2 Bc1

  44. 3.2 Coordinator monitoring • Binding • BC1 actively build a binding with Coordinator • Once the binding is close, Coordinator malfunctions • Listen • BC1 passively listen to beacons sent by Coordinator • If Coordinator does not send beacons, Coordinator fails to operate

  45. Coordinator recovery steps • BC1 -> C • Change its setting as Coordinator • Execute Coordinator mechanisms • No need of rebooting the firmware • Modification requirements • Only in BC • APS for Coordinator monitoring • NWK for Coordinator mechanism re-establishment

  46. Sensor data sending issue • Bindings of sensor data sending • End devices send sensor data to Coordinator by default • Coordinator has lots of bindings with end devices for sensor data retrieving • If Coordinator fails to operate • Bindings are broken • No more sensor data retrieving • End devices have to re-build new bindings manually by default

  47. Automatic data traffic recovery • Re-connect with new Coordinator • End devices require updating Coordinator info • Automatically maintenance of bindings with the Coordinator • Recovery steps • New Coordinator floods its new info to entire PAN • End devices receive flooding messages from new Coordinator • End devices update its Coordinator info, including the bindings

  48. Recovery time of data binding Recovery of Data binding Binding : 669 ms Failure of Coordinator • Listen-15(sec) :15400 (ms)

  49. Recovery time (Binding vs. Listen)

  50. Achievement • Advantech Co. • They are highly interested in this work • Patent • Should be done soon • Paper • Journal paper submission will be done this year

More Related