CoAP for the Web of Things:From Tiny Resource-constrainedDevices to the Web Browser

Matthias KovatschInstitute for PervasiveComputingETH ZurichZurich, Switzerlandkovatsch@inf.ethz.ch

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are notmade or distributed for profit or commercial advantage and that copies bearthis notice and the full citation on the first page. Copyrights for componentsof this work owned by others than the author(s) must be honored. Abstractingwith credit is permitted. To copy otherwise, or republish, to post on servers orto redistribute to lists, requires prior specific permission and/or a fee. Requestpermissions from permissions@acm.org.UbiComp’13 Adjunct, September 8–12, 2013, Zurich, Switzerland.Copyright is held by the owner/author(s). Publication rights licensed to ACM.ACM 978-1-4503-2215-7/13/09...$15.00.

http://dx.doi.org/10.1145/2494091.2497583

AbstractThe Constrained Application Protocol (CoAP) is a new Web

protocol standardized by the IETF. It is not a mere

compression of HTTP, but a re-design from scratch following

the REST architectural style. Thus, its features are tailored for

Internet of Things (IoT) applications and machine-to-machine

(M2M) scenarios with highly resource-constrained devices.

While this makes CoAP very interesting for the Web of Things

(WoT) initiative, it is still detached from the Web world of

browsers and intuitive user interaction. We present the first

attempts to unite these two worlds, so that everyday objects

endowed with tiny, low-cost computing devices can become

first class citizens of the Web. Our Copper (Cu) project brings

CoAP support to the Web browser and has been out in the

wild since late 2010. Thus, we were able to conduct a user

study among industry and research developers who know both,

Web-based CoAP and earlier proprietary protocols for

networked embedded systems. The result shows that industry

developers and those with longer experience agree even more

that Internet protocols and patterns from the Web ease

application development for tiny, resource-constrained devices.

Author KeywordsCoAP; WoT; IoT; Web browser; scripting; user study

ACM Classification KeywordsH.5.m [Information interfaces and presentation]: Misc.

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1495

Introduction

Figure 1: The Tmote Sky is ahighly resource-constrainedplatform: It only has 48 KiB ofROM and 10 KiB of RAM. It isable to implement anRFC-compliant IP stack togetherwith an energy-saving MACprotocol and CoAP at theapplication layer. The programflash is, however, too small toalso include the cryptographiclibraries required for a fullsecurity handshake. Requiringextreme optimization or externalsupport makes the Tmote Sky aborderline Class 0 device.

Web technology is ubiquitous. Using the Web has becomepart of our everyday lives and, moreover, many tech-savvypeople without explicit training are able to create theirown Web applications. Thus, the Web of Things initiativeaims for applying the well-known and proven patternsfrom the Web to the demanding IoT domain [3, 20]. As aresult, devices can be browsed and bookmarked, Webpages can directly include real-time data from sensors,and users can build physical mashups that augment andcontrol their everyday objects [5]. This is an importantstep from traditional networked embedded systems to atruly ubiquitous Internet of Things.

In this course, the IETF has been standardizing theConstrained Application Protocol (CoAP) [16]. It is a newWeb protocol that was designed to meet the requirementsof highly resource-constrained devices and M2M scenarios.CoAP closes the gap between microcontroller-basedlow-power devices and the Web of Things, as HTTP overTCP is not feasible in these environments. RESTfulapplications can now talk end-to-end to tiny devices usingURIs for addressing and uniform interfaces for interaction.

Yet CoAP targets M2M applications without the directuser interaction known from the Web of Things. Our goalis to push CoAP closer to the Web world of browsers withintuitive front-ends, easy scripting, and the human in theloop. For this, we enabled CoAP support directly in theWeb browser and released Copper (Cu)1, a Firefox add-onwhose source code is also available on GitHub2. Inanother project, we extended the JavaScript languagewith an API for direct interaction with tiny IoT devices[9]. Our CoapRequest object is similar to AJAX’s

1https://addons.mozilla.org/de/firefox/addon/copper-270430/2https://github.com/mkovatsc/Copper

XmlHttpRequest and allows to create mashups with tinydevices without the need for application-level gateways.

The WoT initiative mainly advocates the ease ofapplication development resulting from the adoption ofWeb patterns. To evaluate this intuitive feeling, Guinardat al. conducted a study with 69 computer sciencestudents [4]. It shows that REST is considered easier tolearn and more suitable for programming IoT devices thanthe RPC-like WS-* Web services.3

With Copper (Cu) available since late 2010 and around400 steady users, we were able to find 48 participants toconduct a related study that, apart from researchers, alsoincludes 16 industry developers. This paper focuses moreon the Web integration of devices opposed to traditionalnetworked embedded systems. Those usually runproprietary protocols that are highly optimized for a givenapplication, but increase development costs and causetechnological islands. The study supports our hypothesisthat Internet and Web protocols ease development in thisdomain. Furthermore, it also gives good input on how tocontinue with the seamless integration of CoAP into theexisting Web.

Constrained Application Protocol (CoAP)In 2010, the Internet Engineering Task Force (IETF)charted a new working group for “Constrained RESTfulEnvironments” (CoRE). Its goal is to provide a frameworkfor resource-oriented applications intended to run onconstrained IP networks. These networks consist ofresource-constrained devices, which the IETF divides into

3 In a business environments where many WS-* services and more-over policies for QoS and security are already established, WS-* isrecommended. Here, the Devices Profile for Web Services (DPWS)is a good alternative that also builds on IP connectivity for resource-constrained devices. [10]

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1496

the following three classes. Note that the given memorysizes are not strict rules, but rather a rule of thumb. Theclassification is mainly decided through the devicecapabilities:

Class 0 devices are not capable of running anRFC-compliant IP stack in a secure manner. Theyrequire application-level gateways to connect to theInternet.

Class 1 devices are the most resource-constrained devicesthat can directly connect to the Internet with integratedsecurity mechanisms. This requires about 100 KiB ofROM and about 10 KiB of RAM. They cannot employ afull protocol stack using HTTP over TLS, though, andrequire lightweight and energy-efficient protocols. Thisclass is in the focus of the CoRE working group.

Figure 2: New platforms with anARM Cortex-M3 SoC fall intothe Class 1 category. With128 KiB of ROM and 16 KiB ofRAM they have enough space fora full network stack securedthrough Datagramm TransportLayer Security (DTLS). LargerCortex versions with up to 1 MiBof ROM already fall into Class 2.

Class 2 devices almost show the characteristics of normalInternet nodes like notebooks or smartphones, which ispossible with about 250 KiB of ROM and about 50 KiBof RAM. Yet they can still benefit from lightweight andenergy-efficient protocols to free resources for theapplication or reduce operational costs.

Also other networking aspects are subject to constraintssuch as low achievable data rates and high packet loss.Class 1 devices have very limited buffers and mostly uselow-power communications such as IEEE 802.15.4through 6LoWPAN (IPv6 over Low power WirelessPersonal Area Networks) [7]. The verbosity of HTTP isill-fitted for such environments. Also TCP performs badlywhen it is only used for short-lived request/responseexchanges instead of bulk data transport. The SYN/ACKhandshake alone might take a second when a low radioduty cycle is required for battery operation.

Thus, the working group designed a new protocol suitefrom scratch that goes far beyond a simple compression ofHTTP (cf. EBHTTP [19]). Following the RESTarchitectural style [2], CoAP is based on patterns from theWeb: a request/response interaction model betweenapplication endpoints, uniform interfaces that allow forinteroperability, resources that are addressable by URIs,Internet Media Types that represent resource state, andcaching and proxying to enable scalability.

CoAP is a binary protocol that runs over UDP. Amessaging sub-layer adds a thin control layer that providesduplicate detection and optionally reliable delivery ofmessages based on a simple stop-and-wait mechanism forretransmissions. On top, the request/response layerenables RESTful interaction through the well-knownmethods GET, PUT, POST, and DELETE as well as responsecodes that are defined with only a few deltas to theHTTP specification [1]. In addition, CoAP offers featuresthat make the real difference for the IoT.

Observing ResourceCoAP enables native push notifications. Clients can“observe” resources for state changes through a simplepublish/subscribe mechanism [6]. The server keeps trackof interested clients and pushes the new representationwhenever the observed resource changes. This follows abest-effort approach and aims to guarantee eventualconsistency. That means not every state change will arriveat the clients, but all clients will eventually receive thelatest representation of the resource. This can becompared to the debouncing of a button, whereintermediary states can be ignored and filtering is actuallydesirable. However, Reliable propagation of every eventcan still be achieved with the right design of the resourceand its representations.

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1497

Group CommunicationBeing based on UDP, CoAP is able to use IP multicast toprovide RESTful group communication. Clients can usesafe and idempotent methods to interact with a group ofdevices. Group management and best practices aredefined in a supplementary document [13].

Resource DiscoveryThe CoRE working group also defined a format forresource metadata, the CoRE Link Format [15]. It isbased on Web Linking [11] and uses link attributes toprovide information such as the provided content formats(“ct”) or and the maximum expected size (“sz”) of aresource. It is also used to annotate light-weight semanticinformation such as resource type (“rt”) or interfaceusage (“if”). CoAP servers provide a list of all theirresources at the well-known URI path/.well-known/core [12]. This list can also be filteredusing the desired attributes as URI query parameters. Onstart-up, endpoints can also register at a resourcedirectory [17] to enable look-ups while the node issleeping or otherwise disconnected from the network.

Alternative Transportscoap+sms://+123456789/

container/bananas/temperature

Figure 3: CoAP does not onlywork over IP. Alternativetransports also use URIs foraddressing. Being delay tolerant,CoAP can for instance run overSMS, which uses its own reliableand delay-tolerant delivery.

Although UDP is the primary transport for CoAP, theprotocol was designed to run over several alternatives aswell, including TCP for back-end purposes. Many IoTdevices are connected though cellular networks that do nothave IP connectivity, for instance to lower implementationcosts, due to limited coverage, or to temporarily conserveenergy. They can use the Short Message Service (SMS) orUnstructured Supplementary Service Data (USSD)bindings of CoAP, as those transports match theproperties of constrained RESTful environments [18].

CoAP in the Web BrowserTo prototype the full Web experience for tiny IoT devices,we implemented an add-on for Mozilla Firefox [8]. OurCopper (Cu) Coap user-agent allows interaction withembedded Web resources by simply entering a CoAP URIinto the addressbar and using the RESTful methods GET,PUT, POST, and DELETE. It is comparable to other RESTadd-ons such as Poster4 or RESTClient5, but Cu inaddition implements CoAP. It registers a protocol handlerfor the coap URI scheme, which integrates these URIsseamlessly into the browser. Users can browse devices,bookmark their resources like normal Web pages, andfollow links in HTML documents to discover new devices.

Figure 4: The server resources are discovered through theCoRE Link Format and shown on the left for browsing. Thedebug options on the right are optional and can be used to setheader options to custom values for testing and debugging.

4https://addons.mozilla.org/en-US/firefox/addon/poster/5https://addons.mozilla.org/en-US/firefox/addon/restclient/

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1498

Our add-on can also render different Internet media typestypically provided by devices, e.g., JSON as depicted inFigure 4.

Academia and

obbyists (30+2)

Industry (16)

0-4 years experience

(33)

5+ years (15)

Figure 5: Our study has 48participants of which 16 are usingIoT devices or CoAP as industrydevelopers. Two participants arepure hobbyists. In the evaluation,we counted them as non-industry,i.e., academia.The average experience is 4.3years whereas 15 participantshave been active in the field forat least five years.

Copper (Cu) primarily targets developers that want toexplore, test, and debug RESTful Web services based onCoAP—for HTTP-based services, the Web browser isalready a popular tool to do so. In addition to the basicGUI elements to browse resources and issue differentrequests, Cu provides manual override for the full set ofCoAP header options and a detailed log in the Firefoxconsole, so developers can intensively test theirapplications or own CoAP implementations. Whileexperienced users can also use Copper (Cu) to configuretheir devices or retrieve data from them, it is not made forpure end-users of WoT applications. Our add-on is ageneric browser for tiny resource-constrained devices andthus is missing a presentation layer which is usuallyapplication-specific.

Although Copper (Cu) is fully written in JavaScript,CoAP requests cannot be issued from other scriptsrunning in the browser. This means, JavaScript from anexternal Web page cannot include CoAP resources in anAJAX-like manner and user scripting is only availablethrough editing the add-on sources. Our assumption wasthat WoT mashups would mainly be faceless scripts thataugment and automate devices invisibly in thebackground. For this, we created the CoapRequest objectfor a standalone RESTful runtime container that executesserver-side JavaScript [9]. The following study shows,however, that there is a broad interest in AJAX-likeinteraction with CoAP-enabled devices on Web pages toprovide application-specific front-ends for end-users.

CoAP User StudyFollowing up the study by Guinard et al. [4], we publisheda questionnaire to evaluate the WoT vision in the contextof highly resource-constrained networked embeddedsystems. In this domain, the use of IP and Web patternsis relatively new and numerous alternative, oftenproprietary, protocols exist. To find enough experts whoknow and worked with both approaches and, hence, cangive a qualified feedback, we advertised the study over thefollowing channels: (i) The Contiki6 and TinyOS7 mailinglists, which reach mostly researchers in the area ofWireless Sensor Networks, (ii) EuropeanTelecommunications Standards Institute (ETSI) M2Massociates, who have a good overview of the availabletechnologies for IoT and M2M solutions, and (iii)followers of the IETF standardization, who often havedecades of experience in the field. The latter two groupsmostly consist of people with an industry background.

We received N=48 responses from people who workedwith CoAP or IoT devices as researchers (51%), industrydevelopers (34%), students (28%), hobbyists (9%), andlecturers (4%); multiple roles are possible. The experiencein the relevant fields (wireless sensor networks, traditionalnetworked embedded devices, and Web technologies)varies from beginners to experts with up to 20 years ofexperience (4.3 years on average). Their answers are usedto confirm or reject the following hypotheses:

1. Internet protocols and Web patterns ease thedevelopment of distributed software forresource-constrained devices.

2. CoAP is a required extension for the Web tointegrate resource-constrained devices.

6http://www.contiki-os.org/7http://www.tinyos.net/

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1499

0

1

2

3

4

Internet protocols ease thedevelopment of distributedsoftware for tiny devices.

Web patterns ease thedevelopment of distributedsoftware for tiny devices.

CoAP in addition to HTTP is anecessity for the Internet of Things.

I expect native Web browsersupport for CoAP in the future.

I prefer using a HTTP-CoAP cross-proxy for accessing devices.

Overall

Academia

Industry

Less than 5 years

5 years and more

Figure 6: Likert scale responses by our 48 participants (0 = strongly disagree, 4 = strongly agree, error bars: +/- 1 std. dev.)

3. The Web browser is a preferred tool to interact withthese devices when there is no physical interfacemeant for direct interaction.

4. Other tools are only preferred when a task is to beautomated through a script or program.

IP, Web Patterns, and CoAP

Web browser integration of CoAP

(77%)

tandalone

(23%)

Figure 7: Most participantspreferred the Web browser asclient for device interaction.

For the first part, we used a five-level Likert scale fromstrongly disagree (0) to strongly agree (4), i.e., resultingvalues of more than 2 mean agreement with ourstatement. Based on the given background information(see Figure 5), we separated the responses into differentgroups: (i) academia, (ii) industry, (iii) less than five yearsof experience, and (iv) five or more years of experience.For each comparing statements (e.g., academia vsindustry), we perform the Wilcoxon rank-sum test to seeif the two sets significantly different from each other. Foreach statement, we give the corresponding p-valuetogether with the sample sizes.

Figure 6 shows general agreement on our first hypothesis.Overall, Internet protocols are slightly more accepted toease development (3.3) than Web patterns (3.1). Theyare also more appreciated by participants with longerexperience (3.7 vs 3.1 with less then five years).8

Interestingly, participants with an industry backgroundagree more with the advantages of Web patterns (3.5)than academia (3.0).9

Our second hypothesis about the necessity of CoAP canalso be confirmed, although the overall agreement isslightly lower (3.0) and has a slightly higher standarddeviation (1.06). CoAP as additional Web protocol findshigh acceptance among participants with an industrybackground (3.5 vs 2.8 in academia), though.9 (similar value)

The participants are a little less confident about nativeCoAP support in Web browsers (2.8), although they

80-4 vs 5+ years: p− value < 0.01, N0−4 = 33, N5+ = 159Industry vs academia: p− value < 0.001, Ni = 16, Na = 32

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1500

rather disagree with the usage of an HTTP-CoAPcross-proxy (1.8). Conversely, the latter means that directcommunication with devices is preferred.

CoAP support in Web BrowsersIn a second part, we directly asked what way of userinteraction with tiny devices is preferred. 77% voted forthe Web browser over a standalone CoAP client. Themost agreed-on reasons are that this way, no additionalsoftware is required (3.1, stdev. 0.9) and that the Webintegration feels natural (3.0, stdev. 1.0). The onlyagreed-on reason for using a standalone CoAP client wasthat it is better suited for scripting and integration into alarger system (2.9, stdev. 0.7). Other reasons had more orless neutral outcome.

Figure 8 (on the next page) shows the client usage profilesof the participants. Being a contributor to the CoREworking group, our CoAP implementations have alwaysbeen early reference implementations for others. Thus,one of the main use cases is debugging ownimplementations. The other applications are in line withthe role of a Web browser in traditional RESTful Webservices and reflect the preference for Web browserintegration of CoAP.

CoAP Client Market Share

Copper (Cu) 41%

libcoap client 17%

Sensinode NanoService Java Client

5%

Californium (Cf) GUI client

5%

Californium (Cf) console client

10%

other 22%

Figure 9: Market share ofdifferent CoAP clients onworkstations and laptops. Clientsmentioned only once or withoutspecific name are consolidated in“other.”

Copper (Cu) is currently the only CoAP client availablethat integrates into the Web browser. Figure 9 shows that41% of the participants who use CoAP on theirworkstation or laptop (N=41) use our browser add-on asprimary client, followed by the command line libcoap clientwith 17%. The main reason for using a different CoAPclient was by far the need for automation and scriptingwith 55% of the answers and the “I do not use Firefox”runner-up with mere 8%. Although the JavaScript sourcecode of our add-on is available, only 2 participants (6%)

have adapted it to their needs. 47% stated that they are“not familiar enough with Firefox add-ons” to do so, whilethe remaining 47% did not consider this option.

ConclusionDevelopers from industry and academia that deal withnetworked embedded systems are convinced that Internetprotocols and patterns from the Web facilitate their job.Also the Web-like interaction with tiny devices ispreferable, as 77% favor the Web browser integration ofCoAP over standalone clients. From the expectations buteven more from the individual comments, we concludethat users would prefer full CoAP support in Webbrowsers. A primary concern is the creation of intuitiveWeb front-ends that directly include device data withoutthe need for a cross-proxy. We also take away that CoAPscripting support within the browser would be highlyappreciated and that our CoapRequest object API is theright approach. This would, for instance, satisfy thefeature requests for logging and visualization of historicvalues, since well-known libraries such as jQuery Flot10

can be used for this.

In the future, we will continue with the Web browserintegration and provide AJAX-like CoAP support byporting Actinium’s CoapRequest object to the browser.Another concern is the support for CoAP’s securitymodes. Due to the efforts of the IETF “Real-TimeCommunication in WEB-browsers” working group,browser vendors already started to integrate DTLS, e.g.,for direct video chat or gaming [14]. CoAPs support,however, requires additional patches to make DTLSavailable through the scripting API. This could becomethe next big step towards native CoAP support in theWeb browser and a prosper Web of Things.

10http://www.flotcharts.org/

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1501

0 5 10 15 20 25 30

Other

Teaching

Measurements

Checking the health of deployments

Configuring devices

Browsing existing CoAP Web services

Developing new applications

Retrieving information / controlling actuators

Giving a demo (at a conference, open house, etc.)

Debugging own CoAP implementation

Web browser

Different client

Figure 8: Copper (Cu) has been available since CoAP draft 03. Thus, one of the main applications of it is the debugging of otherCoAP implementations. Still, there have been other clients around and usability must have been the reason for choosing this referenceimplementation in particular.

AcknowledgementsWe want to thank all study participants for their time.Special thanks to those, who provided us with detailedfeedback in the individual comment.

References[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,

Masinter, L., Leach, P., and Berners-Lee, T.Hypertext Transfer Protocol – HTTP/1.1. RFC2616, 1999.

[2] Fielding, R. T. Architectural Styles and the Design ofNetwork-based Software Architectures. PhD thesis,University of California, Irvine, 2000.

[3] Guinard, D. A Web of Things ApplicationArchitecture - Integrating the Real-World into the

Web. PhD thesis, ETH Zurich, 2011.[4] Guinard, D., Ion, I., and Mayer, S. In Search of an

Internet of Things Service Architecture: REST orWS-*? A Developers’ Perspective. In Proc.MobiQuitous (Copenhagen, Denmark, 2011).

[5] Guinard, D., Trifa, V., Pham, T., and Liechti, O.Towards Physical Mashups in the Web of Things. InProc. INSS (Pittsburgh, PA, USA, 2009).

[6] Hartke, K. Observing Resources in CoAP. I-D:draft-ietf-core-observe-08, 2013.

[7] Hui, J., and Thubert, P. Compression Format forIPv6 Datagrams over IEEE 802.15.4-Based Networks.RFC 6282, 2011.

[8] Kovatsch, M. Demo Abstract: Human–CoAPInteraction with Copper. In Proc. DCOSS(Barcelona, Spain, 2011).

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1502

[9] Kovatsch, M., Lanter, M., and Duquennoy, S.Actinium: A RESTful Runtime Container forScriptable Internet of Things Applications. In Proc.IoT (Wuxi, China, 2012).

[10] Lerche, C., Laum, N., Moritz, G., Zeeb, E.,Golatowski, F., and Timmermann, D. ImplementingPowerful Web Services for HighlyResource-Constrained Devices. In PERCOMWorkshops (Seattle, WA, USA, 2011).

[11] Nottingham, M. Web Linking. RFC 5988, 2010.[12] Nottingham, M., and Hammer-Lahav, E. Defining

Well-Known Uniform Resource Identifiers (URIs).RFC 5785, 2010.

[13] Rahman, A., and Dijk, E. Group Communication forCoAP. I-D: draft-ietf-core-groupcomm-09, 2013.

[14] Rescorla, E. RTCWEB Security Architecture. I-D:draft-ietf-rtcweb-security-arch-06, 2013.

[15] Shelby, Z. Constrained RESTful Environments(CoRE) Link Format. RFC 6690, 2012.

[16] Shelby, Z., Hartke, K., and Bormann, C. ConstrainedApplication Protocol (CoAP). I-D:draft-ietf-core-coap-17, 2013.

[17] Shelby, Z., Krco, S., and Borman, C. CoRE ResourceDirectory. I-D: draft-ietf-core-resource-directory-00,2013.

[18] Silverajan, B., and Savolainen, T. CoAPCommunication with Alternative Transports. I-D:draft-silverajan-core-coap-alternative-transports-01,2013.

[19] Tolle, G. Embedded Binary HTTP (EBHTTP). I-D:draft-tolle-core-ebhttp-00, 2010.

[20] Wilde, E. Putting Things to REST. Tech. Rep.2007-015, School of Information, UC Berkeley,Berkeley, CA, USA, 2007.

Session: WoT 2013: Fourth International Workshop on the Web of Things

UbiComp’13, September 8–12, 2013, Zurich, Switzerland

1503