 Today, hope you all are doing fine. Let us dive into the topic of differentiating Bluetooth low energy product by exploiting and exploring the features in Zephyr Bluetooth low energy controller. My name is Vinayak and I'm a Principal Research and Development Engineer with Nordic Semiconductor. My primary responsibility has been as co-owner and maintainer of open source Bluetooth low energy controller implementation in Zephyr project. So let's see what we will cover in today's session. We have a brief introduction to Bluetooth technology about some of the stable features in Zephyr Bluetooth low energy controller over the years, introducing the availability of direction finding feature, introducing the availability of isochronous channels feature, walkthrough of architectural challenges and changes in the controller to meet new features and let's do some profile of the broadcast and connected iso samples and in the end we can have a Q&A session. Okay, what is Bluetooth? Bluetooth wireless technology is a short range communication system intended to replace the cables connecting portable and fixed electronic devices. It uses frequency hopping spread spectrum and on the 2.4 gigahertz ISM band. I would like to state a fun fact about myself, how I got introduced to Bluetooth. There was this contract role that I had to interview for. The day before the interview for contract role, this was early in my career. I had quickly read about Bluetooth and this is how I tried to explain it. I assume I had to listen to music on an FM receiver set and the music were part where parts of it were transmitted over a range of frequencies and I had to constantly quickly tune my receiver to these changing frequencies. So basically the music was in small parts, transmitted in different frequencies and I knew the pattern are the next frequencies that I need to tune into. So that's how if you can put it like the frequency hopping. So this is what as a very simple way Bluetooth operates by sending small packets at different frequencies. The classic Bluetooth had 80 radio frequencies and radio channels. Low energy uses 40 of which three are used for advertising their indexed 37, 38 and 39. And these three are spread in the 2.4 gigahertz band subset. They don't interfere or even if one of the channel interferes, the other two are placed apart and would mitigate any collisions when there are advertising of Bluetooth packets. The most popular solution areas which Bluetooth technology covers is like in the case of the phone and have any sensors or watch and it's the sensor that are transferred. It's also used for audio streaming, location services, it could be detection of a device, proximity of a device, direction of a device are also distance. Something that is more popular these days is also mesh network like lighting systems and such sensor networks which need to cover substantial area. As of today, there are billions of products shipped. You can see that when you buy a product or something that uses Bluetooth technology, you would see the Bluetooth logo on it. Also device communication is either point to point. Broadcast to many in proximity, form a mesh spanning vast area, increasing the reach. Device positioning can be simple. It could be like presence detection or proximity, proximity may use received signal strength indication. In this case, you could have alerts like low, medium, high based on how close or far attack a sensor is from your phone or a display unit or something like that. You can have a bit more like direction estimation involving some calculations of the angle of the received signals. Bluetooth also supports distance measurements. If you're interested more about details of Bluetooth technology, states like broadcast, observer and roles like central and peripheral. You can look up my other presentation some years back. It has an animation of how devices advertised, be scanned for and connections be established, etc. Also, it covers some details of the existing architecture and implementation of the then controller in Zafir project. What can you exploit today in Zafir project? First implementation in Zafir project is version 5.3 compliant. The implementation is highly configurable in supported features in your end product. You can configure the buffer sizes, number of buffers used, etc. It's portable to all architecture supported by the Zafir project and your builds can support host and controller configurations. In this case, this is a combined build where you have the controller and the application in a single firmware. You could build HCI controller only and use HCI transport between the two CPUs. In this case, it's actually multi-CPU build. The host is on one CPU and the controller implementation on the other CPU. Zafir project supports a full Bluetooth host and also supports mesh stack in the Zafir project. Product use cases. Some end products that are and be designed effortlessly in Zafir project using the vast number of samples are beacons, Eddystone, proximity tags, heart rate monitors, health thermometers, human interface devices like keyboard, mouse, remote controls, sports watches that can store and transfer vital health data and like your heart rate and pulse and stuff like that, they could use Bluetooth to transfer to your phone or to your PC. Like equipments, bike computers, which also can store and send information and then be transferred on to PC or mobile phones, activity trackers like step counters, etc. Okay, let's explore Bluetooth low energy controller. What's new in the controller? We now have support for long range. This again depends on the SOCE vendor, whether they support code at five. So there is now possibility of transmitting Bluetooth packets over a kilometer range. This is also dependent on advertising extensions, advertising extensions also provide periodic advertising, in which case the advertisement packets at regular interval to which receiver can synchronize instead of having a larger scan windows to receive normal legacy advertisements. In advertising extensions, there are very short legacy extended advertising previews on the primary advertising channel, which is the 37, 38, 39. If you have a lot of devices advertising, it's always better to have smaller packets. In that case, the probability of collision is low. So these primary channel advertising videos point to larger 255 byte advertising videos and these can be chained to have a total of 1,650 bytes. So advertising extensions provides both longer advertising data that can be transmitted, advertising data that can be transmitted periodically and with the mitigation that there is less collisions while devices are transmitting on the advertising channels. There is the support for angle of arrival and angle of departure. This is the direction finding feature. Again depends on the SOCE vendor, whether their radios support the constant tone extensions. So these are the extensions to the Bluetooth and its PDUs. They contain the direction information and help in finding out the angle of the devices around you. With the introduction of low energy audio, the controller has implementation now for Isochronous channels, both broadcast Isochronous and connected Isochronous channels. Broadcast Isochronous channel is a feature that is required for Bluetooth or a cast. The connected Isochronous channels are used mostly for audio streaming and for call audio between the phone and the earbuds. Also these Isochronous channels can be multiple streams and each stream could be to two different devices like two earbuds, one left and right and Isochronous channels have features that help you synchronize between the left and right earbuds. Direction finding feature, a low energy device can make its direction available for a peer device by transmitting direction finding enabled packets. So as you can see here, you can have a device with an antenna that's transmitting packets like containing the direction information and you can have receiving devices which can either be connected to the transmitting device and transmit information to the connecting device that indicate their positions, locations in a room, etc. So you could have multiple receiving devices that receive transmissions and the receiving device can have antennas that detect the angle of reception of the packet from the transmitter. The receivers can have a connection with the transmitter and let them know at what angle they have received the packet and where these receivers are placed that way the transmitting device can be able to calculate its own position relative to these transmitters. It's also possible that one of the receiver here is having multiple antenna and this alone can also show the direction towards the transmitting direction to the transmitting device. There are two ways, two methods in the direction finding feature. One is the angle of arrival. In this method, the device transmits direction finding enabled packets using a single antenna. So it's like a tag that has a single antenna but it's transmitting direction information. The other method is angle of departure. In this case, the transmitting device compared to the previously the receiving device that had the antenna array and RF switch. Here the transmitting device has the RX RF switch and multiple antenna and is transmitting the packets with the direction information while switching the antenna being used for the transmissions. At the receiver side, there is a single antenna and the receiving device now receives these different direction information transmitted over these different antennas. With this information in the reception of these videos, it's then able to calculate the angle of the arriving radio signals. Some product use cases of direction finding, asset management, account and keep track of critical resources in an establishment facility. Indoor navigation and positioning say have a map on your phone when inside a mall, a shopping center, maybe locating facilities or labs inside a hospital, etc. Proximity marketing, so sending discounts and promotions when a customer is around or positioned near a purchase. Point of interest information, facilities in airports, information, details of items in museums and tourist attractions. Personal tracking like have, persons can have a badge or a tag and they could be tracked inside an establishment for safety reasons and access control. There's also the personal item finding, you could have a keychains, bags, with tags and direction finding features can be used to locate them. Also, building an automotive access control, entry and exit to facilities and unlocking of cars and vehicles, etc. Another new feature available in Zephyr Bluetooth Low Energy Controller implementation is broadcast isochronous channels. The isochronous broadcast allows two or more devices to communicate in a unidirectional connectionless manner by using external advertising events, periodic advertising events and big and miss events. This can be clear text or encrypted between the two devices. Here we have an overview of broadcast isochronous group event. Every big event is identified by a preceding periodic advertising OXsync and PDU which contains a structure called the Big Info. Big Info structure contains the big offset which is used by the controller to listen to big event and synchronize to the ISO interval of the broadcast ISO instance. What is new compared to normal ACL connection events or advertising events is the introduction of something called the sub events. Transmission on each sub event is on different radio channel. This provides frequency diversity. Each big event consists of a number of sub events where we have transmission, pre-transmission and pre-transmissions. Pre-transmission provides the time diversity along with frequency diversity. Product use cases for broadcast ISO. Synchronized data transfer or playback over large collection of devices placed apart in a location. Personal audio sharing multiple earbud pairs listening to same media. Hearing a tune to audio sources in theater, conferences, lecture halls and airports. A connected isochronous is a data symmetric or data symmetric point to point logical transport between the central and specific peripheral. Here you can see a phone and the phone establishes a biorectional connection with the left earbud. And also a phone establishes a connection with the right earbud. In this case both earbuds could have audio sync which is a speaker and both could be having a microphone. So the data transfer or ISO data is transferred biorectional from the phone. The phone has a choice to record both the mics and probably apply an algorithm or any intelligence as required. The other diagram here details how the phone establishes an ACL connection thereafter a SIS within a SIG and then a second ACL connection and then the placement of the second stream, characterize a common stream within the group. Centrals can also have more than two streams and ACLs. Each group can have up to 31 streams and the limit on the streams would be dependent on the available RAM and code space on a vendor SOC. This is a detailed illustration of the connected isochronous group event. A SIG event consists of multiple SIS events. SIS reserves transmission reception periods known as sub events. Each sub event is spaced by sub interval space. Transmission and reception happen on the same physical channel and two different sub events use different physical channels. This provides the frequency diversity. SIS supports variable flushing periods for payloads, variable size data contents and a variable number of sub events following a range of isochronous data rates, latencies and retransmissions. Retransmissions are realized by using sub events per SIS. Let's list down some broadcast ISO and connected ISO use cases, basically audio use cases, basic California like receiving call, rejecting, muting and muting when you are in a call, low latency audio from TV. So you could have a television with multiple audiences around and each one could listen into different languages from the television and more number of listeners in a large area. So like in a setup or in a club or an auditorium where multiple users can listen to the speech, broadcast audio in public spaces like airports and museums, time synchronized sensor ecosystems. Typical use case of early isochronous channels is early audio. Details of early audio support specifically in Zephyr project can be found in a prior presentation. This was done in the Zephyr developer summit. Now let's dive into implementation architecture of the Zephyr Bluetooth Low Energy Controller. Here you see the various execution contexts, app, host, upper link layer, lower link layer, hardware, basically timers, radio hardware, interrupt manager, etc. The controller at the top level is split into the upper and the lower link layer. Lower link layer is mostly bare metal. Upper is implemented as threads or low priority ISR or tasklets. The lower link layer are usually implemented by radio vendors and utilities that vendors provide like hall and low level implementations. Here we have a much detailed block of the controller architecture and illustrates the ISO data send data flow. ISO data is enqueued in the thread context of the host entity using mem queue data structure. So this is the host and this is the link layer interface in the thread context. Once enqueued in the thread context, it is directly dequeued in the lower link layer. This is different from the ACL connection where enqueued ACL data is processed in the upper link layer in the ISR context on a tasklet because for the ACL there could be control procedures that will have to be enqueued in the same pipe towards the packet controller or the radio hardware. In the case of ISO, the enqueued ISO data is directly processed by the packet controller or the lower link layer radio interface since there is no concept of like multiplexing the control PDUs along in the same radio transmission for the ISO. In the return path, the acknowledgments are sent back to the pre-thread context to be processed. This is now a detailed illustration of ISO data received data flow. Free ISO RX data buffers reside in a pool in the thread execution context and are populated or enqueued into a free RX packet queue. The lower link layer will dequeue these free RX buffers to be made available to the radio hardware and then the radio hardware will receive ISO data from the peer. On reception of the ISO PDUs these valid are invalid PDUs. I say invalid because there is possibility that at a particular interval there is collision or there wasn't sufficient audio data transmitted by the peer in which case the controller will mark it as invalid but still generate an event PDU event marking its status as invalid. If audio packet has been sourced then in that case the status will be set to true and along with timestamp or enqueued towards the HCI thread to be there after copied into the host of other processing by the application. Mostly if it is audio encoded data then be decoded and then presented out to the user. Okay maybe it's enough of all the talking and theory. Let's do something fun and take a look at how the broadcast and connected ISO appear in a Power Profiler. Let us now take a look at how our broadcast and ISO channels appear on Power Profiling on our upstream samples. For this let us use the Power Profiler Kit made by Nordic Semiconductor. So this is basically a profile view and top view of how the kit looks like. The Power Profiler Kit is a standalone unit as you can see here which can measure and optionally supply current all the way from sub microampere as I have one ampere to all Nordic development kits. In addition can also be used with external hardware. Customers can have their own custom boards and they can supply voltage from this kit or only measure like the current consumed consumed by the custom PCBs. So what you see here is a typical ISO broadcast Power Profiler. This is what you obtain when you have flashed the ISO broadcast sample on a 50 to 833 development kit. In the green you see the advertising extensions. So the extended advertiser uses advextin PDUs which have an aux offset that point to an aux PDU in the future. In this profile you are seeing the profile of an aux PDU before the aux ad win. That's because there has been one advextin before it that points to this and there would be a periodic advertising PDU which is not visible in this profile here but it is something that would precede the big event. So here there is the big event and each big event has a ISO interval of 10 milliseconds. Between the big events and if there is no periodic advertising or external advertising PDUs then the CPU remains idle and it's in like in 10 lower than 10 microampere in the case of the 50 to 833 development kit. Now what you see is a Power Profile of the ISO receive sample from the time it was powered on. So when the chip was powered on it starts with scanning. So there is the scan window here you can see the power consumption of the scan window and a scan interval. So there are these peaks that is the scan window and then the next peak is based on the scan interval apart. So sample user 60 millisecond interval at 30 millisecond scan window. It receives advertising extension PDU here ad report. In the ad report there would be details of the periodic advertising hence it will try to synchronize to the periodic advertising. This is a place where the periodic advertising is synchronized. In the periodic advertising there will be the big info providing the big offset to the big event. So they offset to the big events where the ISO receive sample is supposed to synchronize with. So you will see that once the periodic report is received after 1.2 second which is a periodic interval. The ISO receives synchronizes with the big events and then you will see the peaks of the big events to which it is synchronized to. In the next slide of the ISO receive power profile which is nothing but a zoom in of the big events what you see here is the big event which contains two broadcast ISO streams 1 and 2 that have been synchronized to. These peaks are the receive current consumption. So broadcaster has been transmitting big events with two streams in it and the synchronizer has synchronized to it. The ISO interval is 10 milliseconds so every 10 milliseconds you would see a similar power profile where the radio event is being prepared and receives the two ISO streams. Now let's take a look at the peripheral ISO. This is the corrected ISO use case. The peripheral ISO sample starts with advertising. So these are the current consumption when the advertising PDUs are transmitted. There is a central ISO sample in the vicinity that is scanning for it and when it finds the advertising PDU it establishes a connection. When it has established a connection there is some amount of CPU running in parallel. Some control procedures that happen in the ACL connection and one of these control procedure is to establish the assist. So at this point where you see a lot more peaks over here these are the SIG events that have been established with the central ISO sample. So as the peripheral starts with advertising gets connected as a control procedure where in the create SIS request is received and accepted and a SIS in PDU with an offset SIS offset would say where the peripheral should synchronize with the central SIS PDUs. Here you see a zoom in version of the previous power profile of the peripheral ISO. In this case we have zoomed into where the SIS is established. So to start with there is the ACL connection, the reception by the peripheral and then the peripheral transmits back on the ACL. At the instant where which was mentioned in the SIS in PDU which contains the offset the peripheral would then synchronize with the SIG event and every 10 millisecond it would be synchronized with the SIG events and these are the events where the peripheral would receive the ISO data and have an opportunity to transmit back ISO data towards the central. Now let us take a look at the central ISO power profile. Central starts with scanning as you might have seen in the previous slides for the peripheral it starts with advertising. The central scans for the advertising PDU and establish a connection here. I have mentioned CPU here because when it has established a connection there is some amount of CPU being used to perform gap procedures like discovery etc. So the peaks continue here which are the ACL connections and there will be at some point here the SIS create control procedure where the SIS request and SIS response from the peripheral received and then a SIG PDU is sent from the central and at the instant the central starts scheduling the SIG events. Here this is rather a zoom in version of the previous slide where the central ACL connection already established is shown here and the instant at which the SIS is created. So with the SIS offset from the ACL connection the central implementation schedules the SIG events. Each of these SIG events are 10 second apart and in these events is where the central ISO would send the ISO data and receive ISO data from the peripheral. Let us summarize in simple points this presentation. The ZFA project has fully open source Bluetooth version 5.3 compliant host and controller. The controller, host stack, mesh stack, early audio stack, services and profiles all are open source. These implementations are portable to multiple architectures that is supported in ZFA RATOS. Contributions are by the community and we have a very active developer interaction in interest groups, meetings, mailing lists and chat over Discord channels. Implementation changes continuously tested on pull request in CI using physical layer simulations. Frequent conformance testing by ZFA project members. Best part being the numerous samples very close to product use cases. Thank you.