Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6TiSCH not supported in RIOT #13259

Closed
4 tasks
chrysn opened this issue Feb 2, 2020 · 5 comments
Closed
4 tasks

6TiSCH not supported in RIOT #13259

chrysn opened this issue Feb 2, 2020 · 5 comments
Assignees
Labels
Area: network Area: Networking Type: tracking The issue tracks and organizes the sub-tasks of a larger effort

Comments

@chrysn
Copy link
Member

chrysn commented Feb 2, 2020

Currently, RIOT does not support the 6TiSCH, which is the adaption of 6LoWPAN over 802.15.4 TSCH (time slotted channel hopping), which is advertised as a vast improvement over fixed-channel 6LoWPAN. This issue tracks the over-all steps that are needed in RIOT to run 6TiSCH.


Meta: Given that 6TiSCH is a much sought-after topic that comes up regularly in 6LoWPAN discussions, something web-searchable should reflect the state of things here. (At the time of writing, searches of riot and 6TiSCH yield links to outdated presentations, external libraries mentioning OpenWSN integration and similar).

@chrysn chrysn added Area: network Area: Networking Type: tracking The issue tracks and organizes the sub-tasks of a larger effort labels Feb 2, 2020
@fjmolinas
Copy link
Contributor

I'm currently working on porting OpenWSN back into RIOT as a pkg. The initial approach I'm taking will be to take the whole stack. In #8570 it was taken only up to udp, but since the join procedure was added there is a hard dependency to OpenWSN coap this will initially need to be added.

I hope to be able to open an initial PR on this in the next week or two.

@PeterKietzmann
Copy link
Member

The initial approach I'm taking will be to take the whole stack.

As far as I know, a RPL root node is required in OpenWSN to initiate the network schedule. However, its implementation in OpenWSN is split into two software components. One of them runs on the embedded node and sends Beacons and advertises IPv6 prefixes. With #8570 and is successors, that worked fine. The second component deals with routing but it runs in a python tool on your machine which connects to the embedded node via openserial (a custom UART). How do you plan to deal with that?

@fjmolinas
Copy link
Contributor

The second component deals with routing but it runs in a python tool on your machine which connects to the embedded node via openserial (a custom UART). How do you plan to deal with that?

I currently use openvisualizer, and have no support for RIOT root nodes, I haven't gotten openserial working properly on RIOT nodes either.

The initial PR would require an OpenWSN root node...

@aabadie
Copy link
Contributor

aabadie commented Jul 2, 2020

#13824 is merged so can we consider this one as resolved ?

@SemjonWilke
Copy link
Member

SemjonWilke commented Jul 2, 2020

@aabadie I think the premise of this Issue is addressed.
To put my two pence in, it might still be desired to either write lower layers providing 6tisch for gnrc or gutting openwsn to enable gnrc on top of it. At last to provide a RIOT-only option, without an openwsn specific rpl root node.
Anyway, I agree that this PR should for now resolve this issue.

@miri64 miri64 closed this as completed Jul 6, 2020
@miri64 miri64 added this to the Release 2020.07 milestone Jul 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking Type: tracking The issue tracks and organizes the sub-tasks of a larger effort
Projects
None yet
Development

No branches or pull requests

7 participants