The scope of the 110 page Third Further Notice of Proposed Rulemaking (FCC 11-82) reviewing the Emergency Alert System makes it seem that there's a good chance that the Sept. 30, 2011 deadline may be extended. The NPRM seeks comment on whether the deadline is sufficient or "whether the Commission should extend or modify it so it is triggered by some action other than FEMA's adoption of CAP, such as implementation of revised certification rules."
The proposed rules attached to the NPRM include Section 11.56, "Obligation to Process CAP-Formatted EAS messages." Under the rules, EAS participants may comply with Section 11.56 requirements by deploying an "intermediary device" that "acquires the CAP-formatted message, converts it into an EAS Protocol-compliant message, and inputs such EAS Protocol-compliant message into a separate EAS decoder, EAS encoder, or unit combining such decoder and encoder functions, for further processing in accordance with the other sections of this part."
The NPRM seeks comment as to whether these intermediary devices should be permitted, and if so, how should they be certified.
Use of such intermediary devices would allow stations to continue to use their existing EAS decoders/encoders. However, given that most of these devices were installed when EAS replaced EBS in 1997, I suspect that most stations will want to replace their old EAN systems with newer CAP-compliant systems, if they haven't done so already.
The FCC tentatively decided not to take the opportunity, as suggested by the NAB, to replace the SAME (Specific Area Message Encoding) protocol used by EAN with a fully CAP-centric EAS system, although it requested comment on the proposal. (The NPRM asks, "How long will it take to switch to a CAP-centric EAS system?" and "What are the costs and benefits associated with a CAP-centric EAS system?")
One of the problems in conversion of RSS Version 2 CAP data to the SAME format currently used by EAS is that CAP has more elements, including free form text and optional elements that different devices could convert to different EAS messages. This could lead to viewer confusion.
Sage, an EAS equipment manufacturer commented:
"The CAP protocol is significantly more complex than EAS, with even greater opportunity for slight differences in implementations and procedures to cause a failure to deliver consistent results to EAS participants."
One of the issues the NPRM addresses is how to convert CAP messages to SAME format for EAS. FEMA announced that it had adopted the EAS-CAP industry group (ECIG) "ECIG Implementation Guide," which specifies how CAP messages are to be translated into SAME. Commenters in the previous NPRM recommended that the FCC amend Part 11 to require compliance with this document.
One of the complications that can arise in converting CAP to SAME is that CAP messages can include audio files or URLs for streaming audio. This raises the question as to how EAS participants would rely on such data.
In addressing this issue, the FCC asked, "If an EAS Participant cannot encode the audio portion of a CAP-formatted message in a SAME-compliant manner, would the audio portion of CAP messages be limited to EAS Participants that initially receive such messages via IP-based connections?"
The Commission further asked if such an approach represented a "cost-effective means for achieving uniform consistency across devices and delivery platforms in how CAP alert messages are presented to the public," or if there were alternative proposals for achieving the same results that would be "less burdensome" to equipment makers and/or EAS participants.
Considering that some of these critical issues are undecided, it seems unlikely the FCC will be able to hold to the original Sept. 30, 2011 deadline. The NPRM was released on May 26, 2011 and reply comments are not due until 45 days after it's published in the Federal Register. This means that the FCC will have to wait until mid July at the earliest to review all the comments and to adopt final rules.
