SMS Hardware for Utility Outage Notifications: Hardware Choices for High-Volume Public Alerts

A utility notification is unusual because the sender and the recipient share the same failure. When the power goes out, the customers need to be told, and the site that would tell them may be on the same network that just went down.

This article sets out the notification tiers a utility has to support, how delivering to a service area differs from delivering to a marketing list, how volume behaves in a wide outage, and how redundancy has to be arranged when the site itself is affected.

What are the notification tiers for utility outage SMS hardware?

Safety, restoration and information.

Each tier has a different audience, a different tolerance for delay and a different consequence when it fails.

Safety notifications concern something the recipient must act on, such as avoiding a flooded substation or a gas leak, and they reach everyone in the affected area with the minimum possible delay. Restoration notifications concern the state of the service, such as an estimated restoration time or a change to it, and they reach the affected customers whose contact details are known. Information notifications concern everything else, including planned maintenance and billing, and they tolerate the schedule that suits the operation.

Separating the tiers is what makes the estate designable, because each tier implies a different delivery requirement. A single system that sends everything at the same priority produces a queue in which a routine notice can delay a safety message, which is the failure that a tier separation is designed to prevent. The message path is the same in all three cases, defined in ETSI TS 123 040 and 3GPP TS 23.040.

Tier	Audience	Delivery requirement
Safety	Everyone in the affected area	Minimum delay, priority over everything else
Restoration	Affected registered customers	Inside the stated update interval
Information	Subscribers by preference	Scheduled
Planned maintenance	Affected registered customers	Inside the notice period

Delivering to a defined service area

The audience is geographic, and the contact list is a subset of it.

A utility knows where the fault is and needs to reach the people in that area, while the contacts it holds are only those customers who registered them.

That gap is the defining constraint of utility messaging. The registered contact list covers a proportion of the affected population, and the proportion varies by area and by customer type. Where a safety notification has to reach everyone, the messaging channel has to be complemented by something else, such as a public warning scheme or a site-based announcement, and the design should state which channel covers which part of the audience rather than assuming the list is complete.

The list also has to be selected by area rather than by segment. That means the distribution network topology and the customer records have to be joinable, so that a fault on a specific feeder produces a specific set of contacts. Where the join is not possible, the practical fallback is selection by postcode range or by substation, which is less precise and still far better than sending to the whole customer base.

Volume during a wide outage and how to pace it

A wide outage produces a burst that no average day describes.

A fault affecting a large area generates notifications to a substantial share of the customer base within minutes, and the volume is a function of the fault rather than of the schedule.

Three characteristics shape the design. The burst arrives without notice, so capacity has to be available rather than scalable on demand. It is geographically concentrated, which concentrates the destination ranges and can stress a specific part of the network. And it is followed by a second wave of update messages, because customers expect restoration information as the work progresses. A design that accommodates the first message but not the updates will deliver the first and queue the rest.

The pacing decision follows from the tier. Safety messages should be paced only to the rate the networks accept, while restoration updates can be shaped to the interval the utility has promised. Where the estate cannot carry the burst, the routing policy should allow an alternative path to be used without a configuration change, and the decision to switch should have a named owner. Fault management concepts, including thresholds and clearing conditions, are organised in ITU-T M.3400.

One further practice makes the capability maintainable: rehearse the audience selection as often as the send. A selection that worked for the last fault may fail for the next one if the topology join has changed, and a rehearsal that resolves a feeder to a contact set takes minutes while the same discovery during an event costs hours.

Redundancy when the site has lost power or backhaul

The affected site is part of the problem.

An estate installed in the area that has lost power shares the failure it is meant to report, which is the case that redundancy has to address specifically.

Three measures cover most of it. Site diversity, so that the estate is not wholly inside the affected area, which usually means a second location outside the distribution territory or at least outside the fault zone. Power independence, so that the sending capability does not depend on the supply it is reporting on, which is a battery or a separate feed rather than the same feed as the substation. And connectivity independence, since the backhaul may be affected by the same event, which means a second path that does not traverse the same infrastructure.

Each of those is a design decision with a cost, and the appropriate combination follows from what the utility has promised for each tier. A safety notification that cannot be delivered because the estate lost power is the failure that a regulator or an enquiry will examine, and it is worth designing against explicitly rather than assuming that a second unit in the same room provides cover. Contingency planning and testing as control objectives are organised in NIST SP 800-53 Rev. 5.

Record-keeping for regulated utilities

The record is part of the regulatory position.

Utilities are commonly required to demonstrate that notifications were made, to whom and when, and the record therefore has to be produced from systems the utility controls.

Four fields make that answerable: the event identifier, the area or feeder that defined the audience, the delivery outcome per recipient with its timestamp, and the channel used. Keeping the audience selection with the record matters because the question asked afterwards is often about coverage rather than about delivery: was a particular street included, and if not, why not. That question can only be answered if the selection is recorded at the time of sending rather than reconstructed from the fault record.

The record also has to survive the platforms. Sending platforms change, device logs are short-lived, and the retention requirement for a regulatory record typically exceeds both. Exporting the relevant fields to storage the utility controls, on a schedule, is what makes the record durable, and record-keeping practice for the operational logs involved is covered in NIST SP 800-92.

Consent and non-marketing messaging

Utility notifications are not marketing, and the distinction should be visible in the platform.

A customer who has declined marketing messages should still receive a safety notification, and the platform should enforce that rather than leave it to a list selection.

The practical arrangement is to classify every template by tier and to allow the safety and restoration tiers to send regardless of marketing preference, while the information tier respects it. That classification has to be enforced at the point of sending, because a list built for an outage and reused for a maintenance notice is the route by which a safety category becomes a marketing send. The consent position itself depends on the market and on the framework the utility operates under; where the processing falls within the European framework, the reference points are the regulation on EUR-Lex and the guidance collected by the European Data Protection Board.

Two further design points follow. A notification should identify the utility through an identity used consistently, so that it is recognised during an event. And it should not require a link, because the customer may be without data as well as without power, which is precisely the situation the message addresses.

A deployment outline

The outline works from the notification tiers outwards to the hardware and the records. It is written around the dependencies rather than the equipment, because independence of power, connectivity and site is what decides whether a notification can be sent at all.

1. Define the notification tiers and the delivery requirement for each.
2. Make the customer records joinable to the network topology, so that an area can be selected.
3. State which channel covers the part of the audience that holds no registered contact.
4. Estimate the burst from the largest realistic fault and divide it by the window.
5. Arrange site, power and connectivity independence, and record which measure covers which failure.
6. Set the routing policy for an alternative path, with a named owner for the switch.
7. Record the event identifier, the audience selection, the outcome and the channel per recipient.
8. Classify templates by tier, and enforce the tier at the point of sending.

The outline produces a notification capability that is designed around the fact that the utility and its customers share the event. That single observation is what drives the site, power and connectivity requirements, and it is the part most often omitted when a notification system is planned like a marketing platform.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Can you send a text message when the power is out?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “The message can be sent if the sending estate has power and connectivity independent of the affected supply, and if the mobile network covering the recipient still operates. Both conditions matter, which is why site, power and connectivity independence are separate requirements rather than one measure. Record which of the three dependencies is satisfied at each site, because a site that fails one of them cannot be relied on for the others.”
}
},
{
“@type”: “Question”,
“name”: “Is there a device that notifies you when the power goes out?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Devices exist that detect a loss of supply at a location and send a notification, and they are a different proposition from a utility notification system. The first monitors one site; the second has to reach a defined service area, which brings audience selection, tier separation and regulatory records into scope. Decide which of the two the deployment is, because the requirement and the records are different for each.”
}
},
{
“@type”: “Question”,
“name”: “How does a utility know which customers to notify?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “By joining the fault location to the customer records through the distribution topology, which allows a feeder or a substation to resolve to a set of contacts. Where that join is not possible, selection by postcode range is a workable approximation, provided the audience definition is recorded with the send. Record the audience definition with each send, because a later question about coverage is answered from that record rather than from memory.”
}
},
{
“@type”: “Question”,
“name”: “Do outage notifications need marketing consent?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “They are service communications rather than marketing, and a customer who has declined marketing should still receive a safety notification. The position depends on the market and on the framework the utility operates under, and it should be confirmed with the compliance owner. Confirm the position with the compliance owner and record the answer per market, because a safety notification and a marketing message follow different rules.”
}
}
]
}