A Low-Power CoAP for Contiki Matthias Kovatsch Simon Duquennoy, Adam Dunkels Institute for Pervasive Computing Swedish Institute of Computer Science ETH Zurich, Switzerland Kista, Sweden Email: [email protected] Email: fsimonduq,[email protected] Abstract—Internet of Things devices will by and large Layer Protocol be battery-operated, but existing application protocols Application IETF CoAP / REST Engine have typically not been designed with power-efficiency in Transport UDP mind. In low-power wireless systems, power-efficiency is determined by the ability to maintain a low radio duty Network IPv6 / RPL cycle: keeping the radio off as much as possible. We Adaptation 6LoWPAN present an implementation of the IETF Constrained Appli- MAC CSMA / link-layer bursts cation Protocol (CoAP) for the Contiki operating system that leverages the ContikiMAC low-power duty cycling Radio Duty Cycling ContikiMAC mechanism to provide power efficiency. We experimentally Physical IEEE 802.15.4 evaluate our low-power CoAP, demonstrating that an existing application layer protocol can be made power- Figure 1. Low-power operation is done only in the Radio Duty Cycling (RDC) layer, thereby separating low-power operation from efficient through a generic radio duty cycling mechanism. the application layer. This reduces complexity and follows the layered To the best of our knowledge, our CoAP implementation is architecture that allowed the Internet to evolve. the first to provide power-efficient operation through radio duty cycling. Our results question the need for specialized low-power mechanisms at the application layer, instead providing low-power operation only at the radio duty The contribution of this paper is that we are the first cycling layer. to demonstrate power-efficient CoAP operation through radio duty cycling. These results challenge the need Keywords-Internet of Things; Web of Things; CoAP; embedded Web services; energy; radio duty cycling; for specialized power-management at the application layer: by constraining power management to the radio I. INTRODUCTION duty cycling layer, complexity can be removed from the The Internet of wireless things needs power-efficient application layer. protocols, but existing protocols have typically been de- II. BACKGROUND signed without power-efficiency in mind. In low-power wireless systems, the radio transceiver is typically the A. Power Efficiency through Duty Cycling most power-consuming component, so power-efficiency On typical IoT platforms, the radio transceiver is one translates into efficient radio duty cycling: the ability to of the most power-consuming components. Listening is keep the radio off as much as possible. as expensive as receiving packets. To conserve energy, The Internet protocol stack is a suitable solution to the radio transceiver must be switched completely off realize an Internet of Things (IoT), a network of tiny for most of the time. Several radio duty cycling (RDC) networked embedded devices that create a link to the algorithms have been designed, allowing nodes to keep physical world. The narrow waist of IP can be used to the radio chip off for more than 99% of the time while directly access sensor readings throughout a sustainable still being able to send and receive messages [4], [7]. city, acquire the necessary information for the smart In this work, we use the ContikiMAC RDC proto- grid, or control smart homes, buildings, and factories. col [4]. ContikiMAC is a low-power listening MAC The stack’s layered architecture helps to manage the protocol that uses an efficient wake-up mechanism to complexity. attain a high power efficiency: with a wake-up frequency We have implemented the IETF Constrained Appli- of 8 Hz, the idle radio duty cycle is only 0.6% [4]. cation Protocol (CoAP) [11] for Contiki, which enables The ContikiMAC principle of operation is shown in interoperability at the application layer through REST- Figure 2. Nodes periodically wake up to check the radio ful Web services. As depicted in Figure 1, we have channel for a transmission from a neighbor. If a radio integrated a full protocol stack necessary for an IoT and signal is sensed, the node keeps the radio on to listen for evaluated the system performance from an application the packet. When the data frame is received, the receiver layer perspective. sends an acknowledgment frame. To send a packet, the Send data packets until ACK received When RAM for IP and application buffers is limited, devices can only process a specific amount of data at Sender D D D D A Radio on a time. Larger data can be handled by storing these “chunks” in flash memory, for instance to receive a D Data frame new firmware or to provide a full datalog. To avoid Receiver D A A ACK frame the need of a secondary protocol to exchange these data, CoAP specifies a simple stop-and-wait mechanism Channel check Transmission detected called “blockwise transfers” [1]. Figure 2. A ContikiMAC sender wakes its neighbors up by sending III. A LOW-POWER COAP FOR CONTIKI a strobe of data frames until it gets an acknowledgment. We have implemented CoAP for the Contiki operat- ing system, taking advantage of the Contiki REST layer sender repeatedly sends the data frame until it receives abstraction. This layer provides a generic abstraction for an acknowledgment, or until the packet was sent for RESTful applications [12]. Our CoAP implementation 1 an entire wake-up period without an acknowledgment is available from a public Git repository . At the time being received. of writing, the code implements the CoAP draft speci- fication version 07, released on 8 Jul 2011. B. The Constrained Application Protocol A. The Contiki REST Engine The IETF Constrained Application Protocol (CoAP) Our REST Engine is an improvement of Contiki’s is an application-layer protocol designed to provide a REST layer by Yazar and Dunkels [12]. It provides REST-like interface [5], but with a lower cost in terms of macros to define and automatically instantiate RESTful bandwidth and implementation complexity than HTTP- Web service resources. The layering now follows Con- based REST interfaces. CoAP adopts patterns from tiki’s network stack model. This way, the application HTTP such as resource abstraction, URIs, RESTful code is fully decoupled from the underlying protocol, interaction, and extensible header options, but uses a and either CoAP-03, CoAP-07, or HTTP can be linked compact binary representations that are designed to be to implement the RESTful Web services. We provide the easy to parse. Unlike HTTP over TCP, CoAP uses UDP. necessary mapping of RESTful methods, status codes, This makes it possible to use CoAP in one-to-many and header options, query variables, and so forth to their many-to-one communication patterns. CoAP and HTTP representations. Central CoAP mechanisms are: The new REST Engine offers three abstractions to 1) Applications can send CoAP messages re- create RESTful resources: liably (“confirmable”) or non-reliably (“non- RESOURCE: A basic REST resource is defined by confirmable”). Confirmables are retransmitted URI-path, allowed methods, and a string for the Web with exponential timeouts until acknowledged by Linking [9] information. For every resource, the appli- the receiver or reaching the maximum number of cation must provide a resource handler function, which retransmissions. receives the request and generates the corresponding 2) CoAP is intended to provide group communica- response. Both messages are accessed through the tion via IP multicast, but this mechanism has not REST Engine API, which hides the actual implementa- yet been specified. tion (e.g., REST.set_header_etag(response, 3) CoAP features native push notifications through etag_buf, etag_len)). a publish/subscribe mechanism called “observing EVENT RESOURCE: This abstraction requires a resources” [6]. Clients can send a request with second handler function to be implemented by the an observe header option to a CoAP resource. application developer. A user-defined event triggers this The server keeps track of these subscribers and handler, which can be a button press or a PUT to another sends a response whenever the observed resource resource that caused a status update. changes. PERIODIC RESOURCE: Additional to the signa- 4) For resource discovery, CoAP follows RFC 5785 ture of the basic RESOURCE, the last macro takes a time by using the /.well-known/core path to interval. With it, the REST Engine periodically calls a provide resource descriptions in its CoRE Link second handler function similar to the one for events. Format [10]. This format extends Web Linking [9] This function can be used to poll on-board sensors and defines attributes for a semantical type (“rt”), and for instance perform a threshold check whether the interface usage (“if”), content-type (“ct”), and the resource should be considered as changed. maximum expected size (“sz”) of a resource. In addition, a directory service is intended. 1https://github.com/mkovatsc/SmartAppContiki Client Server Client Server message when finished (see Figure 3). Our implementa- Request Request tion provides a pre-handler that takes care of the ACK ACK and the configuration of the actual response with new Retransmission Request Request message ID and type. We envisioned to implement a processing processing benchmarking mechanism that automatically determines Retransmission response separation for resources. Due to our findings Response Response discussed in Section IV-E, it would, however, only ACK consume precious memory. We recommend to configure the pre-handler simply for every resource that might have a processing delay, for instance because of a slow (a) Without separate response (b) With separate response sensor. Figure 3. With separate responses, the server can notify the client that it received the request, enabling long processing times and avoiding E. Resource Discovery unnecessary retransmissions. The CoRE Link Format [10] is generated automatically for all resources. Our handler for /.well-known/core also respects chunk-wise In the end, a typical RESTful Web service application processing and generates the required substrings3 consists of a single C-file.