Early warning dissemination: channels, the Common Alerting Protocol and writing a warning people act on

Detecting a flood is one job. Getting the message to the people in its path, in a form they understand and act on, is another, and it is where many warning systems fall short. This second job is called warning dissemination. The reliable way to do it is to use several channels at once, structure the alert in a standard format so it can travel between systems, and write the message so people know what to do.

Why one channel is never enough

Every channel has a gap:

• A phone alert does not reach someone with no signal, a flat battery, or no smartphone.
• A siren reaches everyone within earshot, but it cannot say much beyond "act now" unless it carries a voice message, and it is poorly heard indoors.
• An app can carry detail, maps and forecasts, but only for people who have installed it.

Combining them means that when one fails, another still works.

SMS and cell broadcast: what fits in a message

The physical limits of the message decide how you write it.

SMS. A single message carries 140 bytes. In the basic GSM 7-bit alphabet that is 160 characters. As soon as a message includes a character outside that alphabet, which includes every Devanagari letter, it switches to UCS-2 encoding and the limit falls to 70 characters. Longer messages are split into linked segments that each lose a few bytes to a header: 153 characters per segment in GSM 7-bit, and 67 in UCS-2 [1]. Cost, delay and the chance that part of a long message is lost all increase with segments.

Cell broadcast. A cell broadcast page holds 82 bytes, which encodes 93 characters in the default alphabet, and up to 15 pages can be chained into one message. It is addressed to a geographic area and not to numbers, so it can reach every phone in a danger zone without a subscriber list [2].

An example shows how much the language matters. The same warning, written three ways:

Write the shortest message that still carries the content, in every language you serve, and test its length on the real encoding. The Hindi message costs three segments where the short English one costs one.

The Common Alerting Protocol

The Common Alerting Protocol (CAP) is an international standard, an XML format for describing an alert once and sending it through many channels. CAP separates the content of an alert from the channel. An operator writes one alert, and the system can turn it into an SMS, a siren trigger, an app notification, a broadcast and a web feed. India's national platform for disaster alerting, SACHET, developed by the National Disaster Management Authority with C-DOT, is built around CAP. Launched nationwide in August 2021, it delivers geo-targeted alerts by SMS in local languages across all states and union territories [3].

A CAP message has three nested parts [4]:

• alert: the envelope. Required fields are an identifier, a sender, the time sent, a status (Actual, Exercise, System, Test or Draft), a msgType (Alert, Update, Cancel, Ack or Error), and a scope (Public, Restricted or Private).
• info: what is happening. At least one block per alert, possibly in several languages. It carries the event category and type, the urgency, severity and certainty of the event, when it is effective and when it expires, a headline, a description and an instruction.
• area: where. A description plus a polygon, a circle or a geocode.

The three assessments are enumerations, which is what lets different systems treat them consistently [4]:

A compact example of a flood warning:

<alert xmlns="urn:oasis:names:tc:emergency:cap:1.2">
  <identifier>EXAMPLE-2026-10-09-001</identifier>
  <sender>control-room@example.org</sender>
  <sent>2026-10-09T17:42:00+05:30</sent>
  <status>Exercise</status>
  <msgType>Alert</msgType>
  <scope>Public</scope>
  <info>
    <language>en-IN</language>
    <category>Met</category>
    <event>Flash flood</event>
    <responseType>Evacuate</responseType>
    <urgency>Immediate</urgency>
    <severity>Severe</severity>
    <certainty>Observed</certainty>
    <expires>2026-10-09T20:00:00+05:30</expires>
    <headline>River rising fast: move to higher ground now</headline>
    <instruction>Leave the riverbank and low-lying houses now and go to the school on the hill.</instruction>
    <area>
      <areaDesc>Villages along the river, example block</areaDesc>
      <polygon>31.20,77.10 31.20,77.18 31.26,77.18 31.26,77.10 31.20,77.10</polygon>
    </area>
  </info>
</alert>

Two rules matter in practice. An Update or Cancel must reference the earlier alerts it replaces, so that every channel can retire the old message, and an alert should carry an expires time so that a stale warning does not linger [4]. The status of Exercise or Test lets you rehearse the entire chain with the real systems without alarming anyone, which is how drills should be run.

Writing a warning people act on

A warning that is correct and ignored has failed. A large body of social-science research, summarised by Mileti and Sorensen in a 1990 assessment of more than 200 studies for the U.S. Oak Ridge National Laboratory, shows that how a warning is written strongly affects how people respond [5]. The qualities that emerge, as used in emergency management practice today, are that a message should be:

• Specific: say who is affected and where, so people do not spend time seeking confirmation.
• Consistent: not contradictory within a message or across channels.
• Certain: state what is known and what is not, without guessing.
• Clear: in common words, without technical terms.
• Accurate: neither overstating nor understating.

Good messages also state the source of the warning, the hazard, the place, the time, the action to take and when the next update will come. Read the two versions of a warning for a village:

The first is correct to an engineer and useless to a family. Two more rules follow from the evidence. Keep a consistent siren tone and message across the district, so people know what it means. And keep false alarms low, because a population that has heard too many stops responding: the scores for measuring this are in how a flood early warning system works.

How the pieces fit in ClimMaTech's system

• Rakshak is the siren: solar-powered, with a red beacon and configurable voice messages, triggered remotely over GSM (2G / 3G / 4G), LoRa or VSAT. We describe the communication choices in GSM vs LoRa for flood warning sirens.
• Aagah brings flood forecasts and early warnings to people's phones.
• Pravaah can send threshold alerts by WhatsApp, SMS and email to the people who need them.
• The Rakshak Control Centre, coming soon, is the web application for operators who run many sirens. It accepts alerts from official agencies in the CAP format, and from other systems through an API, and an alert can then be sent to the sirens in the right area. The siren itself is triggered through an open API, so it works with ClimMaTech systems and with systems you already have.

Making dissemination dependable

A few practices matter as much as the equipment:

1. Approval for live alerts. In the Control Centre, a live alert needs a second person's approval, and authorised staff can stop one at any time.
2. Drills with real systems. Run exercises with the CAP status set to Exercise or Test, so sirens, operators and residents all know what to expect.
3. Delivery confirmation. Operators should be able to see which sirens received and sounded each alert.
4. More than one communication path, so a single failure does not stop an alert.
5. Multilingual messages, tested for length in each script.
6. Community awareness, so people know what the siren means and where to go.
7. Review after every event, matching what was sent with what happened, and adjusting thresholds and messages.

To see how dissemination fits into a complete system, from sensors upstream to sirens in the community, read How a flood early warning system works.

References

1. SMS encoding and message length: GSM 7-bit (160 characters, 153 per segment) and UCS-2 (70 characters, 67 per segment), as explained in the Twilio SMS character limit glossary and Telekom messaging guide on concatenation and encoding.
2. GSMA, Mobile Network Public Warning Systems and the Rise of Cell Broadcast. gsma.com.
3. MicroSave, Turning the tide: how India's SACHET system is reshaping disaster preparedness. microsave.net.
4. OASIS, Common Alerting Protocol Version 1.2, as summarised in the U.S. National Weather Service CAP v1.2 guide. weather.gov.
5. D. S. Mileti and J. H. Sorensen, Communication of Emergency Public Warnings: A Social Science Perspective and State-of-the-Art Assessment, Oak Ridge National Laboratory, ORNL-6609 (1990). Summary at focusonfloods.org.

The sample messages, character counts, segment counts and the CAP example are illustrative and use a fictional sender and area. Check message length on your own encoding and gateway.

Plan a warning network