The future of Thread and border routers - will it be hubless?
170 views
Skip to first unread message
mjkuwp94
Apr 11, 2021, 9:33:48 AM4/11/21
to openthread-users
Hello,
Background:
I am the one who chose to use Thread for our new product at my place of work and we are working on the proof of concept now. Naturally there are challenges to this position because there are other ways to accomplish the end goal.
In the look we assumed there would be commercial Border Routers being that Thread is a published standard with some popularity and that it does not contain an application layer. I believe it is intended to be analogous to WiFi but of course for battery powered things.
What I have found is that for our product we will need to develop a Hub (Border Router) and we will design this for our own product's needs. We will have some functions in the border router to support our product and help it to be reliable. Having come further in development it now seems that we didn't need the ip packets in order to build this network because the border router (gateway) can translate any kind of message. I have also found building of the proof of concept border router to be more challenging than I anticipated because there is not one fixed, fully functioning example.
In my home I have a Yale Lock and it required the Nest Connect. I also have eve home Door sensors and they required the Apple Homepod Mini. These are both Thread border routers but neither can help me get my own personal Thread devices onto the internet. I didn't have either of these 'routers' before I decided to get the sensors and the door lock.
I have even seen one ioT company boldly market their products as "No Hub" on the same product page identifying the Apple Homepod Mini as the hub. The marketing is not honest.
If each product family based on Thread requires its own Hub then I am unsure what the advantage is other than likely having a better overall network design than the older standards.
What are some possible solutions to this issue assuming the goal is to widen the use of Thread to benefit all of us that will use it? Or is my assertion incorrect?
PS, I have asked related questions prior
I know this is a challenging question to ask in this forum and I risk offending those who have helped build such incredible technology. It is not my intent to offend anyone but It think this is an important topic to tackle so that the Thread project can grow.
tldr:
Will there be 3rd party Thread Border Routers in the same way a consumer can buy a WiFi access point or router today? Alternately, will there be white-label commercial products available to companies not desiring to make their own hardware and software for this standard task?
tldr:
Will there be 3rd party Thread Border Routers in the same way a consumer can buy a WiFi access point or router today? Alternately, will there be white-label commercial products available to companies not desiring to make their own hardware and software for this standard task?
Background:
I am the one who chose to use Thread for our new product at my place of work and we are working on the proof of concept now. Naturally there are challenges to this position because there are other ways to accomplish the end goal.
In the look we assumed there would be commercial Border Routers being that Thread is a published standard with some popularity and that it does not contain an application layer. I believe it is intended to be analogous to WiFi but of course for battery powered things.
What I have found is that for our product we will need to develop a Hub (Border Router) and we will design this for our own product's needs. We will have some functions in the border router to support our product and help it to be reliable. Having come further in development it now seems that we didn't need the ip packets in order to build this network because the border router (gateway) can translate any kind of message. I have also found building of the proof of concept border router to be more challenging than I anticipated because there is not one fixed, fully functioning example.
In my home I have a Yale Lock and it required the Nest Connect. I also have eve home Door sensors and they required the Apple Homepod Mini. These are both Thread border routers but neither can help me get my own personal Thread devices onto the internet. I didn't have either of these 'routers' before I decided to get the sensors and the door lock.
I have even seen one ioT company boldly market their products as "No Hub" on the same product page identifying the Apple Homepod Mini as the hub. The marketing is not honest.
If each product family based on Thread requires its own Hub then I am unsure what the advantage is other than likely having a better overall network design than the older standards.
What are some possible solutions to this issue assuming the goal is to widen the use of Thread to benefit all of us that will use it? Or is my assertion incorrect?
PS, I have asked related questions prior
Jonathan Hui
Apr 12, 2021, 4:41:28 PM4/12/21
to mjkuwp94, openthread-users
Thread is still a relatively nascent technology. I hope to see Thread Border Routers widely available by the end of this year. Project CHIP will also drive the need for Thread Border Routers.
I encourage you to join the Thread Group so that you can have greater visibility into the development and deployment of Thread technology.
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/b742caae-9b0d-4d5e-b1b3-d900b48f7752n%40googlegroups.com.
mjkuwp94
Apr 13, 2021, 8:30:12 AM4/13/21
to openthread-users
Jonathan,
Sincerely,
I really appreciate the responses. We had starting discussing the memberships a while back and that is something that may happen. In general membership either means spending their own money or asking their boss for money which is almost worse. Our company would not qualify as a startup. What we must do first is illustrate the technology and the need. There would be no reason for membership if we end up choosing a different network design so of course this is a little bit like the chicken and egg.
Assuming the technology or standard is available to share routers there is still the question of the business case. For the network that I am building I can say I will be thrilled if it works well for just our equipment and I would have no motivation to bother opening it up for other parties to send traffic on 'my' network. It seems that the solution would be a 3rd party that is only providing the router and has no interest in ownership of the ecosystem. Of course, I am not a business-minded person so I could totally be wrong.
side note, I got the Yale/Google/Nest Connect door lock set up very easily and it has worked well with no drama. I cannot say the same for the eve home sensors as they rely on the Apple Homepod Mini and I don't have an iPhone. I had to borrow a phone from another household member but of course now the HomePod Mini's Thread network is kind of attached to that account. Don't want to get side-tracked here but the point is that closed systems can be frustrating to consumers and I would never have purchased those sensors and HomePod Mini if I were not researching this topic.
As you said, the hope probably lies with CHIP "What Does Project CHIP Mean For Thread In Commercial?"
Assuming the technology or standard is available to share routers there is still the question of the business case. For the network that I am building I can say I will be thrilled if it works well for just our equipment and I would have no motivation to bother opening it up for other parties to send traffic on 'my' network. It seems that the solution would be a 3rd party that is only providing the router and has no interest in ownership of the ecosystem. Of course, I am not a business-minded person so I could totally be wrong.
side note, I got the Yale/Google/Nest Connect door lock set up very easily and it has worked well with no drama. I cannot say the same for the eve home sensors as they rely on the Apple Homepod Mini and I don't have an iPhone. I had to borrow a phone from another household member but of course now the HomePod Mini's Thread network is kind of attached to that account. Don't want to get side-tracked here but the point is that closed systems can be frustrating to consumers and I would never have purchased those sensors and HomePod Mini if I were not researching this topic.
As you said, the hope probably lies with CHIP "What Does Project CHIP Mean For Thread In Commercial?"
Sincerely,
Mark
Jonathan Hui
Apr 13, 2021, 10:36:10 AM4/13/21
to mjkuwp94, openthread-users
On Tue, Apr 13, 2021 at 5:30 AM mjkuwp94 <mjk...@gmail.com> wrote:
I really appreciate the responses. We had starting discussing the memberships a while back and that is something that may happen. In general membership either means spending their own money or asking their boss for money which is almost worse. Our company would not qualify as a startup. What we must do first is illustrate the technology and the need. There would be no reason for membership if we end up choosing a different network design so of course this is a little bit like the chicken and egg.
The Thread Group has an Innovation Enabler Award for exactly your scenario. It is advertised under the Thread Group's "Become a Member" page. I encourage you to apply.
Assuming the technology or standard is available to share routers there is still the question of the business case. For the network that I am building I can say I will be thrilled if it works well for just our equipment and I would have no motivation to bother opening it up for other parties to send traffic on 'my' network. It seems that the solution would be a 3rd party that is only providing the router and has no interest in ownership of the ecosystem. Of course, I am not a business-minded person so I could totally be wrong.
Existing Wi-Fi AP companies are currently participating in the Thread Group. You can find them listed on the Thread Group Members page. I would reach out to one or more of them.
--
Jonathan Hui
Jonathan Hui
Philipp Ebneter
Apr 15, 2021, 3:34:05 AM4/15/21
to openthread-users
These are interesting questions and somewhat related to the clarifications I'm seeking.
I believe what many are missing is an overview of possible interaction scenarios of devices and a control elements on a Thread network. Questions like:
- Which device(s?) is responsible to allow devices into a Thread network. Can there be many?
- How does a device "know" where to send status updates and from where to receive commands? Can there be many components that receive data and send commands to one single device?
- What impact does this have on digital twins in the cloud? Today, many device manufacturers also provide a cloud component that adds things like remote control, value added services etc. Is that a scenario that still makes sense in a Thread network, or will it disappear over time?
For context: I'm working for an automation company "Apilio" and our service is hosted in the cloud with no local hardware. We integrate with devices through cloud APIs only.
Jonathan Hui
Apr 15, 2021, 1:25:25 PM4/15/21
to Philipp Ebneter, openthread-users
Responses below:
On Thu, Apr 15, 2021 at 12:34 AM Philipp Ebneter <philipp...@apilio.io> wrote:
These are interesting questions and somewhat related to the clarifications I'm seeking.I believe what many are missing is an overview of possible interaction scenarios of devices and a control elements on a Thread network. Questions like:- Which device(s?) is responsible to allow devices into a Thread network. Can there be many?
Allowing a new device onto the network requires providing the Thread network credentials to the device.
Thread devices a Thread Commissioning process, where a Commissioner (maybe running on mobile) can authenticate a new device and provide Thread credentials over a secure channel using the Thread network.
Alternatively, vendor-specific methods may also be used to provide Thread network credentials to the new Thread device.
- How does a device "know" where to send status updates and from where to receive commands? Can there be many components that receive data and send commands to one single device?
Thread is an IP-based network, so this is no different than any other IP-based device.
The "where" typically involves some kind of service discovery (e.g. using DNS-SD).
As with IP, a given device may communicate with any number of other IP endpoints.
- What impact does this have on digital twins in the cloud? Today, many device manufacturers also provide a cloud component that adds things like remote control, value added services etc. Is that a scenario that still makes sense in a Thread network, or will it disappear over time?
Thread just provides IP-based connectivity. The digital twin concept or, more generally, proxying for devices in the cloud can still make sense for applications that benefit from such an architecture.
Hope that helps.
--
Jonathan Hui
Reply all
Reply to author
Forward
0 new messages