Roland Lussier Broadcasters are concerned with the Federal Communications Commission Report and Order, issued in EB Docket 04-296, regarding the Common Alerting Protocol and the Emergency Alert System. Although there has been much discussion, many unsolved mysteries remain.
CAP by nature is a file-based protocol that was presented to allow a standardization of both the structuring and sending of alert and warning messages between systems and users. If you examine the CAP file itself, you will find that it is an XML file, which is really nothing more than a readable text document.
What CAP does for the emergency management community is to define many of the fields that are required to present an individual with the information he or she needs to make an informed decision for protective action.
The file structure and protocol was worked out mostly by Art Botterell, manager of a community warning system for the Sheriff’s Department of Contra Costa County in California, and others who were involved with the Partnership for Public Warning.
The protocol is now accepted by the Organization for the Advancement of Structured Information Standards (OASIS), and as such, it holds considerable promise for defining data exchange formats in emergency messaging.
The EAS system as we know it is essentially an audio store and forward system, with minimum additional information and data capability. The FCC has indicated in its R&O that all broadcasters must be able to receive a CAP file within 180 days of the adoption of CAP as a standard by the Department of Homeland Security.
Most broadcasters and experts in the field are at a loss to define what this really means, and the commission is not providing guidance as to its actual intention in providing this ruling.
On the surface, one could presume that the commission simply wanted the next generation of EAS to be able to benefit from the additional information that a CAP-based alert could provide.
However upon closer examination, the problems associated with the R&O become many and complex.
For example if the CAP file is a text document — and by definition it is — how then would a CAP-compliant decoder process an Emergency Activation Notification?
If the CAP alert is really an XML document in file form, how will it be transported, and from where would a broadcaster actually receive it? How would authentication be performed on CAP alerts to assure their authenticity?
Who will be responsible for establishing and maintaining a network of CAP exchange servers? Would there need to be a central CAP aggregator, with redundant communications paths and geographic redundancy? These are, at the least, interesting questions.
CAP and the EAN
From the federal perspective, at least historically, the EAS system has really had only one purpose: to carry an Emergency Activation Notification.
An EAN is composed of an initial burst of Specific Area Message Encoding (SAME) code data followed by the required attention signal, and then the live streaming presidential audio is present for an undetermined duration.
At this point, the president has complete control of the airways, and broadcasters must either yield their airtime or go off the air. No one really knows how long a president might need to address the nation during such an emergency, but when he or she is finished the Endecs at FEMA’s operations centers will send an “End of Message” notice and normal programming can resume.
I mentioned earlier that the CAP alert is actually a text document. As such it has no capability for distributing live audio.
CAP is a file, not a stream, and it was never intended to support live audio. In fact, there is no method possible that would allow a CAP file to include live audio.
A CAP file could reference an attached file that is a recorded audio file, or a CAP file can be constructed to contain an audio file that is embedded using base 64 encoding within the text body of the CAP message; but a file is still a file; it cannot be used to stream live audio of undetermined duration.
How then would a CAP-based messaging system support the requirements of the EAN?
One method to achieve this would be to use a parameter within the CAP file to point to or reference an outside resource on the Web that broadcaster equipment would connect to and initiate a streaming live audio download.
A CAP alert file would be sent both at the beginning — and at the end — of the message to alert the decoder that live audio is available at a specified URL. This is the method that the EAS CAP Industry Group (eas-cap.org) has suggested in its proposed EAS-CAP Profile Recommendation document.
There are a lot of problems with using a method in which the CAP-compliant Endec makes a separate connection to an outside resource URL to receive the live stream; particularly when we consider using it to support an EAN, which by definition is intended to include more than 20,000 broadcast outlets.
One area of concern is the bandwidth required to support these connections. The industry group has suggested that two protocols be supported: the standard (read “bandwidth-hogging”) WAV format and the MP3 format, which greatly reduces the required bandwidth.
The EAS CAP Industry Group suggests in its document that both be supported since the WAV format is free while the MP3 format has a cost associated with it. I see no reason for this accommodation, since the license cost for an MP3 decoder typically is only 75 cents per license.
Weak links?
For purposes of discussion, we will assume that the MP3 format is chosen; we now need to support delivering live presidential audio to our state, which has 100 broadcast sites. The bandwidth required to support steaming MP3 audio to these 100 sites would be 2.5 megabits per second.
If we use the WAV format proposed, the bandwidth would grow to 6.4 Mbps. This bandwidth needs to be continuously allocated, and remain available until the end of the presidential address.
In order to deliver this type of bandwidth, it will be necessary to use a distributed model for the CAP servers. This would most likely result in at least one server per state that is receiving the CAP message from another server or source, somewhat in the same manner that an LP1 station monitors a PEP station.
I wonder if anyone has really given that any thought? It would seem that the system as conceived would become dependent on the integrity of the links between CAP servers and sources through the Internet, quite similar to the existing daisy chain.
This seems somewhat shortsighted when we consider that the requirements document (a presidential order) for an EAN specifically indicates that the system must be in place to allow the president to address the nation when all other means of normal communications are no longer available. My bet is that the old Primary Entry Point to LP1/LP2 daisy chain would have a better chance of success than a network of Internet-based servers.
This begs another question: Who is going to supply and maintain the infrastructure of CAP servers? It seems that the supporters of Web-based solutions are envisioning multiple CAP servers, all pretty much doing their own thing.
As a broadcaster, the CAP server to which you connect for presidential messages might not be the same box to which you connect for a message from your state emergency management agency, or for an Amber alert. They certainly could be, they certainly should be; but nothing says that they must be because there really isn’t anyone in charge of coordination.
How then will broadcasters know what to monitor, and if that particular server is even accessible through the Internet at any given time? If a link or a server were to fail, how much of the delivery infrastructure would be affected?
Trust but validate
Another area that has not been addressed has to do with security. This is of particular interest when it applies to the transmission of an EAN. The CAP protocol supports digital signatures based upon digital certificates.
If we receive a CAP message, how do we know that it is validated and actionable? Presumably if the message has the proper digital credentials it would be authenticated, but bear in mind that this message probably came to us via the Internet. If we are going to use digital certificates, who will act as the issuing authority for those certificates, and who will manage that effort?
The proposed deployment of CAP involves many mysteries. Perhaps one of the greatest is why the federal agencies believe that they can design this system without engaging and including stakeholders in the emergency management and broadcast communities.
The development of effective alert and warning capabilities has never been about technology; the technological solutions have been at hand for years. The challenges that must be overcome lie more in the realm of policy.
The author is president and chief executive officer of Communications Laboratories of Melbourne, Fla., a government contractor with responsibility for the national EAS capability, the National Warning System and the Emergency Management Network.
Radio World welcomes other points of view.
