Technical Architecture

How Crisis Connect Works Under the Hood

Crisis Connect is an offline-first emergency communication system that runs entirely on Bluetooth. It enables secure device-to-device messaging and signaling when Internet, cellular networks, or infrastructure are unavailable.

What it does

  • Direct phone-to-phone communication (no servers)
  • Works with no SIM / no cellular / no Wi-Fi
  • End-to-end encryption for message privacy
  • Built for disaster conditions and degraded environments
01

System Goals

Why this architecture exists

Crisis environments break assumptions that normal apps rely on. Crisis Connect is designed around these constraints:

Infrastructure Collapse: cell towers, power, and backhaul may fail
Congestion: networks may exist but become unusable
Time-to-Connect: communication must start immediately
Battery Limits: phones must last as long as possible
Privacy & Integrity: messages must remain secure in chaotic environments
02

Design Principles

Offline-First

Operates with zero connectivity.

Infrastructure-Free

No servers, relays, or centralized routing.

Low-Energy

BLE for discovery, higher-power transport only when needed.

Secure by Default

End-to-end encryption and integrity protection at the payload level.

03

High-Level Communication Flow

1

Presence Broadcasting (BLE): Devices advertise in low power mode

2

Discovery: Nearby devices detect each other automatically

3

Link Establishment: A direct peer-to-peer channel is created

4

Secure Payload Exchange: Encrypted messages travel over the link

5

No Third Party: No cloud, no server, no intermediaries

04

The 4-Layer Bluetooth Protocol Stack

Crisis Connect uses a 4-layer stack so each function is isolated and testable.

Layer 04

Layer 4 — Security

AES-GCM
Purpose

privacy + integrity

Key Features
  • Encrypts payload before transmission
  • Receiver decrypts locally (no plaintext transit)
  • Integrity verification and replay-resistance mechanisms
Layer 03

Layer 3 — Status & Metadata

GATT
Purpose

lightweight attributes for UI/telemetry

Key Features
  • Device ID / session information
  • Battery level
  • RSSI / signal indicators
  • Connection state
Layer 02

Layer 2 — Transport

RFCOMM / SPP
Purpose

stable, reliable data channel

Key Features
  • Low-latency 1:1 messaging
  • Supports data transfer & offline voice (where enabled)
  • Robust behavior under interference compared to best-effort broadcast
Layer 01

Layer 1 — Discovery

BLE GAP
Purpose

fast, low-energy device discovery

Key Features
  • Continuous BLE advertising (no pairing required)
  • Rapid detection in proximity-based scenarios
  • Supports “immobilized user” cases (device can still broadcast presence)
05

Message Lifecycle

Zero-Plaintext Transit

1

User composes a message

2

Message is encrypted on the sender device

3

Encrypted payload is sent via RFCOMM

4

Receiver decrypts locally

5

Plaintext never leaves the device

Section 06

SOS & Rescue Mode

Crisis Connect includes a dedicated SOS mechanism designed for discovery and field response.

Signal

  • Device continuously emits BLE SOS presence
  • Field teams can detect nearby signals using RSSI patterns

Contact

  • Once detected, a direct link can be established for two-way communication
  • Enables teams to confirm status, needs, and priority without infrastructure
Section 07

Energy Strategy

  • BLE handles discovery in low power mode
  • Transport channels activate only when necessary
  • No background Internet polling
  • No cloud sync loops

Outcome: maximized operational time on limited battery

08

Why Bluetooth-Only?

Intentional tradeoff

Crisis Connect avoids Wi-Fi Direct / hotspots / cellular fallback by design to keep:

Setup minimal (works “as-is” on most phones)
Power usage controlled
Operation reliable when infrastructure collapses
User flow simple under stress
09

Limitations & Operational Reality

  • Range varies by device and environment
  • Dense concrete/metal can reduce performance
  • Bluetooth is proximity-based by nature

Crisis Connect is **not a replacement** for cellular networks. It is a **last-resort communication layer** designed for the moment when networks fail.

10

Intended Use Cases

  • Earthquake response and rubble scenarios
  • Search & rescue field operations
  • Infrastructure collapse / network outage
  • Remote and off-grid missions
11

For Developers & Institutions

  • Designed for field deployment and controlled evaluation
  • Suitable for emergency services & government use
  • Can be tested with scenario-based protocols
  • Documentation and test packs available upon request