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 about matter and
threat as 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 an overview about matter. So, I don't
know how is Temmler with that, how is Temmler with open threat and so on. So, we'll start
a little bit with that. Then, how I'm using it or what we are doing using it on Yachto
as well as on Zephyr. And then, also how we are using matter on top of open threat. Talking
about the more generic mesh capabilities that threat 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
have been introduced about like multicast DNS discovery proxy, as well as service integration
protocol. And then, how I tied it together for our 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 are available. There's also like a lot more slides after the, as a appendix,
we can look them up later on as well. So, for the scope here, my goal and my ideas have
been like going, we need to do something for low power, it should be wireless. I wanted
to have IP version 6 end-to-end connectivity. I want to look for the, for power budget.
So, having 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 that 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 budget, sleepy end devices that really only wake up if they 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. All the stuff I'm talking
about here are obviously open source solutions. Thread as well as Meta have consortiums around
them to like do products 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. It was formerly known as connected home of 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
the bell with more people than CSA. They have an open source SDK for Meta. 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. 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 is like this industry was that
a lot of the big players are sit together and doing that here. So, getting like groups
like Google, Apple, Amazon and so on in one room and working together on this standard
to actually try to get all the devices to talk together even by keeping their own platforms.
That is like 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 every platform individually and get it enabled. So, you don't
need to get your device, work with home kids and with Google Home or what Amazon have their
accounts on. So, you can just do it as a 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, 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. So, meta in Yocto and open embedded. 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 are using something called GN, which is just generate ninja. So, basically
just does a whole run and then generate all the ninja files to get it all built. And they
have something called PickWeep that they, it's like their abstraction, how you get
like all different kind of vendor SDKs supported and like different cross-compiled two-chains
and so on. This is like difficult to get that into something like Yocto open embedded which
just focus on the cross-compiling part here. So, that was quite a bit of work. So, we had
to do like a GN base class to get it supported and do 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 the, in our Neo layer.
But there's also a different layer from NXP meta meta meta which does it a little bit
differently. But in the end, you're getting the same result. You have like integration
to run that on a, on a Linux system. So, this is, that is all there. You can, you can take
that and then build on top of the library and take the examples devices to like do whatever
you want there. On the meta, on the Zephire side. So, on here is a project that runs not
only on Linux, but we also run it on the Zephire side. So, we have like multiple kernels there.
So, we all those need to make sure that we want to have the integration part there as
well. I'm, I have been working on a proof of concept to get meta as a, as a sub module
or as a Zephire module integrated. So, the build system would, inside the meta SDK, there
is like a platform abstraction for Zephire which is based on two SDKs from I think Nordic
and T-Link. The SDKs are based on Zephire as well. And they have like a generic Zephire
abstraction now. And then we have the integration part where we have a CMake file and so on
to hook that into the Zephire build system. We are an external module. And you have like
a specific module, a jumble file that just tells where the CMake file is, how is the
setup, how the build set up is and so on. And then you are setting things like open
thread with dependencies on. 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 takes a bit more time
than expected. But that's definitely something that could be interesting to get that running
on the Zephire side as well. So technically, it's possible. I saw it working in the different
other SDKs. But for our use case, we wanted to have it working with Zephire upstream without
any specific silicon vendor at on and so on. So, this is why we are going 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 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 Zikbi cluster library. So, in case you
are familiar with that from all the projects or something. So, they are basing their device
types and destruction on that one, extending it a little bit and then using it. But it
should be a very good base for your own devices. It doesn't mean it cover all the nitty details
you have maybe on your product or something. But it could be a good entry point for 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 to extend
that over time. As usual like set up is the QR codes you might know from other devices
already like HomeKit and so on. You can also use a pin and then you have NFC that is upcoming
that you can use that as well. So, in terms of connectivity layers, what they are supporting
in the beginning. That is Ethernet and Wi-Fi. There is no much need to like adapt it or
anything. For Wi-Fi they are working on a better software. So, right now it is a soft
API set up if you want to bring a device in. But that means you would need for example
if you do the soft API with your phone and then you leave the connectivity to your normal
data. So, they are working with a Wi-Fi alliance to change that as a neighboring service. So,
that is good. Brutal store energy is also available for device onboarding. It is not a connectivity
layer they are using on for data transmission but it is just only for onboarding. And as
I mentioned before they have like these, if your device supports more 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 IPv6. 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 this, you could
still do all the work with this method to support the basic functionality and then hand
over to the IP to the end device over IPv6 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 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 Thread
for that. So, Open Thread is the open source implementation of the Thread specification.
Thread group is the governance body again. Membership, you have to pay 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 with Open Thread. It's BST3 license. So, that's all easy for you
to integrate in your products and so on. It's mostly driven by Google and formerly Nest
and it has a very established code base already in products and running in the millions of
in the world already. So, Thread 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
Thread devices which are normally devices that have like a good amount of power budget
being either line powered or having like a big battery that they can operate on. These
are like often like routers that can like take the packet forward 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 where they need to increase the quality for all the other nodes available.
Or there 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 Thread devices which are minimal end devices 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 the
notification out for that or you call, you just have a short poll to a parent and ask
if there is any data left for you. So, they are using 15.4 as a base layer, a file layer
and they have a functionality where you send out a packet to if there is any data available
for you and even in the egg frame already you have like a bit set where it says, oh,
there is data waiting for you, don't go to sleep, call me again and then you are getting
all the data 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 be like 15.4, the 2015 release for that so you need to find like the silicon ships
that actually support that and then you can get that running as well.
Okay I talked about the router things before, you have router devices, you have end devices
and then you have a leader of the threat network. 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
wrote over if they are running out of frame counter and so on that really makes sure that
all the stuff is available and all the devices get the need 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 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 your home network, maybe even to the internet that's up to you but
you want to have like more devices than only within the threat network and that is where
the border router comes in. I will talk about that a little bit later because that's also
relevant to the matter part for the integration.
In terms of addressing, there's like three different types of addresses, you have like
the link local, what you can reach directly within your range, in your wireless receiving
range 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 in 20 minutes but it's a little bit more in the slides.
So in terms of the software, they're having there available, there's the OpenStreet core
library which is used for all of them, then you have abstractions for like all the different
silicon vendors integrating with their SDKs and so on, so you can see them all there listed.
If you have a specific device for example, running that you could, you'll burn metal on
that as well or you could go and run it for example as an OpenStreet module on that fire
being supported. And on the link side, they have like two basic services that are running,
there's the OT daemon which is like the basically only a full enterprise which could operate
as a normal enterprise in the network and then you have the OpenStreet border router
POSIX, how they call it, that is the full border router set up that you would run on
your Linux device if it's the border router and engaging there.
So talking about all the power constraints you are having, so there are two advancement
that have been happening driven by meta mostly but falling back to thread to make it even
more power efficient. So this is a multicastiness 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 from the rest of the network or the other way around.
And this is, so if you look at a lot of the IoT 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. And for the border router, this is often more software
components that can be updated in devices that are 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 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.
But nowadays, 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 devices already available that offer border router functionality. All
the Apple devices like the HomePod, the HomePod mini, Apple TV, all the Google Nest devices,
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 the house already, it's already sorted
out. And then there's a lot more hubs doing the support as well. The Ikea, the new Ikea
hubs have 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 are coming out hopefully over
the years. So that means if you bring home an open 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 in get traction there.
But coming back to the situation about the discovery proxy. So this kind of wireless
networks, they don't have any multicast support right? So they, 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 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 services
discovery in networks. So we want to have that support as well. So there's a component
now that has been specified as an ITF RC draft which is sitting there and doing basically
the proxy what the name suggests right? On the one hand if you have like Wi-Fi or ethernet
you do multicast DNS and on the other hand you do a unicast DNS service discovery and
so on. So that is like basically proxy and back and forth. That doesn't mean depending
on the border you're using you don't, 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 like Wi-Fi and ethernet
flooding into in the threat network. But on the threat side you also want to make sure
that you announce the device that are available and so on. That is like the service verification
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
mean and would distribute that again as multicast DNS on the Wi-Fi ethernet side. 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 thread stuff. I upstreamed already
they are in meta or E networking and the meta stuff that is still very much work in progress
going on as well as the ZFIA side. But if you're interested in that, I mean it's not,
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 so it could like go ahead, have like secure
code for this specific device and then you have 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 integration and so on.
And with that I'm done and I should have like a few minutes for questions.
Hi there, thank you very much for that. We're currently looking at developing a matter
device.
So what I'm trying to understand is if I buy a matter device, it might be a matter device
that supports Wi-Fi or it might be a matter device that supports threadover 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 or is it not that simple?
I think you, 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 thread. Because just power budget wise, I mean at least the feedback I saw in the
working groups and so in the feedbacks I got in the working groups.
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.
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 like be conservative in power or something
they are definitely going for that. So and I mean if you do the hardware setup make sure
you have the radio available. If you enable that by default from the beginning it's up
to you, right? I mean you can always have like 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 for the hardware to sacrifice I would not ditch that. It's like yes it's
like a few euro maybe depending on the volume and so on but I'm pretty sure that most of
the device will come with that. So 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? Can you repeat that?
What's the rationale for a non-router end device if it doesn't have any power management
requirements? Okay, I mean the thing is it could be a router. Normally in that case it
would be like a read like a router, a leisure device but you 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 and like maybe your house or your how the environment
is basically you have maybe enough routers available at that point. So all of the full
end devices can do that but you might don't choose for that so.
Okay. Okay, any more questions? Yes sir. Hi.
So one of the most controversial parts of the spec.
Can you a little bit louder? Sorry it's very noisy.
So one of the most controversial parts of the spec 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 having so one of the ideas that is like work around
in the meta-working group is like the distributed ledger where you can authenticate the devices
that are like so you're basically not getting fake device in the network and so on. That's
definitely something that could be problematic for if you want to like do your own device
in your own home for example and get them onboarded. I still have to see if that is really
enforced or not. That is really depending on the platform and so on. How are you using
that together? Yeah, but I need to hear some microphone or something.
Have you managed to get a DIY device onto an actual Google matter network yet?
Not on a Google network now. I was able to like getting all working together on my own
setup but I didn't work against the platforms and so on.
Yeah, that sort of seems like one of the problems.
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? Okay, so here someone said it's possible here.
Okay, thank you everybody. Okay, thank you very much.
I want to check the chat room. There's one more question on the chat room you could answer.
Okay, I will have a look. Thank you.