W3C home > Mailing lists > Public > public-wot-ig@w3.org > September 2015

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

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Sun, 13 Sep 2015 15:46:57 +0200
To: "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA303DBEB6409AA@seldmbx03.corpusers.net>
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.

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:image002.png@01D0EE3B.6B55F160]


image002.png
(image/png attachment: image002.png)

Received on Sunday, 13 September 2015 13:47:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:45 UTC