Building the World's Largest Bluetooth Location Finding NetworkFeatured
Let me provide a quick overview of the functionality you get with Tiles in case you aren’t familiar. Our users attach Tiles to items of value to them. From the Tile mobile app, you can ring your Tile if it’s in Bluetooth range of your phone or view a map with the last known location of your Tile. The Tile mobile app is also doing a background community find of any Tiles in the area and sending anonymous location updates to the Tile server. You can also click on your Tile and have it ring your phone in case you lose your phone.The image below is a graphic of our current Tile network. Every user is passively updating the location of other Tiles through the phone app. Every day we get over 1 billion location updates and we are finding 5.5 million things. Now that I’ve provided an overview of Tile’s functionalities, let’s dive into the Tile architecture. Tile’s use Bluetooth low energy (BLE) to advertise and can be in one of three states: shipping, advertising, or connected. When the user goes through the onboarding flow in the Tile mobile app, we ask the user to press the Tile button which starts advertising in shipping mode. The phone detects the Tile advertising in shipping mode, and completes the activation process, which puts the Tile into advertising mode. The Tile is now advertising every 2 seconds until a mobile app connects to it. The Tile mobile app is listening for this advertisement, and when it sees a Tile, the app connects to the Tile over BLE to retrieve its Tile ID. After the Tile and the app authenticate, the app will send a location update to our backend Tile Services API.In our current architecture, the phone stays connected to the Tile. This reduces the time required to ring the device. However, as we are moving into a world where a user may have multiple devices scanning for their Tiles (for example a Comcast Access Point and their phone) we want to move toward a connectionless model where we only connect to the Tile to ring it. This also helps with conflicts with other Bluetooth accessories. Let’s now dive a little deeper into how our Bluetooth communication works. Instead of using BLE directly via its existing protocol called GATT, we’ve created our own transport layer on top of GATT called Tile Over the Air or TOA. TOA allows for communication between a phone and a Tile (or between an access point an a Tile). We created our own transport layer to be able to have security and do the authentication between the phone and the Tile device. TOA utilizes two existing GATT characteristics for sending and receiving data via a client-server communication pattern. TOA commands are sent to the server (the Tile) using GATT Write without Response. TOA responses are sent to the client (the phone) using GATT Notify. Below is a diagram that shows the interactions between a phone and a Tile to read the Tile ID and authenticate. Now I’d like to explore our backend Tile Services infrastructure. Tile Services has a standard 3-tier web API architecture hosted on AWS. First we’ve got a load balancer layer using both Application Load Balancers and Elastic Load Balancers to balance our traffic across our EC2 boxes hosting our application servers. In the second layer, we have split our APIs into different services. Our Location service is our highest volume service and handles over 1 billion location updates a day. It has much different scaling needs than our much lower volume services. Our API service handles all the APIs for user and tile management. The reTile servers handle our reTile program which allows users to buy Tiles at a discount when their batteries run out. We also have a set of services to handle our Alexa and Google Home voice integrations. Finally, we have an event service that processes all the events generated by our mobile apps for analytics tracking. The third and final layer is our storage layer. Different data is stored in different places. Our location data is stored in redis with location history being on the Aurora DB. We recently moved the rest of our data from an NDB Oracle database to a more standard RDS MySQL solution on AWS. Now that I’ve described our current Tile architecture, I’ll share our plans for the future. Below is a diagram of our vision for the future of Tile. Instead of depending on phones alone to give location updates, we’ll also expect Access Points to provide location data. On top of our own physical Tiles, we are also looking to embed the Tile functionality into the 5 billion bluetooth devices sold this year, including headphones and laptops. This would mean that we’d scale from 20 million Tiles today to 100s of millions of devices providing trillions of location updates.I hope you’ve enjoyed learning about the Tile technology. Feel free to reach out if you have any questions or are interested in learning more! Jossie Haines has worked in the tech industry for 20 years and is currently the Platform Engineering Director at Tile where she integrates the Tile technology into the 5 billion bluetooth devices sold this year. She is also an advocate for women in the tech industry and has mentored at Girls Who Code, Technovations, and Plato. Jossie ran Women at Siri, and leads diversity and inclusion at Tile including the Women at Tile employee resource group, and company wide mentorship program.