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

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

From: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Tue, 22 Sep 2015 18:14:17 +0200
To: 'Dave Raggett' <dsr@w3.org>
CC: "'public-wot-ig@w3.org'" <public-wot-ig@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA303DBEB6409E3@seldmbx03.corpusers.net>
Regarding the discussion on sleep mode, wake-up, the ability for an IoT device to act on REST calls and the battery drain issue I talked to a Bluetooth expert.

To save battery BLE goes into "sleep-mode" when the device is inactive. However, to keep the connection open BLE wakes up and sends "connection messages" with an interval of typically 1-2 seconds. During this "wake-up" the BLE-device can send data to and receive data from the other peer. Accordingly, a BLE device can send and receive messages with a max delay of the BLE connection message interval.

So, if we run the Bluetooth Smart, i.e. the IPv6 Bluetooth profile and CoAP/UDP,  and the device is behind a NAT/Firewall, the device can respond to REST calls under the condition that the UDP port is open, with a delay of 1-2 seconds. However, the main issue is probably the battery drain caused by the keep-alive messaging needed to keep the NAT/firewall UDP port open.


Claes Nilsson
Master Engineer - Web Research

Sony Mobile Communications
Tel: +46 70 55 66 878



From: Nilsson, Claes1
Sent: den 18 september 2015 11:30
To: 'Dave Raggett'
Cc: public-wot-ig@w3.org
Subject: RE: [TF-AP]: Using CoAP for bi-directional communication

Thanks Dave,

Before answering more I need to talk to some experts here.  I am for example considering devices running Bluetooth Smart, i.e. CoAP or MQTT/DTLS or TLS/UDP or TCP/IPv6/6LowPAN/BLE.


Claes Nilsson
Master Engineer - Web Research

Sony Mobile Communications
Tel: +46 70 55 66 878



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

For battery operated devices, a timer interrupt or a hardware interrupt can be used to wake up the device. You may be able to design the electronics to wake the device up, but to save power, the MCU and network hardware would need to be in a sleep mode. Can you describe the use cases where you think that waiting until the next periodic wakeup to receive new messages would be a serious problem?

[Claes]: Use cases are when a server or another IoT device sends an alarm or notification that must be acted on immediately.

If this relying on the network connection, it implies that the device doesn’t sleep, so battery operation would normally be inappropriate.  Perhaps you could clarify what you mean by “acted on immediately” as this presumably depends on the use case.  The longer the latency allowed, the longer the battery life.

In some use cases, you don’t need to use a battery since the device can be powered from the building’s electrical supply, e.g. a room light.  Integrating an IoT device with the light can then allow the MCU and radio to be permanently on.

Given the above info on WebSocket keep-alive, there may not be a significant advantage over a UDP based protocol. In addition, MQTT is based upon TCP and provides an alternative to Web Sockets in that respect.

[Claes]: You have learned me that Web Sockets keep-alive messaging may be as frequent as what is needed for CoAP over UDP. However, there are other advantages with Web Sockets compared to CoAP, e.g.
-        Could probably better pass “troublesome firewalls”

According to Google, this is less of an issue in practice according to their studies.

TCP supports reliable transmission

TCP is ultimately very good at adjusting to the current level of network traffic, but UDP and CoAP can readily support reliable transmission with a reasonably small code overhead.

TCP is more secure than UDP. In TCP it is difficult to inject an arbitrary packet as each packet has a sequence number. In UDP it is simple. A malicious packet could easier pass an open UDP port in the firewall than an open TCP port. By that it is possible to have a TCP port open longer than a UDP port.

Hmm, attackers can monitor and inject TCP packets too, so I not sure about your claim.

Here is an example of a Web Socket server for IoT devices (ARM mbed): https://developer.mbed.org/cookbook/Websockets-Server

Thanks for the pointer.  If we ignore low end devices, then TCP and Web Sockets are fine.  Perhaps, low end devices will disappear if the price differential is small enough.  32 bit MCU’s are certainly a lot more flexible than 8 bit ones.  For any given IoT product, you can see whether the price difference is important, but for the Web overall, we may need to cover a broader range of devices, and hence I am interested to see just how far we can push low end devices as a matter of principle. In essence, if we only address the mindset and needs of some communities, we may find that the Web of Things is not appealing to other communities with different perspectives. For this reason, we may need to work on a variety of competing techniques and see which ones enjoy the widest adoption.

[Claes]: As far as I understand the main security issue with Web Sockets is that the Same Origin Policy is not applied for Web Sockets. Maybe I am naïve but the HW related security solutions you are discussing are they not applicable for use of CoAP, HTTP and MQTT as well? Could the specific security issue of Web Sockets, no Same Origin Policy, be addressable by CSP and CORS? Sorry for my limited knowledge here.

In practice, browsers only allow you to make web socket connections to the same origin as used to load the web page, although the ports may vary.  I believe that CORS headers should work, but haven’t tested that.

Using hardware acceleration for crypto and for secure storage is indeed applicable across protocols, in so far as those protocols are compatible with the crypto algorithms and settings provided by the hardware.

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

(image/png attachment: image004.png)

(image/png attachment: image003.png)

Received on Tuesday, 22 September 2015 16:15:02 UTC

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