 Okay, so welcome to the session. We'll talk a little bit about how to build multi-protocol IoT nodes with a specific focus to those three protocols over there, so Thread, BLE, and ZigBee. And here's the summary of the session. So we're going to talk about the advantages of the benefits of developing such IoT systems with a focus to new platforms that make it feasible to implement such multi-protocol system, also at the edge node of IoT, so not only in a gateway. We'll summarize a little bit the main use cases for the different protocol standards, focusing on those three, but some use cases, and go a little bit deeper into the anatomy of such systems. So we'll look at the platforms, the stacks that are being used there, some considerations for applications if you're building a multi-protocol device. And finally, we'll do some examples at the end where we'll actually work with actual development hardware and firmware and software and see how such a system behaves. Okay, first a little bit about myself. My name is Alain Lazar. I'm a software engineering manager with NXP Semiconductors. I've been working with low power wireless protocols for about 10 years now. I've been involved during this time in shipping stacks, tools, application software that deals with ZigBee threat and BLE stacks, focusing a lot also on the standardization and the certification aspect with respect to interoperability, so multi-vendor interoperability with respect to these standards. And right now I'm also serving as a vice-chair of the Thread Group Technical Committee. So let's get into it. So let's first understand why it would be good to have a system that implements multiple protocols. So there are about three main reasons for doing that. And again, we're talking and focusing on the edge node here, so not necessarily on the gateway. First of all, it greatly expands the connectivity, so basically the number of devices and the number of networks that an IoT device can actually connect to. So if you implement, for instance, one of the standards, let's say, BLE can connect to smart for other BLE devices, but also if you implement one of the other standards, then it's possible to connect to mesh networks and other such devices. So it greatly expands and makes it very flexible to add multiple connectivity, multiple direct connectivity ways of an IoT edge node device. And with that comes a reduction in design costs. So just think about the fact that if you're building an IoT device and maybe it's a BLE and then you implement another standard, you don't need to do two different SKUs. So you just do one SKU with potentially a single firmware build. So that simplifies life a little bit, that, for instance, when you go to do RF or FCC certification or other certification, you go with a single variant of the hardware. And this can greatly make such a design advantage just from a cost perspective. And finally, with such systems, that in multiple protocols, usually you get some processing associated with them, also some security features. So what that gets you is actually for the application, it blurs the radio interface. So it doesn't matter too much whether you're doing BLE or ZigBee or Thread or some of the other protocols at the application level is just a firmware decision of those interfaces you use. So basically it's choosing the best of all worlds. So a lot of these protocol standards have some strengths and some weaknesses. So it's basically exploiting a lot of the current strengths with such a multi-proc system. So also future-proofing your design and reducing a lock-in in a certain vertical, let's say, as it's being deployed now. So let's look at these three protocol standards that are the focus of our session. So how many of you have worked with Bluetooth flow energy or did Bluetooth flow energy designs? Okay, quite a few. How about ZigBee? Okay, and Thread. Okay, got one for Thread. Okay, so let's go a little bit through their main points and, again, strengths and weaknesses. So Bluetooth First, so we're talking here mainly about Bluetooth LE used in IoT devices. We usually use that to connect your accessory or your wearable device to a smartphone or a PC or a tablet. It's very good for devices that don't have user interfaces to go to your mobile app and use that as the user interface for the IoT device. It's mainly direct connections from your smart device to that accessory. Also, we've seen a lot of usage of Bealeen in Beacons. ZigBee has been with us for quite a number of years. I think the initial development of the protocol started early 2001, 2002. It's quite a mature mesh protocol focused on home automation and lighting deployments. So right now I think there's a few hundreds of ZigBee devices which are certified in those areas, so mainly home automation lighting. ZigBee also had some attempts to go also into the smart grid markets. They've got a smart energy profile, that works. But mostly the focus and especially the newest version of the standard gets dubbed ZigBee 3.0. A lot of that is focused on home automation and lighting. A lot of the current smart home hubs, which you can buy in retail, come with a ZigBee radio and those certified devices can interact with that ZigBee radio. What about Thread? Thread is a newer protocol. It's being defined by the Thread group. It's reusing the Mac 5, so the layer 1, layer 2, I888 or do 15.4 that ZigBee is also using. But what it does, it defines a full IPv6 network stack on top of that. That IPv6 network stack is built in the Thread standard to also scale at the same category of devices that Bluetooth and ZigBee cover. So these very small IoT devices like a coin cell battery device. Also, Thread improves a little bit the mesh concept from the other protocols in that it's no single point of failure mesh network. So if the gateway or one of the main routers in the network that coordinates the routing and maintains the network as a whole is decommissioned or is turned off, then other routers can take over for some of those more centralized functions in the other protocols. So that makes Thread network overall and Thread mesh networks a little bit more resilient. Also, being IPv6, Thread goes and defines border router architecture. So border router are gateway type devices at the edge. So it could be a networking device, but it could also be appliance device. And those devices are multi-procalling that they implement also an interface like Wi-Fi or Ethernet and the Thread IEEE 8.15.4 radio. And then you can actually send IP packets from the Edge node, IPv6 Edge node up to maybe a mobile device in the LAN through Wi-Fi or further on to the cloud. So all these three protocol standards are open standards. So they're being developed by industry standard groups like the Bluetooth sync, the ZigBee Alliance and the Thread group. So all of them are similar from this perspective in that you need to be a member in order to be able to influence the specification and get access to the interoperability and certification program. So these alliances basically offer a set of tools or a full certification program in order to ensure that your devices work together seamlessly. Yeah, sure. So we're focusing on these three as part of this talk. I have some points at the end that touch a little bit on those items that you mentioned. So ZigFox and Laura are basically wide area, low power networks. They're implemented in some ways with different platforms that these, the platforms that implement these three protocols. And then Z-Wave is similar in that due to the fact that it's using another frequency band, it's a little bit difficult to build very integrated systems that also add Z-Wave. So it's mainly all these three protocols that I'm listing here are in the 2.4 gigahertz band. So they operate globally. So again, you just need to do one hardware design and that works globally as part of the 2.4 band. So that's, again, one of the advantage here. But that doesn't preclude using those scenarios. We're focusing on these three in this talk because we're going to see a little bit on how the integration goes and you actually have all these three protocols in a single chip. Okay, so let's look at a use case for how you would get the benefit of having two or three of these standards in your single device. So let's imagine you have your mesh network here, a home automation network or maybe a different type of network. So you've got these router devices, the orange hexagons over there, the end nodes. They all form a mesh network and communicate as part of the mesh. And let's say you've got a home automation network and you've got a connected smart lock. So that mesh today may be implemented with ZigBee or Thread. But if you also implement Bluetooth in that smart lock device, then you can go and meet such use cases where the user interacts via their smart phone or their smart watch or their wearable directly via BLE to that node. So outside the band of the main mesh network. But at the same time, the device continues to operate and be controlled in the mesh. So let's say that the smart lock implements Thread and it also has an IPv6 address that it can be used to communicate with a cloud device management service. At the same time, with its BLE operation, which allows a more seamless operation by users for when they actually need to talk to that smart lock or need to interact with that device. So basically, the multi-protocol implementation facilitates these kind of new interaction scenarios where multiple standards are combined and some of their strengths are exploited. Okay, so let's see how one would go and build such a device. So what do you need first? So right now we see an emergence of integrated microcontroller that have multi-mode radios and those really stand at the base of the multi-protocol systems that implement such standards as we saw earlier. And actually there have been quite a bit of those released lately. So NXP has one of them, the schematic is pictured here, but a lot of our competitors also have very similar devices. So what's common among these devices is that they usually implement an ARM Cortex-M as a main processing unit and that's usually implemented in the same silicon package as a system on a chip with a multi-mode radio. Usually the multi-mode radio in most cases is BLE-4 plus capable and I888-15.4 capable, which means that it can implement those three standards that I mentioned earlier and that's one of the reasons. There are some similarities because these all operate in 2.4 so it's pretty easy to actually these build this multi-mode radio and integrate it with a processing core. These devices usually differentiate through their memory capacity, pretty standard memory for the microcontroller core for instance, 512K of flash, 128K of RAM. So we see maybe on the RAM side an increase versus what people were usually using up until a year or so ago just because for some of these multi-procal use cases the RAM is very helpful to do things like packet buffering and be able to run several of the stacks concurrently which need both the flash and RAM for storing state and tables and also allow some space for the application. And usually also have a set of security blocks integrated so you'll have some commonalities also with that because a lot of these standards reuse AES-128 and random number generator because of the way you can actually implement true random number generators. Okay so that's the first step of having such a platform. Then going to the firmware. You need a multi-procal stack, right? So you've got pictured here the high-level architecture of how such a stack would look like. So at the bottom we've got a multi-mode transceiver as we mentioned and because the Zigbian thread reuse the IEEE to 15.4MAC5 you only need one implementation of that. That runs in parallel or is the same layer in the protocol maybe with a BLE controller. And then going further up in the stack layers we've got a BLE host, GAP, JTT profiles on the BLE site so this is pretty much its own vertical these days. And then similar for ZigBee, for ZigBee 3 and previous versions you'll have a ZigBee Pro mesh layer that does some of the base networking and then got a ZigBee cluster library framework that does some of the application semantics around application functionality. And then thread is an IPv6 stack that's made for constrained devices so it reuses 6LowPan as defined by ITF and then it adds IPv6-based routing for the mesh side. But then on top of that you've got a pretty standard IPv6 and UDP socket layer so the application can interact pretty seamlessly in the usual IP way with that. What's regularly built on top of that though is other application layer frameworks that are made for constrained devices such as those based on co-app. So we've got these blocks of the stack layer and then the application layer can have the single chip device application that can actually take advantage of all the flexibility that the stack layer offers. So for instance if the application for that IoT device demands that you will get some UI display to a user for a short time then it will enable the BLE stack. So it will enable that and the user will get a user interface on its smartphone. It needs to be active in a mesh and communicate to smart blocks of lights that it might enable the ZigBee interface. We've got IP scenarios where it communicates to a cloud or other thread devices than that we implement the thread. You can actually mix and match so all these are usually implemented as pretty modular blocks and as we'll see a bit later can also be coordinated in order to run concurrently. A few considerations on such multi-mode application, multi-protocol application. So I have a set of items that are relevant in this case. So first on the firmware system. So the firmware system perhaps as we saw in the stack picture has a bit more complexity just because you need to manage all these items. For item cyber you usually only need to build a single piece of firmware even though your device, a single piece of firmware for these multiple ROCCOs instead of doing maybe a multi-chip scenario where you need to have different firmware for each of the chips that are in the system. An RTOS usually helps here because what you could do is run some of the, especially the lower layers such as the PLE controller such as the MAC-FI, also the upper layers in different RTOS stacks and exploit the advantages that an RTOS brings with this. But a bare metal system is also an option. Then what you also have in terms of firmware is some sort of management module that allows the concurrency management. So if you do want to use multiple of those protocols at the same time at runtime basically so choose dynamically between those then you need to manage their concurrency or their coexistence. Depending on the category of the device whether it's a battery powered, sleepy device or maybe it's a mains powered, that's kind of a smart plug or another light bulb let's say that doesn't have that much constraints on the power side. So what you can do is actually that could implement one of the router functions in the protocols that allow it. However, the messaging pattern of the device of how often do they transmit, whether there are sleepy devices which pull their pattern, whether there are sleepy BLE devices which for instance in some cases establish connections and then detach from that connection. All these communication patterns need to be considered in order to take advantage of the concurrency management APIs and the application kind of coordinate between these. OTA updates, it's probably in such a system you'd have a common way of the platform level of updating the firmware. So probably have a common boot loader that supports updating the firmware, probably modules or items that allow you to verify that firmware image and do the firmware update itself but on the actual protocol and interface that's being used in order to do the firmware updates perhaps not all of those two or three would be used. It would use maybe the ones that have the better throughput or are more handy in terms of accessing the OTA server. So if you go and update such a multi protocol device you could actually connect it through BLE and use your app to update it with a new firmware even if that device also communicates on another protocol, another stack in another network for the ZigBee or the thread without necessarily having to do OTA over those network interfaces. So that's the OTA updates. The application protocol in the ecosystem also plays a role, so most likely for protocols that will be IP based so there are quite a few number of options there. For instance you could use lightweight M2M or OCF constrained IoT or other application layers that use IP. So that's another design consideration. With BLE and ZigBee you kind of need to choose the respective profiles and see if those would be standard profiles or there are some manufacturing extensions that are needed for those. And last but not least of course security. So from a security perspective definitely such a multi protocol system creates new or expands the attack surface because right now you could actually access that device through multiple interfaces so care and consideration needs to be given to that aspect. Again a lot of the common platform and software security blocks may be reusable across those multiple protocols so you'd use similar AES modules for instance between all three because all use that. But then from a perspective of key provisioning let's say probably have different key materials across those three. So that needs to be taken in consideration and considered when building such a system. So I'll go a little bit further to the concurrent radio protocol. So this is an example of how an API that lets one application manage between all these multiple stacks or multiple modes of the radio would be implemented. So it's basically a variation of your concurrent API. This one in particular is also based on the mobile wireless standard that also says a few things about how you do protocol coexistence. And it's got your regular like acquire release APIs or it allows one of the protocols to send an idle signal call back when the radio is no longer used by that respective protocol stack or the operation has ceased. It also could get something like an inactivity duration. This basically allows to one of the protocols to coordinate with the others and the system that's being managed by this API. And you can actually get information on when the next operation of the radio will be done by another protocol. So you can actually knowing that timeframe you can actually use that it's at its best. And no, for instance, if you've got different priorities between these stacks or radio modes, then no one you might be preempted by a higher priority mode. Yeah, sure. So all three are basically optimized in some capacity for very deep sleep power states. So nodes, for instance, that put the MC on the radio in deep sleep mode for extended periods, starting with a few seconds, but expanding until minutes, hours maybe. And once the node wake up then either it uses BLE to sync up with a quick connection. If it's using the IEEE to 15.4 connection then it will probably have that sleepy node will probably have a parent device. So once it wakes up it can synchronize through a 15.4 data request to pull that parent for data. But yeah, a lot of these protocols allow for that and are designed for that. And in a multi protocol system that makes things a little bit easier because if you don't need to do this multiplexing of the radio being always on for some of the protocols, being on for that small amount of time when the device is out of sleep and that's usually a few milliseconds at each wake up then it's much easier to manage because it doesn't have any tight timing characters. You can just wake up and then serialize multiple operation in terms of if you're running all these protocols. So you'll probably have, so one, the node is in deep sleep. It's probably doing that based on a low power timer. So when it went to sleep it set a certain timer. So the node has the control of how much it's in that deep sleep power state. So it's not kind of a wake on radio type of operation. Okay, so an expansion of the coexistence API for instance, there's an example here of additional API if you don't do a single chip operation so you don't have those synchronization primitives then you might do a pin based coexistence. If you have multiple chips that you use to implement a multi protocol system you could use some of the GPIO pins to actually synchronize the radios at the low layer in terms of when they transmit. Again all these are using the same RF space or same RF and so it's very useful to coordinate. If the application has control on all the radio operation it's useful to coordinate using this coexistence mechanism. And basically it can do various things like setting the priorities of these operation. Some higher priorities modes can preempt lower priority modes and get idle indication, get acquired release for the radio operation with such APIs. Okay, so we saw what happens at the edge, what about the gateways? Of course gateways are still in the equation these days so for some of the devices that don't have a direct connection to your smartphone or to a LAN interface that you probably use such a gateway or hub and that's also a multi protocol system. So we've got one pictured here. What's happening for these and again with this standard especially going with thread, Wi-Fi, Ethernet all supporting IPs that we see a transition from application layer gateways as they are very common these days especially implemented in things like smart home hubs to more like network layer gateways. So probably see a lot of these IoT standard protocols be deployed more into things that are part of the network infrastructure like access point, customer premise equipment from your ISP and things like that. But of course in the gateway, on the gateway side you've got a much more complex configuration. So you usually use embedded Linux for that. That's one of our reference design pictured here. I won't go into all the details of the schematic. Just wanted to point out some of the differences maybe to a device that's multi protocol at the edge. So you don't have the same cost constraints. You can do a lot more complex operation through the Linux system. So in many cases for a gateway it actually makes sense to put multiple radio interfaces even if they are similar, even if it's the same radio if you want to do multi protocol. Just because these gateways also have some requirements that they need to be close to 100% on for the network interface doing things like the concurrency operation that sometimes switches between the different stacks is probably not a good thing to do on a gateway. Another thing is that the way such gateways are implemented you probably have the Bluetooth size of BLE and maybe the full Bluetooth combined with a Wi-Fi device rather than we saw with some of the IoT radio in a multi-mode device. So the quick... Well we've got two concurrency aspects. The first is the concurrent operation in terms of the processing. So in terms of how the stacks get access to the core in order to run and maybe in the case of BLE you've got very tight timing constraints so you need to do microsecond operation. So from a processing perspective there are some actual type requirements to that from a processing perspective. Then you've got the RF operation. So the RF operation definitely if you have multiple cores that run your radios it would be good to synchronize if you're using the same band, if you're not using the same band then it's fine to not synchronize. So these are those two concurrency aspects. First if you've got this monolithic single chip specifically edge note type device you can run into both scenarios. If you kind of get this system you usually have a lot of the heavy weight of the tight timing constraint be done by the auxiliary modules not by the main application processor but it's still good to apply a coexistence product or up here in the Linux space. So the 2.4 transmissions are not overlapping. So this is actually available. So I'll have some of the information is at the end of the slide. I can also give the information later. What's next in this area? Let's say of devices that implement multi protocols. So there was a question earlier. So I'll probably see in the edge note even more integration that was possible. So it's kind of the low hanging fruit right now with those 2.4 standards that actually are pretty commonly used. It makes sense from a cost perspective to be implemented in a single integration a single chip with a single multimode radio but I'll probably see other radio patterns being added to the edge note in a single integrated system. So the most probable will be Wi-Fi especially for the 2.4. Again there's some commonality of reusing some of the deep-fi and radio configuration but of course some of the wide area network low pan networks such as Lora, Sigfox. Those are using subgearhertz but you could design radios that actually multimode between 2.4 and subgearhertz. So that's probably the next frontier in terms of this integration. Another next gen development that we could see and there's also already some talk on that with some announcements from the center body to see a lot more of these devices being implemented beyond the smart home. So you'll see those in things like office buildings in professional installation scenarios. An example there for instance would be using the beacon aspect of the BLE in order to do location awareness but then exploiting some of the mesh network and the other characteristics that enable 6.0 pan and co-app-based networks to operate on the other side of the protocol and the stacks. So even more flexibility on the radio side, even more programmability and definitely those two trends at the end you'll see mesh networks really everywhere because right now it's Zigbian thread that have that native but a lot of the latest Wi-Fi router packs, access point packs actually implement some sort of mesh protocols if you go to ERA or Google or Linksys and these guys you can actually right now buy these mesh router systems. They still have some proprietary characteristics. It's similar for BLE. In Bluetooth you'll see some implementation of mesh networks that run over BLE and probably see more standardization in both of those two areas on Wi-Fi and BLE. So a lot of mesh capability and that's a good thing. So it will exploit these multi-mode characteristics of these radios and then depending on the various use case, the various network, one needs to connect to the various devices. One needs to have direct connectivity and then you'll have the possibility to operate in one of the mesh configuration of the other. Definitely IPv6, there are a lot of other discussions here this week on IPv6 and 6.0 plan protocol and end-to-end principles. We'll see more and more of those. It's been going on for a while and I think we now see enough critical mass in IPv6 from the infrastructure. So it kind of makes sense to actually use IPv6 up to the edge node. So that would allow kind of simplifying the stack a little bit. So if you've got this projection of what can be more deployed in a few months or years and it's possible to do now but it's really not typical. It's kind of simplified the protocol stack that we saw earlier. Okay, this multi-mode transceiver, all these five interfaces which are blurred for the application, they're just interfaces. So similar to how you use IP over Wi-Fi and Ethernet and cellular, you'd use IP over BLE or 15.4 or Wi-Fi for the IoT and the set of common modules and common software stacks starting with UDP, DTLS, with some helper application there. Again, I don't see, we'll see reduced fragmentation on that side but one can help and then a device application. Definitely from a stack and from a perspective, it would be a simplified and more seamless operation. Okay, yeah. Well, yeah, so again, I think this is beyond necessarily the frequency band. So as we saw, it's more common right now to see multi-mode radios operating in 2.4 but you can have multiple radios that do multiple frequency. For instance, you go on Wi-Fi multiple of the brands that Wi-Fi provides in that area. So I don't think that necessarily this increases the usage of the 2.4 with such systems, right? Because you'll still see in individual systems enough usage. So it's perhaps a more coordinated use of it if you've got this kind of systems. Okay. So next steps and I think we'll be able to access these so I'm going to the links. Again, NXP provides some of these platforms along with the drivers and stacks, a lot of the other microcontroller and connect microcontroller vendors for similar capabilities. So it's really go to your favorite platform vendor and choose one of their platforms there, both for the edge node and the gateway side. It's good if you're not already member to maybe join the standard bodies because then you'd be able to influence some of the specification directions and first and foremost you'd be able to take part in the certification program that those standard bodies offer that guarantee interoperability if you want to actually get more details on the less common like ZigBee and Thread standards. There are a couple of events that are open to everyone. So the first one for ZigBee is in March 6th in Austin and 4th Thread got an event March 27th in Mountain View, which again opens up public and you can actually get a deep dive of these standards more than we'd be able to do here. And of course, contributing open source software around those, starting with Zephyr which adds a lot of the building blocks for building the multi-procal systems and stacks right now but also Minute, Nimble, IOTVT or Open Thread. So those are some of the, let's say, higher profile open source software that are relevant for building such systems. Most of them are work in progress so not all the blocks are there and available so definitely would use some help. So at the end also wanted to have a quick overview and a quick example in practice. So for that, actually we'll go back to that system that we saw. So we've got this mesh network. I'll use Thread for that and then we've got this multi-procal node that also has BLE, Radion. So for that I'm going to use the NXP Freedom KW41Z which is our latest generation launch in October. Multimode device that implements these standards. So I've got a couple of boards here. So I'll go then just to see what's going on. I also have one of the other variants of the KW41 which is operating as a protocol sniffer. So I'll plug that in, actually plug two of these in because again it's a multi-procal. And then let me go to the... Yeah, I plugged in two and you'll see why. So I've got this adapter that actually allows me to use these to unit as virtual interfaces that are Wireshark compatible. So with this small add-on I'll just launch Wireshark. And going back to this I can see here in Ethernet 7 is the virtual interface. So going to Wireshark I'll choose this virtual interface. I'll start monitoring on it. And I see here the two devices that I plugged in. So what I'll do is actually... I have the 15.4 channels at the top. So I'll start the first one on channel 25. And then I'll power up one of these nodes which is the thread node. So I can then see the MLE messages that thread uses in order to synchronize the mesh network. So this is now operational on thread. And then going to the second one. So these will now do a link synchronization between them. So you can see here there has been some link requests, parent requests, parent response. So these two devices are now talking to each other from a thread perspective. I'll also create a small network. It's four devices. We usually deploy significantly more in testing like 10s or I think the largest network really is about 250 devices. I've got just four here in the thread mesh. Okay. I can see in the Wireshark how the devices change the thread management messages between them. And one thing that I can do, actually I can use the board button interface to actually send messages that are application layer messages. So you can actually see some of the co-app messages that are being exchanged. So you can see the con messages here. Okay. But what I can actually do, because all these devices actually have the BLE radio, have my smart device. So I'll launch an app. So it's a Kinetics BLE toolbox that we use for our BLE reference design. And here in the app I have a thread shell interface. So if I tap that, I actually see the beacon advertisements of these nodes that operate on thread, but they're also sending BLE advertisements telling me that I can actually connect to these devices along with their RSSI. So if I tap one of them in the app, I can actually go and connect through a shell interface. So it's now connecting over BLE. Okay. And then I've got a set of shortcuts here, probably not very visible, but I also can show on the slides. I just did an if config. So with an if config in the shell, I can actually see the IPv6 addresses that the device configures on the thread side. So if I go back to the slides, this is kind of how it looks like. So I've got a set of IPv6 addresses on the thread side and I can actually go in the application. They also send a co-op messages for my application over the thread mesh. Yeah. I've been sending one byte to the NXP TR5 over and over again, but I don't see anything happening. On BLE. Oh, you connected it? Yeah. Probably need to implement a specific profile. I'm not sure if you're using the same app or... I'm using it. Okay. Then it's probably not the same profile on the wireless UART, because it's kind of a UART transport over JDD. So it's probably that's why it's not reacting. So this is, I guess, still a bit to standardize in one of these standard bodies. How do you actually do the transport over BLE? Things like you want to do IP over BLE or a common generic raw transport. Okay. So this shows basically the use case picture here. You've got a BLE connection. Maybe it's not always that you need to do that. Maybe you only need that to show a certain UI temporarily. And at the same time, the device is also operational on the thread network. And actually going back here, so then the reason I had two devices is that I can use another one for BLE. And definitely with a single radio for BLE, you don't get all the information, for instance, in the connection. But going to Wireshark, I've started seeing also the BLE advertisements. So it's on the same interface with threads. So I can actually, if I've got a debug system that's plugged into Wireshark or TCP dump or something that's using pcap, I can actually be able to verify and test both protocols simultaneously. And it's useful to do things like see how the two protocols coordinate with each other. So I've got a lot of advertisements here, but if I filter, let's say, UDP, I'll also see the thread-only messages that are also showing up, okay? And finally, okay, sorry. We're close to the end of the time, but I think we're the last session in this room, so maybe have a couple of minutes. Another example I wanted to show you is using two boards. So I'll just turn off these ones that I use and plug in others. So I'll plug this actually to my PC. And the reason for that is to show the host SDK. So this is, if you do things like a gateway, a multi-pro call gateway, then the host SDK comes, it's a set of tools and BSD license software that runs on things like Linux, Windows, most sport Mac systems. And you can actually build a set of library and interface with the devices for a serial interface, being able to control and coordinate on two or more of these protocols. So with that, for instance, I can... Let me see, for instance, okay, I'll go to the device manager and the two devices that I plugged in the J-Link comport on 6 and 15. Okay, so I can then go to a shell interface here and just use one of the multi-mode Python scripts that I wrote, so 15, and let's say the thread channel is 24. So now I can actually, for testing purposes, also for better use of development, while I go and develop and integrate such protocols, I can actually use this set of host-based tools to start my thread networks. You'll see a lot of log events as the thread network and, for instance, right now, it's running the mesh commissioning protocol to authenticate these two devices to each other. So it's a lot of scripting that I can do with these host APIs. Okay, so the thread initialization completed, so with these two nodes, I now have a small thread network created. But then, and you can already start to see here, a lot of GAT messages. So I started also using the CRL interface to connect to the... and control the BLE interface. So right now, these two devices started sending some ping, so you see the ping at the thread level, but if I go back to my BLE app, just to differentiate around the heart rate, I also see one of those devices implementing the heart rate profile application, so I can connect to it. And actually, I'm starting getting the heart rate information, even those two devices are also sending pings to each other on the thread network. So pretty useful for testing and scripting and batching various commands. So with that, thanks very much for your time and I'm sure there are other questions at the end. They're not open source. For this device, we do provide them in source with a BSD license, but they're not part of an open source project. Again, a lot of the open source, the true open source in projects like Zephyr or others are still working in progress and being now ramped up and hopefully everybody's help is appreciated on that. Yeah. So if that's not running Zephyr, what's producing the co-app packets? It's a co-app module that runs, in this case, this device is actually using FreeRTOS, so it's actually a co-app module that runs over FreeRTOS. It's running FreeRTOS, so you get this in the package from Welter, Digikey or something like that, but I think it doesn't have FreeRTOS by default. So, no, going to the... So what's currently available for this platform in terms of enablement? So if you see these toolings here, so from a driver perspective but also from a stack perspective, for the firmware of these devices, there are a set of firmware modules that you can actually deploy through Eclipse GCC, ARM GCC or IAR based that NXP provides. It's, for instance, similar to on BLE, I've got a soft device stack or something similar. You'll get all the enablement for these devices as you get the boards. You just need to go and download them from those links. So you get everything to build these solutions, but again, a lot of these is not yet fully implanted in open source projects. And now it's still early, and a lot of the coding this SDK packages are... It's not binary blob, so it's both the radio drivers as well as the coexistence framework that I showed as well as the upper layers of the stacks are provided in source, that can be modified and used as a model. Okay, yes? Static routing. Yeah, well, it's a bit difficult to do that with one of the standards because the standards already do mesh, kind of have their own specification around how you do that. So that's usually dynamic, especially for these IoT devices. In ZigBee, it's different versus how you do it in thread, for instance, it's usually handled by the stack based on the specification. So from a static route perspective, device to device, it's more difficult, but if you consider things like border hours or devices at the edge where you've got, for instance, IPv6 provisioning from your ISP, you can definitely do more on such devices and kind of configure which packets, based on the source prefix on IPv6, which packets get routed across the border which go from the upper-layer infrastructure to the IoT network. Okay, so I think we're at the end of the time. So thanks again, everyone, and I'll have some of the next steps, links here. If you want to look at the slide next lecture. Thanks.