Hello, I'm Parth and I lead Mobile Storage Infra on Android for Meta's products. Today, I'm here to share the journey I went through while working in the R& D department at SAP Labs India. The topic is regarding the solution we built for crisis management during COVID using contact tracing to identify, notify, and support SAP employees. Who might be at risk of infection. So what is contact tracing? Contact tracing is the method of identifying and managing people who may have been exposed to a contagious disease. During 2020 and 2021, this was a big problem for businesses. If even a single employee was exposed to COVID, it could infect everyone and anyone else who might be in the vicinity. Contact tracing involves identifying people who might be infectious, Notifying them to quarantine themselves, notifying others who may have come into contact with this person, and then monitoring and providing support and treatment. During 2020 and early 2021, as businesses were slowly opening up, keeping a track of employees who might be exposed to COVID became a major issue. A single person could end up infecting everyone else on campus and cause a complete shutdown of operations. SAP had a manual signup sheet for tracking employees who are visiting office. If someone called in sick, staff would go through the sheet, figure out everyone else who has come into contact and call them to get tested or quarantine themselves. It was a lot of manual effort and notifying employees took a couple of days. during which the infection could spread even more and this process was not scalable. This also introduced a lot of false positives as employees who might be on opposite sides of the campus would also be part of the same signup sheet. From a business perspective, SAP wanted automation to reduce manual effort and delay and they wanted to minimize cost, especially of hardware, as they believe COVID to be temporary. We realized the best way forward would be to use smartphones already on employees. Everyone had a phone that they carry with them everywhere, and no one would share their phones with each other, especially at office. We looked into possible solutions, and the tech we came to use was to use Bluetooth low energy or BLE. BLE as its name suggests, consumes low energy from the device. It provides a lightweight signal that does not have extremely high range, which is perfect for contact tracing. And it can be used to send small amounts of data between devices. BLE technology exists on both Android and iOS, and it provides a framework called Generic Attribute Profile, or GATT for short. GATT can be used to send and receive short pieces of data known as attributes over a BLE link. Device A can act as a server, also called an advertiser, and that broadcasts a unique ID called a scan record. This ID Is of the service itself, the contact tracing service device B will scan for all nearby advertisers. It will collect all the devices which have this unique ID, connect to them, and then read a scan response. And the scan response can have an another ID that can be used to uniquely identify the device or the user. So every device will act as. An advertiser and a scanner and basically will be responsible of sending data of all other nearby devices that we discovered. Now let's get to the limitations of this technology. On Android, multiple clients can connect to a single server, but as soon as a client tries to connect to a second server, the first connection is terminated. This, since connections are asynchronous, we will have to queue them, and this can result to potential loss of nearby devices. But, Android can broadcast two IDs as part of the scan record. Even when the app is backgrounded or screen is locked and the scan response will also work properly when the app is backgrounded or screen is locked. On iOS, it's a little different. The scanner API can queue connections, so we don't need to queue them ourselves, but it can only broadcast a single ID for a service. Also, when the app is backgrounded, the scan response will return a null value, making it impossible to identify the device. The basis of our contact tracing solution is that each device tells our internal servers what other device it came into contact with. This helps us build basically a graph of employees and then notify them of potential infections. Our architecture uses three independent methods of tracing. Android to Android is done using only the advertiser and the scanner. The advertiser will broadcast two IDs. One for the service and the other, which represents the device or the user, the scanner will then scan these IDs, recognize that it is part of the contact tracing service, and then register the second ID as the other device or the other user, the Android device will then communicate to our internal servers in regular intervals with all the devices it came into contact with. An example would be if A, B, and C are Android devices and A is the scanner. It finds B and C and then it'll send an edge from A to B and A to C to our servers. iOS tracing is done using GAT server and client. Every iOS device will advertise the same ID to all other iOS devices. And all of the iOS devices will scan this record that contains a temporary MAC address of the Gatsby server. Now, it will use this temporary MAC address, connect to these devices, read a property called a characteristic, which contains the device identifier and the response. And same as Android, iOS devices will upload all of these edges to our internal servers at regular intervals. So if X, Y, and Z are three iOS devices, There'll be an edge saying X to Y and X to Z from X to our servers. This means now with these two individual architectures running, we have Android devices, which can identify all other Android devices and iOS devices, which can identify all other iOS devices. When it comes to iOS to Android or Android to iOS detection, the tracing is done by the iOS device. Each Android device will also run a GAT server, which the iOS device will connect to. Similar to how it does with iOS GAT servers. It will connect to it and it will read the scan response from the Android device. If for example, X is an iOS device and A is an Android device, the iOS device is responsible for both edges. Only in the case of Android to iOS detection. This removes the limitation that iOS devices cannot send a separate scan response while running in the background, as well as the limitation that Android GATT clients can't queue. The results spoke for themselves. The architecture resolved platform limitations. We had 7, 000 plus employees install and use the app, and they used it to visit the office. We also use geo fencing to ensure the app does not run in the background when employees are not at work. So that we do not invade their privacy. Other technologies that we looked into are Wi Fi, RFID, NFC, and normal Bluetooth. Wi Fi had a significantly higher battery drain, and it was a little more complicated to work with than Bluetooth low energy, especially on iOS. RFID would require higher hardware investment and NFC had the issue of low range. Traditional Bluetooth had changed their APIs so that the MAC address being broadcasted by the Bluetooth device is a temporary MAC address. This was done so that advertising companies and malls do not uniquely identify devices or users based on their Bluetooth MAC address. But because of this change, we couldn't use them for the same thing, identifying users based on the MAC address. So we had to go with Bluetooth low energy because of these limitations on other technologies. We have a patent for this as part of SAP and it's published on Google Scholar. If anyone is interested, please reach out to me and I can send more details. That's all for my presentation and thank you for your time. Have a good rest of the conference.