Matter and Thread as Connectivity Solution for Embedded
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/62018 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Goodness of fitConnectivity (graph theory)BitThread (computing)
00:27
Gateway (telecommunications)Open setThread (computing)Proxy serverCommunications protocolService (economics)Image registrationRouter (computing)Wireless LANSystem programmingBit rateOpen sourceRepository (publishing)Software development kitAnwendungsschichtMultiplicationComputing platformConnectivity (graph theory)Standard deviationComputer configurationCore dumpImplementationAbstractionMeta elementNetwork topologyCodePersonal identification numberType theoryFood energyData transmissionQR codeLibrary (computing)BuildingLatent heatMereologyWebsiteInheritance (object-oriented programming)Spring (hydrology)ImplementationMeta elementBitPersonal identification numberElement (mathematics)Group actionChainAbstractionStandard deviationOpen sourceConnectivity (graph theory)Type theoryRevision controlOpen setLink (knot theory)Public key certificateComputing platformModule (mathematics)SoftwareMultiplication signSoftware testingPower (physics)CASE <Informatik>1 (number)Projective planeCartesian coordinate systemSlide ruleThread (computing)Functional (mathematics)Service (economics)Formal languageComputer filePhysical systemProduct (business)Expected valueDifferent (Kate Ryan album)ExpressionHookingCore dumpPolygon meshStatement (computer science)Router (computing)Point (geometry)Gateway (telecommunications)Generic programmingDirect numerical simulationGoodness of fitTerm (mathematics)Uniformer RaumProof theoryINTEGRALInternet der DingeMobile appResultantKernel (computing)Computer animation
10:25
Thread (computing)Local GroupGroup actionElement (mathematics)GoogolOpen sourceOpen setProduct (business)CodeRouter (computing)Inheritance (object-oriented programming)Message passingBroadcast programmingType theoryAdditionComputer networkAddress spaceTopologyUniform resource locatorLink (knot theory)Directed setLocal ringVermaschtes NetzInternetworkingFactory (trading post)Connectivity (graph theory)Repository (publishing)DemonInterface (computing)Software maintenanceNetzwerkprozessorCore dumpImplementationReal-time operating systemModule (mathematics)Image registrationCommunications protocolService (economics)Proxy serverComputing platformMultiplicationUnicastingverfahrenTelecommunicationProgramming paradigmMathematical optimizationDifferent (Kate Ryan album)Gateway (telecommunications)Sample (statistics)Mobile WebMaxima and minimaMeta elementVermaschtes NetzInheritance (object-oriented programming)UnicastingverfahrenCodeMathematical optimizationBitSoftwareKey (cryptography)Product (business)MereologySlide ruleRouter (computing)Stress (mechanics)Latent heatFrame problemWireless LANType theoryProxy serverScheduling (computing)Range (statistics)Connectivity (graph theory)DemonComputer fileProof theoryFunctional (mathematics)INTEGRALService (economics)Term (mathematics)Constraint (mathematics)Direct numerical simulationDenial-of-service attackInterrupt <Informatik>WindowPower (physics)Different (Kate Ryan album)Endliche ModelltheorieCommunications protocolLine (geometry)Image registration1 (number)Revision controlGoodness of fitThread (computing)Real numberBroadcasting (networking)WhiteboardArithmetic progressionModule (mathematics)Demo (music)Multiplication signCore dumpPlastikkartePolygon meshParallel portAddress spaceFirmwareComputer hardwareLink (knot theory)Computing platformAbstractionNormal (geometry)InternetworkingMultilaterationComponent-based software engineeringCartesian coordinate systemQR codeLibrary (computing)InformationOpen setGateway (telecommunications)Computer animation
20:24
Gateway (telecommunications)Open setThread (computing)Sample (statistics)Demo (music)Electric currentMobile WebPower (physics)Router (computing)Computer hardwarePhysicalismRight angleDisk read-and-write headRule of inferenceGateway (telecommunications)QuicksortDefault (computer science)Term (mathematics)SoftwareComputing platformAuthenticationMereologyGroup actionCellular automatonNoise (electronics)Integrated development environmentFeedbackData managementMaxima and minimaBitPolygon meshMeta elementVolume (thermodynamics)Network topologyComputer animation
25:51
Computer animationProgram flowchart
Transcript: English(auto-generated)
00:06
So, good morning everybody, I'm happy to see such a large crowd here, I hope I can stand up for that. So, I will talk a little bit today about, a little bit out about Meta and Thread as
00:23
a connectivity solution for Embedded here. So, the agenda I have, I mean, giving a little bit of a scope for the talk, then give you like an overview about Meta, so I don't know how Stemlove is set, how Stemlove is open thread and so on, so we'll start a little bit with that, and then how I'm using
00:41
it or what we are doing, using it on Yocto as well as on Zephyr, and then also how we are using Meta on top of open thread, talking about the more generic mesh capabilities that Thread is offering you and the border router that is needed to get it all hooked together, and then about one more detail that has just been introduced about like multicast DNS
01:05
discovery proxy, as well as service review statement protocol, and then how I tied it together for all use cases as a transparent gateway blueprint. So I only have 20 minutes, so if I'm rushing it a little bit, don't worry, the slides
01:20
are available, there's also like a lot more slides after the appendix, you can look them up later on as well. So for the scope here, my goal and my ideas have been like going, we need something for low power, it should be wireless. I wanted to have IPv6 end-to-end connectivity, I want to look for power budgets, so having,
01:40
for example, small sensor devices that can run on a coin cell battery for whatever, six months, a year, maybe two years, depending on the use cases and the usage. And having mesh capabilities, so don't have only like direct connections, but we like being able to extend the network over time by adding more devices and so on. And for the situation with the power budgets, VPN devices that really only wake up if they
02:05
are being interrupted for a specific use case, or only waking up for a short amount of time to querying the parent to get data, that is also something I considered here. And all the stuff I'm talking about here are obviously open source solutions. Thread, as well as Meta, have from the consortiums around them to like do products
02:22
and do like testing and verification, as well as getting a certification and so on. This is definitely something different, so if you want to build a product, you might need to pay for some specific parts, but all the software side or the engineering side, that is open source here, and that's what I'm going to talk about. So Meta, some people might have heard about it before.
02:42
It was formerly known as Connected Home over IP, or SHIP in short. It is part of the now so-called CSI, Connected with Standard Alliance. That, on the other hand, was called Zigbee Alliance before. I think that is something that rings a bell with more people than CSA. They have an open source SDK for Meta.
03:04
It's an application layer, so you're basically like not doing any of these. So it's built on top of IP version 6, and then does all the talk about like how devices access, how the data is expressed and so on, what kind of device types are there. It's more like, they call it like the language for IoT.
03:21
I don't know if I sign off on that, but that's like the basic idea we're having here. So the 1.0 release for the spec as well as the SDK was done in October last year. And one of the interesting part why it got so much hype with the industry was that a lot of the big players sit together and doing that here. So getting groups like Google, Apple, Amazon and so on in one room and
03:43
working together on this standard to actually try to get all the devices to talk together, even while keeping their own platforms, that is a very interesting part. And that could be something that a lot of smaller companies could take as a leverage to get into these kind of platforms to be supported instead of working with each and
04:04
every platform individually and get it enabled. So you don't need to get your device, work with HomeKit, then with Google Home or what Amazon have there, Echo and so on. So you can just do it as Meta device and then it should work in all of them. They also have a feature called Multi-Admin, which is something that would allow you to have like an,
04:25
for example, you have an Android device and your wife has an iPhone or whatever, and both could control the same IoT devices in the same network running the native platforms they are using. So this is something you can share the devices by using on different platforms as well.
04:41
Yeah, so Meta and Yocto and OpenEmbedded. So the Meta SDK, the way they are building that and so on, it's not so, I'm not so familiar with that before I started it. So they're using something called GN, which is just generate ninja. So basically it just does a whole run and then generate all the ninja files to get it all built.
05:02
And they have something called Pigweed that they, it's like their abstraction, how you get like all different kind of vendor SDK supported and like different cost-compiled two chains and so on. This is like difficult to get that into something like Yocto OpenEmbedded, which just focus on the cost-compiling part here.
05:21
So that was quite a bit of work. So we had to do like a GN base class to get it supported and did a lot of like work around here. But in any way, we got that part working. So we have the core libraries building. We have the examples that are part of the SDK building. We have that all in our Neo layer. But there's also a different layer from NXP, MetaMeter,
05:44
which does it a little bit differently but in the end you're getting the same result. You have like the integration to run that on a Linux system. So that is all there. You can take that and then build on top of the library and take the examples, devices to like do whatever you want there.
06:02
On the Meta, on the Zephyr side. So Neo is a project that runs not only on Linux, but we also run it on the Zephyr side. So we have like multiple kernels there. So we always need to make sure that we want to have the integration part there as well. I have been working on a proof of concept to get Meta as a sub-module or as a Zephyr module integrated.
06:23
So the build system would, inside the Meta SDK, there is like a platform abstraction for Zephyr, which is based on two SDKs from I think Nordic and T-Link. The SDKs are based on Zephyr as well and they have like a generic Zephyr abstraction now. And then we have the integration part there.
06:42
We have a CMake file and so on to hook that into the Zephyr build system. We are an external module and you have like a specific module, a JAML file that just tells where the CMake file is, how is the setup, how the build setup is and so on. And then you are setting things like open thread dependencies on.
07:01
This is not ready yet so that's why I have no link here. I'm still working on that. I hope to get it ready but as always, it takes a bit more time than expected. But that's definitely something that could be interesting to get that running on the Zephyr site as well. So technically it's possible. I saw it working in the different SDKs but for our use case, we wanted to have it working with Zephyr upstream
07:21
without any specific silicon vendor at once and so on. So this is why we are doing this approach. So Meta devices. So the device types that are available in the SDK coming from the 1.0 release are very limited. I think they only have like five device types specified right now. There are definitely a lot more coming
07:40
and will come in the next upcoming releases. So Meta is doing like two releases per year in spring and autumn. So there should be a lot more going on there. They are using the ZigBee cluster library. So in case you are familiar with that from all our projects or something, they are basing their device types and abstraction on that one, extending it a little bit and then using it.
08:01
But it should be a very good base for your own devices. It doesn't mean it covers all the nitty details you have maybe on your product or something but it could be a good entry point to cover the basic functionality and then for details you might leave that out and have like an out-of-band situation. Or you go to the Meta working group and work with them
08:21
to extend that over time. As usual, like setup is the QR code you might know from other devices already like HomeKit and so on. You can also use half a pin and then you have NFC that is upcoming that you can use it as well. So in terms of connectivity layers what they are supporting in the beginning
08:40
that is Ethernet and Wi-Fi. There is no much need to adapt it or anything. For Wi-Fi they are working on a better soft... So right now it's a soft AP setup if you want to bring a device in but that means you would need, for example, if you do the soft AP with your phone and then you miss the connectivity to your normal data.
09:01
So they are working with the Wi-Fi alliance to change that at the neighbouring service. So that is good. Brutus Low Energy is also available for device onboarding. It's not a connectivity layer they are using for data transmission but it's just only for onboarding. And as I mentioned before they have like these... If your device supports more
09:22
than the device type expressions they are doing you either need to work together with them to extend that or you need to find a way to have that as an out-of-bound connectivity. But here comes the beauty of being IP version 6. You have like end-to-end connectivity to the device and if you, for example, have like a mobile application or something that would control it
09:41
you could still do all the work with Meta to support the basic functionality and then hand over to the end device over IP version 6 and then control the device for like an extended API you might offer on the device. But Ethernet and Wi-Fi are not really the ones I was looking into when looking at the power budget
10:01
and designing devices that are really power budget friendly and can run for like a year or so on a battery. So I was looking into THREAT for that. So open THREAT is the open source implementation of the THREAT certification. THREAT group is the governance body, again. membership.
10:20
You have to pay a fee if you want to get certified and so on but you don't have to do that if you are just going for the implementation of this open THREAT. It's BSD3 license so that's all easy for you to integrate in your products and so on. It's mostly driven by Google and formally Nest and it has a very established code base already
10:40
in products and running in the billions in the world already. So THREAT is a mesh network. So what does it cover here? So you have like different types of devices that are part of the mesh network. You have full threat devices which are normally devices that have like a good amount of power budget being either line powered or having like a big battery
11:02
that they can operate on. These are like often like routers that can like take the packet forward it to another one and make sure that everything, the whole data keeps flowing and then you have like router eligible devices which is something that will become a router if the mesh network needs them later on to make sure that the data keeps flowing or if they are like in a corner of the mesh network
11:22
where they need to increase the quality for all the other nodes available. Or they could be just a simple full end device which is just operating there, not doing any routing or something but still being a full end device. And then for the power constraint devices you have like minimal threat devices which are minimal end devices
11:40
and they can be sleepy devices. So basically they would like spend most of their lifetime just being asleep, not drawing or drawing as little power as possible and only wake up if they are getting an interrupt like when you open your window or something like that you want to send a notification out for that or you just have a short poll to a parent
12:02
and ask if there's any data left for you. So they're using 15.4 as a base layer, a file layer and they have a functionality where you send out a packet to if there's any data available for you and even in the X frame already you have like a bit set where it says oh there's data waiting for you, don't go sleep, poll me again and then you're getting all the data
12:22
and if not you can fall asleep already again. You can also have like in the newer specifications you have something that is like synchronized schedules but that would mean you need a newer type of like ships available, not all of them do that so you would have to need like 15.4, yeah the 2015 release for that.
12:41
So you need to find like the silicon chips that actually support that and then you can get that running as well. Okay I talked about the router things before, you have router device, you have end devices and then you have a leader of the threat network.
13:00
This one is in charge of making sure that all the key material for example is distributed to all the networks, all the keys are getting rolled over if they're running out of frame counter and so on that really makes sure that all the stuff is available and all the devices get the neat information and then you obviously have like a standby leader if the leader is like running out of battery or like someone tripped over the power cable
13:21
or something like that. So you have all of that covered in the mesh functionality as well. And the other important device that is available in such a network is the border router because you want to have these kind of things obviously connected to at least to your home network. Maybe even to the internet that's up to you but you want to have like more devices
13:41
than only this in the threat network and that is where the border router comes in. I will talk about that a little bit later because it's also relevant to the meta part for the integration. In terms of addressing, there's like three different types of addresses. We have like the link local, what you can reach directly within your range, in your wireless receiving range
14:02
or transmitting range and then you have mesh local addressing which is like available in the whole mesh network and then you have like the global addresses. It's all IPv6 addresses and they have like allow you to like individually target specific parts of the mesh and so on. I'm rushing through that a little bit because it's too much to go into all the details here
14:21
in 20 minutes but it's a little bit more in the slides. So in terms of the software, they have in there available, there's the OpenShift core library which is used for all of them. Then you have abstractions for like all the different silicon vendors integrating this SDKs and so on so you can see them all. They are listed. If you have a specific device, for example,
14:42
running that you could, you bear metal on that as well or you could go and run it, for example, as the OpenThread module on Zephyr being supported. And on the Linux side, you have like two basic services that are running. There's the OT daemon which is like the basically only a full end device which could operate as a normal end device in the network
15:02
and then you have the OpenThread border router POSIX, how they call it. That is the full border router setup that you would run on your Linux device if it's a border router and engaging there. So talking about all the power constraints you are having. So there are two advancements
15:21
that have been happening driven by meta mostly but falling back to thread to make it even more power efficient. So this is a multicast DNS discovery proxy and the service registration protocol. So I talked before, the border router is like the central part here to shield the mesh network
15:41
from the rest of the network or the other way around. And this is, so if you look at a lot of the IT devices you have maybe in your home or you know about, these are often like vendors where you have like one specific hub for your specific device types and so on. Then you have the next hub for the other types and so on. This is all crowded and so on.
16:02
And for the border router, this is often more a software component that can be updated in device that already available. So the 15.4 radios, they are used for threads that are the same radios that are used for Zigbee. That means all the hubs that you might have, already have Zigbee support, it is up to the hardware vendor
16:21
if they want to change that over to a different firmware and then all the other software around it to make sure they can also support thread. It's also possible to run like both of them in parallel if you do like multi-protocol on the firmware level where you have like Zigbee device support as well as thread device support. That's a bit more complicated but it is possible as well.
16:41
But nowadays, so one of the problems I saw when I worked with thread the first time was like everybody needs to get like another device being the hub and so on. But if you look around now, there's tons of device already available that offer border router functionality. All the Apple devices like the HomePod, the HomePod mini, Apple TV,
17:00
all the Google Nest device, Echo and so on. All these things are like the, if you have them in your house already or like people, your target audience have them in your house already, it's already sorted out. And then there's a lot more hubs doing the support as well. The new IKEA hub has support for it. I think that the smart things hub is going to plan support for it and so on. Then a lot of the smaller vendors as well
17:21
are coming out hopefully over the year. So that means if you bring home an Apple thread device or a thread device, you shouldn't be worried to get it on board as long as you have some of these. So it's not as easy support as Wi-Fi for example right now but it's good to get traction there. But coming back to the situation about the discovery proxy.
17:41
So this kind of wireless networks, they don't have any multicast support, right? So whatever you send in as a multicast there will end up as a broadcast in the whole mesh network. Which is obviously not a good thing if you want to be like, if you're constrained in power and need to listen in and wonder what's going on. I mean the sleepy end device for them, it's not too difficult because they would sleep
18:01
and the parents would just discard whatever they have for them if it's not targeted directly for the specific device. But all the other ones would still like draw on the batteries they're having to do that. So on the other hand multicast DNS discovery is something that is very much used in the industry for all kind of service discovery in networks. So we want to have that support as well.
18:21
So there's a component now that has been specified as an ITF of C draft which is sitting there and doing basically the proxy, what the name suggests, right? On the one hand if you have Wi-Fi or Ethernet you do multicast DNS. On the other hand you do a unicast DNS service discovery and so on. So that is like basically proxying back and forth.
18:41
That doesn't mean, depending on the model where you're using, you're not forced to that. So the end-to-end principle of IPv6 still stands. But it's like an optimization you maybe don't want to miss out on. And on the other hand, so that is mostly covering the side where you have Wi-Fi and Ethernet flooding into the threat network.
19:01
But on the threat side you also want to make sure that you announce the device that are available and so on. So that is like the service registration protocol where you go and say, I have the service available as DNS. So this is like what I'm offering here. And they can register on the border router service for that. So that would distribute that again as multicast DNS on the Wi-Fi Ethernet side.
19:25
Yeah, so transparent gateway. So that is like how I knit all the things together. So we have a blueprint that is like, you know, near how we talk about like proof of concept demos we are doing. And we have a layer where we do all the integration parts here. All the open threat stuff I upstreamed already.
19:40
They are in meta-o-e networking. And the meta stuff that is still very much work in progress going on as well as the fire side. But if you're interested in that, I mean, I'm not hiding anything here. It's just not ready to show. But if you're interested we can talk about like where these things are. So this is like an old example I had where I had like just a threat device being onboarded.
20:01
So it could like go ahead, have like the QR code for this specific device and then you even have an Android application to onboard on the network and so on and do all the stuff. And then in the end, with all the components together, you have like IP version 6 connectivity. And on top of that, this meta, you would have like real device abstraction and offering all kind of platform integrations.
20:23
And with that, I'm done and I should have like a few minutes for questions.
20:52
Hi there. Thank you very much for that. We're currently looking at developing a matter cellular gateway using some of the new ESP32 chips that are coming out.
21:04
What I'm having trouble getting my head around is the underlying physical layer in terms of 802.15.4 versus Wi-Fi 802.11. And so what I'm trying to understand is if I buy a matter device, it might be a matter device that supports Wi-Fi
21:22
or it might be a matter device that supports Fredo of 802.15.4, which to my mind feels like it's going to be really confusing for people. And I'm asking, as we go to develop this border router, should we focus on supporting sensor-like devices that are Wi-Fi devices or 802.15.4 devices
21:42
or is it not that simple? I think it's sensible to make sure that you have at least a 15.4 radio in the device because I think all the sensor devices you will see coming are most likely to use Fred because just power budget wise, I mean, at least the feedback I saw in the working groups and the feedback I got in the working groups.
22:03
Excuse me. If you're moving in or out of the room, can you please do that quietly whilst we're doing the Q&A and try and keep the noise down to a minimum because it's getting very difficult to be heard here. So please be considerate to others.
22:20
Here. Okay, so I think you really need to make sure that you have that available because all the companies that are looking into that, they want to be conservative in power or something, they are definitely going for that. And I mean, if you do the hardware setup, make sure you have the radio available.
22:41
If you enable that by default from the beginning, it's up to you, right? I mean, you can always have the firmware available and then ship the device and then enable it later on. I've seen tons of devices doing that, but having it available from the hardware perspective, I would not ditch that. It's like, yes, it's like a few euro maybe, depending on the volume and so on,
23:01
but I'm pretty sure that most of the devices will come with that. Okay. Hey, I've got a question from online here. I'm over here. Online we have a question. What's the rationale for a non-router end device if it doesn't have any power management requirements?
23:22
Okay. I mean, the thing is, it could be a router. Normally, in that case, it would be like a read, like a router eligible device, but maybe you don't need all the routers available in your network, right? I mean, you have like, if you have a mesh network, and depending on how the topology is
23:40
and like maybe your house or your, how the environment is basically, you have maybe enough routers available at that point. So, I mean, I'm not sure. All of the full end devices can do that, but you might don't choose for that, so. Okay. Okay, any more questions?
24:00
Yes, sir. Hi. Hi. So, one of the most controversial parts... Can you speak a little bit louder? Sorry, it's very noisy. So, one of the most controversial parts of this back
24:21
when it was released was they were talking about authentication onto the network, like onboarding via blockchain. Can you discuss that a little bit? Okay, so what I think what you reference to is like the distributed ledger. So, one of the ideas that is like worked around in the meta working group
24:40
is like the distributed ledger where you can authenticate the devices that are like, so you're basically not getting fake devices in the network and so on. That's definitely something that could be problematic for, if you want to like do your own devices in your own home, for example, and get them onboarded. I still have to see if that is really enforced or not.
25:00
That is really depending on the platform and so on. How are you using that together? Yeah, but I need to hear, so a microphone or something. Have you managed to get a DIY device onto an actual Google matter network yet? Not on a Google matter network now. I was able to like get it all working together on my own setup,
25:21
but I didn't work against the platforms and so on. Yeah, that sort of seems like one of the... Well, we have to see. I wouldn't rule it out right now, but I can confirm that it's possible, but it really depends on how you do it. But it's definitely the concern. You're right. It's possible? It's possible? Okay, so someone said it's possible here.
25:42
So, okay. Okay, thank you everybody. Thank you very much. There's one more question on the chat room you could answer. Okay, okay. I will have a look. Thank you.