Hurricane Sandy and EAS-CAP

Carl-Weinschenk-2

By Carl Weinschenk Senior Editor

Cable operators and others have labored for years to comply with rules extending the Emergency Alert System (EAS) to include the Common Alerting Protocol (CAP). CAP is a structure for integrating messages from a wide number of sources and sending them in a data format that makes them usable on the networks commonly used today. The impetus was to avoid the kind of confusion that exacerbated the confusion surrounding Hurricane Katrina in 2005. The deadline for compliance was June 30.

It is reasonable to expect that when Hurricane Sandy lashed New York, New Jersey and other areas, that EAS-CAP would do its job and alert people to the dangers. Indeed, Hurricane Sandy seemed perfect to be EAS-CAP's coming out party. Though the storm was taken seriously, it quickly became apparent that the dangers were far greater than anticipated. Surely, this was just the type of fluid and escalating situation for which EAS-CAP was designed.

The reality is, however, that EAS-CAP was not used during Hurricane Sandy.

The storm was taken seriously, but conditions deteriorated more quickly than even the prudent anticipated on the night of Oct. 29. Despite the dire situation, only three messages were released over the Integrated Public Alert and Warning System (IPAWS) system, one of the main pieces of governmental infrastructure that feeds EAS-CAP. Those messages, said Ed Czarnecki, the senior director for strategy, development and regulatory affairs at Monroe Electronics, were aimed at cell phones, not cable distribution. One was for an evacuation, one a flash flood warning and another, inexplicably, for a blizzard.

Several entities are entitled to send out EAS messages, including the National Weather Service and state and local emergency officials. Ultimately, the network service provider decides what messages to carry. They don't always use all the tools at their disposal. For whatever reason, the EAS systems - legacy or CAP-enabled - were on the sidelines.

IPAWS uses the Internet to distribute data to various wired or wireless service providers and carriers. Perhaps one reason the system didn't play a major role was simply that Internet and broadband were early casualties of the storm and were down in most areas. Czarnecki points to a simulation by Renesys that shows how widespread Internet outages were during the storm.

There are at least three interrelated reasons that consistent emergency messaging is difficult: There are many organizations, offices and departments that hold various pieces of important information. Coordinating this data into coherent messages and delivering them to the right end points is monstrously complex, even in calm conditions. Emergencies of course are anything but calm, so difficult tasks become orders of magnitude more confusing. Finally, networks that under most conditions are reliable and stable can be extremely restricted or completely out of commission.

Those issues certainly make use of any communications conduit difficult. But the point is that that is exactly what EAS-CAP is all about: Simplifying and increasing the chances that people indeed do get the information that they need. At the end of the day, the folks who are in charge of the structure of emergency communications need to do a deep post mortem on Hurricane Sandy and EAS-CAP.

It’s good to see that the FCC is moving ahead. For instance, the commission released a Notice of Proposed Rulemaking on making emergency communications more useful to the sight-impaired. This likely will impact EAS-CAP.

Alerting millions of people to emergencies that are changing in real time is a gargantuan task. To an outsider, Hurricane Sandy was the perfect opportunity to prove that the effort cable operators and others have expended on EAS-CAP was worth it. Perhaps there are good reasons that it played virtually no role - and perhaps there are lessons to be learned in anticipation of the next emergency which, sadly, is inevitable.

Carl Weinschenk is the Senior Editor of Broadband Technology Report. Reach him at carl@btreport.net.


Easily post a comment below using your Linkedin, Twitter, Google or Facebook account.

BTR Blogs

Mark Johnson, Alticast

Guest Blog: RDK Application Framework Considerations

June 18, 2014 Cable operator enthusiasm for the Reference Design Kit (RDK) is growing ...
Tim Hermes, BTR Founder and Publisher

I'm a Believer

June 11, 2014 I guess it was 3D that made me sketchy. 3D's quiet fade-to-black was not...
Carl Weinschenk

Two Things You Can Get in Kansas City: Super Steaks and Super Broadband

May 28, 2014 Google is picking its spots: It is highly unlikely that the company real...

White Papers & Special Reports

HEVC: New Tools, New Challenges

June 2014 High Efficiency Video Coding (HEVC) is the next step in video compression. Ca...

Managing the challenges of UHF leakage and interference to LTE

June 2014 For decades cable operators have managed signal leakage by monitoring in or n...

Traveling Money: Upgrade Field Force and Fleet Management

May 2014 It is technically possible to separate field force and fleet management: One ...

CONNECT WITH US

Webcasts

There is no current content available.

Featured Hangout

Leakage, Ingress and Interference in Digital Cable Networks

March 13, 2014

Join us for BTR’s fourth Google Hangout – this time on UHF leakage and LTE interference – with Nick Segura (Charter) and Ron Hranac (Cisco).
Sponsored by Trilithic.