Federal Communications Commission
News Media Information 202 / 418-0500
445 12th Street, S.W.
Fax-On-Demand 202 / 418-2830
Washington, D.C. 20554
TTY 202 / 418-2555
Released: September 23, 2013
PUBLIC SAFETY AND HOMELAND SECURITY BUREAU SEEKS COMMENT REGARDING
EQUIPMENT AND OPERATIONAL ISSUES IDENTIFIED FOLLOWING THE FIRST
NATIONWIDE TEST OF THE EMERGENCY ALERT SYSTEM
EB Docket No. 04-296
Comments Due: October 23, 2013
Reply Comments Due: November 7, 2013
By this Public Notice
, issued under delegated authority pursuant to section 0.392 of the Federal
Communications Commission (FCC or Commission) rules,1 the Public Safety and Homeland Security
Bureau (Bureau) seeks comment on various equipment and operational issues identified following the
first-ever nationwide test of the Emergency Alert System (EAS)2 conducted by the FCC and the Federal
Emergency Management Agency (FEMA) at 2:00 p.m. EST, on November 9, 2011 (Nationwide EAS
Test).3 These issues include, but are not limited to, those that the Commission had delegated to the
Bureau to resolve on a one-time, operational basis for purposes of conducting the Nationwide EAS Test.4
With this Public Notice
, the Bureau now initiates a dialogue with EAS stakeholders to develop
recommendations for Commission action, if any, to address these issues. The Bureau will consider all
1 47 C.F.R. 0.392.
2 A comprehensive overview of the EAS is contained in the Fifth Report and Order
in this docket. See
the Emergency Alert System; Independent Spanish Broadcasters Association, The Office of Communication of the
United Church of Christ, Inc., and the Minority Media and Telecommunications Council, Petition for Immediate
Relief, EB Docket No. 04-296, Fifth Report and Order
, 27 FCC Rcd 642 (2012) (Fifth Report and Order
). As the
Commission explained, the EAS is a hierarchical alert message distribution system in which a message originator
at the local, state, or national level formats a message in the EAS Protocol, initiates the transmission of such
message at a designated entry point into the system, and from which is relayed from one designated station to
another. See id
., 27 FCC Rcd 646-47, 7. The FCC's EAS rules can be found at 47 C.F.R. 11.1, et seq
Strengthening the Emergency Alert System (EAS): Lessons Learned from the Nationwide EAS Test (EAS
Nationwide Test Report
) (Apr. 2013), available at http://www.fcc.gov/document/strengthening-emergency-alert
system (last visited Sept. 19, 2013).
Review of the Emergency Alert System, EB Docket No. 04-296, Third Report and Order,
26 FCC Rcd 1460
(2011) (Third Report and Order
comments filed in response to this Public Notice
as it develops its recommendations regarding any further
action, including issuance by the full Commission of a Notice of Proposed Rulemaking on some, if not
all, of these issues.
The purpose of the Nationwide EAS Test was to allow FEMA and the FCC to assess how the
national EAS architecture would perform in practice, and to develop and implement any necessary
improvements to ensure that the EAS, if activated in a real emergency, would perform as designed. The
Nationwide EAS Test involved the simultaneous transmission, receipt and broadcast of a "live" national
EAS alert by FEMA and thousands of broadcasters, cable operators and other EAS Participants5 across
the United States and its territories.6 Specifically, FEMA successfully initiated an Emergency Action
Notification (EAN), the EAS event code that would be used for an actual Presidential activation of the
nationwide EAS.7 FEMA delivered the EAN to the EAS Primary Entry Point (PEP) stations,8 which in
turn distributed the EAN throughout the nation via the EAS's so-called "daisy chain" process.9
The EAN is the linchpin of a Presidential alert, as an EAN opens a live audio channel to the
President, and all EAS Participants are required to transmit immediately upon receipt of an EAN.10 Both
the Commission and FEMA reached the conclusion that the EAN should be used during the first
nationwide test to hew as closely as possible to the process that would be followed in the event an actual
5 EAS Participants are the regulated entities that receive and broadcast alerts. These entities are defined in Section
11.11(a) of the Commission's rules and include radio and television broadcast stations, cable systems, wireline
video systems, wireless cable systems, direct broadcast satellite (DBS) service providers, and digital audio radio
service (SDARS) providers. See
47 C.F.R. 11.11(a).
6 See EAS Nationwide Test Report
7 The EAN is followed by an audio transmission of Presidential Messages. See
., 47 C.F.R 11.51(a). Only
the President may issue an EAN for a Presidential alert, and, to date, no President has ever done so.
8 Primary Entry Point (PEP) stations are private or commercial radio broadcast stations that cooperatively
participate with FEMA to provide emergency alert and warning information to the public prior to, during, and after
incidents and disasters. See
47 C.F.R 11.2(b). The PEP stations also serve as the primary source of initial
broadcast for a Presidential or National EAS message. This select group of geographically distributed,
independently powered, and electromagnetic pulse (EMP) hardened radio stations collectively can reach over 90%
of the American populace.
9 Under the EAS protocol, an EAS alert uses a four-part message: (1) preamble and EAS header codes (which
contain information regarding the identity of the sender, the type of emergency, its location, and the valid time
period of the alert); (2) audio attention signal; (3) message; and (4) preamble and "end of message" (EOM) codes. See
47 C.F.R. 11.31(a). At the national level, EAS message distribution starts at PEP stations, which are
designated and tasked by FEMA to transmit "Presidential Level" messages initiated by FEMA. See Fifth Report
, 27 FCC Rcd 642, 646-47, 7. The PEP stations broadcast the EAN to the public and encode the EAN
to be rebroadcast by "Local Primary" (LP) stations that monitor the PEP and in turn rebroadcast the EAN and
encode it for rebroadcasting by all other EAS Participants. See id
. This process of relaying EAS messages from
station to station is often referred to as the "daisy chain." See id
47 C.F.R. 11.53(e) and 11.54.
emergency prompted the President to trigger the EAS.11 In ordering the use of the EAN for this test, the
Commission specifically found that only the EAN could replicate the actual promulgation of a
presidential level message and thus provide an accurate assessment of how the national EAS would
function in the event of an actual Presidential alert.12 EAS Participants were required to submit test result
data to the Commission following the Nationwide EAS Test.13 The Bureau received and analyzed test
result data from over 16,000 EAS Participants, and held discussions with EAS Participants, FEMA and
other EAS stakeholders to analyze the test's results.
On April 12, 2013, the Bureau released the EAS Nationwide Test Report
, which described the
steps leading up to the test, the test itself, lessons learned from the test, and included several
recommendations to the Commission regarding actions designed to strengthen the EAS.14 As explained
in the EAS Nationwide Test Report
, the Bureau and FEMA concluded that the test demonstrated the EAS
to be fundamentally sound.15 The Bureau observed, however, that the test uncovered several problems
that impeded the ability of some EAS Participants to receive and/or retransmit the EAN, including
anomalies in EAS equipment programming and operation that appeared to have led to inconsistent
Issues for Comment
1. Application of EAS Header Code Elements to a Presidential Alert
Section 11.31 of the Commission's EAS rules establishes the "EAS protocol," a four part
message that constitutes the elements of an EAS alert.17 One essential element of the EAS protocol is the
"Header Code," which contains basic identifying information about the alert, such as the identity of the
message originator, the type of event, the geographic location for the alert, the valid time period for the
message, the date and time of release of the message by its originator, and the identification of the entity
transmitting or retransmitting the message.18
Recognition and Processing of Header Code Elements.
The Nationwide EAS Test disclosed that
different manufacturers' brands of EAS equipment did not recognize and process the various Header
Code elements in a uniform manner during the test. For example, as discussed in more detail below,
11 See Third Report and Order,
26 FCC Rcd 1460, 1469-70, 22-24.
12 See id
47 C.F.R. 11.61(a)(3)(iv).
14 See EAS Nationwide Test Report
, n.3, supra
15 See id.
16 See id
. at 13, 15-16.
17 47 C.F.R. 11.31(a). The components of the EAS protocol are the Preamble and EAS header codes; audio
Attention Signal; message; and, Preamble and EAS End Of Message (EOM) Codes. Id.
; see also
18 47 C.F.R. 11.31(c).
some equipment initiated the test immediately upon receipt of the EAN from FEMA at 2:00 p.m. EST,
consistent with the highly publicized schedule for the test,19 whereas other equipment delayed the start of
the test until 2:03 p.m. EST, to coincide with the time of release of the message by its originator (hereafter
referred to as "Time of Release") indicated in the Header Code.20 This discrepancy caused a number of
EAS Participants to initiate the test at 2:03 EST, three minutes after the scheduled start of the test.21 We
note that the EAS is designed to provide the President with real-time access to the nation's airwaves. We
seek comment on what impact, if any, a discrepancy between the time an EAN is received by an EAS
Participant and the Time of Release indicated in the Header Code would have on the public's ability to
obtain important information from the President in an actual emergency.
The Bureau is concerned that differences in the way specific EAS equipment is designed and/or
programmed to recognize and process EAS Header Code elements may have contributed to the
performance discrepancies that occurred during the test. We thus seek comment on the various ways in
which EAS equipment is designed and/or programmed to process the various Header Code elements
during an EAN activation. Commenting equipment manufacturers should indicate the extent to which
their EAS equipment is programmed to recognize and apply any, all, or none of the elements of a Header
Code when the event code is an EAN. We also seek comment about how differences in the way EAS
equipment is designed and/or programmed to process the EAS Header Code may affect how the public
sees or receives an EAS alert during an EAN activation.
Further, we seek comment on whether the unique nature of the EAN as a mandatory nationwide
live alert obviates the need for some or all of the other elements of the Header Code. For example, does
the fact that an EAN is a national event that must be broadcast immediately upon receipt obviate the need
for location and Time of Release codes?22 Commenters should address each Header Code element
specifically, noting the reasons why (or why not) EAS equipment delivering an EAN should recognize
and adhere to the specifics of any, all, or none of the Header Code elements. Such reasons may be
directly related to what is technically required for the delivery of the EAN, or they may be based on other
reasons. For example, would failure to read and verify any, all, or none of the data elements in the EAS
Header Code raise EAS equipment or system security concerns?
Moreover, Section 11.31(c) of the Commission's rules states that the EAS protocol "must not be
amended, extended or abridged without FCC authorization."23 We seek comment on whether parties
view this rule as applying in an EAN activation, and, if so, how it applies. Do EAS Participants and other
stakeholders believe that this rule needs to be clarified or revised to ensure that EAS equipment processes
EANs in a consistent manner? For example, to the extent that commenters believe that one or more of the
19 See EAS Nationwide Test Report
20 See EAS Nationwide Test Report
21 See id
. See also http://radiomagonline.com/viewpoint/passing_the_eas_test_1211/
(noting "few EAS units that
delayed relaying for three minutes"), http://www.satelliteguys.us/threads/271358-DISH-Fails-EAS-Test-No
Perhaps-the-EAS-Test-Fails-DISH!?s=cd5970bb148debf38baf8d078a9d4161 (noting Comcast in Hartford ran the
test at 2:03 p.m.) (last visited Sept. 19, 2013).
47 C.F.R. 11.51(m)(2).
47 C.F.R. 11.31(c).
elements of the Header Code is not necessary where the event code is an EAN, should we propose to
revise or clarify Section 11.31(c) to reflect this? If so, how should the Commission revise or clarify the
rule? Alternatively, if commenters believe that the rule requires that all EAS equipment recognize and
process each of the elements in an EAS Header Code before retransmitting an EAN, are any revisions or
clarifications of the rule necessary? For example, would the Commission need to clarify Section 11.31 to
provide that EAS equipment can be designed and/or programmed to provide that an EAN activation
trumps all other Header Code elements?
Finally, what costs, if any, would EAS Participants incur to ensure that their EAS equipment can
recognize and process all or some of those elements, including any costs for reprogramming, equipment
replacement, or other related adjustments necessary to achieve this result? What are the benefits, and
would they justify any of the identified costs? In responding to these questions, we ask that commenters
identify both costs and benefits with specificity and explain how they weigh against each other.
The section above focused on seeking comment on the treatment of Header Code elements
generally. We now turn to questions regarding two particular elements of the Header Code the Time of
Release and location codes.
Time of Release Code
. As detailed in the EAS Nationwide Test Report
, the Nationwide EAS Test
had been scheduled for 2:00 p.m. EST on November 9, 2011, a date and time of day for which FEMA and
the Commission had engaged in significant governmental and public outreach to publicize.24
Nonetheless, certain EAS Participants initiated the Nationwide EAS Test at 2:03 p.m., three minutes after
the test had been scheduled. Although the EAN was received by EAS Participants at approximately 2:00
p.m. EST, we understand that the alert may have also included a Time of Release of 2:03 p.m. EST in the
Header Code, which may have contributed to the three minute discrepancy.25 We seek comment on
whether certain EAS equipment adheres to the Time of Release Code, even if it is different than the time
of the EAN. Does some EAS equipment "intentionally" disregard the Time of Release code and
broadcast an EAN immediately upon its receipt? What impact, other than potentially delaying the
broadcast of an EAN, do these equipment characteristics have on an EAS Participant's ability to deliver
We also seek comment on whether the Time of Release Code is a key element in defining the
validity of an EAN message, and if so, why. For example, we seek comment on whether the broadcast of
EANs should be triggered upon the Time of Release Code because: (i) broadcasting the EAN
immediately upon receipt might "allow a recorded EAN message . . . to be re-broadcast, either by error or
malicious intent;" (ii) could cause unsynchronized activations between the legacy EAS and [Common
Alerting Protocol]-based EAS and other warning platforms, such as [the Commercial Mobile Alert
System]; and (iii) could "provide a means of scheduling an EAN message at some point in the future."26
24 See EAS Nationwide Test Report
25 See EAS Nationwide Test Report
at 14 (citing
Letter from James F. Heminway, Chief Operating Officer,
Monroe Electronics, to Adm. Jamie Barnett, Chief, Public Safety and Homeland Security Bureau, FCC, Dec. 15,
2011 (Monroe Ex Parte
)). Monroe characterized the Time of Release Code as "time of transmission."
26 See Monroe Ex Parte
at 5. We seek comment on Monroe's assertions.
Section 11.31(c) contains a code element that indicates "when the message was initially released
by the originator."27 The Time of Release Code shows the "day in Julian Calendar days (JJJ) of the year
and the time in hours and minutes (HHMM) when the message was initially released by the originator
using 24 hour Universal Coordinated Time (UTC)."28 However, the Commission's Part 11 rules also
specify that an EAN must be broadcast "immediately" upon receipt.29 We seek comment from EAS
Participants and other stakeholders on how they view the interaction of these two sections. Do parties
perceive them to be mutually inconsistent? If so, what action, if any, do commenters suggest that the
Commission take to address any inconsistency? Commenters should specify the benefits and drawbacks
to any actions they suggest the Commission should undertake.
Further, we seek comment from those EAS Participants, equipment manufacturers, and other
affected stakeholders that do not recognize the Time of Release Code when an EAN is the event code,
what their reprogramming, equipment replacement, or other costs might be if they were required to
recognize the Time of Release Code for an EAN. What would such costs be, and could such costs be
justified in light of whatever perceived benefits might result? As noted above, the EAS is designed to
provide the President with real-time access to the nation's airwaves. Would triggering the EAN broadcast
upon the Time of Release Code satisfy that goal? If, as seems to be the case with the Nationwide EAS
Test, a Time of Release Code is incorrect, would basing the broadcast of an EAN on the Time of Release
Code cause delay or otherwise impede the effective propagation of an EAN nationwide?
We also seek comment on whether the daisy-chain process of EAS message distribution (as
messages pass from one station to another) makes it technically infeasible to base uniform broadcast of
the EAN on the Time of Release Code. For example, are there any delays in EAN propagation resulting
from the daisy-chain process that may impact the timing? Even if using the Time of Release Code is
feasible, would the benefits of triggering the broadcast of EANs upon the Time of Release Code outweigh
In addition, we seek comment on the impact, if any, that interaction of the rule sections discussed
above may have on the EAS performance guidelines set out in the EAS-CAP Industry Group (ECIG)'s
Implementation Guide.30 To the extent there is any impact, would the Commission need to recommend
27 In its ex parte
, Monroe characterizes this code element as "time of transmission." See Monroe Ex Parte
, n.2, at
2. We refer to this code element as "Time of Release." See
p. 4, supra
47 C.F.R. 11.31(c). Under Coordinated Universal Time (UTC), the day, JJJ, is 0 to 365 (366 for leap
year), and the time is HH on a 24 hour lock and minutes, MM, 1 to 60. See
) (explaining UTC) (last visited Sept. 19, 2013).
47 C.F.R. 11.51(m)(2), (n) (requiring that encoders air EANs "immediately" whether operating in
automatic or manual mode); 47 C.F.R. 11.52 (e), (e)(2) (requiring that EAS Participants interrupt "normal
programming" when an EAN is received "immediately" when operating in manual mode (no time period is
expressed for interrupting normal programming in automatic mode); and 47 C.F.R. 11.33(a)(11) (requiring, with
respect to decoders, that "[a] headercodewith the EAN Event code specified in 11.31(c) that is received
through any of the audio inputs must override all other messages"). See also
47 C.F.R. 11.54(a).
30 The EAS-CAP Industry Group, or ECIG, "is a coalition of Emergency Alert System equipment, software and
service providers, with current voting members including: Alerting Solutions, Inc.; Communications Laboratories,
Inc.; iBiquity Digital Corporation; Monroe Electronics, Inc.; MyStateUSA; Sage Alerting Systems, Inc.;
SpectraRep, LLC; TFT, Inc.; Trilithic, Inc. and Warning Systems, Inc." The guidelines set out in the ECIG
that the ECIG revise the ECIG Implementation Guide to reflect such impact?31 If so, what changes
should it recommend? Similarly, what impact, if any, would any of the actions discussed in this section
have on the CAP v1.2 IPAWS USA Profile v1?32 To the extent there is any impact, should the
Commission recommend that OASIS33 or any of the other drafters of the profile revisit the profile to
reflect such impact? If so, what changes should it recommend?
. Section 11.31(c) of the Commission's rules requires, among other things, that all
EAS alert messages include a geographic location code to indicate the affected area of the emergency.34
As the Commission noted in the Third Report and Order
, although Part 11 sets out codes for all the states,
there is no nationwide geographic location code dedicated to a Presidential EAS alert.35 In the Third
Report and Order
, the Commission explored whether it should either adopt a requirement to transmit
EAN messages independent of any particular geographic location code, or whether it should adopt six
zeros (000000) as the national location code.36 Because the Commission was concerned that existing
Implementation Guide control how CAP is utilized within the EAS, specifically, in allowing CAP-based EAS
equipment to work compatibly within the framework of the traditional EAS "daisy chain" process. See
Industry Group, Board of Directors, Comments, EB Docket 04-296 (filed May 17, 2010) at 1-2. See also
website at http://eas-cap.org/members.htm
(last visited Sept. 19, 2013).
ECIG Recommendations for a CAP EAS Implementation Guide, Version 1.0 (May 17, 2010), EB Docket
04-296 (filed May 17, 2010) (the "ECIG Implementation Guide") (this document is also available on ECIG's
website at: http://eas-cap.org/documents.htm
(last visited Sept. 19, 2013)). As explained in the Fifth Report and
, this guide outlines how to convert EAS messages formatted in the Common Alerting Protocol (CAP) into
EAS Protocol-compliant messages. See Fifth Report and Order
, 27 FCC Rcd 642, 857-60, 36-40.
32 CAP v1.2 IPAWS USA Profile v1 is one of a trio of documents, along with OASIS CAP Standard v1.2 and the
ECIG Implementation Guide, which taken together, set forth the standards for distributing a CAP-formatted EAS
message through FEMA's Integrated Public Alert and Warning System (IPAWS) to EAS Participants. See Fifth
Report and Order
, 27 FCC Rcd 642, 649-50, 13.
33 The Organization for the Advancement of Structured Information Standards (OASIS) is a not-for-profit,
international consortium that drives the development, convergence, and adoption of e-business standards. OASIS
Who We Are, http://www.oasis-open.org/who/
(last visited Sept. 19, 2013). OASIS Common Alerting Protocol
Version 1.2 (1 July 2010) (OASIS CAP Standard v1.2) was approved by OASIS on August 12, 2010. See
Common Alerting Protocol (CAP) 1.2 Receives Approval as OASIS Standard, http://www.oasis
open.org/news/oasis-news-2010-08-12.php (last visited Sept. 19, 2013). A copy of OASIS CAP Standard v1.2 is
available at http://www.oasis-open.org/specs/#capv1.2
(last visited Sept. 19, 2013).
47 C.F.R. 11.31(c). The current EAS location codes contained in Part 11 of the Commission's rules are
six digit, standardized ASCII (American Standard Code for Information Interchange) codes that utilize five
character numbers assigned to the various states, counties, cities and portions of counties. See id
. (the codes
conform to the National Standards Institute (ANSI) standard, ANSI INCITS 31-2009 ("Information technology--
Codes for the Identification of Counties and Equivalent Areas of the United States, Puerto Rico, and the Insular
Areas")). In the state/city codes the 6th character is always a zero (0).
35 See Third Report and Order,
26 FCC Rcd 1460, 1471-71, 29.
36 See id.
, 26 FCC Rcd 1473-74, 31-32. The Commission observed that under the location coding structure in
Section 11.31(c), six zeroes could act as a national code by default. Pursuant to the location coding structure in
Section 11.31(c), for each subsection of the location code (state, city, county, etc.), the use of all zeros indicates
EAS equipment might need significant reprogramming and may not function correctly under either
approach, it elected not to adopt a national geographic code for the first Nationwide EAS Test, delegating
to the Bureau the choice of what existing code to choose, and deferring any decision on a permanent rule
change to a later date.37 As a simple expedient that would not require equipment reprogramming, the
Bureau and FEMA subsequently elected to use the Washington, D.C., location code for the Nationwide
EAS Test.38 We now seek comment on whether there should be a nationwide location code, in light of
the experience of the Nationwide EAS Test.
As noted above, the EAN is an alert for the entire United States insofar as it would activate every
piece of EAS equipment in the country.39 Because of this fact, is there any reason that EAS equipment
should be required also to recognize a location code before transmitting an EAN? For non-EAN alerts,
such as a tornado alert, the geographic location element is essential if the alert is to be delivered to the
correct geographic area. On the other hand, where the event code is an EAN, is a location code
unnecessary? Does the location code serve a separate function, such as providing or enhancing security
for the alert, during an EAN activation? Would changing the rules to delete the requirement for a location
code impose unnecessarily burdensome reprogramming or equipment replacement costs on EAS
Participants? If so, what are these costs and could these costs be justified in light of whatever perceived
benefits might result? Commenters should specifically identify costs and benefits, and any other reasons
to support or not support requiring location codes for EAN transmission.
To the extent that a location code is necessary for EAN transmission, we seek comment on how
use of the Washington, D.C. location code affected the Nationwide EAS Test. To what extent did EAS
Participants outside of the Washington, D.C. metropolitan area transmit an EAN message referencing the
Washington, DC area location code? What public feedback, if any, did EAS Participants receive as a
result? The Bureau also received anecdotal information that some cable set top boxes in areas other than
Washington, D.C. rejected the Washington, D.C. location code and did not deliver the alert to the public.
To what extent did this occur? Did the use of the Washington, D.C. location code have other technical
impacts on the Nationwide EAS Test? Based on the experiences of the Nationwide EAS Test, what
would be the likely impact of using the Washington, D.C. location code should the EAS ever need to be
activated for a national emergency?
Alternatively, should the Commission consider amending its rules to specify a nationwide
geographic location code? If so, what specific changes would need to be made to the Part 11 rules to
adopt a nationwide location code, other than adding the adopted nationwide location code to the list of
geographic location codes already contained in the Part 11 rules? We seek comment on what code should
be chosen. For example, should the code be the six zeros (000000) discussed in the Third Report and
the entire area or portion thereof. See
47 C.F.R. 11.31(c). In theory, therefore, the use of all zeroes should
indicate the entire area of all states, cities, counties, etc., and thus serve as a nationwide code.
37 See Third Report and Order,
26 FCC Rcd 1460, 1472.
Public Safety and Homeland Security Bureau Provides Additional Information to EAS Participants for the
November 9, 2011 Nationwide Test of the Emergency Alert System, EB Docket No. 04-296, Public Notice
FCC Rcd 11461 (PSHSB 2011).
p. 4, supra
?40 What are the benefits and, conversely, the costs or detriments of adopting such a code?
Commenters should specifically identify benefits, costs and detriments in their analysis.
Moreover, what would be the impact on the ECIG's Implementation Guide of a rule specifying a
nationwide geographic location code? Should the Commission recommend that the ECIG revise the
ECIG Implementation Guide? If so, what changes should the Commission recommend? Similarly, what
would be the impact, if any, on the CAP v1.2 IPAWS USA Profile v1? Should the Commission
recommend that OASIS or any of the other drafters of the profile revisit the profile were the Commission
to revise its rules? If so, how?
Finally, what impact, if any, would a rule specifying a nationwide geographic location code have
on EAS equipment? Could the location code be readily implemented via software or other changes that
would not require swapping out existing EAS or other equipment? Would EAS Participants incur costs
associated with implementing the location code? If so, what are these costs and can these costs be
justified in light of whatever perceived benefits might result? Again, commenters should specifically
identify benefits and costs.
2. Visual Crawl and Audio Accessibility Issues
The Commission's Part 11 rules require EAS Participants that receive EAS messages formatted
in the EAS Protocol to generate a visual text crawl containing the Originator, Event, Location and the
valid time period of an EAS message.41 However, the Part 11 rules do not specify how the Originator,
Event, Location and the valid time period must be presented for any type of EAS message. In other
words, there are no rules concerning specific language, type size, font, or crawl speed.42 As a result,
during the Nationwide EAS Test, the language in the text crawl generated by EAS equipment for the
EAN differed among manufacturers, and in some cases the text was unreadable because it scrolled across
the screen too fast or was in a font that was not easily readable.43
40 See Third Report and Order,
26 FCC Rcd 1460, 1473.
47 C.F.R. 11.51(d), (g)(3), (h)(3), (j)(2). EAS Participants are required to conduct Required Monthly
Tests (RMT) that includes script content, but that is developed entirely by State Emergency Communications
Committees in cooperation with affected EAS Participants. See
47 C.F.R. 11.61(a)(1). EAS Participants that
receive CAP-formatted EAS messages must generate a visual crawl that contains the Originator, Event, Location
and the valid time period of the message, and must be constructed to include the enhanced text contained in the
CAP message in accordance with ECIG Implementation Guide specifications. See id
42 We observe that the ECIG Implementation Guide -- which governs translation of CAP-formatted EAS messages
into EAS Protocol-compliant EAS messages -- does provide examples of how to translate CAP-formatted alerts
into EAS-compatible visual crawls. See
ECIG Implementation Guide, 5. The National Weather Service, in its
specifications on the Specific Area Message Encoding (SAME) digital protocol which the Commission adopted
as the EAS Protocol when it established the EAS rules also provides some guidance on how its messages should
be translated into visual crawls. See
NATIONAL WEATHER SERVICE, NOAA WEATHER RADIO
(NWR) TRANSMITTERS, NWR SPECIFIC AREA MESSAGE ENCODING, NWR SAME, Update
#4.43 (July 13, 1999), at 14, 27, available at http://www.nws.noaa.gov/nwr/same.pdf
(last visited Sept. 19, 2013).
43 See EAS Nationwide Test Report
We seek comment on whether the Commission should address these inconsistencies and, if so,
how. Should the Commission address this issue by encouraging the development of industry best
practices? Should the Commission amend its EAS rules to establish minimum specifications for the
manner by which EAS Participants should present text crawls? We invite suggestions for how such
specifications could be crafted for all text crawl elements. For example, should the Commission specify
visual crawl language or a text script for the EAN and/or nationwide tests of the EAS? If so, what
language should the visual crawl and/or text script include? Should the Commission consider adopting a
font specification for the visual crawl or specify placement and speed of the visual crawl on the television
screen? How could the Commission ensure that any visual crawl language or text script takes into
account the needs of people with disabilities?44 For example, how could the Commission ensure that the
text crawl and audio portions of EAS messages convey equivalent information such that members of the
public who may have sensory disabilities, such as those who are deaf, hard of hearing, deaf-blind and/or
blind would be able to have equal access to emergency information? If the Commission were to consider
adopting visual crawl and/or text script specifications, should these specifications be limited to the
Presidential alert activations and nationwide EAS tests? Alternatively, should they also apply to state and
local EAS messages? In addition, we seek comment to determine if there are alternatives and best
practices through which we can improve the accessibility and functionality of the EAS in order to ensure
that alerts and emergency communications are fully accessible for individuals with disabilities.
If the Commission decided to adopt specifications for visual crawls and/or text scripts, what
would be the impact on the ECIG's Implementation Guide? Should the Commission recommend that the
ECIG revise the ECIG Implementation Guide? If so, what changes should the Commission recommend?
Similarly, what impact, if any, would such a rule change have on the CAP v1.2 IPAWS USA Profile v1?
Should the Commission recommend that OASIS or any of the other drafters of the profile revisit the
profile were the Commission to revise its rules? If so, what should it recommend?
Finally, what impact, if any, would any rule specifying text script, font, crawl speed, etc.
, have on
EAS equipment? Can such equipment be easily programmed? What about EAS Participants' non-EAS-
related equipment, such as a character generator, that is used to generate an EAS text crawl? Is it feasible
or practical to adopt a single set of specifications that all such equipment could meet? Could
specifications for crafting visual crawls readily be implemented, e.g.,
via software or other changes that
would not require swapping out existing EAS or non-EAS equipment? Would EAS Participants incur
costs associated with implementing visual crawl specifications? If so, what are these costs and could
these costs be justified in light of whatever perceived benefits might result? Commenters should
specifically identify benefits and costs.
3. National Test Event Code
Section 11.31(c) of the Commission's rules requires, among other things, that all EAS alert
messages include an "Event" element with the Header Code to identify the type of emergency involved.45
44 See, e.g.,
Rehabilitation Engineering Research Center for Wireless Technologies, Report on the National EAS
Test On-line Survey and Focus Group Findings
, EB Docket No. 04-296, Ex Parte
Letter (filed March 26, 2012)
(reporting the results of on-line surveys and focus groups which were conducted to examine the effectiveness and
accessibility of the national EAS test).
47 C.F.R. 11.31(c).
As discussed in the Third Report and Order
, there is no national test code for a Presidential alert.46 Thus,
for the first nationwide test of the EAS, the Commission had to choose between the event code for an
actual alert, the EAN, and the National Periodic Test code (NPT).47 The Commission and FEMA elected
to use the EAN rather than the NPT code, primarily to replicate an actual alert as closely as possible,48 but
also because the NPT would not test for problems related to promulgation of the EAN, and would have
required each EAS Participant to manually alter its equipment to recognize and accept the NPT.49 Given
the risk of error and added expense associated with use of the NPT, the Commission opted not to use the
NPT for the initial Nationwide EAS Test.50
Although the use of the EAN effectively triggered EAS equipment nationally, the use of the EAN
also required a substantial amount of outreach both to the public-at-large as well as state, local, tribal and
territorial governments to ensure that the general public would not mistake the test for an actual alert. We
seek comment on the benefits and drawbacks of continued use of the EAN for future nationwide EAS
tests. Should the Commission consider revising its rules to require the use of the EAN code for any
upcoming nationwide EAS test? Would the same basic considerations apply to this decision, i.e.
only the EAN can replicate the actual promulgation of a presidential alert and that it would be too difficult
to reprogram EAS equipment to use the NPT code?
Alternatively, should the Commission consider amending its rules to facilitate use of the NPT
code, instead of the EAN, for future nationwide EAS tests? Should it choose some other type of test
code? If so, what code would be appropriate? What would be the benefits and drawbacks to use of the
NPT or some other test code compared to use of the EAN?
The Commission's rules include references to the NPT, but some may take the view that they do
not provide specific enough guidance on how EAS equipment must process the NPT. If more detail is
needed, what operational requirements should the Commission specify for NPT activations (or for an
alternative test code activation that the Commission, following notice and comment rulemaking
requirements, might ultimately adopt)? What logging requirements should apply? 51 Should EAS
Participants be required to transmit the Attention Signal for EAS messages containing the NPT (or an
alternative national test code if later adopted), as required under the Part 11 rules for all national EAS
messages? What priority, if any, should EAS messages containing the NPT (or alternative national test
code, if later adopted) be given? For example, EAS messages containing the EAN event code override all
other EAS messages and must be broadcast immediately.52 Should the same apply for activations of the
NPT (or alternative national event code, if later adopted)?
46 See Third Report and Order,
26 FCC Rcd 1460, 1471.
47 See id.
discussion at 2-3, supra
. See also Third Report and Order,
26 FCC Rcd 1460, 1469-70, 22-24.
50 See id
., 47 C.F.R. 11.61(b).
., 47 C.F.R. 11.51(n).
Should the Commission's rules require that EAS messages containing the NPT code be
promulgated throughout the EAS just like an EAN, or should it be limited in some respects? If so, what
limitations should apply? For example, should EAS messages containing the NPT code be subject to the
decoder reset requirements, such that they can be limited in duration, and if so, is the current minimum
duration of two minutes sufficient?53
In addition, we seek comment on whether it is technically feasible to use the NPT or some other
national test code, particularly with respect to existing EAS equipment. For example, would existing
EAS equipment require software upgrades in order to process the NPT or would new equipment be
required? What, if any, expense would be involved with such reprogramming or software upgrades?
If the Commission, in consultation with FEMA and other Federal government agencies, decided
to use the NPT or another national test code in future tests, what other actions would the Commission
need to take to ensure that use of the alternative code would allow the EAS community to assess how well
the EAS would work in a real national emergency?
Finally, what impact, if any, does CAP implementation have on the use of the NPT, another
national test code, or the EAN in future nationwide tests? What, if any, rule changes would the
Commission need to adopt to facilitate use of any of these event codes for future nationwide EAS tests in
light of CAP? What would be the impact, if any, of such rule changes on the ECIG's Implementation
Guide? Should the Commission recommend that the ECIG revise the ECIG Implementation Guide? If
so, what changes should the Commission recommend? Similarly, what would be the impact, if any, on
the CAP v1.2 IPAWS USA Profile v1? Should the Commission recommend that OASIS or any of the
other drafters of the profile revisit the profile were the Commission to revise its rules? Would changes to
the ECIG Implementation Guide or the CAP v1.2 IPAWS USA Profile v1 require a further revision of the
Commission's Part 11 rules to ensure that EAS messages (whether formatted in the EAS Protocol or
CAP) containing such nationwide test event code is processed as a national test by EAS equipment?
4. Impact of National Test Length on EAS Equipment
In the Third Report and Order
, the Commission noted that all EAS alerts other than the EAN had
a practical time limit of two minutes, after which the EAS equipment would "time out" and end the alert,
except for the EAN, which could be of indeterminate length.54 The Commission then delegated authority
to the Bureau to resolve the issue of national test length.55 Although the Bureau and FEMA initially
decided that the test would last approximately three minutes to test the "time out" issue,56 after a
subsequent review of the technical elements of the test, the FCC and FEMA concluded that a thirty-
47 C.F.R. 11.33(a)(9).
54 See Third Report and Order
, 26 FCC Rcd 1460, 1490, 79.
55 See id.,
26 FCC Rcd at 1490, 81.
Public Safety and Homeland Security Bureau Provides Additional Information to EAS Participants for the
November 9, 2011 Nationwide Test of the Emergency Alert System, EB Docket No. 04-296, Public Notice
FCC Rcd 11461 (PSHSB 2011).
second test would allow the agencies to effectively assess the reliability and effectiveness of the EAS as a
way to alert the public of national emergencies with limited disruption to the public.57
In the follow up to the Nationwide EAS Test, two EAS Participants reported their inability to
deliver the EAN to the public due to the short 30-second duration of the test.58 One reported that its EAS
equipment could not rebroadcast an EAN shorter than 75 seconds.59 The other suggested that the 30-
second duration of the test was insufficient to allow its engineers to manually override its equipment
when automatic equipment functions failed.60 We seek comment on how the duration for a national EAS
test would affect EAS equipment's ability to deliver an EAN. Is there a minimum amount of time a test
has to run to allow EAS equipment to operate properly? Should the length of the test be predicated on the
ability of EAS equipment to operate for longer than two minutes? How would this affect the
Commission's Part 11 rules? Are there any downsides to a test that exceeds two minutes in length?
Pursuant to Sections 1.415 and 1.419 of the Commission's rules, 47 C.F.R. 1.415, 1.419,
interested parties may file comments and reply comments on or before the dates indicated on the first
page of this document. All comments and reply comments should reference this Public Notice
Docket No. 04-296
. Comments may be filed using the Commission's Electronic Comment Filing System
(ECFS). See Electronic Filing of Documents in Rulemaking Proceedings
, 63 FR 24121 (1998).
Electronic Filers: Comments may be filed electronically using the Internet by accessing the
Paper Filers: Parties who choose to file by paper must file an original and one copy of each
filing. If more than one docket or rulemaking number appears in the caption of this proceeding,
filers must submit two additional copies for each additional docket or rulemaking number.
Filings can be sent by hand or messenger delivery, by commercial overnight courier, or by first-class or
overnight U.S. Postal Service mail. All filings must be addressed to the Commission's Secretary, Office
of the Secretary, Federal Communications Commission.
All hand-delivered or messenger-delivered paper filings for the Commission's Secretary
must be delivered to FCC Headquarters at 445 12th St., SW, Room TW-A325,
Washington, DC 20554. The filing hours are 8:00 a.m. to 7:00 p.m. All hand deliveries
must be held together with rubber bands or fasteners. Any envelopes and boxes must be
disposed of before entering the building.
Commercial overnight mail (other than U.S. Postal Service Express Mail and Priority
Mail) must be sent to 9300 East Hampton Drive, Capitol Heights, MD 20743.
Public Safety and Homeland Security Bureau Announces Updates to the November 9, 2011 Nationwide
EAS Test, Public Notice
, DA 11-1857 (PSHSB rel. Nov. 13, 2011).
58 See EAS Nationwide Test Report
U.S. Postal Service first-class, Express, and Priority mail must be addressed to 445 12th
Street, SW, Washington DC 20554.
People with Disabilities: To request materials in accessible formats for people with disabilities (braille,
large print, electronic files, audio format), send an e-mail to email@example.com
or call the Consumer &
Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (tty).
EB Docket No. 04-296
are available for public inspection and copying during
business hours at the FCC Reference Information Center, Portals II, 445 12th St. SW, Room CY-A257,
Washington, D.C. 20554. The documents may also be purchased from BCPI, telephone (202) 488-5300,
facsimile (202) 488-5563, TTY (202) 488-5562, e-mail firstname.lastname@example.org
Because of the policy implications, we believe that it would be in the public interest to treat this
and its record as a permit-but-disclose proceeding under the ex parte
1.1200(a), 1.1206 of the Commission's rules, 47 C.F.R. 1.1200(a), 1.1206. Therefore, subsequent to
the release of this Public Notice
, ex parte
presentations that are made with respect to the issues involved
in this Public Notice
will be allowed but must be disclosed in accordance with the requirements of
Section 1.1206(b) of the Commission's Rules, 47 C.F.R. 1.1206(b) and must reference
EB Docket No.
For further information regarding this proceeding, please contact Gregory M. Cooke, Associate
Chief, Policy and Licensing Division, Public Safety and Homeland Security Bureau at (202) 418-2351, or
by email: email@example.com
-- FCC --
61 But see
Notice Concerning Ex Parte Status of Information Submitted to the Communications Security,
Reliability and Interoperability Council, Public Notice
, DA 13-1858 (PSHSB rel. Sept. 5, 2013).