An ARES alert system using listservs

ARES LogoLast night I was having a conversation with Marty KB3MXM, ARRL Maryland-DC (MDC) Section Manager, regarding notification of ARES® members in times of need, quickly.  This isn't the first time I've written about the topic and not much has changed.  Taking another look at the subject has given me the opportunity to look at some additional resources.

Various options are available today (each with their own pros and cons):

  • Phone trees
    • PRO: Simple, easy to establish
    • CON: Assumes telephony lines are up and not congested.  Also, calling the 500+ members in the MDC ARES team could take a while.
    • Pretty much every ARES organization has such a device as a means of communicating with their members.  It's cheap, simple, and easy to deploy although it could be time consuming to actually use.
  • Short Message Service (SMS) notification systems
    • PRO: Fast delivery of short messages to cellular phones.
    • CON: Assumes cellular circuits are available, solution can be costly, and may require Internet access to implement a notification.
    • Calvert County AUXCOMM currently uses ez texting to send SMS messages to all members.  At the time the account was established we were able to get a free account with ~100 SMS messages per month.  This type of account is no longer advertised.
    • See also, Multimedia Messaging Service (MMS)
  • Email Listservs
    • PRO: Simple to setup, can send messages to phones via SMS email addresses, regular email addresses, and Winlink addresses.  Email is fairly ubiquitous.
    • CON: Assumes Internet connectivity to the server, from the server to the client email servers, and then to the clients themselves.
    • Similarly to the phone tree, I suspect most ARES groups have one of these already setup and ready to go.
  • Transmitting messages across the radio
    • PRO: All radio with a potential for higher availability.
    • CON: Requires users to be monitoring  a particular frequency all the time.
    • The best case I've seen for this is in Connecticut ARES.  Their DMR network has an alert talkgroup that is silent but for alerts.  Because the system is all UHF the radios are small enough to be carried most places which increases the possibility that a user will have it monitoring the talkgroup for such a call-up.
    • Paging is also an option which could be successful.

There are likely additional means of communicating an alert message to ARES members and I'm sure they've been deployed with success somewhere (and if you know of any please leave a comment!).

The problem with most of these solutions is they require commercial infrastructure that may already be hampered by the emergency that the ARES members are needed for.  Obviously a hybrid approach is always going to be better.   With that in mind, lets discuss using a listserv to transmit alert and informational messages to members.

Listserv

Gnu_mailman_logo2010A listserv is just a system that retransmits email messages received to the list's subscribers.  The listserv may also store a copy of the message for subscribers or the public to review at a later date.  One popular implementation of a listserv server is GNU Mailman.  One could use existing solutions like Yahoo! Groups or Google Groups but these solutions scrape their data for advertisement purposes and can lead to spam and other activities that only degrade for the overall experience.  There is also no guaranteed availability with these solutions so it's likely not a good fit for emergency communications.  By now one can tell I'm advocating for managing your own infrastructure.  There's nothing like controlling your own information and making sure it stays secure.

Specific to the MDC section, multiple layers of listservs might be appropriate to allow an easy transmission to all or parts of the group. Individuals are added to their county(ies), district lists only address the county lists below them, and the MDC list only addresses the district lists:

  • Maryland-DC - MDC-ARES-All@
    • Eastern District MDC-ARES-East@
      • Caroline - MDC-ARES-CARO@
      • Denton
      • Dorchester
      • Kent
      • Ocean City
      • Queen Anne's
      • Somerset
      • Talbot
      • Wicomico
      • Worchester
    • Central District
      • Anne Arundel
      • Baltimore City
      • Baltimore County
      • Calvert
      • Cecil
      • Charles
      • DC
      • Harford
      • Howard
      • Montgomery
      • Prince Georges
      • Saint Marys
    • Western District
      • Allegany
      • Carroll
      • Frederick
      • Garrett
      • Washington

Administration and sending permissions would also be limited to specific addresses at a particular level.  An EC would be able to send a message to their specific county, and perhaps their district, but not to the entire section.  List membership would be managed at the local level by the EC or their designated alternate (AECs?).  One change, one place, would be all that is needed to maintain the entire chain.

The latest version of Mailman supports a forum-type of interface in addition to email delivery so one could input a message via a website if email wasn't available.

Duplication of these layers may be desired to support non-alert messages (routine, informational) that would likely be larger than what could be handled by SMS.  Additional lists could be used for specific section-level nets (e.g. MEPN, MDD) or local nets (BTN) to alert members to an other-than-regular call-up.  Likewise, it might be beneficial to also setup a layer including management (SEC, DECs, ECs, and AECs) when notification of all members isn't warranted (planning).

What about SMS?

SMS can actually be handled by a listserv fairly easily.  Every SMS account actually has an email address attached to it (as listed in the National Interoperability Field Operations Guide, Version 1.5):

ARES members would need to provide their cellular phone number and carrier so they could be added to the list.

But what about using the radio?

Call frequencies and primary repeater

Members that, as a matter of routine, monitor their local ARES repeater or a specific frequency that is used for emergencies can also be alerted in such a manner.  It's important to not count out the simple approach of being able to simply do a call-up on the local repeater as a means of notifying members of an emergency.

Assumptions

It is assumed that a total Internet failure has not occurred.  A system like this is dependent upon Internet connectivity not only between the user's email client and user's email SMTP server but also to the subscribers' SMTP servers and subscribers' clients.  It assumed that notifications sent would occur before the communications emergency actually started or that at least some of the members would receive the message and word could be passed using an additional method (e.g phone tree, repeater call-up) to notify those not yet participating.

There is also an assumption that users have a cellular phone, email address, or Winlink account and that these communications mechanisms are checked regularly.

Conclusion

While there are several ways of notifying ARES members of a communications emergency this shows one way of doing so utilizing a mechanism that is, from the user's point of view, very simple.  We shouldn't let "this isn't a perfect solution" hold us back from "better than we have now" and "yet another tool".  Utilizing a series of listservs could potentially deliver an alert message to all users within a few seconds and this is definitely better than what we have today.