1 / 71

CSE 535 – Mobile Computing Lecture 4: Wireless Networking – Mobile IP and Power Issues in WSN

CSE 535 – Mobile Computing Lecture 4: Wireless Networking – Mobile IP and Power Issues in WSN. Sandeep K. S. Gupta School of Computing and Informatics Arizona State University. Based on Slides by Prof. Richard, UNO and Dave Culler, UC Berkeley. Agenda and Reading from Book.

kimama
Télécharger la présentation

CSE 535 – Mobile Computing Lecture 4: Wireless Networking – Mobile IP and Power Issues in WSN

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. CSE 535 – Mobile ComputingLecture 4: Wireless Networking – Mobile IP and Power Issues in WSN Sandeep K. S. Gupta School of Computing and Informatics Arizona State University Based on Slides by Prof. Richard, UNO and Dave Culler, UC Berkeley

  2. Agenda and Reading from Book Wireless Networking Mobile IP (Sec. 2.3.2 page 50) WSN – Power Issues Remember Ch8-11 in book are on WSN Appending A is on Wireless Communication and Networking – some useful equations on relationship between transimission power and maximum range.

  3. Wireless Networking: Systems Issues • It’s not all about the hardware • Extensions to support mobility • Mobile IP • Wireless network protocols • Primarily hacking TCP • Brief review of TCP, then what breaks under wireless • Without mobility • With mobility • This sets the stage..then we’ll look at the theory behind location management in detail

  4. TCP/IP Issues Application Layer Telnet, FTP, etc. Transport Layer TCP, UDP Network Layer IP Link Layer

  5. Why Mobile IP? • Need a protocol which allows network connectivity across host movement • Protocol to enable mobility must not require massive changes to router software, etc. • Must be compatible with large installed base of IPv4 networks/hosts • Confine changes to mobile hosts and a few support hosts which enable mobility • Just hacking DNS won’t work • DNS updates take time • Hooks for normal users to update DNS won’t be accepted by administrators • After DNS lookup, raw IP address is used by TCP, UDP, …

  6. Mobile IP Discussion Overview • Will cover: • Why IP routing breaks under mobility • Mobile IPv4 basics • Some Mobile IP security issues • Won't cover: • Details of IP routing • IPv6 in detail • Low-level protocol details (message formats, headers, etc.) • All of the Mobile IP-related security issues • Lots more detail in the specifications

  7. Internet Protocol (IP) • Network layer, "best-effort" packet delivery • Supports UDP and TCP (transport layer protocols) • IP host addresses consist of two parts • network id + host id • By design, IP host address is tied to home network address • Hosts are assumed to be wired, immobile • Intermediate routers look only at network address • Mobility without a change in IP address results inun-route-able packets

  8. IP Routing Breaks Under Mobility .50 .52 .53 router 137.30.2.* .200 router 139.20.3.* Why this hierarchical approach? Answer: Scalability! Millions of network addresses, billions of hosts!

  9. Mobile IP: Basics • Proposed by IETF (Internet Engineering Task Force) • Standards development body for the Internet • Mobile IP allows a mobile host to move about without changing its permanentIP address • Each mobile host has a home agenton its home network • Foreign agents on remote networks also assist • Mobile host establishes a care-of address when it's away from home

  10. Mobile IP: Basics (2) • Correspondent host is a host that wants to send packets to the mobile host • Correspondent host sends packets to the mobile host’s IP permanent address • These packets are routed to the mobile host’s home network • Home agent forwards IP packets for mobile host to current care-of address • Mobile host sends packets directly to correspondent, using permanent home IP as source IP

  11. IP header IP header data data Aside: IP-in-IP Tunneling • Packet to be forwarded is encapsulated in a new IP packet • See RFC 2003 for details • In the new header: • Destination = care-of-address • Source = address of home agent • Protocol number = IP-in-IP IP header data area

  12. Mobile IP: Basics (3) Home LAN correspondent host home agent

  13. Protocol Messages • Extensions to ICMP • Agent advertisement • “I’m a foreign agent…” • “I’m a home agent” • Agent advertisements seen by mobile hosts on their home network welcome them back…home • Agent solicitation • Mobile host actively seeks foreign agent • Elicits agent advertisement message

  14. Protocol Messages (2) • Registration Request • Sent to home agent • New IP address • Flags to indicate whether broadcast traffic should be delivered • Security information to prevent remote redirects/replay attacks (more soon) • Registration Reply • ACK or an error

  15. Mobile IP: Care-of Addresses • Whenever a mobile host connects to a remote network, two choices: • care-of can be the address of a foreign agenton the remote network • foreign agent delivers packets forwarded from home agent to mobile host • care-of can be a temporary, foreign IP address obtained through, e.g., DHCP • home agent tunnels packets directly to the temporary IP address • Regardless, care-of address must be registered with home agent

  16. At the Other End... • Depending on type of care-of address: • Foreign agent’s IP or • Mobile host’s IP (obtained via DHCP) • … someone strips outer IP header of tunneled packet, which is then fed to the mobile host • Decapsulation can be performed by agent or mobile host • Aside: Any thoughts on advantages of foreign agent vs. co-located (using foreign agent’s IP) address? • Which has less overhead for mobile host? • Which consumes fewer IP addresses (still a concern with IPv4)?

  17. Routing Inefficiency Mobile host and correspondent host might even be on the same network!! correspondent host home agent

  18. Route Optimizations • Possible Solution: • Home agent sends current care-of address to correspondent host • Correspondent host caches care-of address • Future packets tunneled directly to care-of address • Problems when mobile host moves… • Care of address becomes stale, needs to be updated • Requires that correspondent hosts understand Mobile-IP • Requires security relationship between correspondent hosts and home agent of roaming mobile host

  19. The Devil is in the Details... • How does the mobile host get a remote IP? • Router advertisements, DHCP, manual... • Agent advertisement if remote network is Mobile-IP enabled • How can a mobile host tell where it is? • Am I at home? • Am I visiting a foreign network? • Have I moved? • One way: by listening for advertisements from its home agents • Presence indicates home • Absence tends to indicate not home…

  20. Devil (2) • Redundancy: What if the home agent doesn't answer a registration request? Or is dead? • Registration request to broadcast address of home network • All available home agents will hear and reply, but will reject service because message received via broadcast • Error in Registration Reply (a rejection) carries new home agent ID • Now can request help from a specific new home agent • "Ingress" filtering • Routers which see packets coming from a direction from which they would not have routed the source address are dropped

  21. Packets Dropped: "Ingress" Filtering Correspondent, home agent on same network. Packet from mobile host is deemed "topologically incorrect“ correspondent host home agent

  22. Another Devil: Security Issues • We'll look at one of several security issues: • Bogus registration (denial of service) attacks • Malicious host sends fake registration messages to home agent "on behalf" of the mobile host • Packets could be forwarded to malicious host or to the bit bucket

  23. Bogus Registration Attack ???? Send packets to me!! Hehehehe!! registration request Madame Evil home agent

  24. Authentication • To fix this problem, authenticate registration attempts • Use keyed message hashing to generate a message digest • MD5: see RFC 1321 • Home agent generates hash using shared private key to message to see if message digest is identical

  25. … care-of address… digest ??? Authentication (2) private key home agent

  26. digest Ooops. Replay Attacks! home agent captured registration is retransmitted "…mooohahahahahahahaha!!!!!"

  27. Avoiding Replay Attacks • Avoid replay attacks by making registration requests unique • Add time or a pseudo-random number to registration request/reply • If time or random number is out of sync, provide info to resync in rejection • Insufficient information to help malicious host • Counter instead of time/random number not as good • Would allow storing a ‘set’ of registration requests

  28. … care-of address + random number... digest ??? Random Number Avoids Replay private key home agent

  29. Deployment Scenarios

  30. Another Devil: ARP • Address Resolution Protocol • Allows hosts to broadcast an IP address and retrieve the MAC address of the host • Home agent must perform “proxy ARP” for registered mobile hosts that are away • Home agent must perform “gratuitous ARPs” when mobile host leaves home network to update ARP caches of local hosts • Mobile agent, on returning home, must issue gratuitous ARPs for the same reason

  31. Mobile IP: Conclusions... • Great potential for mobile application deployment using Mobile IP • Minimizes impact on existing Internet infrastructure • Security issues are important • (Complicated) firewall solutions proposed • Several working implementations (e.g., Monarch project at CMU) • Some things still need work: e.g., integration of Mobile IP and 802.11 wireless LANs

  32. Power Issues in Wireless Sensor Nets Bas ed: David Culler University of California, Berkeley http://www.cs.berkeley.edu/~culler Sandeep K. S. Gupta

  33. Outline • Basic model of operation • Node Design a for low power consumption • Operating System Issues • Design of the power-supply subsystem • MAC-level network design for power • Higher-level network design for power • Application level • Important areas of development • Discussion

  34. WakeUP WakeUP Work Work Sleep Sleep Duty Cycle Model of operation Active Active • Sleep – Active [Wakeup / Work] • Peak Power • Essentially sum of subsystem components • MW in supercomputer, kW in server, Watts in PDA • milliwatts in “mote” class device • Sleep power • Minimal running components + leakage • Microwatts in mote-class • Average power • Pave = = (1-factive)*Psleep + factive*Pactive • Pave=fsleep*Psleep + fwakeup*Pwakeup+ fwork*Pwork • Lifetime • EnergyStore / (Pave - Pgen )

  35. Passive Vigilance • Sense only when there is something useful to detect • Listen only when there is something useful to hear • How do you know? • By arrangement • By cascade of lower power triggers

  36. Mote Power Parameters • 1s Microwatts sleep • 10s of milliwatts active (wakeup or work) • Wakeup substantial • Milliseconds (1000s of instructions) • 1% Duty Cycle is common • Wakeup matters

  37. Batteries • Still the best energy store • Issues • Voltage • Source current • Leakage • Voltage profile • Recharge

  38. Design of a Low Power Node

  39. Sensor Interface analog sensors ADC digital sensors Data SRAM pgm EPROM Key Design Elements • Efficient wireless protocol primitives • Flexible sensor interface • Ultra-low power standby • Very Fast wakeup • Watchdog and Monitoring • Data SRAM is critical limiting resource Flash Storage timers proc data logs Wireless Net Interface antenna RF transceiver pgm images WD Wired Net Interface serial link USB,EN,… Low-power Standby & Wakeup

  40. Mote Platform Evolution 3

  41. Focused on low power Sleep - Majority of the time Telos: 2.4mA MicaZ: 30mA Wakeup As quickly as possible to process and return to sleep Telos: 290ns typical, 6ms max MicaZ: 60ms max internal oscillator, 4ms external Process Get your work done and get back to sleep Telos: 4MHz 16-bit MicaZ: 8MHz 8-bit TI MSP430 Ultra low power 1.6mA sleep 460mA active 1.8V operation Standards Based IEEE 802.15.4, USB IEEE 802.15.4 CC2420 radio 250kbps 2.4GHz ISM band TinyOS support New suite of radio stacks Pushing hardware abstraction Must conform to std link Ease of development and Test Program over USB Std connector header Interoperability Telos / MicaZ / ChipCon dev 802.15.4 Platforms UCB Telos Xbow MicaZ

  42. TinyOS-driven architecture • 3K RAM = 1.5 mm2 • CPU Core = 1mm2 • multithreaded • RF COMM stack = .5mm2 • HW assists for SW stack • Page mapping • SmartDust RADIO = .25 mm2 • SmartDust ADC 1/64 mm2 • I/O PADS • Expected sleep: 1 uW • 400+ years on AA • 150 uW per MHz • Radio: • .5mm2, -90dBm receive sensitivity • 1 mW power at 100Kbps • ADC: • 20 pJ/sample • 10 Ksamps/second = .2 uW.

  43. Microcontrollers • Memory starved • Far from Amdahl-Case 3M rule • Fairly uniform active inst per nJ • Faster MCUs generally a bit better • Improving with feature size • Min operating voltage • 1.8 volts => most of battery energy • 2.7 volts => lose half of battery energy • Standby power • Recently a substantial improvement • Probably due to design focus • Fundamentally SRAM leakage • Wake-up time is key • Trade sleep power for wake-up time • Memory restore DMA Support: permits ADC sampling while processor is sleeping

  44. Radio • Trade-offs: • resilience / performance => slow wake up • Wakeup vs interface level • Ability to optimize vs dedicated support

  45. Flash Technology • One write per bit per erase cycle • Flash characteristics: Not used in current motes

  46. WakeUP WakeUP Work Work Sleep Sleep Power States at Node Level Active Active

  47. msg_rec(type, data) msg_send_done) Tiny OS Concepts • Scheduler + Graph of Components • constrained two-level scheduling model: threads + events • Component: • Commands, • Event Handlers • Frame (storage) • Tasks (concurrency) • Constrained Storage Model • frame per component, shared stack, no heap • Very lean multithreading • Efficient Layering structured event-driven execution Never wait or spin Events Commands send_msg(addr, type, data) power(mode) init Messaging Component internal thread Internal State TX_packet(buf) Power(mode) TX_packet_done (success) init RX_packet_done (buffer)

  48. Application: query processing detection, reporting Sensor Drivers & Filters Comm Stack Timer Sensor 3 Sensor 2 Radio Clock Sensor1 Power Management Cooperative Interfaces • Power management extends std control • 1000-fold range of power draw • Components informed of intention to go to sleep • Take internal actions • Propagate control • Scoreboard determined permissible depth of sleep state • Scheduler drops to sleep on idle • Key interrupts drive wake-up • Rich communication interfaces • Signal strength • Post-MAC time-stamping • Sub-carrier signaling

  49. Power-supply Subsystem – (Solar) Energy Harvesting • Energy Store • Power Source • Consumer • Management & Control

  50. Importance of primary buffer • Node is able to operate from capacitors • Moderate period of time (~week) • Source active load (mAs !) • Absorb energy input • Perform frequent charge cycles (daily) • shallow • Source high voltage recharge of secondary • Power MCU during secondary recharge

More Related