07 Battery Aware Scheduling and Emergency Mesh

07 — Battery-Aware Scheduling & Emergency Mesh

Corresponding Specifications: sys-arch/13-battery-aware-scheduling-architecture.md, sys-arch/17-emergency-priority-classes-architecture.md, sys-arch/ui-ux-17-emergency-sos-offline-mesh-architecture.md
Key Crates: crates/siar-emergency, crates/siar-routing-policy

---

1. Five-Tier QoS Traffic Priority Engine

SIAR enforces strict quality-of-service traffic classification across all queues, buffers, and radio transmitters:

+-------------------------------------------------------------------------------+
| Tier   | Traffic Class             | Preemption | Drop Policy | Transports   |
+--------+---------------------------+------------+-------------+--------------+
| Tier 0 | Emergency SOS Broadcast   | Immediate  | Never Drop  | All Radios   |
| Tier 1 | Realtime Signaling / Voice| High       | Drop on TTL | Wi-Fi / LAN  |
| Tier 2 | Direct 1-on-1 Chat        | Medium     | DTN Spool   | Any Radio    |
| Tier 3 | Group MLS Epoch Commits   | Low        | DTN Spool   | Any Radio    |
| Tier 4 | Blob Sync & Background    | None       | Evict First | Unmetered Net|
+-------------------------------------------------------------------------------+

---

2. Battery-Aware Duty Cycling Modes

Mobile devices dynamically throttle radio scan intervals, discovery windows, and CPU wakeups according to remaining battery state of charge (SoC):

stateDiagram-v2
    [*] --> Normal: SoC > 50%
    Normal --> Conservative: 20% < SoC <= 50%
    Conservative --> Critical: 5% < SoC <= 20%
    Critical --> Survival: SoC <= 5%
    
    Normal: BLE scan 50% duty cycle\nWi-Fi Aware active\nInstant blob sync
    Conservative: BLE scan 10% duty cycle\nWi-Fi Aware on-demand\nDefer large blobs
    Critical: BLE scan 2% duty cycle (100ms every 5s)\nWi-Fi disabled\nText-only delivery
    Survival: Passive BLE beaconing only (1 burst/min)\nSOS alerts only\nZero background compute

Loading

---

3. Emergency SOS Protocol & Mesh Flooding

In disaster scenarios, search-and-rescue operations, or life-safety emergencies, the SOS engine triggers an autonomous epidemic broadcast across every active physical interface:

pub struct EmergencySosPayload {
    pub emergency_id: EmergencyId,
    pub sender_id: AccountId,
    pub timestamp: Timestamp,
    pub location: Option<GeoCoordinates>, // Latitude, Longitude, Altitude, Accuracy
    pub emergency_type: EmergencyType,    // Medical, Trapped, Fire, NaturalDisaster
    pub battery_remaining_pct: u8,
    pub text_message: Option<String>,
    pub hop_count: u8,
    pub signature: Signature,
}

sequenceDiagram
    autonumber
    actor Victim as Victim Node (Offline)
    participant Relay1 as Nearby Phone (Mule 1)
    participant Repeater as Solar Mesh Node
    participant Responder as Rescue Team / HQ

    Victim->>Victim: Trigger SOS (UI Button / Crash Sensor)
    Victim->>Relay1: Multi-Radio Blast (BLE Extended Adv + Wi-Fi Direct Probe)
    Relay1->>Relay1: Validate Ed25519 Signature & Pin to Priority 0 Queue
    Relay1->>Repeater: Forward over LoRa / Wi-Fi Mesh Hop
    Repeater->>Responder: High-Gain Long Range Uplink
    Responder-->>Victim: Cryptographic Acknowledgment & ETA Broadcast

Loading

Invariants of Emergency SOS

1. Preempts All Queues: Emergency frames immediately jump to the head of all transmission rings.
2. Exempt from Duty Cycles: Devices in Survival mode still wake up to receive and relay SOS packets.
3. No Centralized Key Verification: Signed with standard Ed25519 identity, decryptable by any authorized responder or public emergency channel.