How to exchange data between any Mesh nodes?

797 views
Skip to first unread message

Catalin I

unread,
Jul 6, 2018, 7:12:33 AM7/6/18
to openthread-users
Hi community,

Now, that I have a Thread mesh-network created, I need to communicate between any 2 nodes, but the question is how node A knows what's the unicast IPv6, of another node, B?

Solution that I found is:
1. each node binds a UDP port (1234) and listens for packets
2. each node broadcasts to ff03::1 (multicast FTD and MED)its own name, IPv6 Mesh-local EID, properties, IDs, etc.
3. each node receiving data, on 1234 port, answers with unicast message(to the sender), with his own IP ML-EID
4. if a node changes his partition or mesh-network, will redo the broadcasting

In the end, most likely, every node can send data to any other node using the IPv6 ML-EID.

If I use RLOC IP instead of ML-EID, due to re-configuration, the RLOC address changes, so for this reason I've used ML-EID. I guess a mesh dividing in 2(or more) partitions will occur less often as Child changing RLOC16. 
I did noticed, sending an IP unicast to RLOC address is faster, than sending it to ML-EID (also for ML-EID first UDP package doesn't reach for 2-3 hops).

I did tested it using manual CLI commands, and seems to work (5-6 nodes were in mesh).

A second solution (on short) would be every child to send his ML-EID to parent-router, then routers to synch their table between them. All these transmissions will be unicasts, based on RLOC, and the RLOC16 of the neighbors.

Please, let me know if you have a better solution, or mines are wrong.

cabled

unread,
Jul 6, 2018, 12:39:42 PM7/6/18
to openthread-users
Hello,

I don't have a solution per se and my use-case is slightly different but it might be useful to share and perhaps cross-iterate a little. Have not tested the below process as I just finished thinking about it earlier today but here goes:

My intention is to have a network of SED nodes returning data back to an aggregator (either FTD or NCP type implementation). 
1) This aggregator can be programmed to populate a field with its own ML-EID. 
2) Every subsequent node that comes on-line requests this data field from its own parent right after it completes the network joining process. 
3) This request can be handled either by UDP or COAP (Have not yet had success initializing COAP on an NCP)... 
4) Transmissions can then be directed to the aggregator thru the ML-EID that has been propagated via this field
5) Presumably some sort of catch condition will have to be coded in to refresh this field if the original aggregator gets swapped out (new target endpoint ML-EID)

That's as far as I've gotten at the moment. 

Apologies again that its not actually a solution, just my own processes in a similar area...

Catalin I

unread,
Jul 6, 2018, 5:25:19 PM7/6/18
to openthread-users
This is interesting, it would solve my second scenario, in which all the nodes from the mesh network should be able to send data on Internet. So, your aggregator behaves as a Border Router. 
This could help you (or you may already know), there is the option of adding an on-mesh prefix (prefix command in CLI). After adding a prefix on the Border Router, on my network (MEDs + FTDs) all the nodes got a new IPv6 unicast having this prefix, but I still don't understand if they know who's the Border Router, in order to send him all the data for outside-mesh. Or if there's any unicast way to send him data. Jonathan mentioned Border Router(BR) serves as a default route for the on-mesh prefix, but I don't know how to hook BR to obtain these packets. 

Thanks a lot!

cabled

unread,
Jul 6, 2018, 8:10:23 PM7/6/18
to openthread-users
Ideally I would use a NCP border router as my aggregator yes. When you use the NCP to initialize the network, the on-mesh prefix can be set via the UI so that's usually fairly easy. 

Are you already able to ping through to the internet from your nodes? I imagine that if the GUA has been broadcast correctly there must be some sort of router advertisement at the stack level that takes care of gateway identification. 

The part where this has stalled for me is trying to bridge the connections or see if they're bridged. I started with both RPi3 and BBB re settling down on the RPi3 for further study. Because I don't receive native IPv6 from my WAN, I use a 6to4 tunnel and get a 2003 (or similar) ipv6 address prefix. All the devices on the eth LAN obtain a proper global address with the right prefix. This includes the eth0 interface on the RPi3. However, I do not see the wlan or wpan interfaces picking up a global 2003 prefix address and my Thread nodes do not receive a GUA either. I also cannot ping from the eth lan through to the wpan.

It seems either 
i) my RPi3 interfaces are not bridged?
ii) despite requesting /62 from the 6to4 tunnel, it is actually only supplying me /64. I recall reading somewhere that for the NCP requires /62 to propagate but I may have misunderstood the article

I've also not managed to figure out how to initialize a second coap instance (separate from the internal thread processes) on the border router to handle data.

Stuart Longland

unread,
Jul 6, 2018, 8:44:25 PM7/6/18
to openthre...@googlegroups.com
On 07/07/18 02:39, cabled wrote:
> 3) This request can be handled either by UDP or COAP (Have not yet had
> success initializing COAP on an NCP)... 

I find with an NCP, you run the CoAP server on the host. In my case it
was a NodeJS CoAP module (forget which one) running within a Docker
container (with "host" mode networking, rather than the container being
on an isolated bridge).

The NCP itself didn't do any CoAP stuff.
--
_ ___ Stuart Longland - Systems Engineer
\ /|_) | T: +61 7 3535 9619
\/ | \ | 38b Douglas Street F: +61 7 3535 9699
SYSTEMS Milton QLD 4064 http://www.vrt.com.au

cabled

unread,
Jul 6, 2018, 9:14:10 PM7/6/18
to openthread-users
Hi Stuart,

Thanks for the pointer. I'll take a look at the Docker option on my pi on Monday. Probably take a while as I haven't played with it previously. May I ask, since you managed to get it to work... conceptually, running a get command from NCP to end node is fine. What happens if I want to use the end node to put/post data back to the host? 

Would the instance of the CoAP server on the host then have to be created with the necessary URIs? Or are we able to put data directly back into the filesystem on the host? 

Catalin I

unread,
Jul 7, 2018, 1:55:26 AM7/7/18
to openthread-users

Are you already able to ping through to the internet from your nodes? I imagine that if the GUA has been broadcast correctly there must be some sort of router advertisement at the stack level that takes care of gateway identification. 

No pinging to Internet, as I have to implement my custom forwarding on my hardware (packets from Radio modem have to be forwarded to Wifi interface). So, this is currently my problem that I don't know how to catch on border router the packets with destination Internet.
Ideally, any Router (and Leader) should know the default gateway(boarder router GUA IPv6) for the on-mesh prefix (GUA). If only I can grab that somehow.

I see that most of the Wifi AP still have IPv4, so the NAT64 is the next problem... though I will unpack ipv6 and repack as ipv4 manually (in my case, not a lot of packets to Internet, and only to known Internet destinations).

Jonathan Hui

unread,
Jul 7, 2018, 2:19:23 AM7/7/18
to Catalin I, openthread-users
As mentioned in a previous post, take a look at the otIp6ReceiveCallback API for receiving IPv6 datagrams that need to be forwarded beyond the Thread network.  You can inspect the NCP code for an example usage.

--
Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/da5fc3c8-0399-4718-81b4-a8b29e50fb9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stuart Longland

unread,
Jul 8, 2018, 8:09:17 AM7/8/18
to openthre...@googlegroups.com
On 07/07/18 11:14, cabled wrote:
> Thanks for the pointer. I'll take a look at the Docker option on my pi
> on Monday. Probably take a while as I haven't played with it previously.

Well, I'll point out our border router is an x86 box, I did try Docker
once on armel, and it ended in tears. Never tried it on armhf, I'd be
inclined to run the CoAP server directly on the Pi rather than within
Docker.

> May I ask, since you managed to get it to work... conceptually, running
> a get command from NCP to end node is fine. What happens if I want to
> use the end node to put/post data back to the host? 

Not quite sure what you mean by "get a command" or what you mean by "host".

If your OpenThread device knows the IP address of your NCP running a
CoAP server, you can send a request to the CoAP server, NCP will forward
the frame to wpantund, which will hand it to the Linux IPv6 stack, and
eventually, your CoAP server receives the UDP message.

Likewise, sending a request, if you know the address of your OpenThread
device, your application sends the UDP message, Linux stack forwards to
wpantund, which forwards to NCP, out to the 6LoWPAN network.

> Would the instance of the CoAP server on the host then have to be
> created with the necessary URIs? Or are we able to put data directly
> back into the filesystem on the host? 

Depends on how your CoAP server is written, but most I've seen are
libraries, so you'd have to write a handler to do something with the
data you've just been sent.
Reply all
Reply to author
Forward
0 new messages