11/4/08 Target Environment • Heterogeneous sensors Tiny Web Services: • Deployment in an enclosed area Design and Implementa=on of Interoperable and Evolvable Sensor Networks – All sensors within a few hops of the gateway – E.g., office, home, warehouse • Mul=ple co‐exis=ng sensing tasks Nissanka Priyantha, Aman Kansal, Michel Goraczk, Feng Zhao Sensys 2008 Presented by Chien‐Liang Fok for CSE 521S, Fall 2008 2 Example Applica=on Problem • Home energy consump=on management • Current WSNs use proprietary protocols and message formats • The United States in 2001: – Gateway cannot expose new node func=onali=es – 107 million residen=al homes • Prohibits – 21.86 quadrillion (10 15 ) Btu consumed – evolu=onary WSNs – $157.5 billion • WSN can help op=mize energy consump=on – addi=on of end‐user applica=ons – “Evolu=onary deployment” needed for cost effec=veness 3 4 Solu=on Two Fundamental Requirements • Provide an API such that all sensors are • Structured Data available to all applica=ons – Sensor data must be understood by applica=ons – E.g., XML • Programma=c descrip=on of func=onality – Func=onality of sensor node must be automa=cally understood by programs – Enables programs to adapt • Increases cost‐effec=veness of WSN 5 6 1
11/4/08 Exis=ng Solu=on: Web Services Advantages of using Web Services • Access remote resources as if they were local • Support evolving systems • Interoperability – Float temperature = GetTemperature(string Location) • Improved system programmability • Used on the Internet • Ease of integra=on with enterprise systems via • Structured data: web method call the Internet • Func=onality descrip=on: web service descrip=on 7 8 Research Goals Research Non‐Goals • Quan=fy cost of providing web services in • Simplify programming of WSN nodes WSNs – May use exis=ng tools like TinyOS and SOS • Enumerate design op=ons and tradeoffs – Only requires a web service interface and WSDL descrip=on – Iden=fy op=mal configura=on for WSNs • Restrict in‐network processing • Implement the system – Method calls may s=ll result in mul=ple nodes – Efficiency collabora=ng • Simplify applica=on programming – May use any protocol (including proprietary ones) – Use exis=ng web service development tools 9 10 Sources of Overhead TCP/IP Design • The network layer (IP) • Overhead between WSN node and PC: • The transport layer (TCP) • The applica=on layer (web services) • TCP message latencies: 11 TCP Retransmission TCP 2
11/4/08 TCP/IP Op=miza=ons Duty Cycling Nodes – Persistent TCP connec=ons • Many sensors can be event driven • 25ms savings – IR‐based mo=on sensor, glass‐break detectors, – Disabled delayed TCP door intrusion sensors, smoke sensors, etc. acknowledgements • Duty‐cycle these nodes to increase efficiency • 200ms savings • Use web service even=ng: – Link Layer re‐transmissions • 2900ms savings TCP without delayed ACK – Low‐power mode between TCP messages – 6lowpan & link layer fragmenta=on 13 14 Web Service Method Encapsula=on Accessing a Service • Web Service Descrip=on Language supports • HTTP GET three protocols: – E.g., hkp://192.168.1.4/setTemp?temp=25 • URL Replacement – SOAP, HTTP, and MIME • SOAP is the de‐facto standard, but too costly: – E.g., hkp://192.168.1.4/setTemp/temp/25 • XML Post – Send an XML message with method name and parameters • Tiny Web Services uses the first two because they • TinyWebServices use HTTP are less verbose and require a simpler interpreter 15 16 XML on WSN Nodes Evalua=on Testbed Planorm • Implement custom node‐specific parser to conserve memory – Only parses expected “simple” messages – Transparent to client applica=on • MSP430F1611 processor, 6MHz, 48K ROM, • Compress XML messages 10K RAM • CC2420 IEEE 802.15.4 radio, 250kbps • μIP TCP/IP stack 17 18 3
11/4/08 Evalu=on Testbed Configura=on Message Comm. and Processing Time • Fine granularity =ming measurements • Processing =me: • Hard‐wire connec=ons to =ming node – First TCP packet: 10.67‐9.68 = 0.99ms – Second TCP packet: 36.35 – 35.53 = 0.82ms 19 20 Energy Cost Response Time • Incremental cost of web services is low • Cost is higher as message frequency increases • Response =me not significantly affected by – Home energy mgmt applica=on uses messaging request size, so long as it fits in one packet periods between 10‐100 minutes 21 22 System Implementa=on Memory Consump=on • Power sensor node: • Home energy management applica=on • 12 day deployment • Client applica=ons wriken using Visual Studio or Net Beans IDE • Can easily fit on MSP430 • Uses sensors typical of security and medical alert applica=ons 23 24 4
11/4/08 The Smart Socket Sensor Data from Home Deployment • WSN node has Smart Socket for controlling • From volunteer family power to device • Time axis omiked to protect privacy • Applica=on uses data from mul=ple sensors to determine home occupancy 25 26 Energy Savings Results Remaining Challenges • Sleep modes – Persistent TCP and even=ng supports sleep modes – Must ensure network‐layer services are not broken by sleep modes • Mesh overheads – All results are on single‐hop wireless network • Security • Lower temperature when home not occupied – Need to secure the system • Total energy consump=on reduc=on was 7.2% 27 28 Conclusions Ports and Binding • Two key components of web services • Web services can be op=mized for use in WSNs • Ports – Applica=on layer func=onali=es that are provided – Supports evolvable systems – E.g., callable methods – Enables interoperability • Binding – Overhead is not significant – The network protocols that are supported – E.g., SOAP • Both are specified using web service descrip=on language (WSDL) 29 30 5
Recommend
More recommend
