RE: [TF-AP]: Using CoAP for bi-directional communication

Thanks a lot for all this information Dave!

Interesting to hear about your experiments with lightweight libraries for networking chips.

In the ideal world we would like to be able to, on cheap constrained devices, expose REST APIs to the resources of the device. We would like these APIs be accessible “anytime”. To make this possible with CoAP over UDP it seems as we need some kind of keep-alive messaging, which is not good for battery operated devices. I don’t think we can solve all use cases by server queuing messages until the IoT device wakes up by itself. Alternatively we might come up with some clever network initiated wake-up system.

It seems as, if the HW permits it, Web Sockets is the best choice for “bi-directional” use cases. However, I would like to better understand the security issues you mentioning.

BR
  Claes


Claes Nilsson
Master Engineer - Web Research
Research&Incubation

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com<mailto:Firstname.Lastname@sonymobile.com>

sonymobile.com<http://sonymobile.com/>

[cid:image003.png@01D0EF43.C03C50D0]

From: Dave Raggett [mailto:dsr@w3.org]
Sent: den 13 september 2015 19:59
To: Nilsson, Claes1
Cc: public-wot-ig@w3.org
Subject: Re: [TF-AP]: Using CoAP for bi-directional communication

Hi Claes,

My comments below ...


On 13 Sep 2015, at 14:46, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote:

Hi TF-AP,

Sorry for being quiet on this list for a while.

I have been experimenting with CoAP using the node coap library, https://github.com/mcollina/node-coap. Many IoT use cases require both peers to act as both client and server that expose REST APIs to be called by the other peer. However, if an IoT device is behind a NAT/firewall we have problems. The IoT device can anytime execute a REST call over CoAP to a cloud server. However, the ability for the cloud server to call a REST API in the IoT device is limited. The IoT device must initiate the communication. To keep the NAT/firewall open for requests from the cloud server to the IoT device a CoAP request from the cloud server, now acting as CoAP client, must be sent over the same IP-address/portnr quadruple (source/dest address/port) as was used for the initiating request from the IoT device in order for the NAT to accept the request from the server.

With the node coap library it is possible to achieve “bi-directional” CoAP with a trick using a local proxy to achieve a constant IP-address/portnr quadruple as long as the UDP traffic is opened in the NAT. However, it may not be possible to achieve this in all CoAP implementations as it might not be possible to set the same portnr as was used as source port to the port that is used for listening on requests on (when the IoT device switches from CoAP client to CoAP server). Furthermore, NAT timeouts for UDP traffic are typically between 30 and 180 seconds, http://mobilesociety.typepad.com/mobile_life/2008/08/nokia-research-center-on-impact-of-keep-alive-messaging-on-power-consumption.html, so a keep-alive from the IoT device to the cloud server is needed if the server should be able to make a REST call to the IoT device “anytime”. And, keep-alives consume battery so better is some kind of “wake up/push” method.

Of course, Web Sockets is a better choice as it solves the bidirectional issue and NAT issue. However, HW requirements are higher for Web Sockets than for CoAP and for really cheap devices CoAP might be the only alternative? I am correct?

I am now interested in hearing the views and experiences from members in this IG on the issues I describe above. I would also like to hear views on minimal HW requirements (memory etc) for CoAP versus Web Sockets and possible other alternatives, e.g. XMPP.

For my experiments with supporting the Web of Things on low end devices, I have been exploring lightweight libraries for current networking chips, e.g. the Wiznet W5100 which is used for the Arduino Ethernet shield.  This chip and similar ones, such as the ENC28J60, include on-chip memory for network buffers and additional hardware that reduces the burden for implementing TCP, as well as enabling the use of UDP and multicast packets.

The W5100, for example, has 16 Kbytes of internal memory and enables you to trade  a reduced number of local sockets for an increase in the memory allocated per socket. The IoT microcontroller (MCU) itself has limited memory.  A traditional API would require you to use the MCU’s RAM to prepare the messages you want to send, then copy each message to the network controller.  Likewise, when a packet is received, you would need to copy the message from the network controller to the MCU RAM.   This memory overhead can be avoided by using a higher level API that allows you to prepare the messages using the network controller’s internal memory, and likewise when parsing a received message.  Of course, this necessitates writing a new library for a specific network controller, but my experiments have shown that this is actually relatively easy given the network controller data sheet and the vendor’s example code.

UDP can be used in an equivalent way to TCP for bidirectional messaging by using message sequence numbers together with retransmissions and acknowledgements.  The overhead for this is fairly small provided you restrict the API to only handle one send message at a time. In other words, if you are limited to a single (re)send buffer held on-chip in the network controller. Short keep alive packets can be used to refresh the firewall so that it allows incoming packets through. However, this may not be practical for battery operated IoT devices that spend a lot of their time asleep. For such devices, the server can queue messages until such time as the IoT device wakes up.

Web Sockets incurs a much bigger overhead, but is still doable on the more powerful MCU’s. However, there are further complications when it comes to security.   I am exploring the use of specialised crypto hardware that offloads this complexity from the MCU to dedicated chips e.g. for NIST ECC profiles. Such chips are inexpensive and look rather promising when it comes to supporting strong security on low end IoT systems.

Best regards,
—
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>