Bluetooth Low Energy is the invisible infrastructure that makes proximity-based social discovery possible. It is built into every modern smartphone, consumes almost no power, and can detect other devices within roughly 10 to 50 meters without requiring an internet connection, a GPS fix, or any deliberate action from the user. But how does it actually work, and why is it the right technology for a social app?
This article is a technical deep dive for anyone who wants to understand the protocol-level mechanics behind apps like Serendipity. We will cover BLE advertising, GATT services, RSSI-based distance estimation, power management through duty cycling, and the trade-offs that make BLE superior to every alternative for this particular use case.
BLE Advertising: Broadcasting Without Connecting
The most important concept in BLE for social applications is the distinction between advertising and connections. In classic Bluetooth, two devices must pair and establish a persistent connection to exchange data. This is great for headphones and keyboards, but terrible for social discovery, because it requires both devices to actively agree to communicate before any data can flow.
BLE advertising works differently. A device can broadcast small packets of data, up to 31 bytes in a standard advertisement and 255 bytes with extended advertising, on three dedicated advertising channels (37, 38, and 39) without any connection being established. These packets are transmitted at regular intervals, typically every 100 to 1000 milliseconds, and any nearby device that is scanning can receive them.
For a social discovery app, this is the critical capability. Your phone broadcasts an advertising packet that contains a rotating identifier, essentially a temporary anonymous token. Other phones running the same app pick up these packets during their scan windows. Neither device needs to connect to the other. Neither device needs to know who the other person is. The raw detection event is recorded locally, and identity resolution happens later on the server, only if both parties consent.
What Goes Into an Advertisement Packet
A BLE advertisement contains a small set of structured fields. For a social discovery use case, the payload typically includes:
- A service UUID that identifies the packet as belonging to the app, allowing the scanning device to filter for relevant advertisements among the noise of every other BLE device in range.
- A rotating identifier that is cryptographically generated and changes on a regular schedule, usually every 10 to 15 minutes. This prevents long-term tracking by third parties while still allowing the backend to resolve encounters between users.
- Optional metadata flags such as protocol version or encounter mode, packed into the remaining bytes.
The rotation of identifiers is essential for privacy. If a device broadcast the same identifier forever, anyone with a BLE scanner could track its movements. By rotating the identifier on a schedule and linking rotations to server-side cryptographic keys, the system ensures that only the app's backend can correlate a rotating ID to a real user, and only when both users have opted in. For a deep look at how this rotation scheme preserves zero-knowledge properties, see our article on zero-knowledge rotating beacons.
GATT: When You Need More Than an Advertisement
Sometimes 31 bytes is not enough. The Generic Attribute Profile, or GATT, defines how two BLE devices can establish a temporary connection and exchange structured data through services and characteristics. A GATT service is a collection of related data points, and each characteristic within a service holds a specific value that can be read, written, or subscribed to.
In a social discovery context, GATT connections are used sparingly. The primary detection mechanism is advertising-only, because it scales better and uses less power. But there are scenarios where a brief GATT connection adds value: exchanging a larger payload that does not fit in an advertisement, verifying mutual app installation through a handshake, or transmitting supplementary context about an encounter.
The key design principle is that GATT connections should be short-lived and infrequent. Every connection costs power and occupies one of the device's limited connection slots. The advertising-first architecture ensures that the common case, simply detecting that another user is nearby, never requires a connection at all.
RSSI and Distance Estimation
Every received BLE packet comes with a Received Signal Strength Indicator, or RSSI, measured in decibels relative to one milliwatt (dBm). A stronger signal generally means the transmitting device is closer. In open air, RSSI follows the inverse-square law: signal strength decreases proportionally to the square of the distance.
In practice, RSSI-based distance estimation is imprecise. The signal is affected by body absorption (a phone in a back pocket radiates differently than one in a hand), multipath reflection off walls and furniture, interference from other 2.4 GHz devices, and variation in transmit power between phone models. A single RSSI reading might correspond to anything from 2 meters to 15 meters depending on the environment.
Social apps handle this imprecision by treating RSSI as a coarse proximity indicator rather than a distance measurement. The relevant question is not "how far away is this person?" but "were they within social interaction range?" For this purpose, a threshold-based approach works well:
- Strong signal (above -60 dBm): Very likely within a few meters. Same table at a coffee shop.
- Medium signal (-60 to -80 dBm): Probably within 10 to 20 meters. Same room or general area.
- Weak signal (below -80 dBm): Could be anywhere within BLE range. Same building, possibly different floors.
By averaging multiple RSSI readings over the duration of an encounter (which might last minutes or hours), the estimate becomes more reliable. A sustained medium-strength signal over 20 minutes is far more meaningful than a single strong reading that might have been a person walking past.
Power Management: Why BLE Does Not Kill Your Battery
The "Low Energy" in Bluetooth Low Energy is not marketing. It is an engineering constraint that shaped every aspect of the protocol. BLE was designed from the ground up for devices that need to run on coin cell batteries for years, and that design philosophy translates directly into smartphone battery efficiency.
Duty Cycling
The primary power management technique in BLE is duty cycling: alternating between active and sleep states on a fixed schedule. A device might advertise for 1 millisecond every 500 milliseconds, spending 99.8% of its time in a low-power sleep state. Similarly, scanning can be configured with a scan window (the active listening period) and a scan interval (the time between scan windows).
For a social discovery app, typical parameters might be:
- Advertising interval: 250 to 1000 ms, depending on the desired detection latency.
- Scan window: 30 to 100 ms of active listening.
- Scan interval: 300 to 5000 ms between scan windows.
The trade-off is straightforward: more aggressive scanning detects encounters faster but uses more power. Less aggressive scanning saves battery but might miss brief encounters. In practice, a scan window of 50 ms every 2 seconds catches the vast majority of nearby advertisers within a few seconds while adding less than 2% to overall battery consumption.
Platform Constraints: iOS and Android
Both iOS and Android impose restrictions on background BLE activity. iOS limits background advertising to a specific format and may reduce scan frequency when the app is backgrounded. Android requires a foreground service notification for persistent background scanning on Android 12 and later. These constraints shape the implementation but do not prevent it. Both platforms recognized the value of background BLE through their COVID-19 Exposure Notification frameworks, which proved that sustained background BLE operation is technically viable and battery-acceptable on billions of devices.
Why BLE Beats the Alternatives
Every wireless technology has been proposed for proximity detection at one point or another. Here is why BLE wins for social applications:
GPS
Accuracy of 3 to 15 meters outdoors, does not work indoors, consumes significant battery, and tells you location rather than proximity. Two people at the same GPS coordinate might be on different floors of a building. GPS is a location technology, not a proximity technology.
WiFi
WiFi-based proximity (same network detection or WiFi RTT) requires both devices to be on the same network or have WiFi ranging hardware. Range is too large for meaningful social context, often 50 to 100 meters through walls. Power consumption for continuous scanning is substantially higher than BLE.
NFC
Near Field Communication works at a range of about 4 centimeters. This is useful for tap-to-pay and access cards, but useless for passive social discovery. You would need to physically touch phones with every person in a coffee shop to detect them.
Ultrasound
Some proximity systems use ultrasonic audio through the phone's speaker and microphone. This is clever but has significant drawbacks: it requires microphone access (a privacy red flag), does not work well in noisy environments, and cannot operate in the background on most platforms.
BLE occupies a unique sweet spot: its 10 to 50 meter range is large enough to detect people in the same space but small enough to be socially meaningful, it works indoors and outdoors, it requires no infrastructure, and it runs in the background with minimal battery impact.
The 50-Meter Range Is a Feature, Not a Bug
When people first hear about BLE-based social discovery, they sometimes ask why we do not try to increase the range or achieve pinpoint accuracy. The answer is that the approximately 50-meter range and imprecise distance estimation are virtues of the system.
A 50-meter radius roughly corresponds to a single venue: one coffee shop, one section of a park, one floor of a coworking space. This is the scale at which shared physical context is meaningful. Two people within 50 meters of each other were probably in the same social environment. Two people within 500 meters might have been in completely different contexts.
The imprecision of RSSI serves a similar purpose. It prevents the app from becoming a precise tracking tool while still providing enough information to classify encounters as likely meaningful. This is a case where less data creates a better product and a more ethical one.
BLE is not just a convenient technology choice for proximity-based social discovery. It is the enabling technology, the one protocol that provides the right combination of range, power efficiency, background operation, and privacy properties to make encounter-based social apps practical on the devices people already carry. Everything else in the stack, from the rotating beacon scheme to the opt-in connection flow, is built on top of these BLE fundamentals.