 Hello everyone. Thank you all for coming here this morning. My name is João Paulo. I work as a software engineer in the Bluetooth team at INDT. I've been working with improving the support for Bluetooth flow energy on Linux and also with IVI related Bluetooth profiles. So today I'm going to talk to you about the support of Bluetooth flow energy and Bluetooth smart device on Linux. So that's the agenda I have. First I'll talk a little bit about the technology itself, like how it does discovery, connection, how the protocols and profiles works, and then I'll tell you what's the status of all of that on Linux. But before getting into Bluetooth flow energy, let's just go a little bit back in the past and remember what is Bluetooth? So Bluetooth was a technology which was designed to substitute cables when you're connecting peripherals to your computer. So it was designed with short distances in mind. And the idea was to provide a high level of security, like the same level you would get on a cable, so you're not expecting people in the next room to be able to wear tap your connection. It was created back in 1994, so almost 20 years now, by a telecom company called Ericsson. And later in 2010 we had the version 4.0 of the Bluetooth specification which defined Bluetooth flow energy. So it was aimed at low power consumption, especially on the peripheral side. So if you come here to learn how to save power on your laptop, I'm sorry. And so the idea is to enable devices that are powered with coin cell batteries, which is usually the battery used on wristwatches, that small round battery. And to have these devices to work for about two years with one single battery. So for that they improved the connection establishment. So the radius between the two peers synchronizes much faster. They have less channels to scan. So you could have a physical connection between these two devices established in about three milliseconds, which is really fast. It's still focused on short range, so that haven't changed. And one economic advantage of that is that they are reusing the same radio that is used by classical Bluetooth. So the cost to have a classical Bluetooth hardware upgraded to a Bluetooth low energy is very, very low. Just some additional structures have to be added, but the radio itself is the same. One drawback of that approach is that classical Bluetooth operations and Bluetooth low energy operations cannot be done in parallel. So you have to multiplex them somehow. And the market they had in mind when creating this Bluetooth low energy besides the market for classical Bluetooth devices, consumer electronics, like you have Bluetooth low energy input devices and these kind of things, mobile phones as well. But they mainly wanted to add these three new markets, the fitness and wellness where you would have like hard heat meters, Bluetooth enabled, wristwatches, pedometers, all this fancy sports device. Medical device as well, like blood pressure monitors, oximeters, glucose monitors, body thermometers, and sensors. So general sensors for like room temperature, gas sensors, proximity sensors, motion sensors, all this kind of stuff, talking to each other wirelessly. They also came up with new branding to refer to Bluetooth low energy devices, which made people a little bit confused in the beginning. So they came up with this Bluetooth smart devices concept, which is basically devices that use Bluetooth low energy to communicate. So it's mostly on the peripheral side. And the Bluetooth smart ready device, it's a classical Bluetooth which can also talk to a Bluetooth smart device. So it's basically what we call dual modes. They have a dual mode radio, which speaks classical Bluetooth and also Bluetooth low energy. That's mostly the computers and mobile phones. So to be able to save power, they also change it quite a bit how the devices find each other and connect to each other. There is a profile in Bluetooth called the generic access profile, which basically defines the procedures for devices to find each other, connect to each other, and also how they use different security levels. So that's the profile statement over there. So the gap profile defines two different types of communication for Bluetooth low energy devices. One is connection oriented, where you have these two roles, the central and the peripheral. They find each other, then they establish a connection before starting to communicate. And also there is a connection less communication between the roles broadcaster and observer. The arrow there is a little bit inaccurate because this communication is unicast, so it's basically communication from the broadcaster to the observer. And they communicate through the discovery process. So when you are using the central and peripheral roles to discover each other, the central device starts scanning. This is scanning, as I said before, it's low energy only, because the radio is shared, so it's concurrent with classical Bluetooth operations. So the BRNDR inquire there is the classical Bluetooth discovery procedure. And it has a configurable window and interval. So the window is basically the amount of time that the radio is actively scanning. And the interval, it's the amount of time that passes between one scanning window starts and the next scanning window starts. So with these two parameters you can configure your dirty cycle, which will influence how fast you can find your device or how likely it is to find your peer device, and also how much power will you expand using that. So usually the profiles have recommendations on how to configure that for different phases of the profile, like after a link is lost or when first looking for a new device. And on the other side, the peripheral simply indicates its presence. So to indicate its presence, it broadcasts small data packets, which are called advertising reports. So the advertising reports are used to indicate the peripheral presence and also to indicate what's the state of that peripheral. So what can the central do with it? There are four different states that it can be. The most common one is the Connectable Undirected Advertising Report. And when the peripherist advertises that, it means that it shall accept a connection request coming from a central device, more of that from any central device. Then we have the Connectable Directed Advertising Report in which the peripheral shall accept a connection request but coming from a non-peer device. So it's directed at a specific central device. Then we have the Scannable Undirected in which the peripheral shall not accept a connection, but it shall answer scan requests coming from any central device. So a scan request is basically package the central sense to gather more information about the peripheral device. So it shall answer this request with scan responses. And then we have the Non-Connectable Undirected in which the peripheral shall not accept a connection and nor answer to scan requests. And then when the devices find each other, the central starts a connection establishment procedure. The connection is always started by the central. It's not possible to have a connection request by the peripheral. So usually if the peripheral is interested in a connection, what it does is it starts advertising and wait for the central to try to connect to it. And there are three different connection establishment procedures defined for Bluetooth flow energy. The most simple ones, the direct connection establishment procedure in which the central simply sends a connection request and the peripheral answers that with a connection response and the connection establishes it. And the general connection establishment procedure and the auto connection establishment procedure you actually configure your central to be scanning and when it sees a peripheral that is interested in it sends a connection request. The difference between these two procedures is that in the general one this configuration is made on the host. So the host put the radio to scan, receives all the device found events and filter to know if that's the device is interested in or not and then sends a connection request. For the auto connection establishment procedure we have some support in the hardware. It's called the white list. So you configure the harder white list with the peripheral addresses you're interested in and then this filtering is done in the hardware. So your host is just awakened when the connection is actually established. So the hardware is scanning by itself when it sees the peripheral you're interested in it tries to connect if the connection is established successfully then your host is notified. So you can save quite some power over that. Also the security provided by this communication model. We have a secure manager protocol which was designed specifically for Bluetooth flow energy. So it provides payload encryption and authentication. Most of the calculations involved in the cryptography of that are done in the central role which is the one that usually has more processing power and more battery power as well. And the encryption engine used is AES 128. So it's easy to add hardware support for the encryption involved in that. So it's something that could save also more processing power and battery power. And it provides three methods for authenticating your peer. When it just works it's basically not authenticating your peer. So with this method you are like that can happen many in the middle attacks. But if you use the pass key entry or the out of band one it provides many in the middle protection. The pass key entry is basically you enter the same pass key on both devices and out of band is when you use another transport to do the authentication. So it could be over NFC so you just bring the two devices together and establish an NFC communication to exchange keys and do the security manager protocol. Or you could connect a cable between these two devices, something like that. And then we have the broadcaster and observer communication which as I said it's connection less. It's a unicast so the data is transferred from the broadcaster to the observer. It uses very small data packets so the whole advertising report if I recall correctly is 39 bytes long but you have the headers and all of that so you get about 27 bytes in the best case per report that you can use. So basically it can be used for some sensors like you could have a room temperature sensor or you could have advertisements like if you go to a shopping mall then there are some stores advertising discounts or this kind of things or transport information in a transport hub so which is the next car arriving or maybe artwork information you go and I'm using. These kind of small informations that are usually always the same so you just want to let people know what's happening in that place. There are no profiles defined by the Bluetooth SIG that use that information yet, that communication model yet. But there is room for you to have a manufacturer specific data in there so basically all the communications that use it now uses the manufacturer specific type of advertising report. So the protocols and profiles involved in Bluetooth flow energy. So basically this is the protocol stack. The great part in the bottom there is inside the hardware. Then the hardware provides a host controller interface for the host and the L2CAP protocol, it's the transport protocol used by Bluetooth. It's the same one as used by Classical Bluetooth. You can think of it as the TCP of Bluetooth. And then all the upper part in orange I think there. It's profiles and protocols that were defined specific for Bluetooth flow energy. So we have the attribute protocol on top of that the generic attribute profile and then the use specific use cases profiles are defined on top of the generic attribute profile. So I'll talk about each of these boxes now. So the attribute protocol, it's basically a protocol to allow discovery and read and write of attributes on a peer device. It works on a client server model. So the server have a bunch of attributes that the client can read, write and also the client can be notified about changes of the value of one attribute on the server side. Attributes are basically a pair of a handle, I'm sorry, it has a handle which is like an address and then it's a pair of a type and a value. So it's like, you can think of it as a, yeah, like a pair of two values. So and it works in this way because it was designed for small data transfers. So you can also save power when transferring data. You don't have to have your radio turned for a long time to be able to transfer data. So then on top of that we have the generic attribute profile which tries to organize this bunch of attributes a little bit. So the attributes are grouped into something called characteristics. A characteristic is basically it has a declaration attribute which says what is the UID of that characteristic and what is the access mode of that characteristic. So if you can read or read and write, it has a value attribute which has the value associated with the characteristic and it has, so those two are mandatory and it can also have some descriptors for configuration, for data format, for example, if you have a room temperature sensor and you, a descriptor would be easy to inform what's the unit of the temperature being measured if it's in Celsius or Fahrenheit. And the configuration is easy to be able to enable notifications of changes on that characteristic. So the client can use this descriptor to ask, okay so when the temperature changes please send me a notification. And then these characteristics are also grouped in a bigger group called services. So basically a gut service is a set of characteristics and then a characteristic is a set of attributes. So I have some little example to make it, try to make it a little bit clearer. So here we have a hypothetical gut server with three attributes there, handle 23, 24 and 25. So for the first handle the type it's 2800 which is a primary service declaration and then the value says what's that service that being declared there which here is link loss service which is part of the proximity profile. Then we have the first characteristic of that service on handle 24. So the type is 2803 that means it's a new characteristic being declared. So that's the declaration attribute I talked about before. And as I said it has the properties which is the access mode of the characteristic. So it's zero way that means you can read and you can write and get a response of your right request. And then it comes watch handle the value attribute for that characteristic is located. As you can see it's 0025. Then last we have the UID of that characteristic. So it's an alert level characteristic which is part of the specification of the link loss service. And finally on the handle 25 we have the UID of the alert level characteristic again. So it's 2806 and then the value of 2 which for those characteristics means a high alert level. Okay so one of the profiles that uses the link loss service is the proximity profile. So basically in this profile you have two rows a reporter and a monitor. And when they distance from each other the an alert is emitted on the reporter. So this alert level is configurable using that characteristic that I showed you before. And there are two different mechanisms to tell when the devices are far away from each other. One is link loss which is that service that I showed you. Basically the alert is emitted when the actual physical link between the two devices is lost. And the other one is path loss. In this with this service the reporter device also indicates what is its transmitting power. So the monitor monitors the RSSI level which is like the power that he is getting from on each packet. So then it can like infuse the distance between the two devices. And there's a configurable threshold where you can say oh when it goes over this distance even if the link is not lost let me know. So then the alert is emitted. Another profile defined by the Bluetooth 6 defined me profile. It's similar to the proximity profile but instead of relying on a distance being over a certain threshold it waits for some kind of user input. So you have the locator where you would have a button or something like this to tell okay let me know where the target is. So the locator writes on the alert level characteristic in the target and the target emits an alert level. And also the alert level can be configurable. We have the heart hate profile as well which is used for that heart hate belts or heart hate watches. So there are two roles a sensor and a collector. The sensor reads heart hate measurements and sends it over to the collectors, to the collector. This one example of characteristic notification. So basically the collector configures the sensor to enable notifications of changes on that characteristic. It also uses descriptors on the characteristic to specify the format of the heart hate value being sent over. There are some different formats that can be used. Also it indicates if the value contains a field called energy expended and the presence of the RR interval as well. So it's field specific to heart hate measurements. There is also another characteristic to provide the where in the body that sensor is used. And there is another characteristic to reset the energy expended field. So the collector would write on that characteristic to reset that. The health thermometer profile, it's similar to the heart hate profile. Basically there is a body thermometer that sends temperature measurements at periodic times. The head over gut profile, they basically encapsulated HID protocol inside heart protocol. So you have a characteristic where you can get notified about HID reports. So every time like a keyboard wants to send a HID report, it actually changes the value of the report characteristic. And since the host has configured notifications for that, it's notified of that value change. It also has a characteristic to store the HID descriptor so you can get that to configure your new input device. One advantage of this profile is because since we have much faster connection establishments with Bluetooth low energy, you don't have that feeling of, oh, my mouse is not working. Okay, now it's working. That usually happens with classical Bluetooth devices. If any of you had one, you know what I'm talking about. And yeah, we wrote the support for this profile at INDT. So we basically created a new kernel interface to be able to create HID drivers from user space. It's similar to UInput. It's called UHID. Maybe it can be used for other things as well. Another profile is the time profile which provides client server synchronization of time. So you have a time server and then your client talks to that server to synchronize the local time, the time zone information and the DST information. So if you are currently on DST and what's the offset, so there are some citizen and Casio watches that already have that. It's really cool. You just like come to your computer and then synchronize time. I don't know. I found it really cool. And what's the support of that on Linux currently? So the kernel support was enabled by default in Linux 3.5. If you're still running something older than that, probably from 3.3 something, there are module parameters to enable experimental support for Bluetooth energy, but I would not recommend you to do that. It would be much better if you can get the newer kernel. So for discovery procedures, we support both LE-only scan that can be triggered through the user space and also something that the specification calls interlimited scan, where you would do 5.12 seconds of low-energy scanning plus 5.12 seconds of BR&DR inquire. So this way you could mimic that you're doing both classical Bluetooth and low-energy Bluetooth operations in parallel, so you can find both kinds of devices. It works pretty well. On the connection procedures, we have support for the direct connection establishment procedure in the kernel. So basically you just create a new Bluetooth-learned socket and it shows a connection called to them, to it, and then it will send a connection request over to the address you passed. And we have the general connection establishment procedure implemented in user space inside Bluetooth D. So to be able to use that, you have to use Bluetooth D for your low-energy connections. Basically we keep a list of the device we are interested into, but the radio into scanning mode, filter that in user space, and so on. The auto-connection establishment procedure is not supported yet. We have plans to do so, but it's not done yet. Also, we added support for the security manager protocol inside the kernel, both for the just works and the pass key entry authentication methods. We don't have support for out-of-band authentication yet. If I'm not mistaken, there is some support for out-of-band over classical Bluetooth. I remember there were some patches, but I'm not completely sure if they made upstream or not, but I think so. So it shouldn't be much work to add out-of-band to Bluetooth low-energy, but as far as I know, nobody is working on that right now, if you're looking for something to do. On the profile support, we have support for all the profiles I said before, and also the cycling speed and cadence, which is basically the devices that you attach to a bicycle and that's cool, and we'll tell you the speed you're going by measuring wheel revolutions and these kind of things. Currently, we are working on a generic attribute profile API. We used it to have one, but when we changed it to BlueZ5, Marcel wasn't really happy about how that API worked, so we decided to just remove it completely and start over. So that's one thing we are doing at INDT. Actually, we have wrote the code for it already, and we presented it at the last wireless summit in New Orleans about a month ago. So now we are fixing some changes we have requested during the summit, and hopefully it will be upstream a month or something like this. Let's see how things go, and we are also working on implementing the generic connection establishment procedure inside the kernel. It's also like most of the code are written, but it's going under peer review right now on the mailing list, and when we finish that, we want to add support for using the harder white list for the automatic connection establishment procedure. So yeah, that's what I had for you today. So if you have any questions or anything? Yes? Alright, so the question, what's the status of Bluetooth Flow Energy in BlueZ4 and in BlueZ5, right? Okay, so for Bluetooth Flow Energy, basically we had support for Bluetooth Flow Energy since BlueZ4.99 I think. So if you use either 4.99, 4.100 or 4.101, you have the initial support we wrote, but then we continue to evolve it through the new versions of Bluetooth. So there is nothing specific in the Bluetooth Flow Energy area new because of the BlueZ5 change, but just the general API of BlueZ has changed basically. So for low energy, besides the code being more mature and all of that, that you would get if we didn't have changed the major version anyway. Did I answer your question? Okay. Okay, so if you want, feel free to come to talk to me afterwards or any day in the conference. I'll be here until Saturday, and you can also send me an email or find me on IRC. So that's it. Thank you very much.