The InternetofofThings Things and and The Internet Wireless SensorNetworks Networks Wireless Sensor

Mario Paoli [email protected] IoT and WSNs

Summary •  Introduction to the Internet of Things (IoT) •  IoT & Wireless sensor networks •  IoT protocol stack for WSN –  802.15.4e (MAC layer) –  6LoWPAN (Routing layer) –  CoAP (Application layer) •  OpenWSN implementation

IoT and WSNs

Page 2

Smart Devices Smart devices are electronic apparatus able to: •  sense a quantity of interest or control a process •  process data •  communicate wirelessly

IoT and WSNs

Page 3

The Internet of Things The Internet of Things (IoT) is a scenario in which smart objects are provided with unique identifiers and the ability to exchange data over a the Internet wireless technologies the Internet

smart devices the Internet of Things

IoT and WSNs

Page 4

What are these things? •  a person with a heart monitor implant •  a farm animal with a biochip transponder •  a car that has built-in sensors to alert the driver when tire pressure is low •  a refrigerator with a temperature sensor In general: any smart object to which can be assigned an IP address IoT and WSNs

Page 5

Applications Fields of applications include: •  waste management •  urban planning •  environmental sensing •  social interaction gadgets •  sustainable urban environment •  emergency response •  intelligent shopping •  smart product management •  smart meters •  home automation IoT and WSNs

Page 6

IoT: challenges & requirements 1. need to assign a unique ID many devices à IPv6, 2^128 addresses 2. many different underlying technologies à web services as wrappers 3. deal with power/resources constrained devices à new communication protocols optimized for specific use cases IoT and WSNs

Page 7

IoT protocol landscape

IoT and WSNs

Page 8

IoT and Wireless Sensor Networks Today we will focus on how to introduce the IoT paradigm on WSN GOAL: Get an information from a node in a WSN issuing a HTTP request (i.e. GET http://node1.wsndis.com/ temperature)

IoT and WSNs

Page 9

Data-Centric communication systems •  Data-Centric: –  Standard WSN approach –  The smallest entity is the WSN –  In this configuration you can just communicate with the sink node

IoT and WSNs

Page 10

Data-Centric communication systems •  sensors or actuators use some kind of low-level proprietary communication protocol to communicate to a gateway •  gateways are typically connected using the standard TCP/IP to the Internet, normally over 2,5G/3G/LTE, Wifi or wired access points.

IoT and WSNs

Page 11

Address-Centric communication systems •  Address-Centric: –  Nodes are identified by an IP address –  The smallest entity is node –  In this configuration you can communicate any node

IoT and WSNs

Page 12

IoT communication model In the IoT communication model sensors are truly nodes of the Internet and expose Web services themselves.

IoT and WSNs

Page 13

Wireless Sensor Nodes: constraints Ø  Limited amount of energy available (battery fueled) Ø  Limited computational capabilities Ø  Small memories (ROM , RAM)

TelosB Processor

16-bit RISC, 8 MHz

Program Memory

48KB

RAM

10KB

IoT and WSNs

Page 14

WSN: protocol stack application

user defined

routing

CTP, RPL…

medium access

802.15.4 (MAC), BoXMAC …

physical

802.15.4 (PHY)

IoT and WSNs

Page 15

IEEE 802.15.4-2006 It standardizes: –  the physical layer (Layer 1, or PHY) –  the medium access control layer (layer 2, or MAC). –  the physical and MAC frame structures

802.15.4 Class

WPAN

Lifetime (days)

100-1000+

Bandwidth (kbps)

20-250kb/s

Net Size

65535

Range (m)

1-75+

Goals

Low Power, Large Scale, Low Cost

IoT and WSNs

Page 16

IEEE 802.15.4 PHY & MAC Frame

IoT and WSNs

Page 17

IoT protocol stack for WSN We want to define a protocol stack that: •  allows robust, reliable, low-power wireless communication •  supports IP routing •  supports unique addressing for a great number of devices •  allows to retrieve information from nodes using HTTP primitives (GET, PUT…) Keeping in mind the constraints imposed by WSN

IoT and WSNs

Page 18

IoT protocol stack for WSN: MAC layer •  The amendment to the existing 802.15.4-2006 called IEEE 802.15.4e defines the MAC protocol for IoT devices •  One mode, called Time Synchronized Channel Hopping (TSCH), significantly increases robustness against external interference and persistent multi-path fading medium access

802.15.4e-TSCH

physical

802.15.4 (PHY)

IoT and WSNs

Page 19

IEEE 802.15.4e MAC •  MAC amendment to the existing IEEE 802.15.4-2006 std. •  Prime characteristics: o  Based on IEEE802.15.4-2006 PHY (to profit from embedded PHYs) o  TSCH: TimeSlotted (Synchronized), to allow for distributed implementation o  TSCH:Channel Hopping, to give resilience to interference/multi-path fading

IoT and WSNs

Page 20

IEEE 802.15.4e TSCH history •  2006: TSCH approach emerges in the proprietary Time Synchronized Mesh Protocol (TSMP) •  2008: TSMP is standardized in ISA100.11a The IEEE 802.15.4e Working group is created. Issue: IEEE 802.15.4-2006 MAC is ill-suited for low-power multi-hop network because of (i) high energy consumption due to relay/router nodes (ii) use of a single channel that implies interference and multi-path fading Final aim: to redesign the existing IEEE 802.15.4-2006 MAC Std. and make it suitable for low-power multi-hop networks in industrial applications

•  2009: TSMP is standardized in WirelessHART •  2010: Part of IEEE 802.15.4e draft •  2011: IEEE802.15.4e draft in Sponsor Ballot (opened on 27 July 2011 and closed on 28 August with 96% of votes being affirmative) •  16 April 2012: IEEE802.15.4e TSCH published

IoT and WSNs

Page 21

IEEE 802.15.4e TimeSlotted CH •  TSCH: TimeSlotted (Synchronized) o  Time is divided in time slots o  All motes are synchronized to a given slotframe o  Slotframe: group of time slots which repeats over time o  Number of time slots per slotframe is tunable A single slot is long enough for the transmitter to send a maximum length packet and for the receiver to send back an ACK

0 1 2

…

99 0 1 2

…

slotframe cycle k IoT and WSNs

99 t

cycle (k + 1) Page 22

IEEE 802.15.4e TimeSlotted CH TDMA + Synchronization + Time formatted in Slotframe(s) Deterministic Networking

•  Deterministic traffic (known a priori) Ø a single time slot is a unit of throughput that can be allocated to a deterministic flow

•  Several isolated flows (Traffic Engineering) Ø  Optimized path and track per single flow

Energy overhead

•  Network synchronization and timely transmission Ø no collision and virtually no jitter IoT and WSNs

Page 23

IEEE 802.15.4e TS Channel Hopping 1/3 •  16 channels are available in the 2.4GHz frequency band (from 11 to 26, 802.15.4 standard) •  A mote sends subsequent packets on different channels Ø  Interference and multipath fading are mitigated Ø  Reliability and Robustness •  A single time slot can be used by multiple pairs of nodes (up to 16) without collisions Ø  Network capacity is increased

IoT and WSNs

Page 24

IEEE 802.15.4e TS Channel Hopping 2/3 A frequency (i.e. channel) is computed using a channel offset and a translation function

ASN 1

2

3 4 5

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

channelOffset

15

1 0 slotOffset Slotframe cycle

Channel

0 1

2 3

4 5 6

k

t (k + 2)

(k + 1)

ch15 IoT and WSNs

ch22

(k + 3)

ch13

ch20 Page 25

IEEE 802.15.4e TS Channel Hopping 3/3

IoT and WSNs

Page 26

IEEE 802.15.4e TSCH Schedule 1/2 •  Each mote follows a communication schedule •  A schedule is a matrix of cells, each of them indexed by a slotOffset and a channelOffset •  Each cell can be assigned to a pair of motes, in a given direction •  A scheduled cell can be used by one and/or multiple couples of devices (i.e., dedicated and/or shared)

Predictable (low) power consumption

IoT and WSNs

motes wake according to the schedule

Page 27

IEEE 802.15.4e TSCH Schedule 2/2 •  A schedule is built according to the specific requirements of the application Ø  Trade-off between energy consumption, robustness and latency •  Different approaches for building a schedule: ü  Centralized - Gateway responsible for building and maintaining the schedule - Efficient for static networks ü  Distributed - Nodes decide locally which cells they will use to communicate with neighbors - Suitable for mobile networks with many gateways - Scalable with large network size

IEEE 802.15.4e defines how the MAC executes a schedule but it does not specify how such schedule is built!!! IoT and WSNs

Page 28

IoT protocol stack for WSN: Routing Layer application

HTTP

transport

UDP

routing

IPv6

medium access

802.15.4e-TSCH

physical

802.15.4 (PHY)

IoT and WSNs

This won’t work: we need an adaptation layer to encapsulate IPv6 datagram into 802.15.4 frames

Page 29

6LoWPAN 6LoWPAN allows IP over 802.15.4 networks Key Features: •  1280 bytes IPv6 MTU over 127 bytes 802.15.4 frame –  IPv6 header compression –  IPv6 datagrams fragmentation •  Support for IP routing –  various protocol to establish routing tables (i.e. RPL) •  Minimal use of code and memory •  Energy efficient (Great ability to work within the resource constraints of low-power, low-memory, low-bandwidth devices like WSN)

IoT and WSNs

Page 30

6LoWPAN: Challenges UDP datagram or TCP stream segment transport header

application payload

Network packet 40 B + options cls flow len hops NH src IP 16 B

Link frame ctrl len src UID dst UID

dst IP 16 B

net payload

1280 Bytes MIN link payload

chk

128 Bytes MAX

IoT and WSNs

Page 31

6LoWPAN: IPv6 addressing 128-bit IPv6 address: •  64-bit prefix + 64-bit Interface ID (IID) The 64-bit prefix is hierarchical: •  Identifies the network globally The 64-bit IID identifies the network interface •  Must be unique for that network

IoT and WSNs

Page 32

6LoWPAN: Architecture The gateway SHOULD do the compression and decompression of IPv6 packets

The compression implies: •  the detaching the 64-bit address prefix •  mapping the 64-bit IID into a 16-bit short address (it can be derived from link-layer 802.15.4 address)

To do so the gateway maintains mapping table for this translation. IoT and WSNs

Page 33

6LoWPAN: Device Address Mapping Table This table consists of 64-bit interface identifier (IID) and 16bit short address. This table MUST contain the mapping information of all the devices in 6LoWPAN. 64 bits IID

16 bits Short Addr.

Interface Identifier: The 64 bit IID assigned to each 6LoWPAN device. Short Address: The 16 bit short address assigned to each 6LoWPAN device.

IoT and WSNs

Page 34

6LoWPAN: IP Header Optimization Network packet 40 B cls flow len hops NH src IP

Link frame ctrl len src UID dst UID

dst IP

net payload

3B hops

chk

6LoWPAN adaptation header

Eliminate all fields in the IPv6 header that can be derived from the 802.15.4 header in the common case: –  Traffic Class & Flow Label : zero –  Length : derived from link frame length –  Hops : cannot be compressed –  Next header : UDP, TCP, or ICMP (compressed in 2 bits) –  Source address : derived from link address –  Destination address : derived from link address IoT and WSNs

Page 35

6LoWPAN: Compressed IP IEEE 802.15.4 Frame Format S pan

Src EUID 64

Max 127 bytes Dst16 Src16

Network Header HC1

IETF 6LoWPAN Format

Fchk

dsp

FCF

DSN

Len

preamble

Dst EUID 64

SFD

D pan

Application Data

IP

Dispatch: coexistence Header compression (IP) IP: Hop limit

IoT and WSNs

Page 36

6LoWPAN: Dispatch •  Coexistence with other network protocols over same link •  Header dispatch - understand what is coming IEEE 802.15.4 Frame Format

FCF

DSN

Len

preamble

Dst EUID 64 SFD

D pan

S pan Dst16 Src16

IETF 6LoWPAN Format

IoT and WSNs

Src EUID 64 Fchk

Network Header

Application Data

00

Not a LoWPAN frame

01

LoWPAN IPv6 addressing header

10

LoWPAN mesh header

11

LoWPAN fragmentation header

Page 37

6LoWPAN: IPv6 Header IEEE 802.15.4 Frame Format S pan

Src EUID 64

Dst16 Src16

Fchk dsp

FCF

DSN

Len

preamble

Dst EUID 64 SFD

D pan

Network Header

Application Data

IETF 6LoWPAN Format 01 0 0 0 0 0 1 01 0 0 0 0 1 0

Uncompressed IPv6 header [RFC2460] HC1

40 bytes

Fully compressed: 1 byte

HC1 tells how the header should be compressed

IoT and WSNs

Page 38

6LoWPAN: HC1 Compressed IPv6 Header HC1

Zero or more uncompressed fields follow in order 0

7

IPv6 destination address (bits 2 and 3): •  00: PI, II •  01: PI, IC •  10: PC, II •  11: PC, IC IPv6 source address (bits 0 and 1): •  00: PI, II •  01: PI, IC •  10: PC, II •  11: PC, IC IoT and WSNs

PI: Prefix carried in-line PC: Prefix compressed II: Interface identifier carried in-line IC: Interface identifier derivable from the corresponding link-layer address Page 39

6LoWPAN: HC1 Compressed IPv6 Header HC1

Zero or more uncompressed fields follow in order 0

7

Next Header (bits 5 and 6): •  00: not compressed; •  01: UDP •  10: ICMP •  11: TCP

HC2 encoding(bit 7): •  0: No more header compression bits •  1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format. Bits 5 and 6 determine which of the possible HC2 encodings apply (e.g., UDP, ICMP, or TCP).

Traffic Class and Flow Label (bit 4): •  0: not compressed •  1: Traffic Class and Flow Label are zero IoT and WSNs

Page 40

6LoWPAN: Compressed IP / UDP IEEE 802.15.4 Frame Format S pan

Src EUID 64

Dst16 Src16

Network Header HC1

IETF 6LoWPAN Format

Fchk

dsp

FCF

DSN

Len

preamble

Dst EUID 64 SFD

D pan

IP

Application Data

UDP

Dispatch: Compressed IPv6 HC1: IP: UDP:

Source & Dest Local, next hdr=UDP Hop limit 8-byte header (uncompressed)

IoT and WSNs

Page 41

6LoWPAN: UDP/IP Header Optimization Network packet 8B

40 B cls flow len hops NH src IP

Link frame ctrl len src UID dst UID

dst IP

UDP hdr

appln payload

7B hops

chk

6LoWPAN adaptation header

•  Transport length derived from link •  Subset of ports in compressed form

IoT and WSNs

Page 42

6LoWPAN: Compressed IP/ Compressed UDP IEEE 802.15.4 Frame Format S pan

Src EUID 64

Max 127 bytes Dst16 Src16

Dispatch: coexistence

HC2

Network Header HC1

IETF 6LoWPAN Format

Fchk

dsp

FCF

DSN

preamble

Len

Dst EUID 64

SFD

D pan

IP

Application Data

UDP

Header compression (IP) Header compression (UDP) IP: Hop limit UDP: 3-byte header (compressed)

IoT and WSNs

Page 43

6LoWPAN: Fragmentation •  IP interoperability over many links => users not limited by frame size •  IP datagrams that are too large to fit in a 802.15.4 frame are fragmented into multiple frames Network packet IP header

net payload

Multiple Link frames 15.4 header

Fn

15.4 header F2 IP 15.4 header F1 IP IoT and WSNs

IP

chk

...

chk chk

Page 44

6LoWPAN: Fragmentation •  All fragments of an IP packet carry the same tag –  Assigned sequentially at source of fragmentation

•  Each specifies tag, size, and position •  Do not have to arrive in order •  Time limit for entire set of fragments (60s) First fragment 11

00 0

size

tag

Rest of the fragments 11

10 0

size

IoT and WSNs

tag

offset

Page 45

6LoWPAN: Example Fragmented / Compressed IP / Compressed UDP IEEE 802.15.4 Frame Format S pan

Src EUID 64

Dst16 Src16

Frag 1st

HC2

Network Header HC1

IETF 6LoWPAN Format

Fchk

dsp

FCF

DSN

Len

preamble

Dst EUID 64 SFD

D pan

IP

Application Data

UDP

Dispatch: Fragmented, First Fragment, Tag, Size Dispatch: Compressed IPv6 HC1: IP: UDP:

Source & Dest Local, next hdr=UDP Hop limit HC2+3-byte header (compressed)

IoT and WSNs

Page 46

IoT protocol stack for WSN: App Layer application

HTTP

transport

UDP

routing

IPv6

adaptation

6LoWPAN

medium access

802.15.4e-TSCH

physical

802.15.4 (PHY)

IoT and WSNs

HTTP do not take into account the small memories and energy consumption constraints of WSN nodes

We need a protocol that fulfills all WSN requirements and that allows the identification of resources using a universal resource identifier (URI)

Page 47

CoAP The IETF Constrained RESTful Environments (CoRE) defined Web transfer protocol called the Constrained Application Protocol (CoAP) in order to introduce Web-services paradigm in the IoT. CoAP: •  REST-based •  take into account WSN devices constraints (low-power, low computational capabilities) •  includes several HTTP functionalities: •  identifies resources in using a universal resource identifier (URI) •  resources can be accessed using methods such as GET, PUT, POST, and DELETE. But CoAP is not just a blind compression of HTTP.

IoT and WSNs

Page 48

REST architecture REST (REpresentational State Transfer) is a simple stateless, client-server architecture to make calls between network devices. In REST-style architecture: •  Clients sends a request for a server resource •  Servers process requests and return appropriate responses •  Resources are identified by a URI

IoT and WSNs

Page 49

REST and Web Services Web service APIs that adhere to the REST constraints are called RESTful: •  •  • 

every resource on a server is identified by a URI, such as http://example.com/resources/ data are represented using an Internet media type (e.g. JSON, XML …) resources are accessed using standard HTTP methods (e.g., GET, PUT, POST, or DELETE)

IoT and WSNs

Page 50

CoAP: features •  •  •  •  •  •  •  •  •  • 

Asynchronous transaction model Embedded web transfer protocol (coap://) UDP binding with reliability and multicast support GET, POST, PUT, DELETE methods URI support Small, 4-byte header Subset of MIME types and HTTP response codes Block Transfer and Observation modes Caching and proxying Build-in Resource Discovery IoT and WSNs

Page 51

CoAP: architecture Transactions: •  identified by a Transaction ID (TID). Messaging: •  Simple message exchange between endpoint Transport: •  UDP binding REST semantic: •  REST Request/Response piggybacked on CoAP messages IoT and WSNs

Page 52

CoAP: request/response layer The request/response layer is where the REST-based communication occurs. The CoAP request has the following format: GET coap://[]: []/[]

IoT and WSNs

Page 53

CoAP: request methods GET

used to obtain information from resources

POST

used to ask the server to create/update a resource on the given URI

PUT

used to update the resource with the enclosed message body

DELETE

used to delete a resource

•  Resources are identified by URIs •  CoAP methods are very similar to HTTP ones

IoT and WSNs

Page 54

CoAP: response codes •  After receiving and interpreting a request, a server responds with a CoAP response •  Every response has a code number that is specified in the Code field of the CoAP header (see next) •  Response codes are a subset of HTTP response codes Some CoAP response codes: Class Success 2.xx 2.01 Created: like HTTP 201 "Created", but only used in response to POST and PUT requests. 2.02 Deleted: like HTTP 204 "No Content", but only used in response to DELETE requests. 2.03 Valid: related to HTTP 304 "Not Modified". 2.04 Changed: like HTTP 204 "No Content", but only used in response to POST/PUT requests. 2.05 Content: like HTTP 200 "OK", but only used in response to GET requests. Class Client Error 4.xx 4.00 Bad Request: The client is not authorized to perform the requested action. 4.03 Forbidden: like HTTP 403 "Forbidden". 4.04 Not Found: like HTTP 404 "Not Found". Class Server Error 5.xx 5.00 Internal Server Error: like HTTP 500 "Internal Server Error". 5.04 Gateway Timeout: like HTTP 504 "Gateway Timeout”. IoT and WSNs

Page 55

CoAP: response codes (examples) REQ:

GET coap://node5.wsn1.dis.uniroma1.it/temperature

RES:

25C Response code: 2.05 Content

Code Header Field

"Not Found" is written as 100 00100, that's 132 in decimal notation, but also 4.04 in CoAP/HTTP notation.

IoT and WSNs

Page 56

CoAP: messages CoAP’s transaction layer can include four types of messages: •  confirmable (requires an ACK) •  non-confirmable (does not need an ACK) •  acknowledgement (ACK for a confirmable message) •  reset (indicates a confirmable message is received but context is missing to be processed).

IoT and WSNs

Page 57

CoAP: Message Header

IoT and WSNs

Page 58

CoAP: Confirmable request

IoT and WSNs

Page 59

CoAP: Confirmable request

IoT and WSNs

Page 60

CoAP: Dealing with Packet Loss

IoT and WSNs

Page 61

CoAP: Separate Response

IoT and WSNs

Page 62

CoAP: observation •  A client (the observer) can register itself to the resource (the subject) by means of a modified GET request. •  The server establishes an observation relationship between the client and the resource.

This functionality avoids the frequent server polling or keep-alive sessions that clients need to do.

IoT and WSNs

Page 63

CoAP: observation

IoT and WSNs

Page 64

CoAP: block transfer

IoT and WSNs

Page 65

CoAP:caching and proxying CoAP includes a simple caching model: •  Cacheability determined by response code •  Max-Age option indicates cache lifetime •  Validity checked using the Etag Option

A proxy: •  provides support for caching •  translates HTTP messages into CoAP messages. •  reduces network traffic IoT and WSNs

Page 66

CoAP:caching and proxying

IoT and WSNs

Page 67

CoAP: resources discovery GOAL: find URIs of the resources in a COAP server Resource Discovery is based on Constrained RESTful Environments (CoRE) Link Format (RFC6690): •  The CoRE Link Format can be used by a server to register resources with a resource directory •  Resource registration can be achieved by having the server POST its resources to "/.well-known/core” •  Resources links can then be discovered by any client by making a request to "/.well-known/core” : •  REQ: GET /.well-known/core?optional_query_string •  The response is a link-header style format: •  RES:

IoT and WSNs

Page 68

CoAP: resources discovery

;if="sensor",;if="sensor”

IoT and WSNs

Page 69

CoAP: energy efficiency Colitti et. al performed an experiment involving a CoAP-enabled Web server and an HTTP Web server on the Contiki embedded operating system. A request for the same resource was performed on both servers: CoAP transaction:

154 bytes

HTTP transaction:

1451 bytes

Power consumptions: CoAP transaction:

0.774 mW

HTTP transaction:

1.333 mW

CoAP transaction consumed 42% less power than the HTTP one. W. Colitti, K. Steenhaut, and N. De Caro, “Integrating Wireless Sensor Networks with the Web,” IoT and WSNs

Page 70

IoT protocol stack for WSN: Recap application

CoAP

transport

UDP

routing

IPv6

adaptation

6LoWPAN

medium access

802.15.4e

physical

802.15.4 (PHY)

IoT and WSNs

Page 71

OpenWSN implementation “The goal of the OpenWSN project is to provide implementations of a complete protocol stack based on Internet of Things standards, on a variety of software and hardware platforms.” •  open-source •  written in C •  supported platform: –  Gina –  Zolertia Z1 –  many others IoT and WSNs

Page 72

OpenWSN Architecture

IoT and WSNs

Page 73

OpenWSN – MAC layer The link layer consists of two sublayers: –  "02a-MAClow” It consists of the IEEE802.15.4e implementation and the associated timer. It runs entirely in ISR (interrupt service routine) mode and "executes" the schedule without modifying it –  "02b-MAChigh” It is responsible for managing the schedule. It runs entirely in task mode.

IoT and WSNs

Page 74

OpenWSN implementation The link layer consists of two sublayers: –  "02a-MAClow” It consists of the IEEE802.15.4e implementation and the associated timer. It runs entirely in ISR (interrupt service routine) mode and "executes" the schedule without modifying it –  "02b-MAChigh” It is responsible for managing the schedule. It runs entirely in task mode.

IoT and WSNs

Page 75

OpenWSN – Synchronization All nodes run a timer which fires at (and defines) the beginning every slot. The only convention to enable synchronization is that every packet is sent exactly TsTxOffset ms after the beginning of the slot. For every packet, the receiver timestamps the reception of the SFD. •  If this receiver were perfectly synchronized, that timestamp would be TsTxOffset. •  If it got desynchronized, that timestamp will be less or more than TsTxOffset. IoT and WSNs

Page 76

OpenWSN – Synchronization Resynchronization always consists in the slave aligning the boundary of its next slot to the same boundary on the master. The time master is that mote in the network which never synchronizes to any other mote Two types of synchronization •  Packet-based synchronization is used when the master sends a packet to the slave; •  ACK-based synchronization is used when the slave sends a packet to the master;

IoT and WSNs

Page 77

OpenWSN – Packet based The child expected the packet TsTxOffset into the slot, but received it correction later. To ensure that its next slot is perfectly aligned, it temporarily increases the size of the current slot to TsSlotDuration+correction.

The child receives the packet early. In this case, it temporarily decreases the size of the current slot.

IoT and WSNs

Page 78

OpenWSN – Ack Based The technique to synchronize is still the same, but it's now the master which measures the time correction. The master receives the data early. It indicates to the child the correction value in its ACK. After receiving the ACK, the slave temporarily increases its current slot length by correction.

The master receives the data late. It indicates the correction value in its ACK. After receiving the ACK, the slave temporarily decreases its current slot length by correction.

IoT and WSNs

Page 79

OpenWSN – Clock Drift The clock driving the timer should be the most stable clock source on the board often a 32kHz crystal are the most accurate clock source in a mote. But even the best clocks have some drift depending on: •  Manufacturing conditions •  temperature The amount of discrepancy in frequency is called clock drift. •  Good 32kHz crystals have a clock drift of 10 ppm (parts-permillion). •  If a crystal is 10ppm slow/fast, it "loses"/"gains" 10sec every million seconds, or 10usec every second. IoT and WSNs

Page 80

TinyOS RFXLink It is a library that defines a standard link layer for hardware platform supported by TinyOS. Modular architecture that allow add/remove functionalities easily. (Some) features: •  • 

• 

• 

• 

LOW_POWER_LISTENING: The radio will duty cycle the radio (turn it off and on). BACKOFF & SLOTTED_MAC mode: There are two CA (collision avoidance) algorithms: one is the simple random backoff. The other one is a slotted time sync based RADIO_DEBUG: IE component in the radio stack will make sure that everything goes as intended via RADIO_ASSERT macro. All assert violations are reported over the serial interface. TRAFFIC_MONITOR: It keeps track of the number of send end received bytes, the amount of time when the radio driver was turned on, and other statistics. PACKET_LINK: It provides standard functionality: retransmits messages when needed. IoT and WSNs

Page 81

TSCH & RFXLink Library

IoT and WSNs

Page 82

TSCH RFXLink Wiring IoT and WSNs

Page 83

References IoT: •  http://electronicdesign.com/communications/understanding-internet-things •  http://tools.ietf.org/html/draft-lee-iot-problem-statement •  http://www.utwente.nl/ewi/dacs/Colloquium/archive/2010/slides/2010utwente-6lowpan-rpl-coap.pdf TSCH: •  http://www.ietf.org/proceedings/87/slides/slides-87-6tsch-1.pdf •  http://www.ietf.org/mail-archive/web/6tsch/current/pptYjZGdKbZGS.ppt 6LoWPAN: •  http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpan-tutorial.pdf •  http://tools.ietf.org/html/rfc4944 •  https://tools.ietf.org/html/draft-daniel-6lowpan-interoperability-01 •  http://tools.ietf.org/html/draft-montenegro-lowpan-ipv6-over-802.15.4-02 CoAP: •  http://tools.ietf.org/html/draft-ietf-core-coap-18 •  http://www.slideshare.net/zdshelby/coap-tutorial OpenWSN: •  https://openwsn.atlassian.net/wiki/pages/viewpage.action?pageId=688187 IoT and WSNs

Page 84

Acknoledgement Some of the material shown today is taken from the: What is IEEE802.15.4e TSCH? by Maria Rita Palattella and Alfredo Grieco http://www.ietf.org/mail-archive/web/6tsch/current/pptYjZGdKbZGS.ppt 6LoWPAN Tutorial by David E. Culler and Jonathan Hui http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpantutorial.pdf CoAP: The Internet of Things Protocol by Zach Shelby http://www.slideshare.net/zdshelby/coap-tutorial

IoT and WSNs

Page 85

IoT vs Internet protocol stack

IoT and WSNs

Page 86