| This looks very interesting.
One observation:
This looks to me more like you are using MQTT as a transport layer for CoAP. The MQTT topic usage reminds me of TCP sockets.
Would you not call this CoAP over MQTT?
For example, what would prevent one from running OCF over this?
Best regards,
Michael
Dear iot.eclipse working group,
MicroEJ is involved in several IoT commercial projects, that use
commercial MQTT brokers to organized the web of devices.
MQTT is one of the most commonly used central server, especially because
its publish/subscribe paradigm eases sending data to/from the cloud.
Aside those MQTT brokers, other services are requested like device
management. The LWM2M protocol is becoming one of the standards for
remotely managing a device through a set of normalized operations.
However, although its semantics can be implemented on any kind of
protocols, the lwM2M specification is written in a way that it is
tightly coupled to the CoAP protocol. On another hand, tons of IoT
devices are connected to a central server using a regular TCP connection,
for two main reasons:
• It is no more an issue (on server side) to keep millions of TCP
connections up at same time.
• Although the device is viewed as a server that exposes resources upon
which requests are initiated from the cloud, the connection is initiated
by the device, which removes trying to resolve NAT traversal issues.
We would like to draft with you a specification that makes it possible
to use only one "iot_link/paradigm", that is MQTT, and have lwM2M
implemented on top of MQTT.
The goal of this specification is to propose lwM2M semantics with CoAP
message format, based on MQTT publish/subscribe paradigm, on top of a
TCP transport.
The key driving points are :
• One single open link from a device to the broker_in_the_cloud for data
AND device management,
• Minimizing embedded client footprint in order to target
resource-constrained devices, such as those running with
microcontrollers or small embedded microprocessors. Especially trying to
avoid as much as possible mechanisms specified by CoAP to manage
unordered or loss packets (binary data streaming instead of unordered
blockwise transfer, de-duplication, sending again after timeouts...), as
TCP transport implies no packets loss.
Please find attached a first draft. We would really appreciate to get
feedback so that we would finish a first Reference Implementation to
give to the community as a starting point. This implementation uses
the Java implementation of Paho on the device. On the server side, for
a demonstration purpose, we use Mosquitto and a modified version of
Leshan.
Looking forward for your inputs,
Jérôme Leroux
--
| <afihmdlobgkdmgdd.png> |
Jérôme Leroux
Tel: +33 972 377 179 11, rue du
Chemin Rouge, IS2T - Bât. D 44300 Nantes,
France
<ljndllbpaoiccdod.png> <efiefflfgkcnnbke.png> <ebiidbcpdfklnjof.png> |
|
| <event.png> |
|
This
email (and all attachments) may contain information that
is proprietary privileged, and/or confidential. If you
received this e-mail in error or if it was improperly
forwarded to you, the information contained in the
e-mail should, at all times, remain confidential. Please
notify the sender immediately by e-mail, and delete or
destroy the original and any copies. Any unauthorized
use, disclosure, reproduction, retention or distribution
by any person other than the intended recipient is
strictly prohibited.
|
<ESR030-LWM2M-MQTT-1.0-ADraft4.pdf>_______________________________________________ iot-wg mailing list iot-wg@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-wg
|
