Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
3. Towards A Standards-Based Stack PowerPoint Presentation
Download Presentation
3. Towards A Standards-Based Stack

3. Towards A Standards-Based Stack

85 Views Download Presentation
Download Presentation

3. Towards A Standards-Based Stack

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 3. Towards A Standards-Based Stack Thomas Watteyne @ EDERC 2010

  2. Protocol Stack IETF IEEE Thomas Watteyne @ EDERC 2010

  3. Section 3 - Overview 3. Towards A Standards-Based Stack 3.1 IEEE 802.15.4E 3.2 IETF 6LoWPAN 3.3 IETF RPL 3.4OpenWSN 3.5 Conclusions Thomas Watteyne @ EDERC 2010

  4. 3.1 IEEE802.15.4E Thomas Watteyne @ EDERC 2010

  5. 15.4-2006, 15.4 PHY, 15.4 MAC, 15.4E? • IEEE 802 LAN/MAN Standards Committee • standardizes a.o. 802.3 (Ethernet) 802.11 • http://www.ieee802.org/ • IEEE 802.15 Working Group for WPAN • wireless Personal Area Network • standardizes a.o. 802.15.1 (Bluetooth), 802.15.4 • http://www.ieee802.org/15/ • IEEE 802.15 WPAN Task Group 4 • low data rate solution with multi-month to multi-year battery life, very low complexity • operating in an unlicensed, international frequency band • sensors, interactive toys, smart badges, remote controls, and home automation, etc. • first standard in 2003, updated in 2006 • standardizes both PHY and MAC • http://www.ieee802.org/15/pub/TG4.html • IEEE 802.15 WPAN Task Group 4e • define a MAC amendment to the existing standard 802.15.4-2006 • enhance and add functionality to the 802.15.4-2006 MAC to better support the industrial markets • uses 802.15.4-2006 PHY • draft standard on 03/08/2010, integrated in next revision of the 802.15.4 standard (exp. 2011) • http://www.ieee802.org/15/pub/TG4e.html Thomas Watteyne @ EDERC 2010

  6. IEEE802.15.4 – Overview • Emphasis of IEEE 802.15.4 is: • low-cost, low-speed ubiquitous communication between nearby devices with little to no underlying infrastructure • basic framework assumes 10-meter communications area @ 250 kbit/s • lower transfer rates of 20, 40 and 100 kbit/s are now considered too • to meet embedded constraints, several PHY layers are available • Key technology features are: • real-time suitability by reservation of guaranteed time slots • collision avoidance through CSMA/CA • integrated support for secure communications (128-bit AES encryption) • power management functions such as link quality and energy detection • 16 channels in ISM bands for operation, i.e. 868-868.8 MHz (Europe), 902-928 MHz (North America), 2400-2483.5 MHz (worldwide) • star and mesh topologies can theoretically be built • support for low-latencies and dynamic device addressing Thomas Watteyne @ EDERC 2010

  7. IEEE802.15.4 – PHY Layer • The 2006 revision of the standard defines 4 PHY layers: • 868/915 MHz DSSS with binary phase shift keying (BPSK) • 868/915 MHz DSSS with offset quadrature phase shift keying (OQPSK) • 2450 MHz DSSS with offset quadrature phase shift keying (OQPSK) • 868/915 MHz PSSS, i.e. combination of binary keying and amplitude shift keying • The 2007 IEEE 802.15.4a version includes 2 PHY layers more: • Chirp Spread Spectrum (CSS) @ 2450 MHz ISM • Direct Sequence Ultra-wideband (UWB) @ < 1GHz, 3-5GHz, 6-10 GHz • Beyond these PHYs at the three bands, there are: • IEEE 802.15.4c for 314-316, 430-434 and 779-787MHz bands in China • IEEE 802.15.4d for 950-956MHz band in Japan Thomas Watteyne @ EDERC 2010

  8. IEEE802.15.4 – PHY Layer • binary phase shift keying (BPSK) • quadrature phase shift keying (QPSK) • offset quadrature phase shift keying (OQPSK) Thomas Watteyne @ EDERC 2010

  9. IEEE802.15.4 – 2.4GHz PHY • O-QPSK, 250 kb/s, 62.5 ksymbol/s • Direct Sequence Spread Spectrum • Max PSDU = 127B • Turnaround: TX-RX ≤ RX-TX ≤ 192us • ED over 8 symbol periods DSSS: 4 bits of information = 32 chips (raw data rate of 2Mbps) Thomas Watteyne @ EDERC 2010

  10. IEEE802.15.4 – MAC Layer • Some key attributes: • CSMA/CA channel access • manages access to the physical channel and network beaconing • controls frame validation, guarantees time slots, handles node associations • offers hook points for secure services • In more details: • networks which are not using beaconing mechanisms utilize an un-slotted variation which is based on the listening of the medium, leveraged by a random exponential backoff algorithm (acknowledgments do not adhere to this discipline) • confirmation messages may be optional under certain circumstances, in which case a success assumption is made; timeout-based retransmission can be performed a number of times • due to the maximization of battery life, the protocols tend to favor methods implementing periodic checks for pending messages, the intensity of which depends on application needs Thomas Watteyne @ EDERC 2010

  11. IEEE802.15.4 – MAC Layer • There are two general channel access methods: • Non-Beacon Network: • simple, traditional multiple access system used in simple peer networks • standard CSMA conflict resolution • positive acknowledgement for successfully received packets • Beacon-Enabled Network • can be used in beacon-request mode without superframes • superframe structure - network coordinator transmits beacons at predetermined intervals • dedicated bandwidth and low latency • low power consumption mode for coordinator Thomas Watteyne @ EDERC 2010

  12. IEEE802.15.4 – MAC Layer • Super-Frame Structure for Beacon-Enabled Mode: Thomas Watteyne @ EDERC 2010

  13. IEEE802.15.4 – Packet Format 0-127 4B of data(all 0’s) 0x7A synchronization header physical header 16-bit CRC beacon, ACK, DATA, command MAC header Thomas Watteyne @ EDERC 2010

  14. IEEE802.15.4 – Device Classes • Full function device (FFD) • any topology • network coordinator capable • talks to any other device • Reduced function device (RFD) • limited to star topology • cannot become a network coordinator • talks only to a network coordinator • very simple implementation Thomas Watteyne @ EDERC 2010

  15. IEEE802.15.4 – Star Topology PAN Coordinator Master/Slave Communications flow Full function device Reduced function device Thomas Watteyne @ EDERC 2010

  16. IEEE802.15.4 – P2P Topology Cluster tree Point to point Full function device Communications flow Thomas Watteyne @ EDERC 2010

  17. IEEE802.15.4 – Combined Topology Clustered stars - for example, cluster nodes exist between rooms of a hotel and each room has a star network for control. Full function device Reduced function device Communications flow Thomas Watteyne @ EDERC 2010

  18. IEEE802.15.4 Scenario • First node makes sure it is alone, scans for a “good” frequency and transmits beacons. • New node scans (active or passive) and hears beacon. Sends an association request (indirect response). Tracks beacon periodically. • Upstream data transmitted in CAP using CSMA/CA. If downstream data, coordinator set pending data field. • Device can ask to (dis)allocate a GTS to the coordinator. GTS slots are announced in beacon, CSMA is not used in GTS slot. • Secondary coordinators to create a generalized star topology. Thomas Watteyne @ EDERC 2010

  19. IEEE802.15.4 - Problems • Powered Routers • router nodes have their radio on all the time • if battery-powered: 2400mAh AA pack @ 81mA (CC2420) -> 29h of lifetime • assumption: mains powered • Single channel operation • WiFi-like: one channel for the whole network • suffers from external interference (WiFi, Bluetooth) • suffers from persistent multipath fading (especially indoors) • Topologies • works great in star topologies • e.g. multiple switches connected to a single lamp • extended star topologies are hard to manage Thomas Watteyne @ EDERC 2010

  20. IEEE802.14.4E - TSCH • Time Synchronized Channel Hopping • cut time into slots • have nodes follow a common schedule B D A C Thomas Watteyne @ EDERC 2010

  21. IEEE802.14.4E - TSCH • The channel offset is translated to frequency using a translation function • This insures that successive packets sent over a same link are sent over all frequencies • iff the superframe length and number if frequencies are mutually prime frequency = (absolute slot number + channel offset)%16 Thomas Watteyne @ EDERC 2010

  22. IEEE802.14.4e - TSCH A B Thomas Watteyne @ EDERC 2010

  23. Thomas Watteyne @ EDERC 2010

  24. Thomas Watteyne @ EDERC 2010

  25. TsPacketWaitTime Watchdog_TXACK TsRxOffset TsTxAckDelay Stopping_time Startup_time SETTING_CHANNEL STARTING STARTED RXDATA WAIT_TXACK TXACK STOPPING STOPPED 2 7 8 9 1 10 11 Guard_time_large Guard_time_small Watchdog_TXDATA TsAckWaitTime Watchdog_TXACK+Guard_time_small TsRxAckDelay TsTxOffset Startup_time+Guard_time_large SETTING_CHANNEL STARTING STARTED TXDATA WAIT_RXACK RXACK STOPPING STOPPED 1 2 4 5 6 10 11 SLOT_TIME >TsRxOffset+TsPacketWaitTime+TsTxAckDelay+Watchdog_TXACK+Stopping_time

  26. IEEE802.15.4e – Synchronization • clocks drift(10ppm typical) • Periodic realignment(within a clock tick) ∆t Thomas Watteyne @ EDERC 2010

  27. Improved Reliability Thomas Watteyne @ EDERC 2010

  28. Improved Connectivity Thomas Watteyne @ EDERC 2010

  29. Improved Throughput Thomas Watteyne @ EDERC 2010

  30. Improved Energy Consumption • 2ms maximum de-synchronization • 20ppm relative drift • Resynchronization every 100 seconds (10ms slots) 0.010% idle duty cycle • 25mA when mote is active • 2400mAh batteries(AA batteries) • lifetime of 109 years(>> shelf-life) Thomas Watteyne @ EDERC 2010

  31. Improved Throughput Thomas Watteyne @ EDERC 2010

  32. IEEE 802.15.4e - TSCH antenna humidity sensor IR light sensor • TelosB mote • TinyOS operating system • 30ms time slots • 19kB ROM / 3kB RAM • 10kbps over 14 hops visible light sensor CC2420 radio MSP430 microcontroller 1 2 3 4 Thomas Watteyne @ EDERC 2010

  33. Thomas Watteyne @ EDERC 2010

  34. 3.2 IETF 6LoWPAN Thomas Watteyne @ EDERC 2010

  35. IPv4 vs. IPv6 • Internet Protocol v4 (IPv4): • IPv4 (RFC 791) originates from 1981 • upper layer protocols responsible for end-to-end reliability • works over almost any layer 2 network and with many routing protocols • addressing is being pushed to extremes by Internet growth • Internet Protocol v6 (IPv6): • IPv6 (RFC 2460) is the next generation of the Internet Protocol • complete redesign on IP addressing: hierarchical 128-bit address with decoupled host identifier; stateless auto-configuration; etc • simple routing and address management • majority of traffic not yet IPv6 but most PC operating systems already have IPv6, governments are starting to require IPv6, most routers already have IPv6 support • IPv6 transition is coming slowly but quietly Thomas Watteyne @ EDERC 2010

  36. IPv4 vs. IPv6 • IPv4 ... ... versus IPv6 addressing: Thomas Watteyne @ EDERC 2010

  37. IPv4 vs. IPv6 Monday, September 26, 2011 Thomas Watteyne @ EDERC 2010

  38. IP headers IPv4 header [RFC791], 1981 IPv6 header [RFC791], 1998 Thomas Watteyne @ EDERC 2010

  39. IETF 6LoWPAN - Overview • Key properties: • IP for very low power embedded devices • IETF Standard for IPv6 over IEEE 802.15.4: RFC4944, to be obsolete by IPHC • 80% compression of headers • IPv6 40-byte header -> 2 bytes (best case) • UDP 8-byte header -> 4 bytes • end-to-end Internet integration • fragmentation (1260 byte IPv6 frame -> 127 byte 802.15.4 frames) Thomas Watteyne @ EDERC 2010

  40. Header Compaction RFC4944 Not compacted Well-known value Value inferred from IEEE802.15.4 header Thomas Watteyne @ EDERC 2010

  41. Internet Integration Thomas Watteyne @ EDERC 2010

  42. 3.3 IETF RPL Thomas Watteyne @ EDERC 2010

  43. IETF ROLL - Overview • Routing Over Low-Power and Lossy Networks (ROLL): • IETF information discussion started in 2008 • Finalizing “RPL: IPv6 Routing Protocol for Low power and Lossy Networks” • website: http://tools.ietf.org/wg/roll • list: http://www.ietf.org/mail-archive/web/roll/current/threads.html • Since WSNs are application specific, 4 scenarios are dealt with: • building applications: draft-ietf-roll-building-routing-reqs • home applications: draft-ietf-roll-home-routing-reqs • industrial applications: RFC 5673 • urban applications: RFC 5548 Thomas Watteyne @ EDERC 2010

  44. IETF ROLL – RPL • Adopted as a working document by IETF ROLL on August 3, 2009 • Close integration with IPv6/6LoWPAN • DAG Information Option (DIO) • Destination Advertisement Option (DAO) • Core operation: • build a Directed Acyclic Graph (DAG) onto the connectivity graph of the network, directed toward a DAG root • each node has at least one DAG parent; nodes send inward traffic to their DAG parent • nodes announce their presence to the DAG root using Destination Advertisement • Source routing is used for outward traffic Thomas Watteyne @ EDERC 2010

  45. IETF ROLL – RPL • Constraint Based Routing • finding the shortest path according to some metrics satisfying a set of constraints • Objective Code Point (OCP) included in DIO: • The set of metrics used within the DAGe.g. Expected Transmission Count (ETX) • The objective functions used to determine the least cost constrained paths in order to optimize the DAGe.g. minimize ETX • The function used to compute DAG Depthe.g. DAG Depth is equivalent to ETX • The functions used to construct derived metrics for propagation within a DIOe.g. additive Thomas Watteyne @ EDERC 2010

  46. IETF ROLL – RPL wsn.eecs.erkeley.edu Thomas Watteyne @ EDERC 2010

  47. IETF ROLL – RPL wsn.eecs.erkeley.edu Thomas Watteyne @ EDERC 2010

  48. IETF ROLL – RPL Thomas Watteyne @ EDERC 2010

  49. 3.4 OpenWSN Thomas Watteyne @ EDERC 2010

  50. Charter openwsn.berkeley.edu The OpenWSN project serves as a repository for open-source implementations of protocol stacks based on Internet of Things standards, using a variety of hardware and software platforms. Thomas Watteyne @ EDERC 2010