 Okay, then I just get this started. Okay, welcome everybody. My name is Marcel Altman, I work for Intel and I'm giving the talk about the next generation of Bluetooth, which is Bluetooth 5. Before I start off, small disclaimer, to get this all correctly done properly, Linux is trademarked by Nino Storewalls, Zephyr Project is trademarked by the Linux Foundation and Bluetooth is a trademark of the Bluetooth 6 and all other trademarks are done by their respective owners. So just to get this out of the way so we don't have any problems with the further slides. Myself, I've been working on Bluetooth pretty much since 2000, so that has been 17 years. The technology keeps evolving, keeps changing and we're gonna have the next, we talk about today about the next latest iteration, which is Bluetooth 5. I've maintaining the Linux Bluetooth text since 2004, that has been also quite a while now. In the meantime, I've created a couple of other projects, Conman, a connection manager for Linux, a phone or complete telephony stack for building mobile phones on Linux, pack runner, proxy services, El and embedded Linux library and IWD wireless demon. If you care about the latest, the last two, I think the talk is on Thursday that we'll explain these ones in more detail if you haven't already seen that one. I joined Intel in 2007, so this is my 10th anniversary pretty much this year, has been quite a while as well. I'm sitting on the Bluetooth architecture review board for the Bluetooth SIG and I chair the Bluetooth internet working group and the next standard we might wanna talk about this in about six to seven months will be how we're actually doing with bringing mesh technology into Bluetooth SIG, but that's a time when we do this another time. So moving on pretty quickly, so Bluetooth 5, the one big thing everybody used the Bluetooth standard they used to have a pretty much major, minor version numbering scheme. This time around the Bluetooth SIG decided to spice it up a little bit and they just called it Bluetooth 5 and I will spend the last of the next 30 minutes around to actually give you the details on this one what it work comes from and dissecting a little bit of the marketing buzz from actually what's technically possible and where we're getting this one and when we are getting it. The funny thing is with the typical N5 kind of thing it actually did remind me of something that we had around 24 years ago. The German people inside the room might remember this when we changed from a four digit zip code to a five digit zip code. It was the nice hand gesture. So every time I see the Bluetooth SIG doing the five thing, it reminds me of that one. So it's an inside joke, but I found it kind of funny. So let's get this going on. I'm skipping everything before Bluetooth 4.0 because it really doesn't matter anymore. Bluetooth 4 is the standard that accept automotive that there's still little people a little bit behind. Bluetooth 4 is pretty much what changed the world order back in 2010 when they enabled something that's called now low energy. Originally it was called Wibry, then it was called ultra low power and the name that actually settled on was low energy. So it was an additional technology introduced into Bluetooth that allowed low power devices for sensors like peripherals, type styles, like a hard rate monitor and so on and so forth and they could last on a battery on a coincident battery for a really long time. So that was back in 2010. So my rule of thumb is always a new standard needs around five to six years before it has mass market penetration. So around 2015 we had then funny mass market penetration for Bluetooth 4.0 and it's still the most used Bluetooth devices we have out there when it comes to the low energy feature. In the meantime, we have done a couple of updates CSA 2, 3 and 4 says cross-spec addendum not really that important because they just updated Bluetooth classic. As I said, Bluetooth 4 introduced low energy, the new technology we wanted to base on but they had to do a couple of updates for the classic one that you use in your current headsets and there are CSA 2 and CSA 3 and CSA 4. One of them introduced 3D glasses support and one of them did a couple of updates for 802.11N feature when Bluetooth tried to do a high speed which in hindsight never really succeeded as a technology because Wi-Fi was just doing native Wi-Fi was just way easier. Bluetooth 4.1 in December 2013 was the big update that was needed from a security point of view. It moved away from the classic Safer Plus encryption cipher and E0 probably doesn't mean much to anybody. Technologies to using AES and being NIST and FIPS compliant. So it allowed you to actually build Bluetooth devices with proper encryption and proper authorization. But they only did this for classic so all the low energy sites still had a horribly broken pairing system while low energy always had AES encryption but the pairing was so fundamentally broken that it took you less than a second to actually break the keys. Bluetooth 4.2 fixed that so the combination of 4.1 and 4.2 allows you to have AES encryption and really strong key generation on both transports and the nice thing you could also then transfer the key from one transmitter to another one is you don't have to pair them twice. The names under the spec are actually the code names for the development. One funny note, Bluetooth 4.0 never got a code name. Every single spec in the development cycle starting from 1.0 had a code name but 4.0 they actually did forget to give it a code name. CSA 5 came out in December last year and the only thing it really did it increased the output power so you can actually compete with 802.15.4 a technology if you're in America or country where you have a little bit loose regulations in Europe you still can't use that high output power but it given a competitive advantage if you build products for the market in the US. The one interesting is really Bluetooth 5 and now you see that I'm calling 5.0 so here's the fun part. The marketing likes to call it 5 the technical spec is actually 5.0 how it's supposed to be. Original code name was Shanghai if people saw that and noted earlier in some publications. Released about two months ago and came with tons of additions and fixes. So the interesting part, Bluetooth 4.0 was the introduction of low energy. 4.1 fixed a couple of classic issues at a level of low energy features starting with Bluetooth 4.2 we only had low energy updates so classic is not really making any progress. 5.0 has a single feature that updates classic but the majority 90% of them are pretty much only low energy so you see the trend is going Bluetooth moves away from its classic roots where in the headset it moves really towards low energy and low power devices. Marketing, so marketing is always funny so Bluetooth 5 twice the speed four times the range and 800% data increase and obviously it does for wireless coexistence. The funny thing is the wireless coexistence is only for LTE and classic so why they put this on these slides? Probably to say I never really understood but I think it's good to have there. The other ones, if you think you can get them all together at the same time, you will see you have to think again. So they're kind of a little bit misleading and we go through them. That's the marketing view, how they wanna see and how the spec perceived. If you go on the technical side it looks a lot more boring and more cryptic. So slot availability mask aka SAM is the coexistence feature that allows you to actually use LTE and classic audio connections a little bit easier together. And the main reason for that one is because LTE operates on a 2.5 gigahertz spectrum if you're unlucky and that swaps over in 2.4 and you hear it drops in audio in some cases. Most interesting or one of the most interesting features to me at per second so we doubling the speed of Bluetooth low energy. We also doubling the range which was doubler early long range. We're doing advertising extensions. I will explain what that is later in the talk because that's one of the most interesting features what it does for you. But that's labeled with the 800% data throughput increase. And we have three that actually never got caught up by any of the marketing thing. One is the channel selection algorithm too and I have a slide for this one that explains this. So it does a little bit different frequency hopping. We have also limited high duty cycle non-connectable advertising. A long word for three changes, three lines of changes in the spec it just removes one restriction that was introduced with 4.0 and these days was felt as like completely not needed anymore. And then we have cross transport pairing number two. We found a flaw in the cross transport pairing not really a flaw but something where we weren't really sure if this is cryptographic fine and if this is FIPS compliant so we actually went around and updated this one so we actually can have a FIPS compliant mechanism. So I'm going through these features now one by one and the first one I'm gonna pick out is the two megabit per second LE and what it's doing. For that one I have to make a few steps back with Bluetooth 4.2 introduce data length extensions and I will give you the details on why this is important. But fundamentally about two years ago the Bluetooth 6 said oh with data length extension we get twice the 2.5 times the speed and we get 10 times the capacity. The 2.5 is something I can figure out where they got the number from. The 10 times number I never understood where they got them from because even if you in the best estimate it's something nine times only. By running the stand there were the marketing numbers that's how they advertised it. Let's go with it. Still Bluetooth 4.1 4.0 4.1 4.2 one megabit GFSK modulation eight bit preamble then nothing changed. We just introduced the longer packet lengths. Bluetooth 5 does it a little bit differently. It actually changes the FI so you get a two megabit FI still using GFSK but the symbol rate gets doubled and because of double symbol rate we're actually using a six in bit preamble so we also have to increase the preamble so we get the marketing two speed from. So how that actually worked out and that's one of the features where 4.2 plus 5.0 gives the big thing that you really want because if you only implement two megabit per second it really doesn't give you much. You want the data length extension as well. This is actually readable. I hope it is readable. So this is the basic packet format that goes over the air. You have your preamble, you have the access code, you have your payload and you have a CRC. Really simple. If you break them down with 4.0 and 4.1 we had a length that actually only gave you 27 octets of payload. That goes roughly around 300 microseconds air time that actually gonna use us. If you go further with the data length extensions we had a couple of bits unused so it allowed us to actually use it longer lengths and we just increased it. The reason why this was never done before originally Bluetooth was for sensor data. So please transmit me your heart rate or please give me the status of the light or please give me some data that is 3, 4, 5, 6 octets. So 27 octets seemed massively amount of data that we had. Obviously the world moves on and people have found really interesting ways in using Bluetooth or energy and they wanted to do data transfers. Especially also because devices like iOS and Android provided easy APIs without any sign up for any certification program or anything where you can actually just use it. And they have been using this for a lot of things where you have to push a lot of data through. So data extension gives you a lot of extra throughput and every throughput slide it will show you the difference why this made a huge impact. So simple change in the end of the day with 4.2 but it comes at a high cost. So if you look at the button diagram the increase in air time that we now need to transmit these data increases and in that time you can't do anything else. Which means previously we spent 300 microseconds roughly 300 microseconds for the transmissions. Now if you want to use the full data size we spent over 2,000 microseconds and at a time you can't do anything else. Previously you could have fit two more packets from another transmission in there or do something else that's now blocked. And the longer you spend on the air time the more you have to deal with interference, et cetera. So while it gets you faster there but if you have interference the problems increase and you might actually have other problems. Two megabit per second helps a lot here because we're actually changing the file and we're changing the symbol rate. So if we stay packet size stays the same we currently would reduce it from 2,000 microseconds to 1,000 microseconds. So we can do it in half the time that's where the speed increase comes from. And this means we would half time occupy the air space and this means we can do more transmissions at the same time. Which is nice, which we really want to. And if you have small packets still the send source like the only use less than 27 octets you will still decrease the time on the air so you have actually a lot more chances that things get done quicker and you unblock the air space. Which is kinda nice and hopes with interoperability a lot. So the throughput numbers are the most funny ones because I always, I had that in the beginning we had one megabit and two megabit. Bluetooth 4.0 and 4.1 was never really one megabit. It could never get it through because it was capped in 27 octets of data payload. So with all the switching between receive and transmit you end up with roughly around 300 kilobit maximum throughput rate. Which is totally fine if you do a couple octets of data but if you wanna do a firmware update on your watch or something else that's not gonna fly. You're waiting for half an hour or something. The data lengths extension increased it roughly with 2.6 times. So you know the marketing numbers and you count the numbers they go a little bit off. That's okay but they were roughly in the right ballpark with a throughput size. You have the maximum net you can get on a one megabit per symbol rate. So you have around 800 kilobit there. Which is pretty good. The right side then with two megabit LE you get another 1.7 increase. So it's not really two X compared to 4.2 but marketing numbers, you can do the math as you want to. You'll find a way how it comes nicely but they're forgetting that you have the round to receive and transmit which are not really getting any faster that way. And you have interframe spaces that have stayed the same. So around 1.7 roughly around. The interesting part is really that 4.2 together with data length extension and two megabit phi gives you 4.6 times increase of the throughput that you can get. So think about it, if you need now four minutes to transfer a file to your watch or something else you only need one minute. And that's really visible to the user and makes a huge difference and makes a big impact. So that's two megabit per second, big deal. And I think it will give the technology a big boost. The next one is we're going over to long range. One of the, you could say interesting features but normally Bluetooth had the range of around 100 meters most and it's a little bit less with LE and two megabit per second has a little bit less as well but they had the idea, let's get a larger range that's more need driven by other technologies can do it as well, why can't we? So for long range they introduced what is called coded phi. So they decided we have to change up the coding a little bit. The important thing is really if you think you get long range and faster speed at the same time really think again, that's not how this works. You have to make a choice. If you wanna go far, you're actually losing throughput. And if you wanna go far, you also have to spend more time on air, which means you're more reluctant to interference because you have to occupy the airspace a lot longer. So coded phi gets two coding schemes. It's pretty much to figure out what we can. It was needed in the end. At some point it was actually three coding schemes but one of them we found out was completely useless either the stick in one coding scheme or the second one. So the difference, still one megabit per second symbol rate but the data rate gets changed. You have one megabit data rate for the one megabit phi as we've known today and they get 500 kilobit or you get 125 kilobit. Air detection, still there, has to be there. The basic packet format hasn't changed but now for the coded phi you need forward error correction because the further you're gonna go with your output power and the more you occupy the time on air, the more likely you actually have errors happening then you need to actually correct them on the receiver side. So this in the end all boils down. So if you assume one megabit per second is the one times range with a coded phi with S2 you get around double the range. If you do with a coded phi with S8 you get around four times the range. With a two megabit phi you actually get less than one factor as I said. You're paying the price with the faster speed that you can't actually go that further. You would need a lot more power to do so. All the other ones are optional. Only the existing one one megabit phi is mandatory. But fundamentally we have three phi's now in the system. The legacy one, the coded one and the two megabit one and the coded one has two schemes that you're actually gonna select from. Other schemes can actually be selected at runtime so the receiver can actually decide to actually switch it on and off depending on what the characteristics on the air transmission is so they can decrease the throughput and increase the throughput as needed. While switching between one megabit and two megabit is a conscious decision so they have to say okay I'm switching to the megabit now while the other one can be done on a perfect basis. What this means for the bit stream processing on top is the legacy one that will be used for one megabit and two megabit. You do encryption, you do your CSE, you do whitening, it gets off the air. On the other side you unwhiten, you do CSE checking and then you do decryption. Straight forward, most systems do it this way. And even Bluetooth Classic has done it in a similar fashion. Now with the LE-coded PHY you end up doing encryption CSE generation still the same but now you have the whole block in there with the FCC forward error correction and the pattern matching to actually handle these errors. So you do FCC encoding, you see pattern matching and then the whitening, unwhiting and then it goes all the way back where you do the pattern dematching and the FCC decoding and then CSE decoding and the decryption. So it's a lot more complicated. You have to pay a lot price if you want to go a lot farther. I think some companies did some tests, some demos with this one. You can actually get to a kilometer range but this all depends on your line of sight, how much interference you have. So someone says, oh, we can do kilometers now. That, yeah, that works maybe in a field test but it doesn't mean it. But if you currently reach 100 meters you might actually really quadruple it to 400. And if you have good line of sight, current classic might actually do 500 meters and then you can actually quadruple it as well and you maybe get your two kilometers. Something wrong. So take this with a grain of salt how far you can actually get with this technology. You can get further but it doesn't mean you actually get always to a kilometer. And everybody who gives you a kilometer range available delusional on how this goes. So the next one, advertising extensions. It's really the big feature that is gonna change something. I'm not really impressed with the 800% data throughput increase or capacity increase or how they called it. I can understand how they came to the number but take it with a grain of salt as well. It's just a marketing number. So advertising is used in Bluetooth for beacons for connection handling. So every time you create a connection you have to advertise. It's one of the basics on how Bluetooth low energy actually works and how things are done there. It uses three advertising channels. So they pick three channels that are purely only for advertising. All the other 37 are for data. That's where you come your 40 channels split over the 2.4 mega spectrum and the maximum payload was 31 octets. So that's all you can put in there. Strictly speaking with a defined data format they have it's only 29 octets. But that's all you can data can get in there when you want to broadcast data. And advertising is broadcasting. You send out the data and if someone listens the other side gets it. If nobody listens you basically sending them out for no reason. But that's how all your beacons and everything else works way up. So now I'm here and so on. The difference with advertising extensions is we wanted to increase this to same with data length extension it increases to something around 250. Perfectly 255 octets to actually get more payload because a lot of more things can be just broadcasted out and sometimes you have to encrypt things and so on and so forth. You need extra mix and things like that. And if you already spend eight octets on a 31 octet payload for your MIG and then you need your announces and everything else put in there. You left with like eight octets of payload or something if you want to do more advanced protocols and that's where it doesn't get you anything. So the idea is we actually can offload the data into the data channels. So we have 37 channels that are currently data channels. Let's turn them into broadcast channels and use them. And I will give you a detail on why we did it this way and how it's going to work. So to recap this again the spectrum has to be explained a little bit. So 2.4 gigahertz divided into 40 channels and divided into 40 channels in a funky way so to speak. They have zero to 37 as the data channels and they're split across the spectrum but they have three spikes there that strategically placed and so they interfere less with wifi. So if you map out the wifi channels on that spectrum how wifi would use them you find these sweet spots where you actually can put them. There were four of them to be precise. We see there's another force one there that was not decided to be used. So put one at the top, put one at the bottom and put one in the middle and they choose to use the upper middle one. It's like this least interference you're going to have with wifi and put these ones as the three pillars where everything happens from finding a device, connecting to device and so on and so forth. These are the advertising channels and they're labeled 37, 38 and 39. It's just how they label them. But you can't really put the channel number into the megahertz number by simple math. They're just randomly assigned there. The interesting thing to really know is you have to advertise on all three of them. If you advertise you do 37, 38, 39 and you do round robin again 37, 38, 39 and it goes on and continues and once you have done completed 37, 38, 39 you have a full advertising event that's called one event and that has to happen. In the top diagram you see there's a small piece in there that is called scanner. So it has an extension where you can actually ask for more data. So if you see an advertising event you can ask and can you give me more data and then you get another 31 updates. It was more like okay that's data that's not always really needed but if someone asks me for it I will send it out again and then you use a free slot and send the other one out. That's why you see in the middle one you see three of them. So you do an advertising which is a TX you see a receiver, you turn on the receiver and then you wait for the other one. And the other one it doesn't happen. So that's how the advertising works but it also means that if you want to increase this now you actually spend more time on these three channels and if you have iBeacons, Google Eddystone pick whatever advertising goes on there. I think every phone these days advertises something constantly. These three channels are really occupied and you want to spend as less time on these ones as possible. So one thing that actually happened is that the scanner site where you can ask for more data certain phones keep asking for more data all the time and they keep blocking then something if you want to connect because that would be the same packet where you actually ask, oh I want to connect to you. And so these three channels are really, really busy. If you look at the packet format it's by the way pretty much the same the preamble access address is just a fixed access address, the data and the CRC. If you boil this down we actually would have an option to just use the same as the data length extensions take some of the reserved bits and make the PDU longer. Would have worked perfectly fine. Everybody would have been able to receive them and we could have just done this. The problem is like we would have spent more time on the three channels and we would have just eventually blocked ourselves out with these channels. We actually wanted to make the packet smaller on these three channels and not larger because that's limited airspace. If you think about 2.4 gigabytes is already blocked. If you only have three out of 40 channels and you've been blocking these ones more and they're your main channels to operate on you don't want to put more stuff in there. So this one happened a little bit differently and trust me on this one this was one of the features that took pretty much all two years to get this into a releasable state from a spec point of view. So what you see on the left is that you have your three packets. As I said, all advertising has to have an event of three. So you do 37, you do 38 and you 29 and that's your spectrum top to bottom in 2.4 gigahertz. And if you would keep digging these ones they would just occupy the same amount of airspace. What we wanted actually, let's put tiny beacons reduce them to a couple of octets onto the advertising channels and then just have them point them where the data is. Because really we don't need the data we also don't need to repeat the data three times because it makes no sense. Let's put the data at one point and then have three beacons that can be collected by the scanners and then, oh your data's there then you've divided a couple of microseconds and you just jump on the data channel get up the data. And with that one we can put in the whole packet 255, not always but in most cases around over 200 octets of payload into that offloaded one which means we increase the size dramatically and we can reduce the size in the advertising channel that's so crucial for LE and LE to operate. And one interesting fact is that you can actually chain them together. There's nothing stopping you from saying the one in the data channel on the broadcast channel actually points to another one what you see on the right where you go like, oh I'm putting another one over there so you can chain them together and have I think the standard limits into six chains so you get around a couple of thousand octets of payload which means you could even fit an IPv6 packet into the broadcast which is what we actually after that we can do this and then again just get collected. A nice thing with doing it this way is we can actually go from one megabit in the advertising channels to two megabit or LE-coded in the data channels. We couldn't do this in the advertising channels for our PCNs since there's no negotiation so you don't know what you're getting. So you don't know if the outside supports it or not. It's like okay that's pretty much fixed for lifetime at one megabit per second. But in the beacon that we're sending out in the advertising channels we actually put an indicator in there. What's the phi on the broadcast channels so we can tell them okay that runs at two megabit per second or LE-coded so we can actually do the longer range which is kind of nice so we cannot only do put more data in it we can also transmit it faster and free the spectrum even further. And that's advertising extensions. There's an additional one that is periodic advertising which I actually mentioned. So you can also put trains of packets at defined interval times on the new data channels so the receiver can just pick them up without having to go back to the advertising channels to find all of them. They notice all the next one happens there and you can monitor changes in the packet payload easily so you can synchronize to them. It's similar to what 3D glasses do for their shutter synchronization so you could build them with LE now using that technology. Channel selection, algorithm number two. I just want to mention this quickly. Up to now, Bluetooth was a little bit, let me put it this way. We didn't spend much time actually thinking about how the channels actually distributed when you do a connection and want to pick the next channel. All 37 channels supposed to use equally if available. The problem with the simple mod 37 operation and channel mask, we actually blocked channels out because of interference, is that you will not have an equal distribution and that gets you into trouble if you have to do something like more data-driven transmissions than we have done before which you want to actually equal this out better and it also becomes a problem in the European regulations when you actually want to use a higher output power and you're not equally distributed across the 2.4 giga spectrum. So the new channel algorithm will actually go and say, we're using a more pseudo-random distribution and this one gives us an equal distribution on the 2.4 giga spectrum for our data channels. It's behind the ground things. It lays the ground back for the next Bluetooth spec where this becomes absolutely crucial that we distribute the events evenly and including sub-events. I'm leaving the other ones out but these are the big ones that we actually have for Bluetooth 5 and they make a huge difference and it's a big difference compared to what we had with Bluetooth 4.0 and 4.2. So if you take the features again and put them on the table, Slot Availability Mask doesn't need any new hardware. So not a big deal but it will require firmware update for your controller. So we don't know when this is gonna happen. Some companies are committed to this one, others are not and we will have to update the host to actually use this one. So your operating system, depending on which one you use, 2 giga per second actually needs a new fi. So you have to redo your hardware design and build a new fi that actually can use this. Some companies have been already preparing for this one so they can switch it on with a firmware update. Other companies will require complete new hardware. Long-range is the same thing. Nobody I think has prepared for this one but I've seen an announcement that long-range hardware will be available at least for testing purposes really soon. I don't know when this becomes ubiquitously available to everybody. I don't think it will take another three to four years because you find a laptop that supports our phone and supports long-range. Advertising extensions in theory doesn't need an hardware update. You can do it on existing hardware but it also relies on that your hardware is capable of keeping the stringent timing requirements when you have to switch off into a data channel for picking up the packets. And depending on your hardware design that might be not as easy as you think. But in theory and I've seen this couple of companies doing you can actually do this with just a firmware update. Channel selection number two doesn't need a new hardware. It helps if you have a new hardware because you need a dedicated random number generator so you want to put this into the hardware but you can pretty much do this in software as well so you could do this with a firmware update if you care. Funny enough, that one feature is designed in a way that the operating system doesn't have to do anything so it will be just automatically available. While for long-range in two and per second to recap this one, you actually have to enable these extra files otherwise it will stick with a one megabit file. Limited high duty cycle, non-connectable advertising. Yes, you need a firmware update because it has to retake a restriction off and you have to make the operating system use that one. There will be not much use of this one, I think except for new protocols and profiles that are coming out that makes use of these lifting of this restriction. Cross transport pairing number two is completely in the rating system that has no hardware or firmware impact. You can do this on a higher layer really easily and then that's about it. So what we have, which I would hope looked a little bit differently but reality is the standard is relatively new, two months old and the hardware availability is really limited at this point in time. So slot availability desk and Linux, we actually don't support it, I don't think we ever will. It only makes sense if you actually have an LTE modem and the LTE modem that actually can communicate to the base station to give you the parameter to program back into the Bluetooth chip. Two megabit LE, we don't have this either. It is rather trivial to support since operating system only has to do one thing is actually enable the two megabit file. So I wanna use it for this connection, yes or no. So once hardware comes available that should be rather trivial to add. Same goes for long range. It should be really easy to add as well because you just enable it or disable it the same as with the two megabit file. Picking the right usage to actually choose long range over two megabit is a different thing where we actually probably have to do some policy decisions where the application can be in charge. So look, I wanna be long range. So please let me use long range. Advertising extensions is going to be a lot of work to support in Linux. Interesting enough, our APIs are ready for it. So the APIs can flexible enough that we can actually make use of the new advertising extensions and the multiple advertising instances that it actually does support. But implementing it once the hardware is available and the firmware updates are available will take probably quite a few months before we get this going. I hope we get this done fast because it will make a huge difference for all kinds of use cases. And getting people to play with it is really important. Channel selection on number two don't have to do anything on the operating system that will just work if it becomes available. High duty cycle, we have no use for it. So we probably not gonna do it. The cross transport pairing we actually have completed. So if you use a Linux side with this one it will automatically enable it and get you into better FIPS compliance if needed. The other one, the Zephyr status is as bleak as the Linux one. I don't think slot availability mouse will ever be done mainly because the classic support on Zephyr is more, I don't know how far this is gonna go that this becomes useful there. But I don't think Zephyr where we run on a system where you have audio and an LTE connection and running this at the same time. So the usefulness of SAM is limited. To bring it to FI is definitely interesting but you need the right hardware to support it. And from the controller side for Zephyr so the firmware side, there will be a lot of work. The host side as with the Nox I don't think there will be a lot of work to do except enabling it. But the controller side will be the heavy lifting. The same goes for long range. You have to get the right hardware. A few companies have an announced hardware so they might gonna start working on it if they support Zephyr and from the host side again it's just switching on the file. Advertising extensions will be the really interesting one because in theory you can do it on existing hardware but it depends on how lucky or unlucky with the time requirements the hardware supports. So I would assume we will see advertising extensions at minimum on a Nordic NF52 chip really soon. And then we have to figure out what we can do with this on the host side because Zephyr will probably the first one that makes use of it. So we're gonna see channel selection on number two depends on if you are fast enough for your pseudo random. If you have to do this in software I don't think any hardware has planned for this one yet. Duty cycle is really not a big deal for Zephyr since you control the controller so the firmware and the host you can just switch off the limitations if you make using them. Cross transfer pairing as with the Nox that has been actually implemented and tested against each other. So we have that one up and running there. So summary on this one. Two meter per second is ready to be deployed and once you take a sniffer to an iPhone 7 you see that Apple actually switched it on and allegedly the Apple Watch 2 has it as well. So they're actually already making use of this one which means if the hardware gets further deployed and becomes available I assume that two meter per second will be the first feature that you're gonna see from the list of them that actually be used and as I said earlier it's around 4.6 throughput increase compared to Bluetooth 4.0 and that's a big deal. You want your half if you wanna have to transmit a lot of data you wanna do this faster. Advertising extensions has the highest potential for driving new use cases and new technologies in the beacon world. So we have the spec there. Now we have to get the hardware there and the firmware there that can do it and then we have to figure out what we're gonna do with it. Right now there is no service or profile in the Bluetooth 6 that actually uses it. So that's more allowing the ground work for new things to come. So we have to see what new standards are coming or what companies have ideas within how you can use this. Interesting. As I said it's ready to put an IPv6 packet in there. It can fundamentally do it. So we're gonna see how we actually put this further for the IoT use cases. And long range frankly I don't know if this will be a big thing or not a big thing. We have to see how good it becomes in reality when it actually gets deployed. It has its downside but also its upside. So we have to see how long range fits into the whole ecosystem of Bluetooth and if it finds a use case to be used. With that one, thank you and any questions? Go ahead. So you're from, are you maintaining Bluetooth stack? Yes I do. So your Linux status was with respect to Bluetooth support? Yes. And is there any kind of timeline, anticipate timeline that puts the yeses in this call? So normally you're trying to be as fast as possible but with the limitation on the hardware and the firmware for some of the sites, we have to wait. So there's a couple of hardware out there. So we can do the combination of having a Zephyr controller and the Linux host. So but it means we first have to implement it on the Zephyr site on the controller, then we can use it on the Linux side and then do the whole end-to-end testing. So I think you will see a couple of these things maybe pushed out really quickly but I don't think they will be enabled until we have a little bit more hardware to test this against. My wild guess estimate would be if we're lucky in a couple of months, if we're unlucky it might take a year or two. But I hope by the end of the year we have this up and going. I think to make up the second rule really happened first because we will see hardware on that one really quickly. Advertising extension is the one where on the Linux side if people wanna tinker this one and build interesting things, that's wanna give them to redefine what's currently possible with Bluetooth LE. Go ahead. Do we go out in class? No, Bluetooth classic compared to Bluetooth low energy. So if you pair on classic, you would have to pair again on LE but that was fixed with 4.0 where you can fundamentally take a key, do a key derivation function and put this in the new key into the other bearer in the other transport. There was a Dini Snuff who on these ones which I think they still make them cryptographically sound but it's not how NIST recommends them and FIPS follows NIST recommendations. So we fixed them to comply with the NIST. That's why it's a number two, we can't even fix what's up with numbers. Yeah, it was already there. We had this already working since about two years now. That's good, thank you. Any other questions? Go ahead, please. How do you think it's far to Android? So the new features in Bluetooth and Bluetooth 5 will get the same time on Linux and on Android? So that would have been the case about a year ago but the way how Google Android evolves right now is that they wanna build their own Bluetooth stack and they're redoing this one. So I think Bluezy on Android can be used, definitely. But I think it will be a lot of my extra work since Google doesn't wanna have the separate Hull Abstraction as they used to. They wanted taking full control over this one they're driving their own. So when are they gonna add in Bluetooth 5 support? Into Android I have no idea. So with that one I still think to make it per second will happen there. Same as Apple switched it on in iOS pretty much instantly after the spec got adopted. They could fundamentally do the same if they have the right hardware manufacturer supporting it one. But I've seen this with Android as well. Sometimes it takes them two years to actually realize it's an important feature and it's then up to the individual way to make the decision to actually put it in. So your guess is as good as mine. Previously it was pretty easy. You just install Bluezy for Android and then you got all the new features. That's not the case anymore, sadly. Go ahead, please. That has changed. Two, three? Yeah, two or three months? Yeah, maybe two or three months ago. Sometime last year. Last year? Yeah. I think it's still experimental, right? I think one of them still needs to be made unexperimental. I have to read it on the internet. One of them is still, it's coming next time around. Say again, I didn't know. Oh, Bluetooth Mesh? So Bluetooth Mesh will be not, so Bluetooth 5 is the one that came out in December. Bluetooth Mesh, as far as I can tell publicly, will be coming out soon. I'm bound by the same confidentiality as everybody else. You work for the, if you're a Bluetooth SIG member, I can tell you the exact details if you're not not in a public forum. But Bluetooth Mesh is scheduled to come out soon. And it's an addition. So currently Bluetooth is connection oriented and Bluetooth Mesh changes around to become a full Mesh technology. That's it then. And thanks everybody and have a good day.