Standardized Protocol Stack for the Internet of (Important) Things

Transcription

1 CST543 Internet of Things 物聯網 Standardized Protocol Stack for the Internet of (Important) Things Palattella, Maria Rita, et al. Communications Surveys & Tutorials, IEEE 15.3 (2013): 吳俊興國立高雄大學資訊工程學系

2 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 2

3 Abstract This paper introduces the wireless communications stack the industry believes to meet the important criteria of powerefficiency, reliability and Internet connectivity A standardized approach, using latest developments in the IEEE and IETF working groups, is the only way forward IEEE PHY layer power-efficient IEEE e MAC layer Powersaving and reliable IETF 6LoWPAN adaptation layer Universal Internet connectivity IETF ROLL routing protocol Availability IETFCoAP Seamless transport and support of Internet applications 3

4 Internet of Computers and Internet of Things Application Layer CoAP: 4+ TCP: 20 UDP: 8 IPv4: 20 IPv6: 40 Ethernet: 26 Transport Layer Network Layer Link Layer Physical Layer Ethernet(802.3) Full Internet device High performance ZigBee( ) Limited Internet device Low rate UDP: LoWPAN: 2 MAC: 5 PHY: 6 Preamble 8 Dest. Address 6 Source Address 6 Proto Type 2 Payload CRC Bytes (max) 4

5 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 5

6 Origin of the IoT Term Kevin Ashton from the MIT Auto-ID Center proposed the term Internet of Things in early 2000 s Binding of Radio Frequency Identifiers (RFID) information to the Internet Concept adopted by the European Union in the Commission Communication on RFID in 2007, conclusions on Future Networks and the Internet: The Internet of Things is poised to develop and to give rise to important possibilities for developing new services but that it also represents risks in terms of the protection of individual privacy U.S. National Intelligence Council (NIC) reported in 2008 By 2025 Internet nodes may reside in everyday things, food packages, furniture, paper documents, and more Today's developments point to future opportunities and risks that will arise when people can remotely control, locate, and monitor even the most mundane devices and articles Popular demand combined with technology advances could drive widespread diffusion of an Internet of Things (IoT) that could, like the present Internet, contribute invaluably to economic development and military capability 6

7 Motivation Converged View: simple embedded sensor networking is now evolving to the much needed standards and Internet enabled communication infrastructure between objects To inter-connect as well as to Internet-connect Due to the nature of IoT objects, very low power consumptions are required so any object can plug into the Internet while being powered by batteries or through energy-harvesting Existing Internet protocols such as HTTP and TCP are not optimized for very low-power communication, due to both verbose meta-data and headers, and the requirements for reliability through packet acknowledgement at higher layers, which hinders the adaptation of existing protocols to run over that type of networks 7

8 Three Core Requirements for IoT Objects A Low Power Communication Stack The majority of objects have batteries at best Finding enough energy to power processing and communication is a major challenge Any stack must therefore exhibit a low average power consumption A Highly Reliable (but Efficient) Communication Stack Internet protocols incorporating techniques to support reliability at various protocol layers concurrently, which leads to a reliable end-to-end experience, albeit in a rather inefficient way The same or higher reliability need be achieved at highest possible efficiency An Internet-Enabled Communication Stack The Internet is exhibiting emergent behavior today because Communication is bidirectional Any machine around the world can talk to any other machine It is hence of paramount importance that the IoT is IP enabled 8

9 Events Shaping the IoT World 80 s - Distributed Sensor Networks program at the MIT Lincoln Labs 90 s - Smart Dust DARPA project at UC Berkeley 2000 ~ - Pioneering companies emerged Proprietary hardware communication stack and 2003 ~ IEEE and IETF standardization bodies started IEEE Defined Low-power PHY layer Medium Access Control (MAC) Foundation of ZigBee 1.0 and 2006 Unpredictable reliability issue 9

10 IEEE Working Group for WPAN Task Group 1: WPAN / Bluetooth Task Group 2: Coexistence Task Group 3: High Rate WPAN IEEE IEEE P a IEEE b-2006 IEEE c-2009 Task Group 4: Low Rate WPAN WPAN Low Rate Alternative PHY (4a) Revision and Enhancement (4b) PHY Amendment for China (4c) PHY and MAC Amendment for Japan (4d) MAC Amendment for Industrial Applications (4e) PHY and MAC Amendment for Active RFID (4f) PHY Amendment for Smart Utility Network (4g) Task Group 5: Mesh Networking Task Group 6: Body Area Networks Task Group 7: Visible Light Communication 10

11 Basic framework Range up to 10 meters Frames up to 127 bytes Transfer rate up to 250 kbit/s Initially defined 20 and 40 kbit/s in 868/915 MHz 250 kbit/s rate in 2450 MHz 100 kbit/s rate added in revision Three possible frequency bands MHz: Europe One communication channel (2003, 2006, 2011) MHz: North America Up to ten channels (2003), extended to thirty (2006) MHz: worldwide use Up to sixteen channels (2003, 2006) Two node types Full-function device (FFD): can serve as a coordinator to relay messages Reduced-function device (RFD): only communicates with FFDs Topologies Star Peer-to-peer (point-to-point): basis for ad hoc networks Routing not directly supported Cluster tree, mesh network 11 Link Layer

12 IEEE e Time Synchronized Mesh Protocol (TSMP) of Dust Networks Became the de-facto standard for reliable low-power wireless in industrial application Foundation of TSMP: time synchronized channel hopping Also became the foundation of the WirelessHART standard Integrated into IEEE e in 2011 Become a MAC protocol in the next revision of IEEE

13 IEEE e BlueTooth Low Energy 4.0+ IoT Standards K. S. J. Pister and L. Doherty, TSMP: Time Synchronized Mesh Protocol, in International Symposium on Distributed Sensor Networks, DSN, November 2008 HART Communication Protocol and Fundation, Available online: J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez, IPv6 over BLUETOOTH (R) Low Energy, IETF RFC 7668, Octobor 2015 N. Kushalnagar, G. Montenegro, and C. Schumacher, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals, IETF RFC 4919, August 2007 G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 Packets over IEEE Networks, IETF RFC4944, September 2007 T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. P. Vasseur, and R. Alexander, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, IETF RFC 6550, March 2012 J. P. Vasseur, M. Kim, K. Pister, N. Dejean, and D. Barthe, Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks, IETF RFC 6552, March 2012 Z. Shelby, K. Hartke, C. Bormann, and B. Frank, Constrained Application Protocol (CoAP), IETF RFC 7252, June 2014 M. Belshe, R. Peon, and M. Thomson, Hypertext Transfer Protocol Version 2 (HTTP/2), IETF RFC 7540, May

14 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 14

15 Low-Power Radio Hardware Receiver Low-power Radio (-90dBm sensitivity) Input: 1 pw (10-9 mw) (Low-Noise Amplifier) (Local Oscillator) (Band-Pass Filter) Low-power Radio Output: 0dBm / 1mW Transceiver (Power Amplifier) 15

16 Radio Hardware Challenge PA and LNA all draw substantial amounts of current, making the radio the most power-hungry component in most designs The radio does not consume any energy when off The challenge of a good communication stack is to enable reliable transmission of data, while keeping the radio off most of the time An energy-efficient communication stack has a duty cycle (far) lower than 1% Radio duty cycle is the portion of time the radio is on, either transmitting or receiving 16

17 Comparison of Different Compliant Devices Power range from -50 dbm to +5 dbm (default 0 dbm) Optimizing the power consumption of a system is to Lowering current consumption in transmit and receive mode Lowering the duty cycle of the radio (having the radio off most of the time) 17

18 Example: Effects of Power Consumption and Duty Cycle Assuming the mote is powered by a pair of AA batteries, holding 3000 mah of charge AT86RF231: draws 13 ma when on A protocol which left the radio always on (duty cycle = 100%) 3000 mah / 13 ma = 230 h (or less than 10 days) A protocol with a 1% radio duty The lifetime increases by a factor of 100, to 23,000 h (near 32 months) LTC5800: draws 5 ma when on A protocol with a 1% radio duty 3000 mah / 5mA / 1% = 60,000 h (near 7 years) 18

19 PHY of IEEE Most widely used: GHz (Worldwide, unlicensed) 16 channels * 5 MHz between GHz and GHz Only 2 MHz wide/channel to prevent interfering with neighboring channels Switch channels in no more than 192 us 2 Mbps physical data rate 250 kbit/s transfer rate Direct Sequence Spread Spectrum (DSSS) (8x) Offset-Quadrature Phase-Shift Keying (O-QPSK) 2-bit modulation 4-bit data encoded as 32 chips (physical bits) using a simple lookup table Sending a packet (Max 128 Bytes) Preamble for 128 us SFD (Start of Frame Delimiter) Frame Length (Max 127 Bytes) Bytes (max) 19

20 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 20

21 IEEE e Power-Saving Link Layer Motivation: IEEE MAC Sublayer (2003) Geared toward star networks: a special coordinator mote Ill-suited for low-power multi-hop networking due to Power hungry to keep 100% duty cycle for relay messages Single channel operation: interference makes the network instable Revision: IEEE e MAC Sublayer (2010) Enables high reliability while maintaining very low duty cycles Channel hop for reliability Synchronize the motes for energy efficiency TSCH (Time Synchronized Channel Hopping) since 2010 based on TSMP (Time Synchronized Mesh Protocol) in

22 TSCH Slotframe Structure Slotframe: a group of slots which repeat over time A single slot is longer enough For the transmitter to send a maximum length packet For the receiver to send back an acknowledgement The slot duration is implement-specific, 10 ms suggested Each mote follows a schedule which tells it what to do in each slot: either transmit, receive, or sleep Sleeping slot: turn off its radio Active slot: the schedule indicates With which neighbor to transmit or receive On which channel offset 22

23 TSCH Transmission and Reception Slots At each transmission slot The MAC layer checks whether it has packet in its queue destined to the neighbor associated with that slot YES: turns the radio on and transmits the packet and waits for the ACK If ACK received, removes the packet from the queue Otherwise, keeps the packet in the queue NO: keeps the radio off At each reception slot The mote turns on its radio right before the time it expects to receives the packet If it receives a packet destined for it, it Sends an acknowledgement Turns off its radio Forwards the packet to the upper layer If not received (timeout), it returns to sleep 23

24 An Example Topology with the Associated Schedule The slotframe is 5 slots long and there are 6 channel offsets Each mote only cares about the cells in participates G D: Waits for slot 3, and sends it on channel offset 0 D A and C A: shared, backoff for collision G A: G D, buffered at D, and then D A 24

25 IEEE e Scheduling IEEE e Defines how the MAC layer executes a schedule Does not specify how such a schedule is built Scheduling challenges When mote A has a transmit slot to mote B, B is actually listening for packets from A If A is no longer a neighbor of B, B should not be listening anymore for packets from A Constantly refreshes as links come and go Two approaches to the schedule Centralized: a specific manager mote is responsible Every mote in the network regularly updates the manager with the list of other motes it can hear, and the amount of data it is generating The manager builds and updates its schedule, and informs the affected motes Distributed: motes decide locally Internet-like reservation protocols such as RSVP and MPLS could be applied Remains a very open issue 25

26 TSCH Synchronization Device-to-device synchronization is necessary in a slotframe-based network TSCH defines two methods Acknowledgment-Based Synchronization The receiver Calculating the delta between the expected time of frame arrival and its actual arrival, and Providing that information to the sender mote in its acknowledgment This allows a sender mote to synchronize to the clock of the receiver Frame-Based Synchronization The receiver Calculating the delta between the expected time of frame arrival and its actual arrival, and Adjusting its own clock by the difference This allows a receiver mote to synchronize to the clock of the sender Re-synchronization If there is traffic, re-synchronize using the data frames they exchange If no traffic for some time (ie. 30s), motes exchange keep-alive messages Time propagates outwards from the coordinator Maintain unidirectional time propagation and avoid timing loops The direction of time propagation is independent of data flow in the network Each mote determines whether to follow a neighbor s clock based on the presence of a ClockSource flag in the corresponding neighbors record (configured by the network manager in a centralized system) 26

27 Channel Hopping Channel hopping: mitigates the effects of interference and multipath fading Improves reliability by combining with slot access Multiple channels: more motes can transmit their frames at the same time using different channel offsets 16 channels available for IEEE e A blacklist can be used to restrict the set of allowed channels for coexistence purposes f = F{(ASN + chof) modn ch } where Function F: the set of available channels realized with a look-up-table chof: channel offset ASN: absolute slot number, the total number of slots ASN =(k * S + t), where S is the slotframe size and t is the slot number 0 t S 1 n ch : number of available frequencies (channels); size of a look-up-table S and n ch are relatively prime, each link rotates through k available softframe cycles Successive frames over a same link are sent over different physical frequencies in successive slotframe cycle k 0 chof n ch -1 27

28 Network Formation: Advertising and Joining Networ formation in TSCH networks includes two components Advertising Joining Joining a network A new device trying to join the network listens for Advertisement command frames When at least one of these frames is received, the new mote joins the network by sending a Join Request command frame to an advertising device In a centralized management system, Join Request frames are routed to the network manager In a distributed management system, they can be processed locally When a new mote is accepted into the network, the advertiser activates the mote by setting up slotframes and links between the new mote and other existing ones Once all the motes have joined the network i.e., the network manager has not received any Join Request frames during a timeout period, the Advertising procedure can be disabled 28

29 Network Ramp-Up Example Network manager A with two motes B and C using a slotframe of 7 slots Network Manager Slotframe # Operation 0 B A: Join Request 1 A B: Join Response 2 A B: Set Link 3 C B A: Join Request 4 A B C: Join Response 5 A C: Set Link 6 A B: Set Link 29

30 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 30

31 Characteristics of Low Power WPAN Characteristics of low power WPAN Small packet sizes (127 bytes) Support for addresses with different lengths Low bandwidth Star and mesh topologies Battery supplied devices Low cost Large number of devices Unknown node positions High unreliability Long idle periods during when communications interfaces are turned off to save energy The IP-over-X specification introduces a (sub-)layer, called adaptation layer, to define how to transport IP packet over X IPv6 over Low power WPAN (6LoWPAN) 31

32 Consideration of IPv6 for Low Power WPAN IPv6 consideration With default minimum MTU size (i.e., 1280 bytes), a no-fragmented IPv6 packet would be too large to fit in an IEEE frame (i.e., 127 bytes) The overhead of 40 bytes long IPv6 header would waste the bandwidth available at the PHY layer Further adaptations Auto-configuration Compliance with the recommendation on supporting link-layer subnet broadcast in shared networks Reduction of routing and management overhead Adoption of lightweight application protocols (or novel data encoding techniques) Support for security mechanisms (i.e., confidentiality and integrity protection, device bootstrapping, key establishment and management) 32

33 6LoWPAN Frame Format An intermediate adaptation layer between IPv6 and IEEE MAC levels IPv6 header and Next Headers may be compressed Encapsulated datagrams are prefixed by a stack of headers, each one identified by a type field Each header may be present or not Headers should appear in a precise order NO 6LoWPAN: the packet is not compliant to 6LoWPAN (To be discarded) Dispatch: to compress an IPv6 header or to manage link-layer multicast/broadcast Mesh Addressing: allow frames to be forwarded at link-layer (multi-hop) (next slide) Fragmentation: a datagram does not fit within a single IEEE frame First 2 bits Following bit combinations NO 6LoWPAN 00 xxxxxx Any combination Dispatch 01 Mesh Addressing 10 Fragmentation Additional Dispatch byte follows Uncompressed IPv6 Addresses LOWPAN_HC1 compressed IPv LOWPAN_BC0 broadcast 1xxxxx LOWPAN_IPHC compressed IPv6 xxxxxx Any combination 000xxx First Fragmentation Header 100xxx Subsequent Fragmentation Header 33

34 Mesh Addressing Header An Originator device may use other intermediate devices as forwarders toward the Final Destination device AMesh Addressing Header is used prior to any other headers of the 6LoWPAN encapsulation For each forwarder node, it includes the link-layer addresses of the considered forwarding node and of the next-hop node, in addition to the link-layer addresses of the Originator and of the Final Destination The IEEE standard does not define any routing capability and relies on functions of upper layers to do this task A routing protocol that can be used for populating the routing table Multicast/broadcast communication at link layer A Broadcast Header immediately follows the Mesh Addressing Header For controlled flooding mechanisms (e.g., the one described in Sec.V) or for topology discovery It is a kind of Dispatch Header and it includes a 1-byte long Sequence Number for detecting and, thus, suppressing duplicate packets 34

35 Fragmentation Header Must follow Mesh Addressing and Broadcast headers, if present Header includes Datagram Size: the dimension of the entire IP packet before link layer fragmentation (it shall be the same for all link layer fragments of an IP packet) Datagram Tag: all fragments of an IP packet carry the same tag Datagram Offset: specifies the offset of the fragment from the beginning of the payload obviously it is present only in the second and subsequent fragments 35

36 Header Compression Within the same WPAN, many IPv6 header fields are expected to be common and/or easy to derive without requiring their explicit indication by the sender Payload Length can be inferred either from the MAC Frame Length or from the Datagram Size field in the fragmentation header Hop Limit will be set to a well known value by the source Addresses assigned to 6LoWPAN interfaces are formed with an Interface Identificator derived directly from MAC addresses 36

37 LOWPAN_IPHC Encoding Scheme A 13-bit LOWPAN_IPHC (IP Header Compression) encoding field is appended to the first 3 bits of the Dispatch Type If some of the IPv6 header fields have to be carried in clear, they follow the LOWPAN IPHC encoding The 40-byte IPv6 header is compressed down to 2 bytes in the best case for an IPv6 link-local communication 7 bytes when routed through multiple hops TF: Traffic Flow (i.e. 11=no bits) N: Next header, set if LOWPAN_NHC header follows, or an in-line next header followed (next slide) HLM: Hop LiMit (1; 64; 255; 00: a separate byte sent) C: CID-Context ID, set if a third byte is added to specify source and destination address M: Multicast, set if the destination is multicast address S/SAM: source address ; D/DAM: destination address 37

38 LOWPAN_NHC (Hext Header Compression) N bit in the LOWPAN_IPHC header is set Defined similar to the dispatch byte LOWPAN_NHC base header for UDP Length is always elided C: set if checksum is removed P: port compression The 8-byte UDP header is compressed down to 32 bits: both ports uncompressed (16 bits) 8 bits: 4 bits for each port Best-case LOWPAN_IPHC IPv6 packet 38

39 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 39

40 IETF ROLL Working Group RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks (LLN) (RFC 6550, Feb 2013) Support link layers of constrained, lossy, or limited resources Destination Oriented Directed Acyclic Graph (DODAG), identified with a DODAGID, is created by accounting for link costs node attributes/status information an Objective Function: map optimization requirements The topology is set-up based on a Rank metric, which encodes the distance of each node with respect to its reference root RPL encompasses different kinds of traffic and signaling information exchanged among nodes RPL traffic Multipoint-to-Point (MP2P): destinations are usually the DODAG roots Point-to-Multipoint (P2MP): sent from DODAG roots to destination nodes Point-to-Point (P2P): communications between two devices 40

41 Instances of RPL Topology Multiple instances of RPL may run concurrently on the network devices Each instance has specific routing optimization objectives, such as the minimization of delay and energy consumption a RPLInstanceID is employed to identify one of the possible RPL instances running on the same network Three simple topology examples 1. A single DODAG with just one root The simplest RPL topology A WSN monitors a small size area 2. Multiple uncoordinated DODAGs with independent roots the LLN is split in several partitions depending on the needs of the application context 3. A virtual root coordinating several LLN root nodes The absence of limitations on the parent set selection 41

42 RPL Topology Formation RPL information dissemination mechanism Enables a minimal configuration in the nodes and allows them to operate mostly autonomously DODAG Information Option (DIO) messages Containing information about the Rank, the Objective Function, the IDs, and so on Multicasted (periodically and link locally) by each node to create the DODAG, thus establishing paths towards the roots A node receiving a DIO message uses its information to join a new DODAG, or to maintain an existing one, according to the Objective Functions and the Ranks of their neighbors Node operations for network formation and management Send and receive DIOs Compute their own Rank, based on information included in received DIOs Join a DODAG and select a set of possible parents in that DODAG among all nodes in the neighborhood Select the preferred parent among the possible ones 42

43 Rank(N): Rank of Node N Upward Route with Rank Update x : the greatest integer less than or equal to x MinHopRankIncrease: implementation-dependent minimum hop rank increase value, the minimum difference between Rank of a node and Ranks of its possible parents DODAG root sets its Rank equal to the value MinHopRankIncrease Upon a DIO message is received from a neighbor, a node setups its own Rank to a value that is a function of both the neighbor Rank and the cost to reach the DODAG root through it (like distance-vector) Its set of possible parents contain only that neighbor, if one of the following conditions is true: (i) the node Rank was not already setup; (ii) the old value, A, of the node Rank and the computed one, B, verify the relation DAG Rank(A) >DAG Rank(B) if DAG Rank(A) =DAG Rank(B), neighbor added to the set of possible parents Finally, each node can select its preferred parent within its set of candidate parents based on several possible rules, such as Objective Function, path cost, Rank, and so on 43

44 Downward Paths for P2MP and P2P Destination Advertisement Object (DAO) messages RPL uses DAO messages to back-propagate routing information from leaf nodes to the roots Triggered by the reception of a DIO message, or in global and local repair operations After receiving a DAO message, each node forwards it to its parent at the expiration of a timer, which is implementation-dependent To avoid redundancies and to control the signaling overhead For each node, the trickle algorithm triggers a new DIO message only when the overall amount of control packets already sent in the neighborhood of that node is small enough 44

45 RPL Control Messages Encapsulated into ICMPv6 packets Code: kind of control message Base: RPL message header the basic information related to the functions of the carried object Options: body of such messages May be composed of any combination of optional functions (padding, metric containers, route information, DODAG configuration, RPL target, and so on) Possible metrics: node energy, hop count, link throughput, latency, link reliability, and link color (specific properties of links used to include or exclude) such links) Each message has a secure variant providing integrity and protection as well as optional confidentiality and delay features 45

46 Objective Function Translates key metrics and constraints into a Rank A rank models the node distance from a DODAG root Allows the selection of a DODAG to join and the identification of a number of peers in that DODAG as parents All candidate neighbors are examined to evaluate if they can act as RPL router Exclude all those links and candidate nodes that do not match basic Objective Function compatibility rules, e.g., related to security issues, performance, an so on The preferred parent is elected as the one that can grant the smallest Rank 46

47 Objective Functions Proposed by IETF Objective Function 0 A node Rank is obtained by adding a normalized scalar, RankIncrease, to the Rank of a selected preferred parent The RankIncrease value is a multiple of 0x100, so that Rank values can be stored in one octet Requires only the information in the RPL DIO header A common denominator among all generic implementations Since It might happen that there are multiple different implementations for a specific problem or environment Minimum Rank Objective Function with Hysteresis A node switches to the minimum cost path, NewPathCost, only if the following inequality is verified: CurrentPathCost: the path cost of the current path γ: the PARENT_SWITCH_THRESHOLD Employs a DODAG parent set with only one node This node is automatically chosen as the preferred parent 47

48 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 48

49 Issues of LLN Applications using IPv6 A LLN using IPv6 Wide range of devices with different capabilities From full servers to constrained devices consisting of 8-bit or 16-bit microcontrollers with wireless network interfaces Nodes can be addressed and information can be routed directly through the network without NAT For complete Internet compatibility, some features which are not addressed by the network layer are required It would be desirable that a node manage multiple non-interfering requests Requires to talk application layer protocols to interoperate with existing applications As classical networks do not need to operate with energy restrictions, content tagging and metadata are not optimized for minimum packet overhead; this limits their integration in LLN applications A set of techniques to compress application layer protocol metadata are proposed Optimized Transport Layer and Application Layer are required 49

50 Transport over LLNs IPv6 supports packet fragmentation into 127 bytes long packets TCP for LLNs Traffic control and reliability are expensive in terms of number of transmitted packets and end to end packet confirmation Expensive energy requirements imposed by end to end reliability Two academic proposals Lightweight TCP implementation based on the use of caching the use of Selective Repeat variant Use of UDP and retransmission control mechanisms at application layer are demonstrating a good trade-off between energy cost and reliability UDP: datagram-oriented Provides application multiplexing through the concept of port Delivery and duplicate protection are not guaranteed Compression of UDP headers is supported in 6LoWPAN HTTP: simple, popular request-response Overhead of content tagging and metadata 50

51 Constrained Application Protocol (CoAP) Defines a subset of RESTful specification Instead of blindly compressing HTTP Easily translates to HTTP Meets specialized requirements: multicast support, very low overhead, and simplicity for constrained environments Two-layer asynchronous request/response protocol Request/response layer: mapping requests to responses and their semantics Message layer: reliability and sequencing Features Constrained web protocol specialized to M2M requirements. Stateless HTTP mapping through the use of proxies or direct mapping of HTTP interfaces to CoAP UDP transport with application layer reliable unicast and best-effort multicast support Asynchronous message exchanges Low header overhead and parsing complexity URI and Content-type support Simple proxy and caching capabilities Optional resource discovery 51

52 CoAP Message Layer Control message exchanges over UDP between two endpoints Requests and Responses share a common message format Messages are identified by an ID used to detect duplicates and for reliability Four types of messages Confirmable: Messages that require a response Response can be piggybacked in an acknowledgement or sent asynchronously in another message if the response takes too time to be computed. Confirmable messages that cannot be processed are replied with a Reset message Non-Confirmable: Messages that do not need to be neither acknowledged nor replied In case they cannot be processed, they are ignored Multicast messages are supported being only possible for Non-Confirmable messages Acknowledgement: Messages that confirm the reception of a confirmable message They can contain the piggybacked response to the confirmable message Reset: In case a confirmable message cannot be processed 52

53 CoAP Request/Response Layer CoAP messages include either a method or response code Optional (or default) request and response information, such as the URI and payload content-type are carried as CoAP options A Token Option: to match responses to requests independently A Request consists of the method that should be applied to the resource the identifier of the resource a payload and an Internet media type (if any) an optional meta-data about the request A Response is identified by the Code field (similar to the HTTP Status Code) Indicates the result of the attempt to understand and satisfy the request Reliability mechanism CoAP messages may arrive out of order, duplicated or lost Reliability works over Confirmable messages Receiver must acknowledge it or reject it by sending a Reset message Sender retransmits the Confirmable message at exponentially increasing intervals, until it receives an acknowledgment (or Reset message), or runs out of attempts (controlled by a retransmission counter) Features Simple stop-and-wait retransmission with exponential back-off for confirmable messages Duplicate detection for both confirmable and non-confirmable messages. Multicast support 53

54 CoAP Frame Format A fixed-sized CoAP Header followed by options in Type-Length-Value (TLV) format and a payload Version: 2 bits, set to 1 in the current version Type: 2 bits, (0) Confirmable, (1) Non-confirmable, (2) Ack, (3) Reset OC (Option Count): 4 bits, indicate the number of options in the message Code: 8 bits, indicate a request method or a response code Message ID: 16 bits, a unique ID to detect duplicates Options: Option list in TLV format Payload: content of the message Defined by the Content-Type Option Error responses include a human-readable description of the error such as Bad Gateway 54

55 CoAP Basic Methods and Responses Request Methods GET: Idempotent and safe operation that retrieves a representation for the information corresponding to the resource identified by the request URI POST: Requests the processing of the representation enclosed in the resource identified by the request URI Normally it results in a new resource or the target resource being updated. The method is neither safe nor idempotent PUT: Requests that the resource identified by the request URI be updated or created with the enclosed representation The representation format is specified by the media type given in the Content-Type Option. PUT is not safe but idempotent DELETE: The method requests that the resource identified by the request URI be deleted Response codes Success Codes 2.XX: request has been received, understood and accepted E.g. code 2.01 is analogous to HTTP code 201 Created but only in response to POST and PUT requests Client Error Codes 4.XX: a client incurred in some error E.g. code 4.04 is the same as HTTP code 404 Not Found Internal Server Error Codes 5.XX: a server is not able to carry out the request E.g analogous as HTTP 502 code Bad Gateway 55

56 CoAP URIs, Caching and Proxying CoAP URIs UDP port Query in the form of key=value pairs Cache support HTTP: Client sends a Conditional GET with If-Modified-Since CoAP: Server tags responses with explicit Max-Age option The age that will maintain the response cached until its expiration By default the Max-Age option is 60s Proxy support Requests distinguished between to origin or proxy server CoAP requests to a proxy are made as Confirmable or Non-Confirmable Setting the Proxy-Uri Option and splitting the request URI to the Uri-Host, Uri- Port, Uri-Path and Uri-Query Options 56

57 CoAP Application Layer Protocols Mapping CoAP implements a subset of the HTTP functionalities Direct mapping to HTTP Also easily mapping to Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) Mapping through an intermediary CoAP clients access resources on HTTP servers Initiated by Including the Proxy-Uri Option with an http URI in a CoAP request to a CoAP-HTTP proxy, or Sending a CoAP request to a reverse proxy that maps CoAP to HTTP Translating the HTTP Status codes to the Response Codes in CoAP HTTP clients access resources on CoAP servers Initiated by Specifying a coap URI in the Request-Line of an HTTP request to an HTTPCoAP proxy, or Sending an HTTP request to a reverse proxy that maps HTTP to CoAP The mapping requires a filtering of those codes, options, and methods that are not supported by CoAP 57

58 Outline I. Introduction II. Low-Power PHY Layer IEEE III. Power-Saving Link Layer IEEE e IV. Connecting to the Internet IETF 6LoWPAN V. Routing IETF ROLL VI. Transport Layer and Above IETF CoAP VII. Concluding Remarks 58

59 Lessons Learned Lessons learned A very promising wireless communication stack for the IoT has been deeply analyzed Helps the reader catch the reasons why this new proposal is quickly gaining consensus in important industrial applications Contribution Outline a technically viable (standardized) communication architecture able to support the stringent energy and connectivity needs of the emerging IoT 59

60 Conclusions PHY Current IEEE PHY layer suffice in terms of energy efficiency Future: ultra low rate transmissions over very narrow frequency bands MAC Current IEEE MAC layer(s) do not suffice Industrial multihop/mesh applications under extreme fading and interference conditions No optimal centralized or decentralized scheduling protocols been put forward Network - 6LoWPAN Instrumental in connecting low power radios to the Internet Open issues Suitable choice of the embodiment of the objective function Inclusion of trust Ability to run over any link layer protocol Application CoAP Same design principles as HTTP Acting as a true enabler for the IoT 60