>> And you can find more information about CoAP over TCP on BT adapters here >> which we presented during DC TG Conference call.
I was on a DCTG call 2-3 months ago when MyeongGi presented his proposal to use the CoAP_TCP serialization over BR/EDR, but there was NO mention of BLE. >> That means BR/EDR, LE shows similar transport attributes with TCP in >> relaibility. I don?t know if this assessment is entirely correct, at least in practice, if not even in principle. The literature you cited only states the equivalence of L2CAP-provided reliability between BR/EDR and LE. With BR/EDR it is actually RFCOMM which as a reliable stream-based protocol provides similar service guarantees to TCP. IoTivity uses RFCOMM, and as a result might be able to be more proactively detect and handle connection loss. Under these constraints, it seemed reasonable to use the CoAP_TCP format over the air, and that is why I had not raised any objections to that proposal. With BLE however, the GATT->ATT->L2CAP interface gives us what might look like a packet/datagram based protocol. So, it might be preferable to track/maintain state in the upper layer (i.e. CoAP). Even if the current implementation functions correctly (i.e. you have covered for all the corner cases), in the best case it seems like an unnecessary optimization in my opinion. Is this change only enabled with a compile-time option? Thanks, -Kishen. From: ASHOKBABU CHANNA <ashok.channa at samsung.com<mailto:[email protected]>> Reply-To: "ashok.channa at samsung.com<mailto:ashok.channa at samsung.com>" <ashok.channa at samsung.com<mailto:ashok.channa at samsung.com>> Date: Tuesday, February 23, 2016 at 7:37 AM To: MyeongGi Jeong <myeong.jeong at samsung.com<mailto:myeong.jeong at samsung.com>>, Kishen Maloor <kishen.maloor at intel.com<mailto:kishen.maloor at intel.com>>, "Gomes, Vinicius" <vinicius.gomes at intel.com<mailto:vinicius.gomes at intel.com>>, "Othman, Ossama" <ossama.othman at intel.com<mailto:ossama.othman at intel.com>> Cc: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>>, "Bottazzini, Bruno" <bruno.bottazzini at intel.com<mailto:bruno.bottazzini at intel.com>> Subject: Re: Re: [dev] Problems when implementing IoTivity GATT transport Hi, Regarding the fragmentation at CA - BLE adapter: There were two reasons behind to apply fragmentation / defragmentation logic at adapter level: 1) When we tested with Arduino BLE, we found it was able to receive only 1 byte at a time but not more than that. 2) And Android will not send full data in terms of 20 byte chunks we push more data. it will send only first 20 bytes of data. For these platform limitations, we need a mechanism at sender side and receiver side to know about the length of the data transmitted before analyzing it further. So in order to get platform interoperability, we added fragmentation / defragmentation logic . And you can find more information about CoAP over TCP on BT adapters here<https://workspace.openinterconnect.org/apps/org/workgroup/dc_tg/download.php/4111/CoAP%20over%20TCP%20over%20Bluetooth-r2.pptx> which we presented during DC TG Conference call. Regards, Ashok ------- Original Message ------- Sender : MyeongGi Jeong<myeong.jeong at samsung.com<mailto:myeong.jeong at samsung.com>> S5/Senior Engineer/IoT Lab./Samsung Electronics Date : Feb 23, 2016 19:36 (GMT+05:30) Title : Re: [dev] Problems when implementing IoTivity GATT transport Hi, Maloor, Vinicius. I'd like to say why we applied CoAP over TCP format to the LE-GATT transmission. First of all, IoTivity CoAP over TCP format currently follows OIC core framework specification, not CoAP over TCP draft spec. You can find it from the OIC core specification( 12.6.6 CoAP serialization over TCP ) 12.2.6.3 Message type and header The message type transported between OIC Client and OIC Server shall be a non-confirmable message (NON). The protocol stack used in this scenario shall be as described in section 3 in IETF draft-tschofenig-core-coap-tcp-tls-04. The CoAP header as described in figure 5 in IETF draft-tschofenig-core-coap-tcp-tls-04 shall be used for messages transmitted between an OIC Client and an OIC Server. An OIC Device shall use ?Alternative L3? as defined in IETF draft-tschofenig-core-coap-tcp-tls-04. Second, Like BR/EDR, LE transport layer guarantees the complete transmission by retranmitting in case of CRC error. In poor RF situation, BR/EDR and LE also cannot send and receive packet completely. That means BR/EDR, LE shows similar transport attributes with TCP in relaibility. So, CoAP/TCP format is more suitable than CoAP/UDP header format over BR/EDR and LE-GATT. 3.1.3.2 LE reliability Like BR/EDR, in poor RF environments, the LE system should be considered inherently unreliable. To counteract this, the system provides levels of protection at each layer. The LL packet uses a 24-bit cyclic redundancy error check (CRC) to cover the contents of the packet payload. If the CRC verification fails on the packet payload, the packet is not acknowledged by the receiver and the packet gets retransmitted by the sender. Broadcast links have no feedback route, and are unable to use the acknowledgement scheme (although the receiver is still able to detect errors in received packets). Instead, each packet is transmitted several times to increase the probability that the receiver is able to receive at least one of the copies successfully. Despite this approach there are still no guarantees of successful receipt, and so these links are considered unreliable. In summary, if a link or channel is characterized as reliable this means that the receiver is capable of detecting errors in received packets and requesting re- transmission until the errors are removed. Thanks. Best Regards, --- MyeongGi Jeong Senior Engineer, Software Architect Software R&D Center, Samsung Electronics Co., Ltd. +82-10-3328-1130 | +82-2-6147-7699 ------- Original Message ------- Sender : Maloor, Kishen<kishen.maloor at intel.com<mailto:kishen.maloor at intel.com>> Date : 2016-02-23 03:52 (GMT+09:00) Title : Re: [dev] Problems when implementing IoTivity GATT transport Hi Vinicius, My explanations were based entirely around OIC?s BLE-GATT profile that I authored about a year ago, and which documented the design. I believe all LE connectivity adapters had eventually conformed to it. Also, the profile made NO mention of ever using the CoAP_TCP serialization over BLE, and instead proposed to utilize CoAP?s own reliability semantics over GATT. I just briefly looked at the commit you mentioned, and see a few recent changes, and see why you?re asking this question. It might be OK to use CoAP_TCP over BT EDR (which uses RFCOMM), but not over BLE, at least the way it was initially designed for OIC. I?m not sure what the developer had in mind, or if they?ve also updated OIC?s BLE profile to address the consequences of these changes. I?m glad to at least see TCP support as a build-time option. >> ..fragmentation and reassembly mechanism chosen is based >> on a expired draft: ? fragmentation and reassembly >> mechanism chosen is based on a expired draft: ? and is >> effectively a proprietatry protocol I don?t disagree on that point. I?m not aware of what is currently being done. I had suggested the possible use of CoAP block options for this purpose, which seemed like a natural choice, but the decision was made and agreed upon by the implementers. So, to hasten your progress at this point, my suggestion would be to adhere to the BLE profile (i.e. without the CoAP TCP adaption) and check/discuss with the associated developer(s) to understand their chosen fragmentation/reassembly procedure. Thanks, -Kishen. On 2/22/16, 6:23 AM, "Gomes, Vinicius" wrote: >Hi Kishen, > >"Maloor, Kishen" writes: > >> Write Without Response (and notification) characteristics were chosen >> because >> of their asynchronous behavior at the LE layer, whereas reliable >> write/write >> along with the write long characteristic procedure enforces the need for >> acknowledgements to every write over the LE network layer. >> > >Taking a look at the commit history, it was my impression that was a plan >about using the "CoAP over TCP" CoAP header for BLE connections, which >implies that the underlying transport is reliable. > >See the current version of the draft: > >https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-01 > >There are no CoAP 'ACK' messages, so the transport layer must maintain >that reliability assumption. > >> Furthermore, it is IoTivity PDUs going over the air directly, and not >>UDP >> packets (so your suggestion of CoAP over TCP doesn?t and shouldn?t even >> apply >> here) >> > >See commit d26e1cb "CoAP over TCP transmission over BLE" in the current >master. > >> Since IoTivity PDUs happen to be larger than (I think) 20 bytes, we >> require >> fragmentation and reassembly which is performed in the application >> (IoTivity >> framework in this case). This is the design, and that is how it is >> implemented >> in all supported IoTivity platforms. >> > >One of my points is that as of now the fragmentation and reassembly >mechanism chosen is based on a expired draft: > >https://datatracker.ietf.org/doc/draft-tschofenig-core-coap-tcp-tls/04/ > >and is effectively a proprietatry protocol, now that the draft expired. > >> Support for secure connections (i.e. to be secured by IoTivity?s >>security >> model) over BLE is currently an open issue, and I believe is/will be >> addressed. >> >> -Kishen. >> >> >> On 2/19/16, 1:04 PM, "iotivity-dev-bounces at >> lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> on >> behalf >>of >> Vinicius Costa Gomes" >> of vinicius.gomes at >> intel.com<mailto:vinicius.gomes at intel.com>> wrote: >> >>>Hi Ossama, >>> >>>"Othman, Ossama" writes: >>> >>>> Hi Vinicius, >>>> >>>> On Fri, Feb 19, 2016 at 11:07 AM, Vinicius Costa Gomes < >>>> vinicius.gomes at intel.com<mailto:vinicius.gomes at intel.com>> wrote: >>>>> >>>>> When implementing the IoTivity (I couldn't find a complete >>>>>specification >>>>> for this in OIC, so the work used IoTivity as reference) GATT >>>>>transport >>>>> in Soletta[1], we found a couple of problems: >>>>> >>>>> * IoTivity uses a few BlueZ D-Bus APIs that have changed >>>>> upstream, for example, org.bluez.GattManager1.RegisterService() has >>>>> changed to org.bluez.GattManager1.RegisterApplication() (this API >>>>>is >>>>> marked as experimental, so the usual stability guarantees doesn't >>>>> apply); >>>>> >>>> >>>> The new BlueZ GATT API you pointed out hasn't been released yet. >>>>BlueZ >>>> 5.37, the latest release, still implements the older API. IoTivity's >>>>Linux >>>> BLE transport was originally based on the GATT API exposed by BlueZ >>>>5.31. >>>> The BlueZ GATT APIs changed due to a D-Bus specification violation >>>>where >>>> the GATT service D-Bus object path was incorrectly expected to be >>>>rooted at >>>> the same level as the Object Manager. No one has gotten around to >>>>updating >>>> IoTivity to conform to the new (unreleased) BlueZ GATT API yet. >>>> >>>> * Over Bluetooth Low Energy transport, IoTivity uses the same header >>>>> format as CoAP over TCP, but based on a draft that has already >>>>> expired, see here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/ >>>>> (also, the necessity of this header in Bluetooth Low Energy could >>>>>be >>>>> discussed, as GATT maps to a reliable datagram based transport) >>>>> >>>>> * Performing the fragmentation on IoTivity's side seems unnecessary, >>>>>if >>>>> the value to be written is larger than the negotiated MTU, BlueZ >>>>>will >>>>> perform the Write Long Characteristic procedure if necessary, then >>>>> it's just a matter of requiring devices to implement the necessary >>>>>ATT >>>>> operations; >>>>> >>>> >>>> That's only true if the "reliable-write" or "write" property is set >>>>for >>>>the >>>> BlueZ GATT Characteristic. IoTivity (and the OIC Bluetooth Transport >>>> Profile) uses "write-without-response", which doesn't exhibit the >>>>behavior >>>> you described. Furthermore, currently only the Linux BLE >>>>implementation in >>>> IoTivity uses BlueZ. We can't count on this behavior for the >>>>platforms >>>> that do not use BlueZ. In any case, I don't know all of the details >>>>for >>>> why the Write Long characteristic procedure was not chosen for >>>>IoTivity's >>>> BLE transport, but I assume it's because Write Long blocks waiting >>>>for a >>>> reply whereas Write Without Response does not. >>> >>>From what I understand, using the CoAP over TCP headers it is implied >>>that you are using a reliable transport (as there are no ACK messages), >>>for example. just after issuing a Write Without Response request, you >>>receive an event informing that a disconnection occurred, without the >>>reliable-write procedures you have no way to know if the transmission >>>succeeded (or not). >>> >>>> >>>> HTH, >>>> -Ossama >>> >>> >>>Cheers, >>>-- >>>Vinicius >>>_______________________________________________ >>>iotivity-dev mailing list >>>iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> >>>https://lists.iotivity.org/mailman/listinfo/iotivity-dev >> > > >Cheers, >-- >Vinicius _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:EW9BEWXXYKEN at namo.co.kr] -------------- next part -------------- A non-text attachment was scrubbed... Name: 201602232107702_4XEV4D4T.gif Type: image/gif Size: 13168 bytes Desc: 201602232107702_4XEV4D4T.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160224/f8d81c00/attachment.gif>
