What is disaster-resilient communication?

Disaster-resilient communication is less a single technology than a property of a whole chain: the networks people rely on, the organisations that restore them, and the applications that run on top. The ITU’s emergency telecommunications programme frames the goal as disaster-resilient ICT infrastructure for saving lives and reducing damages, and points to digital technology’s role in early warnings and in the flow of vital information after a disaster.

In the United States, FEMA treats communications as one of its Community Lifelines, the basic services that let the rest of society function. The Communications lifeline covers infrastructure, responder communications, alerts, warnings and messages, finance, and 911 and dispatch. FEMA says that when a lifeline is disrupted, decisive intervention, such as rapid re-establishment or contingency response solutions, is needed to stabilise the incident.

It helps to separate three layers:

• Keep the network up. Backup power, diverse routes and coordinated operators reduce how much fails.
• Restore it quickly. Agreements, reporting and deployable equipment shorten the outage.
• Keep working in the gap. Devices and applications that can still do useful work locally, then catch up.

The FCC’s rules give a concrete picture of the second layer. From 2016, the FCC relied on the Wireless Network Resiliency Cooperative Framework, a voluntary agreement among a limited group of facilities-based mobile providers that the Commission endorsed in place of mandatory rules. It had five parts: roaming under disaster arrangements when technically feasible, mutual aid between providers, municipal preparedness and restoration, consumer readiness, and public information on service and restoration status.

In 2022 the FCC adopted the Mandatory Disaster Response Initiative. It largely codified the Framework’s five provisions as mandatory, extended them to all facilities-based mobile wireless providers, and added requirements to test roaming and to report on performance after disasters. The rule, 47 CFR 4.17, applies when Emergency Support Function 2 is activated, when the FCC activates its Disaster Information Reporting System (DIRS), or on a qualifying request from a state. Providers must test their roaming capabilities and coordination with other providers every year.

DIRS is how the regulator sees the damage. Under 47 CFR 4.18, facilities-based cable, wireline, wireless and interconnected VoIP providers report the status of their infrastructure each day while DIRS is activated in an area they serve. The Framework’s public information part relied on the same system: the FCC posting DIRS data on cell site outages, aggregated county by county. The rule is still changing: the eCFR lists its most recent amendment as published in June 2026.

When towers, fibre or power are destroyed rather than degraded, restoration means bringing equipment in, and paperwork can slow that down. The Tampere Convention, an international treaty in force since 8 January 2005, asks states to waive regulatory barriers to telecommunication assistance, including licensing requirements for allocated frequencies, restrictions on importing equipment, and limits on the movement of humanitarian teams. It also requires states to inventory the people and equipment available for disaster relief and to plan how to deploy them.

Responders have their own requirements. NIST’s Public Safety Communications Research division ran a Resilient Systems research portfolio whose stated vision is for public safety networks and applications to keep functioning when communication infrastructure is degraded or destroyed. It names the scenarios to plan for: areas without cellular coverage, limited or non-existent backhaul, and frequency impairment caused by a disaster or by jamming.

Carrier rules and deployable equipment shorten outages. They do not help an application in the time before service returns. That gap is the application’s responsibility, and the design choices are well understood:

• Queue instead of failing. An app that records work locally and sends it when a link returns, a pattern called store-and-forward, does not lose that work during the outage.
• Use the devices that are present. Phones nearby can exchange data directly over Bluetooth or Wi-Fi with no carrier network, and can form a mesh that relays for each other.
• Tolerate long delays. Delay-tolerant networking assumes a complete path may never exist at one moment, and moves data hop by hop as links appear.
• Say what has not happened yet. People should see which records are still only on their device and which the backend has accepted.

None of this replaces emergency services, alerting systems or carrier restoration. It makes sure the work people do during an outage is not lost, and that teams on the ground can still coordinate with whoever is nearby.

1. Which of your functions belong to a lifeline, or support one, and must keep working without a carrier network?
2. How long could the network be down where you operate, and how much work piles up in that time?
3. Which devices will actually be present, and can they reach each other directly?
4. When connectivity returns, how do queued records reach the backend, and who resolves conflicts?
5. Have you tested it with the network switched off, on the real devices, rather than assumed it?

The answers set the requirements for the third layer. The first two belong to carriers and governments; the third is the one an application team controls.