TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

Name: TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)
Uploaded: 2017-08-11T09:31:40+00:00
Duration: PTM46S38
Description: TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)
David E. Culler 1st European TinyOS Technology Exchange TTX VI Feb 10, 2009

A decade ago… ETTX

Traditional Systems Well established layers of abstractions
Strict boundaries Ample resources Independent Applications at endpoints communicate pt-pt through routers Well attended Application Application User System Network Stack Threads Transport Network Address Space Data Link Files Physical Layer Drivers Routers ETTX

by comparison, WSNs ... Highly Constrained resources
processing, storage, bandwidth, power Applications spread over many small nodes self-organizing Collectives highly integrated with changing environment and network communication is fundamental Concurrency intensive in bursts streams of sensor data and network traffic Robust inaccessible, critical operation Unclear where the boundaries belong even HW/SW will move => Provide a framework for: Resource-constrained concurrency Defining boundaries Appl’n-specific processing and power management allow abstractions to emerge ETTX

Internet Research Perspective…then
“Resource constraints may cause us to give up the layered architecture.” “Sheer numbers of devices, and their unattended deployment, will preclude reliance on broadcast communication or the configuration currently needed to deploy and operate networked devices.” “There are significant robustness and scalability advantages to designing applications using localized algorithms.” “Unlike traditional networks, a sensor node may not need an identity (e.g. address).” “It is reasonable to assume that sensor networks can be tailored to the application at hand.” ETTX

And Now: Complete IPv6 in TinyOS
ROM RAM CC2420 Driver 3149 272 Encryption 1194 101 Media Access Control 330 9 Media Management Control 1348 20 6LoWPAN + IPv6 2550 Checksums 134 SLAAC 216 32 DHCPv6 Client 212 3 DHCPv6 Proxy 104 2 ICMPv6 522 Unicast Forwarder 1158 451 Multicast Forwarder 352 4 Message Buffers 2048 Router 2050 106 UDP 450 6 TCP 1674 50 24038 ROM 3598 RAM (including runtime) * Production implementation on TI msp430/cc2420 Footprint, power, packet size, & bandwidth ETTX

… and in Open Source ETTX

and Power and Reliability …
Data Rate Sensitivity (Router) Data Rate Sensitivity (Edge) Deployment Duty Cycle Deployment Reliability ETTX

Where Did We Go Wrong? ETTX

Internet – Networks of Networks
Ethernet WiFi Serial links connect hosts and devices and other networks together Horizontally integrated vs Peripheral Interconnects USB, Firewire IDE / SCSI RS232,RS485 IRDA BlueTooth connect one or more devices to a host computer Vertically integrated Physical link to application ethernet wifi LoWPAN ETTX

Which are real sensors nets like?
Trending Monitoring Data Analytics Management Ethernet WiFi GPRS RS232 RS485 Operations Controllers hartcomm.org Field Units ETTX

A Network Starts with a Router
ETTX

Mote/TinyOS – let chaos reign
WINS (UCLA/ROckwell) Mica Intel/UCB dot Intel iMOTE XBOW cc-dot mica2 rene2 cf-mica Bosch cc-mica Dust Inc blue cc-TI digital sun rain-mica mica zeevo BT Telos micaZ MOTE2 Eyes BTNode trio Intel rene’ LWIM-III (UCLA) SmartDust WeC Rene 97 LWIM 98 99 00 01 02 03 04 05 06 07 Expedition NEST Cyber-Physical SENSIT CENS STC NETS/ NOSS DARPA 8 kB rom ½ kB ram 48 kB rom 10 kB ram NSF ETTX

And rain it did… Application Transport Network Link ETTX 2002 2003
SPIN Broadcast Storm TinyOS 0.6 WooMAC GAF S-MAC Aloha PS PSFQ GDI CODA MintRoute T-MAC RMST B-MAC MultihopLQI Fusion Deluge FPS WiseMAC SP Drip Drain BVR Redwoods North Sea SCP-MAC PEDAMACS X-MAC Volcano CTP Flush Golden Gate Bridge S4 Dip Transport Network Link 2002 2003 2004 2005 2006 2007 1999 2000 2001 2008 ETTX

A Low-Power Standard Link
802.11 802.3 Class WPAN WLAN LAN Lifetime (days) 1-7 Powered 0.1-5 Net Size 65535 7 243 30 1024 BW (kbps) 20-250 720 11,000+ 100,000+ Range (m) 1-75+ 1-10+ 10 1-100 185 (wired) Goals Low Power, Large Scale, Low Cost Cable Replacement Throughput Low Transmit power, Low SNR, modest BW, Little Frames Reined in the Phy Chaos, allowed MAC chaos to Reign ETTX

Key Developments Event Driven Execution closely tied to storage mgmt
reliable concurrency, small footprint, and low-power usage Idle listening Radio power: transmit ≈ receive ≈ just listening All the energy is consumed by listening for a packet to receive E = P*Time => Turn radio on only when there is something to hear Reliable routing on Low-Power & Lossy Links Power, Range, Obstructions => multi-hop Always at edge of SNR => loss happens => monitoring, retransmission, and local rerouting Trickle – don’t flood (tx rate < 1/density, and < info change) Connectivity is determined by physical points of interest, not network designer. May have huge number of neighbors, so … never naively respond to a broadcast, re-broadcast very very politely ETTX

Meanwhile: Key IPv6 Contributions
Large simple address Network ID + Interface ID Plenty of addresses, easy to allocate and manage Autoconfiguration and Management ICMPv6 Integrated bootstrap and discovery Neighbors, routers, DHCP Protocol options framework Plan for extensibility Simplify for speed MTU discovery with min 6-to-4 translation for compatibility Prefix IID ICMPv6 IPv6 Base HbH Opt Routing Fragment Dst Opt 128 bits ETTX

IPv6 over 802.15.4: Not an obvious fit
UDP datagram or TCP stream segment …, modbus, BacNET/IP, … , HTML, XML, …, ZCL transport header application payload Network packet 40 B + options cls flow len hops NH src IP dst IP net payload 16 B 16 B Link frame ? 1280 Bytes MIN ctrl len src UID dst UID link payload chk 128 Bytes MAX ETTX

6LoWPAN adaptation layer
Diverse Object and Data Models (HTML, XML, …, BacNet, …) 7: app Application (Telnet, FTP, SMTP, SNMP, HTTP) 4: xport Transport (UDP/IP, TCP/IP) 3: net Network (IP) 6LoWPAN 2: link Link Serial Modem X3T9.5 FDDI 802.3 Ethernet 802.5 Token Ring 802.11 WiFi LoWPAN 802.3a Ethernet 10b2 802.11a WiFi 802.11b WiFi 802.3i Ethernet 10bT ISDN Sonet 802.11g WiFi 802.3y Ethernet 100bT 802.11n WiFi DSL 802.3ab Ethernet 1000bT GPRS 802.3an Ethernet 1G bT 1: phy ETTX

IPv6 Header Compression
in HC byte v6 zero In header uncompressed derive from header derive from header ETTX

6LoWPAN – IP Header Optimization
Network packet 40 B cls flow len hops NH src IP dst IP net payload Link frame 3 B ctrl len src UID dst UID hops chk 6LoWPAN adaptation header Eliminate all fields in the IPv6 header that can be derived from the header in the common case Source address : derived from link address Destination address : derived from link address Length : derived from link frame length Traffic Class & Flow Label : zero Next header : UDP, TCP, or ICMP Additional IPv6 options follow as options ETTX

Energy Consumption Analysis
* * Payload Δ Energy Δ for fixed payload ETTX

Multi-Hop Communication => Routing
PAN Short-range radios & Obstructions => Multi-hop Communication is often required i.e. Routing and Forwarding That is what IP does! “Mesh-under”: multi-hop communication at the link layer Still needs routing to other links or other PANs “Route-over”: IP routing within the PAN => ROLL ETTX

Embedded IPv6 in Concept
Structured Decomposition Retain strict modularity Some key cross-layer visibility IP Link ⇒ Always On Retain illusion even when always off IP Link ⇒ “Reliable” Retain best-effort reliability over unreliable links IP Link ⇒ Broadcast Domain IPv6 can support a semi-broadcast link with few changes ETTX

Autoconfiguration Configuring Large Numbers of Interfaces
RFC 4861 – Neighbor Discovery RFC 4862 – Stateless Addr Autoconf RFC 3315 – DHCPv6 Existing Options New Options ICMPv6 Hdr Router Adv Prefix Info MHop Info Cur Hop Limit Managed Addr Config Other Config Router Lifetime Reachable Time Prefix Length Autonomous Config Valid Lifetime Preferred Lifetime Prefix Network ID Sequence Number Router Hops Flags Trickle ETTX

Autoconfiguration Configuring Large Numbers of Interfaces
Stateless RFC DHCPv6 RFC 3315 Response Response L2e B L2s 0x0001 L3 2001:abcd::1 L2e B L2s 0x0001 L3 2001:abcd::1 Request L2e B L2s 0x0023 L3 L2e B L2s L3 2001:abcd::23 0x0023 2001:abcd::23 Request L2e B L2s 0x0092 L3 L2e B L2s L3 2001:abcd::92 0x0092 2001:abcd::92 ETTX

Media Management Control
Routing & Forwarding Delivering datagrams over multiple hops with High reliability and Low Energy usage Net Forwarder Router ICMPv6 Multicast Unicast Routing Protocol Buffer Queue Send Manager Forwarding Table Prefix Next Default Routing Table Send Manager Prefix Next Link Media Management Control Remote Media Link Stats Local Media Data Ack Neighbor Table Addr Period Phase Pending RSSI PRR Sample Period Sample Phase ETTX

Cross-Fertilization of WSN and IETF ideas
Discovering Links ICMPv6 Hdr Router Adv MHop Info Default Routes Building a Connectivity Graph Routing Table Prefix Next Low Routing Cost High Routing Cost Selecting the Next Hop Routing Table Forwarding Table Prefix Next Prefix Next Default Default route Hop-by-hop retry Reroute on loss ETTX

Complete Embedded IPv6 Stack
App HTTP Telnet SNMP DNS … DHCPv6 Tran UDP TCP Net Forwarder Multicast Send Manager Buffer Unicast Queue Forwarding Table Router ICMPv6 Autoconf Routing Protocol Routing Table Prefix Next Default Stateless Autoconf 6LoWPAN Adaptation Prefix Next Link Data Ack Media Management Control Remote Media Link Stats Local Media Neighbor Table Addr Period Phase Pending RSSI PRR Sample Period Sample Phase ETTX

Media Management Control
Adding up the pieces ROM RAM CC2420 Driver 3149 272 Encryption 1194 101 Media Access Control 330 9 Media Management Control 1348 20 6LoWPAN + IPv6 2550 Checksums 134 SLAAC 216 32 DHCPv6 Client 212 3 DHCPv6 Proxy 104 2 ICMPv6 522 Unicast Forwarder 1158 451 Multicast Forwarder 352 4 Message Buffers 2048 Router 2050 106 UDP 450 6 TCP 1674 50 24038 ROM 3598 RAM (including runtime) * Production implementation on TI msp430/cc2420 ETTX

So what’s Next? ETTX

Rein in the Chaos – by layers
ETTX

Y-A-MAC? Yet-Another-MAC layer? If it is REALLY going to be a standard
Interoperability ‘within the PAN’ requires compatible MACs. left a big hole Beaconing doesn’t work No low power defined for FFD Perhaps the research community should stop “differentiating” and step forward to make one MAC stick Frame formats are not “up for debate” Link / Net Interface ETTX

Routing - really At layer 3
Not 2, not 7, 3! Implemented with routing table, forwarder, and well-defined protocols Packets, States, Actions ROLL working group in IETF Application “requirements” Excellent Protocol Survey Entering actual work phase ETTX

ROLL Internet Drafts draft-ietf-roll-protocols-survey -052009-01-26
draft-ietf-roll-terminology draft-ietf-roll-building-routing-reqs draft-ietf-roll-home-routing-reqs draft-ietf-roll-indus-routing-reqs draft-ietf-roll-urban-routing-reqs ETTX

The Heart of ROLL ETTX

Transport Crazy not to support UDP and TCP
Do we enter a TCP for LLNs renaissance? Do we define a new transport? What is the “embedded sockets API?” ETTX

Issues in Communication Abstraction
Names What are they? What do they mean? What is their scope? How are they allocated? How are they translated into useful properties Address? Physical Resource? Storage Transmit When can it be reused? How do you know? What do you do when it is full? Receive When is it allocated? Reclaimed? By whom? What happens when it overflows? Asynchronous event How do you know that something has arrived? ETTX

Answers: Naming TinyOS Active Messages IP Architecture
TOS_local_addr, 16 bits, only within “a network”, allocated at program download time Scope limited to TOS_group, within PAN, Channel, and physical extent. The standards that try to do it all with IEEE bit short address are not much better IP Architecture Link name: IEEE => EUID64 & SA16 EUID64 globally unique, SA16 assigned to be unique over the PAN Net name: IP address Prefix | Interface Id Must be unique within routability extent Several IP address: Link Local, Global, Multicast, … Service name: Port Hostname Translated to IP by DNS ETTX

Answers: Storage TinyOS Active Messages BSD Sockets TinyOS Sockets ???
Sender app allocates send buffer, OS owns it till sendDone event OS provides App with recv buffer, app must return it or a replacement BSD Sockets Sender app allocate buffer, copied to kernel on send Receiver allocates buffer and passes pointer to kernel, kernel copies Additional sets of buffer managed within the kernel TinyOS Sockets ??? ETTX

Example: UDP Interface
interface Udp { command error_t bind( uint16_t port ); command uint16_t getMaxPayloadLength( const sockaddr_in6_t *to ); command error_t sendto( const void *buf, uint16_t len, const sockaddr_in6_t *to ); event void recvfrom( void *buf, uint16_t len, sockaddr_in6_t *from, link_metadata_t *metadata ); } Wiring to a UDP interface is enough for sendto – no allocate Standard Unix sockaddr_in6_t Bind – associates the component that uses the interface with the port Starts receiving whatever datagrams come in on it Sendto sends a datagram from a buf to an IP destination Neighbor, intra-PAN, inter-network (wherever it needs to go!) Linklocal address is 1-hop neighbor Pan-wide routable prefix Error when not in network or overrun transmit resources Recvfrom gets a buffer with a datagram and metadata about it Able to fill the 15.4 frame without knowing details of header compression ETTX

Example: UDP echo service
configuration EchoUdpC { } implementation { components KernelC; components EchoUdpP as EchoP; EchoP.Boot -> KernelC.Boot; EchoP.Udp -> KernelC.Udp0; } module EchoUdpP { uses interface Boot, Udp; } implementation { event void Boot.booted() { call Udp.bind( ECHO_PORT ); /* bind to port 7 */ event void Udp.recvfrom( void *buf, uint16_t len, sockaddr_in6_t *from, link_metadata_t *linkmsg ) { call Udp.sendto( buf, len, from ); /* echo msg back */ ETTX

And what about TCP UDP is a datagram transport
Essentially the same as AM Fits naturally in event-driven model Can use NesC platform independent data structure to have unambiguous packet formats without hton / ntoh error prone bit twiddling. But TCP is a stream protocol… ETTX

TCP Interface Transitions of the TCP protocol reflected as events
interface Tcp { command error_t bind(uint16_t port, uint8_t *buf, uint16_t bufsize); event bool accept( sockaddr_in6_t *to ); command error_t connect( const sockaddr_in6_t *to, uint8_t *buf, uint16_t bufsize ); event void connected(); command error_t send( const void *buf, uint16_t len ); event void acked(); event uint16_t recv( void *buf, uint16_t len ); command error_t close( bool force ); event void closed(); } Transitions of the TCP protocol reflected as events Recv per segment Here, appln allocates send buffer but stack manages it. Send is not split-phase (!!!) ETTX

TCP echo server module EchoTcpP { uses interface Boot, Tcp; }
implementation { uint8_t m_buf[ BUF_SIZE ]; /* Transmit buffer */ event void Boot.booted() { call Tcp.bind( ECHO_PORT, m_buf, sizeof(m_buf) ); event bool Tcp.accept( sockaddr_in6_t *to ) { return TRUE; } event void Tcp.connected() { } event void Tcp.acked() { } event uint16_t Tcp.recv( void *buf, uint16_t len ) { return ( call Tcp.send( buf, len ) == SUCCESS ) : len ? 0; event void Tcp.closed() { /* setup socket for new connection */ ETTX

Event-Driven Execution of Services
Start Service request TCP Bind Start Timer recv Fire ETTX

Split-Phase Data Acquisition
Ready Sample ReadDone Read ETTX

Examples - Tasks serviceReq Ready Sample notify fired readDone fired
ETTX

HTTP event bool HttpTcp.accept( sockaddr_in6_t *to ) {
serverState = LISTENING; return TRUE; } event void HttpTcp.connected() { serverState = CONNECTED; init_pump(); } event uint16_t HttpTcp.recv( void *inbuf, uint16_t len ) { if (httppump(inbuf,len)) { switch (http_method) { case HTTP_GET : signal Http.GETservice (url, uindex); break; case HTTP_POST: signal Http.POSTservice(url, uindex); break; default: call HttpTcp.close( FALSE ); } return len; command error_t Http.serviceDone() { call HttpTcp.close( FALSE ); return SUCCESS; } command error_t Http.send( const void *buf, uint16_t len ) { return call HttpTcp.send( buf, len ); } event void HttpTcp.acked() { } event void HttpTcp.closed(){call HttpTcp.bind(port, resp, respLen);} ETTX

Resource Blueprint at the Top
configuration WebSense { } implementation { components KernelC; components WebC as WebC; /* Web request service */ components HttpC as HttpC; /* TCP HTTP (port 80) service */ components new TimerMilliC() as HttpTimer; /* Protocol deadman */ components Msp430Adc12C; /* Hardware ADC abstraction */ components Msp430PortsC; /* Hardware IO Ports */ WebC.Http > HttpC.Http; /* Protocol interface */ WebC.Boot > KernelC.Boot; WebC.IPv6Addresses -> KernelC.IPv6Addresses; WebC.Time > KernelC.GlobalTime; HttpC.HttpTcp > KernelC.Tcp0; HttpC.IPv6Addresses -> KernelC.IPv6Addresses; HttpC.Timer > HttpTimer; /* Digital inputs */ components new DigitalInC("Door") as Din0; WebC.Door -> Din0.DigitalIn; Din0.Pin -> Msp430PortsC.Port1[2]; Din0.PinInt -> Msp430PortsC.Port1Interrupt[2]; /* Analog inputs */ components TempIntC; WebC.Temp -> TempIntC.TempInt; TempIntC.ADC -> Msp430Adc12C.Msp430Adc12[INCH_10]; /* Internal temp */ components new AnalogInC(REFVCC, "Pot") as TrimPot; WebC.Pot -> TrimPot.Sensor; TrimPot.ADC -> Msp430Adc12C.Msp430Adc12[INCH_4 ]; } ETTX

… or if you prefer Zigbee Profiles
“A UDP/IP Adaptation of the ZigBee Application Protocol” ETTX

what it means for sensors
Low-Power Wireless Embedded devices can finally be connected using familiar networking technology, like ethernet (but even where wiring is not viable) and like WiFi (but even where power is not plentiful) all of these can interoperate in real applications Interoperate with traditional computing infrastructure Utilize modern security techniques Application Requirements and Capacity Plan dictate how the network is organized, not artifacts of the underlying technology Gateways and Proxies may or may not be at the media boundary … ETTX

Making sensor nets make sense
LoWPAN – 1% of power, easier to embed, as easy to use. 8-16 bit MCUs with KBs, not MBs. Off 99% of the time Proxy / Gateway Web Services XML / RPC / REST / SOAP / OSGI HTTP / FTP / SNMP TCP / UDP IP ROLL 802.11 , … Ethernet Sonet IETF 6lowpan ETTX

Thanks ETTX

Technology Transformation - Bottom Line
Network hartcomm.org Microcontroller Flash Storage Radio Sensors have become “physical information servers” Treat them as “information servers” ETTX

Industrial Interconnects
Specific Legacy Physical Link TCP/UDP/IP Many IP links Implementation Glue Object and Data Model BACnet RS-232 & RS-485 => IEEE via BACnet/IP LONworks Twisted Pair & Power Line => LonTalk/IP Common Industrial Protocol (CIP) CAN & ControlNet => EtherNet/IP SCADA Prop. RS-485 & Leased Line & Prop. Radios => ModBUS => Ethernet => TCP/IP FieldBus Modbus, Profibus, Ind. Ethernet, Foundation HSE, H1, …SP100.11a? In 2000, ODVA and CI introduced another member of the CIP family: EtherNet/IP, where “IP” stands for “Industrial Protocol.” In this network adaptation, CIP runs over TCP/IP and therefore can be deployed over any TCP/IP supported data link and physical layers, the most popular of which is IEEE , commonly known as Ethernet. The universal principles of CIP easily lend themselves to possible future implementations on new physical/ data link layers. [The Common Industrial Protocol (CIP) and the Family of CIP Networks (Pub 123 )] ETTX

A Decade Ago ETTX

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

Similar presentations

Presentation on theme: "TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

Similar presentations

Presentation on theme: "TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)"— Presentation transcript:

Similar presentations

About project

Feedback