Dear Hauke,
thank you for your answers. Please see my comments inline.
On 11/20/2015 01:13 AM, Hauke Petersen wrote:
Hi,
thanks for sharing your architecture with us, it is always interesting
to see what people are planning! I will try to answer your questions
as good as I can, see answers inline below.
On 19.11.2015 20:09, Patrick Rota - Swissponic Sagl wrote:
Hello everyone,
we are developing an IOT application and we got impressed with RIOT.
It sports some really nice features and it looks like there is a
great community over here.
On the paper RIOT seems to be perfect for our application, but we
need to go deeper before we start investing our resources into this
project. We have some questions that are not easy to answer just by
looking at the documentation, so your experience is much appreciated.
Let me first introduce our platform.
As in many WSN we have multiple wireless nodes and one (or more)
router / coordinator / gateway.
++ Nodes ++
Nodes are based on Atmel SAM R21 that, as you know, is basically an
Atmel SAM D21 plus an Atmel RF233 in the same package. We already
designed the modules and they work well with Atmel code examples.
We want to use the following stack:
RF233 <-> 6LowPAN <-> TCP <-> MQTT client <-> Application
++ Router / coordinator / gateway ++
Another device acts as PAN coordinator and as router/gateway to the
local LAN.
This device is based on a Olimex A13-SOM-512
(https://www.olimex.com/Products/SOM/A13/A13-SOM-512/) running Linux
with a wired Ethernet interface and the same SAM R21 radio module
(with a different firmware). The two boards are connected trough a
serial connection (USART).
Here the communication stack is a little more complex:
[Olimex A13] Application <-> MQTT broker <-> (???) <-> Kernel Serial
driver <-> USART
|
[serial from A13 to SAMR21]
|
[SAMR21] USART <-> (???) <-> 6LowPAN <-> RF233
As you can see, we are not sure about the stack composition, see
"(???)". We would like to integrate the coordinator and routing
functions in the A13 side (since we have more resources there) and
basically just use the SAMR21 as a transceiver.
----
I hope I gave enough details to understand the platform. If not, I
will be happy to answer your questions.
Now, our questions:
1) Architecture: is RIOT viable for this architecture?#
YES indeed! These kind of setups are exactly what RIOT is intended for!
Perfect! We are almost convinced. Today we cloned from the repository
and started playing with the native example and we are even more
impressed. It worked flawlessly out of the box. In the next days we will
try to implement something on the SAM R21 platform.
2) Gateway: which stack layers do you advise to include for the
"(???)" parts? Is it a good idea to include the coordinator on the
A13 side? Or is better to put it into the SAMR21 side?
On first sight I would use SLIP here, which is already supported by
RIOT. Only drawback is that SLIP does as far as I know not support any
802.15.4 link layer specific functionalities, so the PAN coordinator
part would need to be handled by the SAMR21. Resource wise this is not
problem at all (as the samr21 provides plenty of ressources in terms
of memory and processing power to this). Only thing is some missing
parts on the implementation side in RIOT, though I am not quite sure
about the latest state on this.
If I understand well, are you suggesting the following?
[Olimex A13] Application <-> MQTT broker <-> Linux TCP/IP stack <->
SLIP <-> Kernel Serial driver <-> USART
|
[serial from A13 to SAMR21]
|
[SAMR21] USART <-> SLIP <-> 6LowPAN+Coordinator <-> RF233
I'm not really familiar with SLIP, so I don't know if I got it right. At
which level does SLIP operate? It will send IP packets over serial?
SAMR21 is pretty capable, but with 32kB RAM would it be able to
coordinate hundreds of nodes? Somebody ever tried with a large number of
nodes? The original reasoning behind putting the coordinator on the A13
side was for managing a large number of notes.
@Martine, @Oleg: do you know the latest about this?
3) Robustness: please be honest, is RIOT robust and mature enough for
a large scale use? Do you know of commercial products that integrates
it?
A mean thing to ask developers about the maturity of their code :-)
No, seriously: IMHO RIOT is ready and mature enough for large scale
use since the latest 2015.09 release. We have just recently tested
some long-term setups using the samr21 nodes with raspberry pi +
at86rf233 based modules as boarder router that were running for weeks
without any trouble. As young as RIOT is (and especially the GNRC
network stack), I wouldn't expect it to bug free, but I with little
effort one can build very reliable products with it.
Sorry, I didn't want to be mean. I was just seeking a honest answer, to
the benefit of everybody.
I'm glad to hear about the long term setup. Well done!
4) License: RIOT is published with a LGPLv2 license and if we
understand well, we can then use it in our product without any
limitation. Is this right?
'Without limitations' might give the wrong impression. In general the
situation is quite easy: if you change any of the existing code (e.g.
you fix bugs), you have to make those changes available to the
community (e.g. commit them into RIOT's master branch). But you are
perfectly fine in linking RIOT together with your disclosed,
proprietary application code.
Please see my next answer to Matthias and Andrew.
5) TCP: we have seen that some TCP support has been temporarily
removed and being refactored. What is the plan for reintroducing it?
(MQTT is based on TCP)
There is current work going on to re-implement TCP, and last I heard
is that it is already partly working, so I expect TCP support to be
back in RIOT rather soonisch, though we can't give a hard time-frame
on this. Further I can't really tell, which TCP features will be
supported. But this process can probably speed up if more people
decide to help...
We can help on this side.
6) MQTT: is there any plan to develop a MQTT client for RIOT? Is
anybody already developing it?
In general: Yes. But the current effort is focussing on MQTT-SN (the
MQTT variant that works over UDP). But using MQTT-SN might maybe be
also a solution for you to use? As far as I know you can have a
transparent broker between these two variants on the Linux side (e.g.
Paho or similar) and this would remove the need for TCP on the
contrained devices side.
I didn't know about MQTT-SN. Thanks for the hint. I read the
specifications this afternoon and it looks even better for our purpose,
since it's optimized for WSN. Plus, we don't need TCP any more. Perfect.
This is another part where we could help.
I've seen that Paho already offers a C/C++ MQTT-SN client. Could be a
starting point?
7) Mesh: what is the status of meshing networks? Is it working well /
stable?
So far we have pretty stable support for RPL storing mode. Though I am
no expert here, work on RPL non-storing as well as work on OLSRv2 is
on its way.
I don't know what is the difference between the two modes. I need to
study a little more... :-)
8) Security: which level of security RIOT provides? For a commercial
use, it is important that security (authentication, authorization,
encryption) is well implemented. Is this the case?
This is indeed our week spot currently. There is very recent work
going on to include tinyDTLS [1] for transport layer security and
tweetNACL [2] for end-to-end cryptography.
In today's world, security is very important. For RIOT to be adopted on
a large scale, implementing security features must be a priority. As
Things got more and more connected, people get more and more afraid of
security breaches. Some cases already made the news and some other
initiatives (big T for example) put a lot of focus on security.
Just my two cents.
---
We hope that you can shed some light on our doubts. In that case we
will be happy to join your community and adopt RIOT as our base. We
are ready to contribute to the project, in particular by working on
the TCP, MQTT and OTA update, or where needed. We could also provide
some HW if anybody is interested.
That would be really awesome! As stated above, most of the stuff you
need is already there or is being worked on currently - and with some
more help it should even be faster to have these features in RIOT. But
looking at your general architecture again it feels like this is
exactly what RIOT is designed to do!
Please let us know where you need more information and how we can help!
Great!
Cheers,
Hauke
Regards,
Patrick
[1] https://github.com/RIOT-OS/RIOT/pull/4308
[2] https://github.com/RIOT-OS/RIOT/pull/4317
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
