Use mobile application as thread router

[Nicolas Crochet]

Hi,

Sorry for the inconvenience if this is not the right place to ask this question.

I am pretty new to Open Thread and there is something that I cannot quite wrap my head around.

I am making a proof of concept using Amazon FreeRTOS to push MQTT messages from a BLE device toward AWS IoT Core through my mobile application with the given Amazon SDK for Android.

I was wondering how I would approach this proof of concept using Google IoT Core instead, and this were I discovered Open Thread :

Connect Thread Devices to the Cloud with IoT Core (Google I/O'19)

During the introduction all the key words made me really excited for Open Thread :

• RF network agnostic
• Platform agnostic
• And my client not wanting to have to put an additional gateway to use my first product

This is where I am a bit lost. Everywhere I look on Open Thread, you need to use a Thread router to connect devices.

Is connecting devices to internet with Ipv6 through a mobile application a futur goal of Open Thread ? (being not possible right now because not integrated in RF modules protocols and mobile applications SDK)

Or am I completely lost on Open Thread concept, from what I understood in this introduction, and the idea is to rely on Thread gateways diffusion as a general agnostic entry point to many projects ?

Thanks in advance,

[Jonathan Hui]

OpenThread is an open-source implementation of the Thread protocol, which is an IPv6-based link technology analogous to Wi-Fi but intended for ultra low-power devices and applications. You can find an overview of Thread and OpenThread in our Google I/O 2018 session.

Thread is currently specified over IEEE 802.15.4. As a result, for two devices to communicate, they will both need to include an IEEE 802.15.4 radio. However, because Thread transports standard IPv6 datagrams, Thread supports any IP-based application layer running on top. Supporting IP makes it possible for a given application layer to support multiple link technologies simultaneously (Ethernet, Wi-Fi, Cellular, and Thread). At the same time, supporting IP allows a given Thread network to support multiple application layers simultaneously without the need for application layer gateways in between. Wi-Fi APs, for example, enjoy these same benefits and Thread extends those benefits to ultra low-power applications.

Hope that helps.

--

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/fcf68691-9668-43b9-a51f-b16c151c65aan%40googlegroups.com.

[Nicolas Crochet]

Jonathan,

Thank you for your clarification !

I thought Thread was actually working on top of low-power IP protocols such as Zigbee and BLE, but it is more another IP based network.

Thanks again,

[Nicolas Crochet]

Hi,

Just another quick question.

What makes Thread great over BLE (that already has Ipv6 in its protocol) ?

Thanks,

[Jonathan Hui]

BLE was not designed to support general-purpose networking.

Nanoleaf's page highlights the benefits of Thread in their solution: https://nanoleaf.me/en-US/integration-hub/thread/

HomePod mini + Nanoleaf hands-on reviews also clearly demonstrate the user-facing benefit of Thread: Thread vs. Bluetooth - featuring the Nanoleaf Essential Bulb & Light Strip

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/6f71e915-7b02-4fed-9dae-e7ac434f5a28n%40googlegroups.com.

[Douglas Rocha Ferraz]

Hi Nicolas,

I'll echo Jonathan's answer. Bluetooth and Bluetooth LE were designed for a different paradigm of central-to-peripheral communication. It’s great that all phones today have it, but I see four main disadvantages: 1. BLE doesn't scale as the number of devices grows. You'll quickly reach a bottleneck. 2. You are limited by the link budget of your radio 3. IP isn’t native (no standard for its abstraction really took off) and 4. connections take time and introduce latency

Thread addresses those issues and the results we see on the devices that adopted it are very encouraging (check the videos!). Moreover, thread also allows low power devices, which is a main issue with Wifi sensors. Finally, there's a great open source codebase and industry momentum.

On the flip side, you must always remember to be concise on all messages, as in any low-power network. Though low-latency, bandwidth is limited. And as mentioned, it uses IEEE 802.15.4 radios, thus you’ll need one or more border routers to access the network before phones and computers start adopting 802.15.4

Check OpenThread’s website for some great tutorials on getting started

Best,

Douglas Ferraz
dou...@nanoleaf.me

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAGwZUDuonte7XuUu-Q5iD4eEfwO-%2BdfNDeLw2igE1JOM8rc28g%40mail.gmail.com.

[Nicolas Crochet]

Jonathan, Douglas,

Thank you for your detailed answers, I understand Thread with much more clarity now.

This video also helped a lot : https://www.youtube.com/watch?v=GL3PzxuiIPo&ab_channel=AutomateYourLife

For industrial applications, I think Thread will only take off when embedded on phones or if major companies adopt it at once. 

Selling a first connected product to your industrial client with an additional gateway is too difficult.

Especially if it is a simple low-cost and low-power device: the device might cost the same as the gateway.

But once developed, a Thread network could be great on an industrial site with its inherent security and reliability.

Great job for making it happen !

Kind regards,