 So, good afternoon everybody. So as Lisa said, I'm João Paulo. I work as a software engineer in the Bluetooth team at INDT. I've been working lately with the audio support for IVI related profiles, and also with Bluetooth Low Energy, which I'll talk about a little bit today. So INDT is a research institute which is founded by Nokia. We have four sites around Brazil. I work in the Recifi site on the far north-east in the OSS and user interaction area. Today I'll talk a little bit, a small introduction to Bluetooth Low Energy. I'll show you how devices discover and connect to each other. I'll talk a little bit about the protocols and profiles we have for Bluetooth Low Energy and what's the current support on Linux. So, does anybody here have no idea what Bluetooth is? I hope not. Okay. So just to remember the past, Bluetooth was designed to substitute cables when you're connecting, prefers to a central computer. So it was designed with short distances in mind. It provides a high levels of security and was created in 1994 by Ericsson. Later on in June 2010, the version 4.0 of the specification was adopted. It's focused on low power consumption. So it enables devices that are powered with coin cell batteries to communicate with Bluetooth. The aim is to have these devices, their battery lasting for a year to two years. So it has also faster connection establishments. This, the connection phase is one of the phases that consumes a lot of power in the Bluetooth communication. So they change at the radios a little bit. So the radios of the two devices synchronize faster. So they spend less time in the connection phase so they save power this way. So it provides a 200 kilobits data rate and a range of about 50 meters. And the radio is shared with classic Bluetooth. This is good because it reduces the hardware cost but also since the radio is shared, some operations cannot be done in parallel. For example, you cannot try to discover LED devices and classic Bluetooth devices at the same time because the radio parameters are a bit different for these two discoveries. The market they are aiming is mainly to conquer these three last markets there, fitness and wellness, medical devices and sensors and automation devices. And expanding their use over consumer electronics, PCs and mobile phones. You may have seen this branding using somewhere already. For Bluetooth low energy devices, they came up with these new names. So they're calling Bluetooth smart. The devices, the peripherals that uses Bluetooth low energy only. And Bluetooth smart ready, a central device that it's able to talk with Bluetooth smart devices. So it was a bit confusing in the beginning where they came up with these new names. But now mostly in the market they are selling devices using those brandings. Okay, so the discovery and connection of Bluetooth low energy devices. There is a profile that's used to specify how Bluetooth devices find each other and connect to each other. It's called a generic access profile. So it basically defines procedures for central devices to find the device they want to connect to and for the connection to be established. And it also defines how the security is involved in this process. The generic access profile defines four roles. The central and peripheral, which talk to each other in a connection oriented way. And broadcasting observer, which talk to each other in a connection less way. So when we are using the central and peripheral roles, the central role is the one that scan to find a lead devices around it. This scan can only find a lead devices. It's concurrent with BRDR inquire, which is how the BRDR device discovery is called. BRDR, it's the classical Bluetooth. And it has configurable parameters. So there is the interval between two scanning windows starts that can be configured and also the time that scanning is happening. So let's say we have an interval of five seconds and a scanning window of two seconds, then the hardware is going to be scanning for two seconds and then on the next three seconds of the interval, it's gonna be off. And then after that three seconds is gonna start another scanning window. If you want it to scan continuously, you just give a window and interval of the same size. And the peripheral can indicate its presence, broadcasting some small data packets, which we call advertising reports. So advertising reports are used for the peripherals to indicate their presence. And also they let the central device know what's the connection mode they are. There are four different connection modes. The device can be in the connectable undirected mode where it shall accept a connection request coming from a central device. The connectable directed mode where it shall accept a connection request coming from a non-peer device. So the connectable directed has a MAC address associated with it. There is the scanable undirected where the device shall not accept an incoming connection request from a peer device, but it shall respond scan requests with scan responses. So scan request is a data packet where the central device requests more information about the peripheral device. And the last one is the non-connectable undirected where it shall not accept incoming connections neither answer scan requests. After the devices find each other, they can start a connection establishment procedure. There are three different connection establishment procedures defined in the specification. The direct connection establishment procedure, it's basically you just send a connection request message to the peripheral device and then the peripheral answered that request. The general and the auto connection establishment procedures they are used for either automatic connections or reconnections. So you have a list where you put the device you're interested to connect to in and then the system starts scanning and when one of these devices entering range it sends the connection request package to it. The difference between the general and the auto connections is that in the general connection all device found events are sent to the host and the host has to check if that device is one of the devices he's interested in and send the connection commands. On the auto connection establishment procedure all of this is done inside the hardware. So the filtering is done by the hardware firmware and the host is only awake when the connection establishment is established. On the security side we have the security manager protocol which is used to do all the security negotiation off the stream encryption. It provides payload encryption and payload authentication. All the security manager protocol calculations are mostly done in the central device which usually has a better hardware and has more power available. So you can have savings on the peripheral device. Also it supports hardware module, hardware encryption modules. So on the peripheral it can be done in hardware to save power as well. And there are three authentication methods that can be used for pure authentication. The just works method. It doesn't provide man in the middle protection. The pass key entry method and the out of band method provides man in the middle protection. So the pass key entry you enter pass key, the same pass key on both sides, on both devices. And the out of band use another channel to authenticate the pure device. That could be over NFC or over a cable. So that defines also the broadcaster and observer roles which are mainly used for connection less undirected data transfers. So it's always small data that is transferred. Generally you can do something around 27 bytes per advertising report you can send. Could be a little more of that if there is some profile that is defined by the Bluetooth CIG, but at the moment no profile is defined. So mainly it's used for manufacturer specific use cases. So some of the use cases that can be covered with this roles are when you have a sensor, like for example a room temperature sensor advertising the room temperature. So any observer device could get this information. Also for information advertisement in transport hubs or shopping malls advertising discounts, this kind of things. So now I'm gonna show you the protocol stack and profiles that are defined for the central peripheral role. So this is the basic Bluetooth energy profile stack. Everything that's on white there on the bottom is inside the hardware. On top of that there is the host controller interface which is implemented by the hardware firmware and provide it's a well-defined interface that all Bluetooth adapters has to implement to be compliant with the Bluetooth stack. And then we have the L2CAP protocol which is the transport protocol for Bluetooth. It's shared with classic Bluetooth. It basically provides the same features as the TCP provides on the TCP stack. And on top of that, all of them were defined together with the Bluetooth 4.0 specification. So the attribute protocol. Then on top of, I'll talk about them individually later on. So each of them provide services for the upper layers. So the attribute protocol is a protocol designed with small data transfers in mind. It works in a client server model so the client can read, write, and be notified of changes of values in attributes on the server side. So attributes are basically a pair of a type and a value. So you have a well-defined types for these attributes with UIDs assigned by the Bluetooth sig. And on the attributes database on the server, each attribute has a handle which is used to address those attributes. Then the attribute protocol is used by the generic attribute profile which tries to organize these attributes in the database. So the attributes are basically grouped in something bigger called characteristics. So the characteristics has a declaration attribute which has the UID of that characteristic and also access control modes for that characteristic. It has a value attribute with the value related to that characteristic that is stored. And it could have one or more descriptors describing the data on that characteristic or some other, it's like metadata about that main data. So for example, it could be used to specify what units are used in some kind of measurement provided in the characteristic and this kind of things. And also characteristics are then grouped in bigger sets called services. So basically a service is a group of characteristics that is defined in a specification. So to make it more concrete, I brought an example here. So on the first line, we have first the handle which will be the address of that attribute, 0023. Then the type it's 2800 which is the UIG for primary services, so it's a service declaration here and the service we are declaring here, it's a link loss service which the UIG is 1803. On the second line, there's the first characteristic of the link loss service on the handle 24. So the UIG is 2803 which is a characteristic declaration and the characteristic declaration has their value well-defined. So the first byte indicates the properties of the characteristic which says how can you access that characteristic? So for this characteristic specifically, we can read the value and we can write and get a response from that right. So the attribute protocol provides two types of writing mechanisms, one with a response and one without a response. So this characteristic supports only the right with response method. So the next two bytes of the characteristic declaration indicates the address of the value attribute of that characteristic which here is on the handle 25. And the last two bytes indicates the UIG of that characteristic. So here it's 2A06 which is an alert level characteristic which is one of the characteristics that's part of the link loss service. And finally, on the third line we have handle 25 with the value of that characteristic. So the UIG is 2A06 which indicates the alert level characteristic again and the value is two that for this characteristic means alert level high. This is basically how every got service is grouped and defined. So some of the profiles that are defined by the blue to see at the moment. One of them is the proximity profile where you have two roles involved. One is the proximity reporter and the other is the proximity monitor. So when this two devices distance from each other and alert is emitted on the reporter side, the alert level is configurable. It's exactly the characteristics I showed you before. So you write on that characteristic to say what level of alert you wanna hear. And there are two mechanisms defined to tell this difference. One of them is the link loss which is exposed through the link loss service I have showed you before. So basically with this mechanism when the link is actually down, the alert is emitted. And the other one is path loss. With the path loss method, there is a calculation based on the transmission power between the two devices and the transmission power in the origin and the signal strength in the receiving side so they can estimate the distance between them and when it goes under a certain threshold, the alert is emitted and the threshold is configurable. So another service is the find me profile. It's very similar to the proximity one but instead of relying on the distance to emit an alert, you rely on user interaction. It also has an alert level characteristic and when one of the sides writes a value on that alert level characteristic, the alert is emitted on the receiving side. So it can be used for you to find something you lost like your keys or something like this and you have your phone and you can send a comment on your phone for your keys to emit an alert. The alert level is also configurable. There's a profile for heart-hate devices as well. So there is the heart-hate sensor which is the belt for measuring heart-hates and the collectors decide that receive the heart-hate measurements. Besides the heart-hate information itself, there can be the energy expanded field which is basically a counter of how much energy you have spent from a certain point of time and the RR interval which is the time between two heart-hates and all of, if this data are sent or not with the measurement, it can be configured by the collector side. So that's one example of how descriptors can be used. There's a descriptor which can be written to configure the actual data coming out of the sensor. So there's also another characteristic that provides body sensor location and the energy expanded counting can be reset by the collector writing on a different characteristic. The health thermometer profile is very similar to the heart-hate profile. Basically there is a body thermometer which sends the body temperature at periodic intervals. This interval can be configured. There's a profile for encapsulating HID protocol inside of attributes which is used for human interface devices with low energy consumption. Basically there is a characteristic for the heat report and every time a new heat report wants to be sent the value of that characteristic changes. So a notification of that change is sent to the host and then the host can read the characteristic. And also there is a descriptor which stores the, I'm sorry, yeah, the descriptor which stores the HID descriptor. A characteristic that starts the HID descriptor. It's called report map. So it's basically you can obtain all this information through GAT and inject it on your regular HID subsystem. The time profile is used for time synchronization. The client synchronizes its time information with a server. It provides local time information, time zone information and DST offset, the current DST offset. All right and the current status of the support on Linux. Bluetooth flow energy is enabled by default in the kernel from the kernel 3.5 for older kernels. There was a parameter, a module parameter called enable LE. So if you are using an older kernel and wanna check if there is the experimental support for Bluetooth flow energy can look for this module. I recommend if you wanna really use Bluetooth flow energy get a kernel, a recent kernel. For device discovery, we support LE only scanning and also I think called interleaved discovery which is a subjection of the spec for doing Bluetooth flow energy scanning for five dot 12 seconds and then doing BRNDR inquiring for the next five dot 12 seconds. So this way you can look for both kinds of devices in a short time slot. On the connection front, we support the direct connection establishment procedure in the kernel. So basically you have an L2CAP socket where you can issue a connect system call and it will send a connect request to the remote device. We also have the general connection establishment procedure implemented in user space inside the Bluetooth demo. And right now it's only used for profiles that require automatic reconnections. And the automatic connection procedure is not supported at all at the moment. The security manager protocol is supported and we supported the just works and the pesky entry authentication methods. We support all the profiles I talked about before for the proximity. For the proximity, we don't support the path loss service. We just support the link loss service. Support the find me profile, the hard hate profile, health thermometer, heat over GATS time. And also the cycling speed and cadence profile which is used to send speeding information from the bicycle speedometers for your phone or something like this. And at the moment we are working on a GATS API. GATS is the generic attribute profile. So you can have the buzz API to be able to implement your own profiles outside of Bluetooth D, be them Bluetooth C specified profiles or manufacturer specific profiles. And also we are working on moving the general connection establishment procedure inside the kernel. So we are defining the APIs for that and writing this code. When we finish this move, the idea is to try to use the white list in the Bluetooth adapters to save power on the central side as well in the connections. Okay, so that's what I had for you today. If you have any questions, can you use the microphone please? What about profile support from the user space like BlueZ, do you need to support the corresponding protocol? Like you have, this you're talking about kernel, right? No, but also the user space demo is where the profiles are implemented. Yes, so is it implemented in BlueZ or BlueSolil or what is it? It's implemented in BlueZ, the Bluetooth D. What about the new Android Bluetooth? You better ask the Android guys about that. Anyone else with questions? Comments maybe?