Survivor Beacon Mode

Earthquake response has a cruel arithmetic. The so-called "golden hours" pass quickly, but people survive far longer than that under rubble: survivors are recovered three, five, even seven days after a collapse. The decisive question is rarely whether someone is alive; it is whether rescuers can find them in time.

Nearly every victim carries a smartphone, and increasingly a smartwatch. These are the densest, most personal sensor networks ever deployed, and in a disaster they are almost entirely wasted. A buried phone keeps doing what it always does: searching for a network, lighting its screen, running background tasks, and draining its battery. It dies just when its owner most needs it to be findable. The recurring detail in news coverage of recent earthquakes, survivors located with a phone at 3%, is not a heart-warming coincidence. It is a system failure. The most reliable beacon a victim owns burns out before help arrives.

Today, locating those devices is a manual, equipment-heavy task: rescue teams sweep for cellular signals, sometimes from aircraft. It works, but it is slow, it requires specialist gear, and it finds a device, not a living person. There is no built-in mode that makes a trapped device want to be found: efficiently, intelligently, and in a way that also signals whether the person carrying it is still alive.

This proposal stands on a substantial body of work. Its contribution is integration, not the invention of any single piece.

Crowdsourced earthquake detection

Google's Android Earthquake Alerts System uses the accelerometers in billions of phones as a planet-scale seismic network, detecting quakes and issuing warnings seconds before the shaking arrives. This was demonstrated again during the June 2026 Venezuela earthquakes, when Android phones alerted while nearby iPhones stayed silent. Apple relays official alerts but operates no phone-sensor detection network of its own. Crucially, this system warns people before shaking; it does nothing to find them after a collapse.

Detecting buried devices

Airborne systems such as Lifeseeker turn a victim's phone into a locatable beacon using its cellular signal, even without network coverage, from helicopters or drones. Research on passive positioning via 4G uplink signals can locate phones in shallow rubble across wide areas. These approaches are powerful but depend on specialist equipment and aircraft, and they locate a handset rather than confirming a heartbeat.

Acoustic methods

Researchers at the University of Tokyo have proposed using smartphone microphones to locate buried victims, exploiting the fact that sound propagates through debris. Related work has shown that automatic reply messages from a victim's phone can localise them to within about two metres even when the person is too weak to call for help.

Wearable vital signs

The Apple Watch already performs fall detection that triggers Emergency SOS, issues irregular-rhythm notifications, and measures blood oxygen. The iPhone, in turn, offers Emergency SOS via satellite, which works where cellular networks are down. Every sensing primitive this proposal needs is already shipping in consumer devices.

The gap

What does not exist is a single, OS-level mode that makes an ordinary buried device actively and efficiently findable by any nearby rescuer, while using the wearer's vital signs to prove life and prioritise rescue. That is the gap this proposal addresses.

Survivor Beacon Mode is a built-in state that a smartphone (and, where present, a paired smartwatch) enters automatically after a likely entrapment event, optimised for one goal: maximise the chance and speed of being found by rescuers, while keeping the person's location and identity private until a legitimate rescue device asks.

3.1 · Activation

The device enters the mode when it detects a strong earthquake (using its own accelerometer, ideally cross-confirmed against the crowd-sourced detection network or a known seismic event), or when it registers a hard impact or fall that the user does not cancel. As with existing fall detection, a brief countdown lets a conscious, unhurt user dismiss a false alarm before the beacon begins. The mode is opt-in at the system level and fully cancellable; it must never become a covert tracking feature.

3.2 · Two layers: phone base, wearable enhancement

Base layer: the phone (near-universal). The device begins broadcasting an anonymous Bluetooth Low Energy (BLE) advertisement. BLE advertising draws very little power, which is the whole point: it converts a phone's dying battery from hours of normal use into days of findability. The decisive advantage is that every rescuer's own phone is already a BLE receiver, with no aircraft and no specialist hardware required. A single rescuer walking a collapse site with a standard phone can pick up and roughly localise beacons by signal strength.

Enhancement layer: the wearable (when present). A smartwatch adds what a phone alone cannot: proof of life. The beacon escalates in richness as evidence allows:

• Phone onlyA device is here.
• Wearable presentA living person is here, with a heart rate of X bpm.
• Vital-sign trendA living person is here, and their condition is deteriorating. Prioritise.

Heart rate is the headline signal: it is robust, simple, and impossible to fake. It directly solves the hardest case: a survivor who is unconscious, immobile, and silent, and whom no acoustic method could ever detect.

3.3 · Rescuer-initiated challenge-response

To conserve battery and to disambiguate the many devices in a disaster zone, richer and more expensive signalling stays dormant until a rescue receiver pings nearby. Only then does the device wake additional sensors, for example the microphone for an acoustic confirmation step, or a higher-rate vital-sign report. This keeps the standing cost near the BLE-advertising floor while still enabling detailed interrogation once a rescuer is close.

3.4 · The triage logic, stated carefully

A detected pulse, movement, sound, or screen tap marks a point as "confirmed living, go now." But silence, stillness, or a flat sensor reading must never be read as "deceased" and used to deprioritise someone. An unconscious survivor, a person pinned and unable to make a sound, or a phone muffled under concrete will all look quiet. Triage here is strictly additive. The system raises confidence in life; it never adjudicates death.

3.5 · Getting the signal out when the towers are down

A buried device's BLE reaches only metres, attenuated further by rubble, so the beacon is a complement to existing long-range cellular detection, not a replacement. But BLE chains: a victim's beacon reaches a rescuer's phone, or a surviving nearby device, which can relay and aggregate. Where a path exists, satellite relay (already present on recent iPhones) can lift an aggregated "survivor map" out of a region with no working cellular infrastructure, giving incident command a live picture of where confirmed-living beacons are concentrated.

This is deliberately framed as an integration ask, not an invention ask.

They already hold every piece. Crowd-sourced detection (Google's accelerometer network), wearable vital signs (Apple Watch), fall and crash detection that already triggers SOS, and satellite emergency relay all exist today. Survivor Beacon Mode chains together components these companies already build and ship. That is a far easier "yes" than building anything from scratch.

Only they can reach the necessary states. A third-party app cannot override power management, run reliably while the device is locked or nominally "off," or operate the radios in the special low-power modes this requires. To work at population scale, this must live in the operating system. Apple and Google are the only two organisations with both the install base (billions of devices) and the OS-level control to make it real.

It is a humanitarian feature neither company yet fully owns. Detection has a clear leader; finding survivors afterwards does not. This is open ground, and it is the kind of feature whose value is measured in lives.

A proposal that hides its weaknesses does not deserve to be taken seriously. Here are this one's.

• Blood-oxygen readings are unreliable in exactly the wrong conditions. Wrist pulse-oximetry degrades under poor perfusion (cold, low blood pressure, shock, crush injury), which is precisely the state of many trapped victims. SpO₂ should therefore be a secondary signal with explicit uncertainty, never a headline clinical number. Heart rate, which is far more robust, should carry the proof-of-life claim. (Blood-oxygen sensing on the Apple Watch has also been entangled in a multi-year patent dispute, a further reason not to build the core of the proposal on it.)
• Most people do not own a wearable. The vital-signs layer enhances coverage; it cannot be the foundation. The base layer must be fully useful on a phone alone, or the system covers only a minority.
• False positives at scale. A dropped phone must not trigger a city-wide alarm. Activation needs a confirmation countdown and cross-checking against a confirmed seismic event before beacons are treated as credible.
• Battery versus signalling is a real tension. Keeping a microphone and rich sensing always on would defeat the purpose. The challenge-response design (a frugal BLE floor, with expensive sensing only on rescuer demand) is the proposed resolution, but the exact power budget needs empirical validation.
• Privacy and consent are not optional. The beacon must be anonymous, activated only in a genuine emergency, clearly opt-in, and incapable of being repurposed as a surveillance channel. Getting this wrong would rightly sink the feature.
• Range through rubble is limited. BLE complements, rather than replaces, long-range cellular and acoustic detection. Its value is the zero-extra-hardware receiver in every rescuer's pocket, not raw reach.
• Cross-vendor interoperability needs a standard. An Android-carrying rescuer should be able to detect an iPhone-carrying victim and vice versa. That requires an agreed, open beacon format, which is itself a call to action for the standards community, not something either company should own privately.

This document asks for three things:

• Apple and Google to evaluate and prototype a Survivor Beacon Mode built from components they already ship, prioritising the phone-only base layer and heart-rate-based proof of life.
• The research and standards community to define an open, cross-vendor "disaster beacon" profile so that any rescuer's device can detect any victim's device, regardless of brand.
• Anyone able to help, from engineers to first responders to disaster-response organisations, to challenge, improve, and pressure-test this concept. It is published openly and deliberately early precisely so that it can be torn apart and made better.

The components exist. The need is proven with every earthquake. What is missing is the decision to connect them. If that decision saves even one person who would otherwise have been found too late, it is worth making.

1. Global earthquake detection and warning using Android phones. Science, 2025.
2. Android Earthquake Alerts System. Google Crisis Response.
3. Venezuela's earthquakes and the Android/iPhone alert gap. PhoneArena, June 2026.
4. Lifeseeker: locating mobile phones for search and rescue without network coverage. DroneLife, 2020.
5. Mobile phone passive positioning through detection of uplink signals for search and rescue. Sensors / PMC, 2019.
6. Using smartphones to locate trapped victims in disasters. PMC, 2022.
7. Using smartphone microphones to locate disaster victims (University of Tokyo). TechXplore, December 2025.
8. The Apple Watch blood-oxygen dispute and its resolution. 9to5Mac, 2026.

La respuesta a un terremoto tiene una aritmética cruel. Las llamadas "horas doradas" pasan rápido, pero las personas sobreviven mucho más tiempo bajo los escombros: se rescata a supervivientes a los tres, cinco e incluso siete días de un derrumbe. La pregunta decisiva casi nunca es si alguien sigue vivo; es si los rescatadores pueden encontrarlo a tiempo.

Casi toda víctima lleva un smartphone, y cada vez más un smartwatch. Son las redes de sensores más densas y personales jamás desplegadas, y en una catástrofe se desaprovechan casi por completo. Un móvil enterrado sigue haciendo lo de siempre: buscar red, encender la pantalla, ejecutar tareas en segundo plano y agotar la batería. Muere justo cuando su dueño más necesita ser localizable. El detalle que se repite en las noticias de los últimos terremotos, supervivientes hallados con el móvil al 3 %, no es una casualidad entrañable. Es un fallo del sistema. La baliza más fiable que tiene una víctima se apaga antes de que llegue la ayuda.

Hoy, localizar esos dispositivos es una tarea manual y dependiente de equipos: los equipos de rescate barren en busca de señales de móvil, a veces desde aeronaves. Funciona, pero es lento, requiere material especializado y encuentra un dispositivo, no a una persona viva. No existe un modo integrado que haga que un dispositivo atrapado quiera ser encontrado: de forma eficiente, inteligente y señalando además si quien lo lleva sigue con vida.

Esta propuesta se apoya en un cuerpo de trabajo considerable. Su aportación es la integración, no la invención de ninguna pieza por separado.

Detección sísmica colaborativa

El sistema de Alertas de Terremoto de Android de Google usa los acelerómetros de miles de millones de teléfonos como una red sísmica a escala planetaria, detectando seísmos y emitiendo avisos segundos antes de que llegue el temblor. Se volvió a demostrar durante los terremotos de Venezuela de junio de 2026, cuando los móviles Android avisaron mientras los iPhone cercanos permanecían en silencio. Apple retransmite alertas oficiales, pero no opera ninguna red de detección propia basada en los sensores del teléfono. Y, sobre todo, este sistema avisa a la gente antes del temblor; no hace nada por encontrarla después de un derrumbe.

Detección de dispositivos enterrados

Sistemas aerotransportados como Lifeseeker convierten el móvil de una víctima en una baliza localizable usando su señal celular, incluso sin cobertura de red, desde helicópteros o drones. La investigación sobre posicionamiento pasivo mediante señales de subida 4G permite localizar teléfonos en escombros poco profundos en zonas amplias. Son enfoques potentes, pero dependen de equipos especializados y aeronaves, y localizan un terminal en lugar de confirmar un latido.

Métodos acústicos

Investigadores de la Universidad de Tokio han propuesto usar los micrófonos de los smartphones para localizar víctimas enterradas, aprovechando que el sonido se propaga a través de los escombros. Trabajos relacionados han demostrado que los mensajes de respuesta automática del móvil de una víctima pueden localizarla con un margen de unos dos metros, incluso cuando la persona está demasiado débil para pedir ayuda.

Constantes vitales de los wearables

El Apple Watch ya detecta caídas que disparan el SOS de emergencia, emite avisos de ritmo irregular y mide el oxígeno en sangre. El iPhone, por su parte, ofrece SOS de emergencia vía satélite, que funciona donde las redes celulares están caídas. Cada componente de sensorización que esta propuesta necesita ya se fabrica en dispositivos de consumo.

El hueco

Lo que no existe es un único modo, a nivel de sistema operativo, que haga que un dispositivo enterrado corriente sea localizable de forma activa y eficiente por cualquier rescatador cercano, usando a la vez las constantes vitales de quien lo lleva para probar que hay vida y priorizar el rescate. Ese es el hueco que aborda esta propuesta.

El Modo Baliza de Superviviente es un estado integrado en el que un smartphone (y, cuando existe, un smartwatch emparejado) entra automáticamente tras un probable atrapamiento, optimizado para un único objetivo: maximizar la probabilidad y la rapidez de ser encontrado por los rescatadores, manteniendo privadas la ubicación y la identidad de la persona hasta que un dispositivo de rescate legítimo lo solicite.

3.1 · Activación

El dispositivo entra en el modo cuando detecta un terremoto fuerte (con su propio acelerómetro, idealmente contrastado con la red de detección colaborativa o con un evento sísmico conocido), o cuando registra un impacto o caída fuerte que el usuario no cancela. Como en la detección de caídas actual, una breve cuenta atrás permite a un usuario consciente e ileso descartar una falsa alarma antes de que arranque la baliza. El modo es opcional a nivel de sistema y totalmente cancelable; nunca debe convertirse en una función de rastreo encubierto.

3.2 · Dos capas: el teléfono como base, el wearable como mejora

Capa base: el teléfono (casi universal). El dispositivo empieza a emitir un anuncio Bluetooth de baja energía (BLE) anónimo. El anuncio BLE consume muy poca energía, y ese es justo el truco: convierte la batería agonizante de un teléfono de horas de uso normal en días de localizabilidad. La ventaja decisiva es que el propio teléfono de cualquier rescatador ya es un receptor BLE, sin aeronaves ni hardware especializado. Un solo rescatador caminando por un derrumbe con un teléfono normal puede captar y localizar aproximadamente las balizas por la intensidad de la señal.

Capa de mejora: el wearable (cuando existe). Un smartwatch aporta lo que el teléfono solo no puede: prueba de vida. La baliza escala en riqueza según lo permiten las evidencias:

• Solo teléfonoAquí hay un dispositivo.
• Con wearableAquí hay una persona viva, con un ritmo cardíaco de X lpm.
• Tendencia vitalAquí hay una persona viva y su estado se deteriora. Prioridad.

El ritmo cardíaco es la señal protagonista: es robusta, sencilla e imposible de falsear. Resuelve directamente el caso más difícil: un superviviente inconsciente, inmóvil y en silencio, al que ningún método acústico podría detectar.

3.3 · Reto-respuesta iniciado por el rescatador

Para ahorrar batería y desambiguar los muchos dispositivos de una zona catastrófica, la señalización más rica y costosa permanece dormida hasta que un receptor de rescate hace ping cerca. Solo entonces el dispositivo despierta sensores adicionales, por ejemplo el micrófono para un paso de confirmación acústica, o un reporte de constantes a mayor frecuencia. Así el coste en reposo se mantiene cerca del mínimo del anuncio BLE, sin renunciar a una interrogación detallada una vez que el rescatador está cerca.

3.4 · La lógica de triaje, con cuidado

Un pulso, un movimiento, un sonido o un toque en la pantalla marcan un punto como "vida confirmada, ir ya". Pero el silencio, la quietud o una lectura plana del sensor nunca deben leerse como "fallecido" ni usarse para despriorizar a nadie. Un superviviente inconsciente, una persona atrapada e incapaz de emitir un sonido, o un móvil amortiguado bajo el hormigón parecerán todos en silencio. Aquí el triaje es estrictamente aditivo. El sistema eleva la confianza en que hay vida; nunca dictamina la muerte.

3.5 · Sacar la señal cuando las torres están caídas

El BLE de un dispositivo enterrado llega solo a unos metros, atenuado además por los escombros, así que la baliza es un complemento a la detección celular de largo alcance existente, no un sustituto. Pero el BLE encadena: la baliza de una víctima llega al teléfono de un rescatador, o a un dispositivo cercano que sobreviva, que puede retransmitir y agregar. Donde exista un camino, la retransmisión por satélite (ya presente en los iPhone recientes) puede sacar un "mapa de supervivientes" agregado de una región sin infraestructura celular operativa, dando al mando de incidentes una imagen en vivo de dónde se concentran las balizas con vida confirmada.

Esto se plantea a propósito como una petición de integración, no de invención.

Ya tienen todas las piezas. La detección colaborativa (la red de acelerómetros de Google), las constantes vitales del wearable (Apple Watch), la detección de caídas e impactos que ya dispara el SOS, y la retransmisión de emergencia por satélite existen hoy. El Modo Baliza de Superviviente encadena componentes que estas empresas ya fabrican y distribuyen. Es un "sí" mucho más fácil que construir algo desde cero.

Solo ellas pueden alcanzar los estados necesarios. Una app de terceros no puede anular la gestión de energía, ejecutarse de forma fiable con el dispositivo bloqueado o nominalmente "apagado", ni operar las radios en los modos especiales de bajo consumo que esto requiere. Para funcionar a escala de población, esto tiene que vivir en el sistema operativo. Apple y Google son las dos únicas organizaciones con la base instalada (miles de millones de dispositivos) y el control a nivel de sistema operativo para hacerlo realidad.

Es una función humanitaria que ninguna de las dos posee todavía del todo. La detección tiene un líder claro; encontrar supervivientes después, no. Es terreno abierto, y es el tipo de función cuyo valor se mide en vidas.

Una propuesta solo merece tomarse en serio si muestra sus debilidades. Estas son las suyas.

• Las lecturas de oxígeno en sangre son poco fiables justo en las peores condiciones. La pulsioximetría de muñeca se degrada con la mala perfusión (frío, tensión baja, shock, aplastamiento), que es precisamente el estado de muchas víctimas atrapadas. Por eso el SpO₂ debería ser una señal secundaria, con su incertidumbre explícita, nunca una cifra clínica protagonista. El ritmo cardíaco, mucho más robusto, debería sostener la afirmación de prueba de vida. (La medición de oxígeno en sangre del Apple Watch también ha estado enredada en un litigio de patentes de varios años, una razón más para no construir el núcleo de la propuesta sobre ella.)
• La mayoría de la gente no tiene wearable. La capa de constantes vitales amplía la cobertura; no puede ser el cimiento. La capa base tiene que ser plenamente útil solo con el teléfono, o el sistema cubre a una minoría.
• Falsos positivos a escala. Un móvil que se cae no debe disparar una alarma a escala de ciudad. La activación necesita una cuenta atrás de confirmación y un contraste con un evento sísmico confirmado antes de tratar las balizas como creíbles.
• Batería frente a señalización es una tensión real. Mantener el micrófono y la sensorización rica siempre encendidos echaría por tierra el propósito. El diseño de reto-respuesta (un mínimo frugal de BLE, con sensorización costosa solo a demanda del rescatador) es la resolución propuesta, pero el presupuesto exacto de energía necesita validación empírica.
• La privacidad y el consentimiento no son opcionales. La baliza debe ser anónima, activarse solo en una emergencia real, ser claramente opcional e incapaz de reconvertirse en un canal de vigilancia. Hacer esto mal hundiría la función, y con razón.
• El alcance a través de los escombros es limitado. El BLE complementa, no sustituye, la detección celular y acústica de largo alcance. Su valor es el receptor sin hardware extra en el bolsillo de cada rescatador, no el alcance bruto.
• La interoperabilidad entre fabricantes necesita un estándar. Un rescatador con Android debería poder detectar a una víctima con iPhone y viceversa. Eso requiere un formato de baliza abierto y acordado, que es en sí mismo una llamada a la comunidad de estándares, no algo que ninguna empresa deba poseer en privado.

Este documento pide tres cosas:

• A Apple y Google, que evalúen y prototipen un Modo Baliza de Superviviente construido a partir de componentes que ya distribuyen, priorizando la capa base solo de teléfono y la prueba de vida basada en el ritmo cardíaco.
• A la comunidad de investigación y estándares, que defina un perfil abierto de "baliza de catástrofe" entre fabricantes, para que el dispositivo de cualquier rescatador pueda detectar el de cualquier víctima, sea de la marca que sea.
• A cualquiera que pueda ayudar, desde ingenieros hasta primeros intervinientes y organizaciones de respuesta a catástrofes, a cuestionar, mejorar y poner a prueba este concepto. Se publica de forma abierta y deliberadamente pronto, precisamente para que pueda desmontarse y mejorarse.

Las piezas existen. La necesidad se demuestra con cada terremoto. Lo que falta es la decisión de conectarlas. Si esa decisión salva aunque sea a una persona que de otro modo se habría encontrado demasiado tarde, merece la pena tomarla.

1. Global earthquake detection and warning using Android phones. Science, 2025.
2. Android Earthquake Alerts System. Google Crisis Response.
3. Venezuela's earthquakes and the Android/iPhone alert gap. PhoneArena, 2026.
4. Lifeseeker: locating mobile phones for search and rescue without network coverage. DroneLife, 2020.
5. Mobile phone passive positioning through detection of uplink signals for search and rescue. Sensors / PMC, 2019.
6. Using smartphones to locate trapped victims in disasters. PMC, 2022.
7. Using smartphone microphones to locate disaster victims (University of Tokyo). TechXplore, 2025.
8. The Apple Watch blood-oxygen dispute and its resolution. 9to5Mac, 2026.