Emergency Broadcast Messaging on a 4G GSM Gateway: Designing for the Worst Day

Emergency messaging is the workload that never gets a second attempt. A routine campaign that misses its window is a disappointment; a warning that arrives after the event is a failure that will be examined in public.

This article sets out what distinguishes emergency messaging from a campaign, how to estimate the volume of a single event, how redundancy should be arranged across networks and hardware, and what a test has to cover before anyone relies on the system.

What distinguishes emergency broadcasts from a campaign on a 4G GSM gateway?

The consequence of a delay, and how many notice.

A campaign plans its volume; an emergency event determines it, and the volume is often larger than any routine peak the estate has seen.

Four properties separate the two. The timing is not chosen, so the send cannot be moved to a quiet period. The recipient list is the entire affected population rather than a consenting segment, which changes the consent position to something the operator has to establish rather than assume. The message may be sent under a legal or regulatory framework rather than a commercial one, and those frameworks differ by market and are generally the accountability of a public authority rather than of a messaging operator. And the record is scrutinised for years rather than weeks.

These are described in engineering terms here, and the institutional side is deliberately left where it belongs: the decision to broadcast, the framework it is sent under and the wording used are matters for the responsible authority. What the engineering design has to deliver is the capability to send it, and evidence that the capability works. The message path is defined in ETSI TS 123 040 and 3GPP TS 23.040.

Property	Campaign	Emergency event
Timing	Chosen	Imposed by the event
Recipients	A consenting segment	The affected population
Record	Reviewed internally	Reviewed publicly
Retry	Next campaign	Usually none

Volume assumptions for a single event

Take the worst realistic case, not the average one.

The planning figure is the population inside the affected area, multiplied by the number of messages the event is expected to generate.

Two multipliers are easy to miss. The first is that a developing event generates several messages rather than one: an initial warning, an update, a change and an all-clear. The second is that the affected population is not only the residents, and a transport hub or a large event can add a transient population that no resident list contains. Both multipliers apply at the same time, which is why the planning figure is usually several times the number the first estimate produces.

The window then converts that volume into a required rate. A population of two hundred thousand with four messages each in a thirty-minute window is a rate of roughly twenty-seven thousand messages per minute, which is beyond most owned estates and is the point at which the design decision becomes about using multiple paths rather than about sizing one. Recording the calculation with its assumptions is what allows the capability to be explained to whoever is accountable for the framework.

Redundancy across networks and hardware

Diversity in both dimensions, because the failure may be either.

A large event can disable a site, a network or both, and redundancy that addresses only one of those fails in the case that matters.

Network diversity means subscriptions on more than one operator, so that a problem with one does not remove the whole path. Site diversity means the estate is not entirely in the affected area, which is a specific requirement for emergency messaging because the event may be at the place the estate is installed. Where the send is large enough to require a provider path, the provider route should be treated as part of the design rather than as a fallback of last resort, and the routing policy should state which traffic uses which path and who authorises a switch.

Hardware diversity is the third and least useful on its own, for the reason it always is: a second unit on the same operator in the same building does not survive the failure it was bought for. It is worth having where it covers a device fault, and it should not be counted as redundancy against an event. Contingency planning and testing as control objectives are organised in NIST SP 800-53 Rev. 5.

Queue behaviour when the send is bursty

The queue is the component that decides whether the tail is minutes or hours.

A burst submitted at once into a paced estate produces a queue whose depth determines the delivery time of everything at the end of it.

Three design rules follow. The queue should be visible, so that the operator can see how much remains and project when the send will complete. It should have a defined expiry, because a warning that arrives after the event is worse than one that was not sent, and a queue that keeps delivering stale messages does not help anyone. And it should be prioritised, so that the messages whose window is closing are delivered before those whose window is wider, which is usually achieved by splitting the population into a small priority group and a general group rather than by attempting to prioritise inside a single queue.

The pacing policy also has to be different from a campaign’s. A campaign paces to protect the numbers, while an emergency send paces to the rate the networks accept, which is a figure worth measuring per operator in advance rather than discovering during the event. Where an alternative route can carry traffic faster, the routing policy should allow it to be used without a configuration change.

Sender identity that recipients trust

The message has to be believed in the first second.

An unrecognised sender during an emergency produces doubt at the moment when doubt is most costly, and doubt produces calls that a busy response centre cannot absorb.

Three properties help. A consistent identity that has been used before for official messages, so that the warning is not the first message the population has seen from that sender. A message that names the authority in its text and states what to do, because the instruction is what the recipient acts on. And a design that does not rely on a link, since a message that requires a click is both less immediate and less trusted during an event.

Where a market operates a public warning framework, that framework may specify the channel technology, and it is worth establishing whether SMS-based messaging is part of it or a supplement to it. The two are different technologies with different characteristics, and the authority responsible for the framework is the source of the answer. The numbering conventions behind the sender identity are described in ITU-T E.164.

What should the test cover?

The event, not the equipment.

A test that sends one message to each recipient proves the path exists and says almost nothing about the capability that matters.

Four elements belong in a readiness test. The full volume at the intended window, even if it is run against a subset with the same rate. The failure of one path, to measure the switch and what it costs in delivery time. The expiry behaviour, to confirm that messages beyond their window are not delivered. And the record, produced from the systems the authority would use, because a record that cannot be produced afterwards is not evidence. The test should be run with the people who would operate it, at the hour they would operate it, which for emergency messaging is often not a weekday afternoon.

The results belong with the readiness documentation rather than in a test folder. Fault management concepts, including how thresholds are set and cleared, are organised in ITU-T M.3400, and record-keeping practice for the logs that support a review is covered in NIST SP 800-92.

A readiness checklist

The checklist covers what has to be in place before a broadcast path can be relied on, and it is written to be tested rather than asserted. Each item produces an artefact, whether a measurement, a document or a completed exercise, because the readiness of a warning path is demonstrated rather than declared.

1. Population estimate including transient populations, and the number of messages per event.
2. Required rate from the volume and the window, with the assumptions recorded.
3. Subscriptions on more than one network, and estate not wholly inside the affected area.
4. Routing policy for a provider path, with the authority to switch named.
5. Queue visibility, expiry and priority grouping defined.
6. Measured per-operator acceptance rate, taken in advance.
7. Sender identity established and previously used for official messages.
8. Readiness test covering full-rate volume, path failure, expiry and record production.

Scope note: this article describes engineering capability, not the institutional framework for public warning. The decision to broadcast, the framework it is issued under, the wording used and the authority accountable for it are matters for the responsible public body, and the applicable rules differ by market.

One final element belongs in the readiness documentation: the person who can authorise a test and the person who can authorise a live send. Those are different authorities, and both should be named in advance with a deputy for each, because the moment when a warning is needed is not the moment to establish who may issue it. A readiness document that names no individual is a document that will be resolved by whoever is present.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How many messages per minute can an emergency broadcast system send?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The figure depends on the estate, the subscriptions and the rate the networks accept, which is why it should be measured in advance rather than estimated. Most owned estates require several paths to reach a large population inside a short window, and the acceptance rate per operator is the input that decides how many. Measure the accepted rate with the operators who cover the target area, because a figure from another market does not transfer.”
}
},
{
“@type”: “Question”,
“name”: “Should emergency messages be sent by SMS or by cell broadcast?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “They are different technologies with different characteristics, and which applies depends on the framework the responsible authority operates under. Confirm the position in each market with that authority rather than choosing a channel on technical grounds alone. Document which channel the authority has designated, because the choice is a regulatory decision rather than an engineering one and it has to be evidenced.”
}
},
{
“@type”: “Question”,
“name”: “Do recipients need to have consented to receive an emergency warning?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The consent position for public warning differs from commercial messaging and is set by the framework the authority operates under. That determination belongs with the authority rather than with the messaging operator, and it should be documented before a deployment is designed. Confirm the position in writing with the authority, and record who approved it, because a deployment designed on an assumption cannot be defended later.”
}
},
{
“@type”: “Question”,
“name”: “Why do we need the estate outside the affected area?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Because the event may be at the place the estate is installed. Site diversity is a specific requirement for this workload: an estate inside the affected area shares the failure it is meant to warn about, which is the case that redundancy has to cover. Design the second site outside the likely affected area, and test the failover between the two rather than describing it.”
}
}
]
}