- From: Isomaki Markus (Nokia-TECH/Espoo) <markus.isomaki@nokia.com>
- Date: Wed, 18 Nov 2015 16:49:24 +0000
- To: "EXT Nilsson, Claes1" <Claes1.Nilsson@sonymobile.com>, 'Dave Raggett' <dsr@w3.org>, Jason Proctor <jason@mono.hm>
- CC: Jaime Jiménez <jaime.jimenez@ericsson.com>, "Hund, Johannes" <johannes.hund@siemens.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
- Message-ID: <cd5b1acb26674c7a968d146717bad312@NOKWDCFIEXCH02P.nnok.nokia.com>
Hi, Does anyone have real experience how the LTE (or 3G) networks supporting IPv6 actually work in this sense? For instance, have they dropped all firewalling so that e.g. TCP connections could be kept open without timeouts or even incoming TCP/UDP would be possible without creating a biding by outgoing traffic? That would be nice for device-to-cloud connectivity maintenance perspective, but might bring additional problems. My experience with some earlier non-firewalled/NATed cellular networks was that there was quite a lot of unsolicited traffic coming in (various sort of probes I presume), and that was quite disasterous for the device power consumption too, as each incoming packet caused the radio to jump to an active/connected channel for a while, and there was no way to do anything about this in the device. The best approach woud be if the device was able to control the firewall bindings by itself, but protocols such as PCP made for that purpose have seen very little (if any?) deployment. Markus From: EXT Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com] Sent: Wednesday, November 18, 2015 10:55 AM To: 'Dave Raggett' <dsr@w3.org>; Jason Proctor <jason@mono.hm> Cc: Jaime Jiménez <jaime.jimenez@ericsson.com>; Hund, Johannes <johannes.hund@siemens.com>; public-wot-ig@w3.org Subject: RE: [WoT IG]: Issues with bi-directional communication for CoAP and other IoT-related protocols Yes, this depends on the context. An example when an IoT device connects directly to the cloud is a device running LTE MTC, i.e. it is directly connected to the mobile network and has an IPv6-address. BR Claes From: Dave Raggett [mailto:dsr@w3.org] Sent: den 17 november 2015 19:28 To: Jason Proctor Cc: Nilsson, Claes1; Jaime Jiménez; Hund, Johannes; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org> Subject: Re: [WoT IG]: Issues with bi-directional communication for CoAP and other IoT-related protocols On 17 Nov 2015, at 18:13, Jason Proctor <jason@mono.hm<mailto:jason@mono.hm>> wrote: greetings all IMHO, the assumption that the device still has the same IP address as it had the last time it and the cloud server communicated is problematic. in my mind, for various reasons, there will likely be a proxy server on the same network as the device, whose job it is to proxy stuff on behalf of an entity requesting access (it might also do some auth, etc). so the device communicates its abstracted address (eg HeartMonitor._wot._tcp.local for mDNS) to the cloud server, facilitating an address-neutral discovery on the way back. the proxy could also set up port forwarding etc for the duration of the connection. On Tue, Nov 17, 2015 at 3:39 AM, Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>> wrote: Hi Jaime, The slides are here: https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/att-0104/Issues_with_bi-directional_communication_for_CoAP_and_other_IoT_related_protocols.pdf This will depend upon the context. In some cases, having a local powered gateway/hub that sits between the cloud and the IoT device is the way to go. This makes it easier to deal with sleepy devices, strong security, and to preprocess/multiplex sensor data to reduce the load on the cloud server. In other cases, the IoT device will connect directly to the cloud. Maintaining a “connection” through a NAT Firewall has its costs, so some such devices will be directly connected. A hybrid approach has the firewall in the cloud. With growing interest in low power wide area networks for sensors, that could be an increasingly popular choice. — Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>
Received on Wednesday, 18 November 2015 16:49:59 UTC