• State Verified Answer
  • Replies 2 replies
  • Subscribers 69 subscribers
  • Views 543 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 302375
Options

Best mesh stack for large scale sensor network

Marshal

Hello,

I'm working on an application with potentially thousands of nodes in a network. The sensor only needs to send it's readings every 6 hours or so and the payload will be less than 8 bytes. I am planning on targeting openthread due to network reliability and congestion concerns with the flood approach in Bluetooth mesh. Is my judgement correct in the opinion of others? I haven't found much information on a network this large. Has anyone had experience with this? Open thread claims to support 16K nodes in a network, but has anyone tested this in a real network?

Thanks in advance,

Marshal

Parents
  • +1

    Hi Marshal, 

    OpenThread, in it original form, focus on Home Automation and normally it aims at a network with maximum a few hundred nodes.

    Of course on the theory you can do the calculation to get 16000 nodes, but the challenge here is that the maximum number of router is 32 and you need to distribute a few hundred end node in the range of each router to be able to achieve the number of a few thousands node you are looking at. In addition, by having a few hundred node in the range of one single router, there will be a lot of traffic for keeping the routing table up to date. This can easily making congestion. 

    You can use broadcast mode and may overcome the limitation of the max number of routers and routing table complexity. But then it's no different from a flooding network. 

    I haven't seen any report on testing Thread with more than few hundred nodes.

    In your case, I would still suggest to use Bluetooth mesh if you don't plan to have IP access on each of the node like what supported in OpenThread. 

    I agree that there could be a challenge of network congestion when doing flooding mesh with thousands of nodes. But it's only the case if you let all nodes to do relaying.

    Instead, there should be only a handful number of "backbone" nodes that should do the relay task. I would assume the sensors are static and will not move. In that case, when deploying, you can find a list of minimum number of nodes that can cover the whole area (with some redundancy) that should act as relay node. So instead of having the package retransmitted a few thousand time on every node, you can reduce it down to few hundred times or maybe even less, as long as the range of those who retransmit cover the whole network. In addition, you can limit the retransmission by using TTL as well. It will limit the maximum number of hop a message should be forwarded. If you know for sure that a packet shouldn't take more than 10 hopes for example to reach the destination, you can limit that down. 

    Bluetooth mesh works extremely well with short data of less than 11 bytes. It doesn't have the IP overhead that Thread has and doesn't have the routing table that requires constant update. 

Reply
  • +1

    Hi Marshal, 

    OpenThread, in it original form, focus on Home Automation and normally it aims at a network with maximum a few hundred nodes.

    Of course on the theory you can do the calculation to get 16000 nodes, but the challenge here is that the maximum number of router is 32 and you need to distribute a few hundred end node in the range of each router to be able to achieve the number of a few thousands node you are looking at. In addition, by having a few hundred node in the range of one single router, there will be a lot of traffic for keeping the routing table up to date. This can easily making congestion. 

    You can use broadcast mode and may overcome the limitation of the max number of routers and routing table complexity. But then it's no different from a flooding network. 

    I haven't seen any report on testing Thread with more than few hundred nodes.

    In your case, I would still suggest to use Bluetooth mesh if you don't plan to have IP access on each of the node like what supported in OpenThread. 

    I agree that there could be a challenge of network congestion when doing flooding mesh with thousands of nodes. But it's only the case if you let all nodes to do relaying.

    Instead, there should be only a handful number of "backbone" nodes that should do the relay task. I would assume the sensors are static and will not move. In that case, when deploying, you can find a list of minimum number of nodes that can cover the whole area (with some redundancy) that should act as relay node. So instead of having the package retransmitted a few thousand time on every node, you can reduce it down to few hundred times or maybe even less, as long as the range of those who retransmit cover the whole network. In addition, you can limit the retransmission by using TTL as well. It will limit the maximum number of hop a message should be forwarded. If you know for sure that a packet shouldn't take more than 10 hopes for example to reach the destination, you can limit that down. 

    Bluetooth mesh works extremely well with short data of less than 11 bytes. It doesn't have the IP overhead that Thread has and doesn't have the routing table that requires constant update. 

Children
Related