Is available mesh networking over 6LowPan?
177 views
Skip to first unread message
Juan FM
Apr 23, 2018, 4:29:38 AM4/23/18
to NuttX
Hi!
As I wrote in previous thread, I'm trying to work with 6LowPan with the Olimex-Stm32-E407 board and the MRF24j40 module.
At the moment, it's working properly in StartPan topology (I've tried with 3 UDP clients connected at the same time to an UDP server).
So my question is, if it's available mesh networking and in the positive case, how it's possible to use it?
In the config menu (Networking Support -> Internet protocol selection), I saw "Number of IPv6 neighbors" and "Enable L2 forwarding" and maybe that options are related with mesh networking.
Thank you for your help!
As I wrote in previous thread, I'm trying to work with 6LowPan with the Olimex-Stm32-E407 board and the MRF24j40 module.
At the moment, it's working properly in StartPan topology (I've tried with 3 UDP clients connected at the same time to an UDP server).
So my question is, if it's available mesh networking and in the positive case, how it's possible to use it?
In the config menu (Networking Support -> Internet protocol selection), I saw "Number of IPv6 neighbors" and "Enable L2 forwarding" and maybe that options are related with mesh networking.
Thank you for your help!
patacongo
Apr 23, 2018, 9:10:06 AM4/23/18
to NuttX
So my question is, if it's available mesh networking and in the positive case, how it's possible to use it?
There is no mesh networking in the source tree.
I have been discussing a mesh implementation with another person as well.
I believe that this is a application program not part of the OS. The OS needs to provide all of the raw packet hooks and IOCTL commands to support the mesh, but the mesh logic is part of the application space... at least that is my belief unless show otherwise. I have no idea what part of the mesh other that support for AF_IEEE802154 sockets broadcast would need to be provided by the OS.
I think you should be able to take any of several meshes that are available for Linux out there and adapt them to work on top of NuttX AF_IEEE802154 sockets. I suggest that you review those. If there is any missing functionality to support those meshes, then the operating system should support that.
Juan FM
Apr 24, 2018, 3:59:40 AM4/24/18
to NuttX
Hi Greg,
I was exploring a little how it was implemented the 6lowpan protocol in NuttX and I saw that it's a port of Contiki OS. So, I'm investigating it and I saw that that OS have support for mesh networking with multi hopping over IpV6.
So maybe it's a good idea try to port it from Contiky.
Do you any suggestion about how to start?
Juan.
patacongo
Apr 24, 2018, 8:58:14 AM4/24/18
to NuttX
I was exploring a little how it was implemented the 6lowpan protocol in NuttX and I saw that it's a port of Contiki OS. So, I'm investigating it and I saw that that OS have support for mesh networking with multi hopping over IpV6.So maybe it's a good idea try to port it from Contiky.
I think that would be very difficult. 6LoWPAN does derive from Contiki but it has been highly modified and adapted to work within the NuttX BSD socket layer.
So the environment is complete. You might be able to start with that mesh but you would have to convert all of the interfaces to use AF_IEEE802154 socket interfaces. That would be a lot of work (but also a good contribution if you have a few weeks to spend on it).
Greg
patacongo
Apr 24, 2018, 10:19:39 AM4/24/18
to nu...@googlegroups.com
Looking at the Contiki code. I think this is the key stuff
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.h
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.c
It also seems pretty intangled with a routing table:
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.c
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.h
But otherwise seems pretty much self-contained.
So the good things about porting this:
1. It is small and selfcontained,
2. It has a BSD license
And the bad,
It looks to me like just about every line of code would have to change. This would be framework upon which you would have to adapt all of the buffering and interfacing logic. You would have to add the socket layer interface. It currently works on callbacks, for example, a read callback is used when incoming data is available. That would have to be converted to a thread that opens a socket and waits on recvfrom(). And similarly for other callbacks.
It would have to be converted to a proper POSIX application that obeys the rules and properly uses the BSD socket layer.
But it looks to me like it is doable. But I think the the Contiki mesh code would serve only as a design framework upon which you would have to re-implement everything. Since the code is small, I don't see that as a big deal. It would not be an obstacle for me if I were interested in porting the code.
Greg
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.h
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.c
It also seems pretty intangled with a routing table:
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.c
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.h
But otherwise seems pretty much self-contained.
So the good things about porting this:
1. It is small and selfcontained,
2. It has a BSD license
And the bad,
It looks to me like just about every line of code would have to change. This would be framework upon which you would have to adapt all of the buffering and interfacing logic. You would have to add the socket layer interface. It currently works on callbacks, for example, a read callback is used when incoming data is available. That would have to be converted to a thread that opens a socket and waits on recvfrom(). And similarly for other callbacks.
It would have to be converted to a proper POSIX application that obeys the rules and properly uses the BSD socket layer.
But it looks to me like it is doable. But I think the the Contiki mesh code would serve only as a design framework upon which you would have to re-implement everything. Since the code is small, I don't see that as a big deal. It would not be an obstacle for me if I were interested in porting the code.
Greg
patacongo
Apr 24, 2018, 1:48:14 PM4/24/18
to NuttX
A few more thoughts:
In addition to the mesh and routing table,
In addition to the mesh and routing table,
Looking at the Contiki code. I think this is the key stuff
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.h
https://github.com/contiki-os/contiki/blob/master/core/net/rime/mesh.c
It also seems pretty intangled with a routing table:
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.c
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route.h
There is also logic that handles nexthop
https://github.com/contiki-os/contiki/blob/master/core/net/rime/nexthop.c
https://github.com/contiki-os/contiki/blob/master/core/net/rime/nexthop.h
and route discovery:
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route-discovery.c
https://github.com/contiki-os/contiki/blob/master/core/net/rime/route-discovery.h
I think that the routing table and nexthop logic would probably go in the OS: If asked the NuttX network to send a raw ieee802.15.4 frame to a unreachable endpoint, the network would need to get the nexthop from the some kind of routing table that maps non-reachable radio addresses via a hop through a reachable radio. The other logic would be in the application space, particularly the route discovery logic which implements a non-standard packet protocol to query for routes. You would use raw AF_IEEE802154 sockets for that.
This mesh implementation appears light when it comes to mesh maintenance. In a real world application with drones or robots, endpoints would be appearing and disappearing routes need to change dramatically. They will break and need to heal frequently. You also need to pick the best route and avoid loops when multiple routes are available. To do this right usually involves very creative, patent-able algorithms.
Brennan Ashton
Apr 24, 2018, 2:48:09 PM4/24/18
to patacongo, NuttX
On Tue, Apr 24, 2018 at 10:48 AM patacongo <spud...@gmail.com> wrote:
This mesh implementation appears light when it comes to mesh maintenance. In a real world application with drones or robots, endpoints would be appearing and disappearing routes need to change dramatically. They will break and need to heal frequently. You also need to pick the best route and avoid loops when multiple routes are available. To do this right usually involves very creative, patent-able algorithms.
I have actually had reasonable success using Thread as a 15.4 routed mesh, but if you have things going on/offline a lot the rebuilding of route tables starts to take a tole
I have not used Thread with Nuttx, so I cannot comment on how that would all fit together, but it does not look like it would be too complicated to actually build this as an application library.
I think everything is already done on the OS to support the radio interfaces:
patacongo
Apr 24, 2018, 6:22:54 PM4/24/18
to NuttX
Hi, Brennan,
Interesting. There is a lot of information at that site, but difficult to get simple facts. You have to provide personal information even to read the license.
The is proprietary product, right? I do see reference to a RAND RF (Royalty Free) license which sounds like a proprietary agreement.
The diagrams show the product as a part of the stack, replacing UDP, IP routing, and 6LoWPAN layers, built on top of the IEEE 802.15.4 MAC/PHY link layer.
In fact, the diagram would look the same as the NuttX stack if you were replace the name Thread with NuttX. Other more detailed diagrams show UDB + dTLS and a security component to the IP forwarding and possible some protocol extensions in the IP forwarding layer.
Although the list of APIs looks innocuous, the diagrams look more invasive. I would propose that an initial NuttX implementation would:
- Focus less on security, Defer security to the application level (although that sounds like "famous last words").
- Leave the NuttX UDP, IP forwarding, and 6LoWPAN generally intact
- Perhaps extend the routing table information. There is sufficient information the current routing table to support one hop and this is used in the currently supported Star configuration to get from one starpoint to another. I am not sure what else would need to be extended. It is sufficient to support the first hop in a multi hop forwarding process. The first hop destination would have to make the same determination for the next hop. I am not sure how we avoid loops in this case so I keep the door open for extended routing table information.
- Any extensions to routing table content might ripple to IP forwarding changes.
- I assume that some logic outside of the OS knows all about mesh routes and manages the single hop / first hop routing table appropriately.
- The custom discovery logic would use AF_IEEE802154 raw sockets to implement the custom protocol. This would result in changes to the appliation routing database and updates to the IP forwarding routing table.
That is far from a design but does represent a first though on functional partitioning, at least from my point of view. Since this is not an area where I have any expertise, I accept I might have misconceived several things. Certainly that is more wishful thinking that anything cast in stone.
Greg
I have actually had reasonable success using Thread as a 15.4 routed mesh, but if you have things going on/offline a lot the rebuilding of route tables starts to take a tole
Interesting. There is a lot of information at that site, but difficult to get simple facts. You have to provide personal information even to read the license.
The is proprietary product, right? I do see reference to a RAND RF (Royalty Free) license which sounds like a proprietary agreement.
I have not used Thread with Nuttx, so I cannot comment on how that would all fit together, but it does not look like it would be too complicated to actually build this as an application library.I think everything is already done on the OS to support the radio interfaces:
The diagrams show the product as a part of the stack, replacing UDP, IP routing, and 6LoWPAN layers, built on top of the IEEE 802.15.4 MAC/PHY link layer.
In fact, the diagram would look the same as the NuttX stack if you were replace the name Thread with NuttX. Other more detailed diagrams show UDB + dTLS and a security component to the IP forwarding and possible some protocol extensions in the IP forwarding layer.
Although the list of APIs looks innocuous, the diagrams look more invasive. I would propose that an initial NuttX implementation would:
- Focus less on security, Defer security to the application level (although that sounds like "famous last words").
- Leave the NuttX UDP, IP forwarding, and 6LoWPAN generally intact
- Perhaps extend the routing table information. There is sufficient information the current routing table to support one hop and this is used in the currently supported Star configuration to get from one starpoint to another. I am not sure what else would need to be extended. It is sufficient to support the first hop in a multi hop forwarding process. The first hop destination would have to make the same determination for the next hop. I am not sure how we avoid loops in this case so I keep the door open for extended routing table information.
- Any extensions to routing table content might ripple to IP forwarding changes.
- I assume that some logic outside of the OS knows all about mesh routes and manages the single hop / first hop routing table appropriately.
- The custom discovery logic would use AF_IEEE802154 raw sockets to implement the custom protocol. This would result in changes to the appliation routing database and updates to the IP forwarding routing table.
That is far from a design but does represent a first though on functional partitioning, at least from my point of view. Since this is not an area where I have any expertise, I accept I might have misconceived several things. Certainly that is more wishful thinking that anything cast in stone.
Greg
Brennan Ashton
Apr 24, 2018, 7:15:57 PM4/24/18
to patacongo, NuttX
On Tue, Apr 24, 2018 at 3:22 PM patacongo <spud...@gmail.com> wrote:
Hi, Brennan,I have actually had reasonable success using Thread as a 15.4 routed mesh, but if you have things going on/offline a lot the rebuilding of route tables starts to take a tole
Interesting. There is a lot of information at that site, but difficult to get simple facts. You have to provide personal information even to read the license.
The is proprietary product, right? I do see reference to a RAND RF (Royalty Free) license which sounds like a proprietary agreement.
There is ThreadGroup which thread is from and one would certify a product under. Much like Bluetooth there are membership/certification fees. While you cannot directly download the spec you can freely download the whitepapers that talk about how this all is wired together.
There is also a BSD licensed stack openthread.io. So is it free... sort of, but selling products with it certainly requires paying.
I have not used Thread with Nuttx, so I cannot comment on how that would all fit together, but it does not look like it would be too complicated to actually build this as an application library.I think everything is already done on the OS to support the radio interfaces:
The diagrams show the product as a part of the stack, replacing UDP, IP routing, and 6LoWPAN layers, built on top of the IEEE 802.15.4 MAC/PHY link layer.
In fact, the diagram would look the same as the NuttX stack if you were replace the name Thread with NuttX. Other more detailed diagrams show UDB + dTLS and a security component to the IP forwarding and possible some protocol extensions in the IP forwarding layer.
Although the list of APIs looks innocuous, the diagrams look more invasive. I would propose that an initial NuttX implementation would:
- Focus less on security, Defer security to the application level (although that sounds like "famous last words").
- Leave the NuttX UDP, IP forwarding, and 6LoWPAN generally intact
- Perhaps extend the routing table information. There is sufficient information the current routing table to support one hop and this is used in the currently supported Star configuration to get from one starpoint to another. I am not sure what else would need to be extended. It is sufficient to support the first hop in a multi hop forwarding process. The first hop destination would have to make the same determination for the next hop. I am not sure how we avoid loops in this case so I keep the door open for extended routing table information.
- Any extensions to routing table content might ripple to IP forwarding changes.
- I assume that some logic outside of the OS knows all about mesh routes and manages the single hop / first hop routing table appropriately.
- The custom discovery logic would use AF_IEEE802154 raw sockets to implement the custom protocol. This would result in changes to the appliation routing database and updates to the IP forwarding routing table.
That is far from a design but does represent a first though on functional partitioning, at least from my point of view. Since this is not an area where I have any expertise, I accept I might have misconceived several things. Certainly that is more wishful thinking that anything cast in stone.
Greg
I don't think you are too far off. I would be hesitant to try and recreate openthread just to try to reuse, the UDP stack. I believe that it would sit nicely on top of what already exists for 6LoWPAN, which is what Zephyr does.
Very thin shims to get some configuration data from 802.15.4 about rssi, and mac addressing. Then they just pass around IPv6 packets.
I don't have very much interest in doing the work to make OpenThread run on NuttX, but just was pointing out this as a routed mesh over 6LoWPAN that I found to actually work and that I don't think it would take much to get it to _just_work_.
--Brennan
patacongo
Apr 24, 2018, 7:44:15 PM4/24/18
to NuttX
Very thin shims to get some configuration data from 802.15.4 about rssi, and mac addressing. Then they just pass around IPv6 packets.
RSSI (or perhaps, the last RSSI) is the kind of information that an application should be able to get via network IOCTL commands.
Most NuttX configurations use MAC-based IPv6 addressing so most MAC addressing can be handled indirectly via IPv6 addressing.
It would be interesting to see how a Linux mesh works. Surely they do not modify the Linux/BSD network stack. I think architecturally, a Linux implementation would have more in common with a NuttX solution than a Contiki or Zephyr solution which do not respect a portable POSIX RTOS interface.
Greg
Brennan Ashton
Apr 24, 2018, 8:11:17 PM4/24/18
to patacongo, NuttX
I must be missing something because that is exactly my understanding of how this is working. L2 is just implemented in userspace, that does not violate the POSIX boundary.
patacongo
Apr 24, 2018, 8:35:32 PM4/24/18
to NuttX
I must be missing something because that is exactly my understanding of how this is working. L2 is just implemented in userspace, that does not violate the POSIX boundary.
We are probably not communicating. I assumed OSI model layer 2 which is definitely inside the OS.
The following is more info than you care about. I am just posting it here for the record:
To get the RSSI, Linux uses the SIOCGIWSTATS IOCTL to get signal strength (Socket IOCtl Get Inet Wireless STATisticS). That IOCTL is defined for NuttX (as are all of the standard wireless IOCTLs) but there has been no need to implement it up to this point.
it returns struct iw_statistics which includes:
/* Quality of the link */
struct iw_quality
{
uint8_t qual; /* link quality (%retries, SNR,
* %missed beacons or better...) */
uint8_t level; /* signal level (dBm) */
uint8_t noise; /* noise level (dBm) */
uint8_t updated; /* Flags to know if updated */
};
{
uint8_t qual; /* link quality (%retries, SNR,
* %missed beacons or better...) */
uint8_t level; /* signal level (dBm) */
uint8_t noise; /* noise level (dBm) */
uint8_t updated; /* Flags to know if updated */
};
The networking logic currently gets the following from the IEEE 802.15.4 MAX on a frame-by-frame basis:
uint8_t lqi; /* Link Quality Index */
uint8_t rssi; /* Non-standard field */
uint8_t rssi; /* Non-standard field */
Juan FM
Apr 27, 2018, 7:17:13 AM4/27/18
to NuttX
Well I think, that I will try to port it, but at the moment it's not totally necessary for the project that I'm doing so I will do with some calm.
Thank you for all the info!!
Juan.
patacongo
Apr 27, 2018, 11:07:45 AM4/27/18
to NuttX
Well I think, that I will try to port it, but at the moment it's not totally necessary for the project that I'm doing so I will do with some calm.
I would think the best, most portable, most standardized starting point would be to implement RFC 6775 ( https://tools.ietf.org/html/rfc6775 ). NuttX currently supports IP forwarding via a route-over topology (per the terminology of the RFC). RFC 6775 also addresses mesh-under routing using a border router in a mesh. Very efficient.
That is at least something that we should consider. I have implementation of RFC 6775 on my list of things to do so I there were people will to share in the burden, I think we could make good progress getting that in place. Once RFC 6775 is in place, then I think we could seriously address complete mesh solutions.
Reply all
Reply to author
Forward
0 new messages