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

Hi James,

I don’t think that ”always on” is an option. The standard Bluetooth behavior is sleep mode with short wake ups for "connection messages". What needs to be added, if the device is behind a NAT/Firewall and we want to be able to send REST calls to the device anytime, are the keep-alive messaging with the server. I currently don’t have figures on the extra battery consumption caused by these keep-alive messages but we are investigating.

I guess that we need some kind and of push/wake-up method to activate the device after a long period of inactivity. Then the device could start to send keep-alives. It may not be possible to always have the keep-alive messaging running. But I am not sure so this is for further study.

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@01D0F5EF.07CC1AF0]

From: Lynn, James (Fortify on Demand) [mailto:james.lynn@hpe.com]
Sent: den 22 september 2015 18:40
To: Nilsson, Claes1; 'Dave Raggett'
Cc: 'public-wot-ig@w3.org'
Subject: RE: [TF-AP]: Using CoAP for bi-directional communication

Very interesting Claes,

Do you have any idea how much drain this causes to wake up, do a minimal amount of work and then go back to sleep – and is there additional overhead to wake up? How would one estimate the minimal amount of energy consumed as compared to “always on”? Would it be for example 1%? I understand it would vary greatly depending on what was being done, but perhaps your BT expert has run some test cases.

Thanks,
J Lynn

From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com]
Sent: Tuesday, September 22, 2015 12:14 PM
To: 'Dave Raggett'
Cc: 'public-wot-ig@w3.org'
Subject: RE: [TF-AP]: Using CoAP for bi-directional communication

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.

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:image004.png@01D0F5EE.81CA8860]

From: Nilsson, Claes1
Sent: den 18 september 2015 11:30
To: 'Dave Raggett'
Cc: public-wot-ig@w3.org<mailto: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.

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:image004.png@01D0F5EE.81CA8860]

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>>