Skip Navigation

Federal Communications Commission

English Display Options

Commission Document

Review of the Emergency Alert System, Fifth Report and Order

Download Options

Released: January 10, 2012

Federal Communications Commission

FCC 12-7

Before the

Federal Communications Commission

Washington, D.C. 20554

In the Matter of
)
)

Review of the Emergency Alert System;
)
EB Docket No. 04-296
)
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
)
)

Randy Gehman Petition for Rulemaking
)

FIFTH REPORT AND ORDER

Adopted: January 9, 2012

Released: January 10, 2012

By the Commission:

TABLE OF CONTENTS

Heading
Paragraph #
I.
INTRODUCTION ................................................................................................................................. 1
II. SUMMARY ........................................................................................................................................... 3
III BACKGROUND.................................................................................................................................... 6
A. Second Report and Order................................................................................................................. 8
B. Subsequent Procedural History ................................................................................................. 13
IV DISCUSSION............................................................................................................................. 15
A. Scope of CAP-Related Part 11 Revisions ...................................................................................... 16
B. Obligation to Accept CAP Messages............................................................................................. 31
1. CAP-Formatted Message Conversion to SAME ..................................................................... 31
2. CAP-Related Monitoring Requirements ................................................................................. 41
3. Next Generation Distribution Systems .................................................................................... 54
4. Equipment Requirements ........................................................................................................ 59
5. Miscellaneous Rule Changes Related to Fully Implementing CAP...................................... 103
6. Waivers................................................................................................................................. 144
C. EAS Equipment Certification ...................................................................................................... 155
D. CAP Messages Originated by State Governors ........................................................................... 181
E. Revising the Procedures for Processing EANs ............................................................................ 194
F. Part 11 Revisions Not Related to CAP ........................................................................................ 228
1. Definitions ........................................................................................................................... 229
2. Miscellaneous Rule Changes................................................................................................. 235
3. Attention Signal .................................................................................................................. 239
4. Equipment Issues................................................................................................................... 247
5. Training ................................................................................................................................ 255
6. Persons With Disabilities................................................................................................... 258
7. Proposals Beyond the Scope of the Order ....................................................................... 266
V. PROCEDURAL MATTERS.............................................................................................................. 278

Federal Communications Commission

FCC 12-7

A. Accessible Formats ...................................................................................................................... 278
B. Regulatory Flexibility Analysis ................................................................................................... 279
C. Paperwork Reduction Act Analysis ............................................................................................. 280
D. Congressional Review Act........................................................................................................... 282
V. ORDERING CLAUSES..................................................................................................................... 283
APPENDIX A – Final Rules
APPENDIX B – Final Regulatory Flexibility Analysis

I.

INTRODUCTION

1.
In this Fifth Report and Order, we continue the process the Commission began in 2007 to
transform the EAS into a more technologically advanced alerting system by revising our Part 11
Emergency Alert System (EAS) rules to specify the manner in which EAS Participants1 must be able to
receive alert messages formatted in the Common Alerting Protocol (CAP)2 and by streamlining our Part
11 rules to enhance their effectiveness and clarity. This Fifth Report and Order is the second of two
orders that implement Part 11 rule changes stemming from the Third FNPRM in this docket.3 The other
order, the Fourth Report and Order, addressed the single issue of establishing a new deadline of June 30,
2012, for meeting the various CAP-related requirements that this order codifies.4
2.
Congress established the Commission for the purposes of, among other things, the national
defense and the promotion of safety of life and property through the regulation of wire and radio
communications networks.5 For nearly fifty years, the Commission has implemented this mandate by
adopting rules that set technical and other requirements to provide the public with an effective national
public alert and warning system. In addition to its obligations under section 151 of the Act, the
Commission also has rulemaking authority to regulate participation in the EAS under sections 4(i) and
(o), 303(r), and 706 of the Act.6 In developing and implementing these systems, the Commission has


1 EAS Participants are the regulated entities that receive and broadcast alerts. These entities are defined in section
11.1(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).
2 See 47 C.F.R. § 11.56. See infra paras. 10-11 for a description of CAP.
3 See Review of 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, ET Docket No. 04-296, Third Further Notice of Proposed Rulemaking, 26 FCC
Rcd 8149 (2011) (Third FNPRM).
4 See Review of 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, ET Docket No. 04-296, Fourth Report and Order, 26 FCC Rcd 13710 (2011) (Fourth
Report and Order).

5 See Section 1 of the Communications Act of 1934 (as amended) (the “Act”), 47 U.S.C § 151.
6 See 47 U.S.C. §§ 154(i) and (o), 303(r), 606. For further, detailed discussion of the Commission’s authority to
regulate emergency alerts and warnings, see Review of the Emergency Alert System, EB Docket No. 04-296, Notice
of Proposed Rulemaking
, 19 FCC Rcd. 15775, 15778-15779, paras. 10, 11 (2004); Review of the Emergency Alert
System, EB Docket No. 04-296, First Report and Order and Further Notice of Proposed Rulemaking, 20 FCC Rcd.
18625, 18627, para. 5 (2005); Review of 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, Second Report and Order and
Further Notice of Proposed Rulemaking
, 22 FCC Rcd 13275, 13278, para. 4 (2007); Third FNPRM, 26 FCC Rcd.
8149, 8152, para. 3.
2

Federal Communications Commission

FCC 12-7

worked with federal partners and in coordination with state and local stakeholders. We find that
modernizing the EAS to make it capable of processing CAP-formatted alert messages is necessary and
consistent with our statutory goals, because a CAP-based EAS will be more flexible and robust than the
current system. In this regard, we observe that the rules we adopt today will integrate the EAS with the
Federal Emergency Management Agency’s (FEMA’s) Integrated Public Alert and Warning System
(IPAWS). This will allow authorized alert initiators to issue alerts that will be delivered simultaneously
by the EAS as well as the Personal Localized Alerting Network (PLAN).7 A CAP-based EAS will also
be compatible with the many state alerting systems that are switching to CAP.8 The rules we adopt in this
order also will allow alert originators and EAS Participants to make fuller use of CAP’s capacity to
convey textual information by allowing alert initiators to deliver text files that can track the audio portions
of a particular alert. Such visual displays of alert information will be significantly more detailed than
what has been possible under the legacy EAS. By thus enhancing the accessibility of the EAS, we
increase its benefit to the public, particularly to members of the deaf and hard of hearing communities.
Accordingly, the rules we adopt today are a significant next step in facilitating the development of a
robust and redundant system for distributing vital alert information to all Americans.

II.

SUMMARY

3.
With this order, we codify in detail the general obligation the Commission adopted in the
Second Report and Order in this docket to require EAS Participants to be able to receive CAP-formatted
messages.9 This will enable EAS Participants not only to receive CAP-formatted alert messages, but also
to redistribute those messages in the legacy EAS format over the current broadcast-based EAS.
Specifically, under the rules we adopt today, CAP-formatted EAS alerts: (i) will be converted into and
processed in the same way as messages formatted in the EAS Protocol; and (ii) will be used to generate
enhanced visual displays for the viewers of the EAS station processing the CAP message. In addition, we
are streamlining the Part 11 rules to improve the overall effectiveness of the EAS.10
4.
We take the following actions:
·
As a general matter, we conclude that the scope of the CAP-related obligations addressed in this
order must be limited to those necessary to ensure that CAP-formatted alert messages distributed
to EAS Participants will be converted into and processed in the same way as messages formatted
in the current EAS Protocol.11
·
We require EAS Participants to be able to convert CAP-formatted EAS messages into messages


7 See 47 C.F.R. § 10.1 et seq. PLAN was formally referred to as the Commercial Mobile Alert System (CMAS) in
the Commission’s rules.
8 For example, Washington State has a CAP-enabled system in place.
9 See Review of 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, Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC
Rcd 13275 (2007) (“Second Report and Order”).
10 In a separate proceeding we adopted an order setting technical parameters for a nationwide test of the EAS. See
Review of the Emergency Alert System, Third Report and Order, 26 FCC Rcd 1460 (2011) (National Test Order).
The first ever nationwide test of the EAS was subsequently conducted on November 9, 2011. See Public Safety and
Homeland Security Bureau Announces that First Ever Nationwide Diagnostic Test of the Emergency Alert System
Will Occur on November 9, 2011 at 2 PM EST
, Public Notice, 26 FCC Rcd 8398 (PSHSB 2011). See also Public
Safety and Homeland Security Bureau Provides Additional Information to EAS Participants for the November 9,
2011 Nationwide Test of the Emergency Alert System
, Public Notice, 26 FCC Rcd 11461 (PSHSB 2011).
11 See infra para. 26.
3

Federal Communications Commission

FCC 12-7

that comply with the EAS Protocol requirements,12 following the procedures for such conversion
set forth in the EAS-CAP Industry Group’s (ECIG’s) ECIG Implementation Guide.13
·
We require EAS Participants to monitor FEMA’s IPAWS system for federal CAP-formatted
alert messages using whatever interface technology is appropriate.14
·
We permit, with certain limitations described below, EAS Participants to use intermediary
devices to meet their CAP-related obligations.15
·
We require EAS Participants to use the enhanced text in CAP messages to meet the video
display requirements.16
·
We adopt streamlined procedures for equipment certification that take into account standards
and testing procedures adopted by FEMA.17
·
We eliminate, as unnecessary, the requirement that EAS Participants receive and transmit CAP-
formatted messages initiated by state governors.18
·
We streamline the rules governing the processing of Emergency Action Notifications (EAN) and
eliminate as unnecessary several provisions in Part 11, such as the Emergency Action
Termination (EAT) event code and the Non-Participating National (NN) status.19
5.
The CAP-related rules we adopt today will enable EAS Participants and alert initiators to
integrate the EAS with other federal, as well as state and local, CAP-based alerting systems across the
country, thus making public alerts disseminated through the EAS more effective and informative.
Virtually all commenters agree that incorporation of CAP into the Part 11 rules will significantly benefit
both public safety officials and the public by creating a more efficient, reliable, and effective EAS.
Because the order does not impose new obligations but primarily details the manner in which EAS
Participants must implement the CAP requirement, the rules we adopt today will impose minimal new
costs, particularly as many EAS Participants have already purchased and installed CAP-compatible EAS
equipment.20 In many cases, the rules will result in decreased costs. For example, by removing redundant
or obsolete sections from our EAS rules, we not only streamline EAS operation, but also decrease costs to
all involved in the functioning of the EAS. Moreover, the CAP-related amendments that we make to our
EAS rules are designed to minimize costs. We are eliminating the obligation to receive and process CAP-
formatted alert messages initiated by state governors, in part because we find that a federal mandate to
carry such alerts duplicates features offered by the IPAWS and that eliminating the mandate to carry


12 See 47 C.F.R. § 11.31.
13 See infra para. 36.
14 See infra para. 50.
15 See infra para. 74.
16 See infra paras. 138-140.
17 See infra paras. 165-167, 175-176.
18 See infra para. 191.
19 See infra paras. 194-227.
20 See, e.g., Sage Alerting Systems, Inc., Comments, EB Docket 04-296 (filed July 20, 2011) at 16 (Sage
Comments); Monroe Electronics, Inc., Reply Comments, EB Docket 04-296 (filed July 19, 2011) at 4 (Monroe
Reply Comments); The Association of Public Television Stations and the Public Broadcasting Service Comments,
EB Docket 04-296 (filed July 20, 2011) at 3-4 (Public Television Comments); The National Association of
Broadcasters Comments, EB Docket 04-296 (filed July 20, 2011) at 24-25 (NAB Comments).
4

Federal Communications Commission

FCC 12-7

gubernatorial alerts will also allow EAS Participants to avoid the costs associated with upgrading EAS
equipment to comply with this requirement. In the few instances where the rules we adopt today may
result in new costs to EAS Participants, we believe that these costs are more than outweighed by the
significant benefits to public safety that a functioning CAP-based EAS will bring to the American public.

III.

BACKGROUND

6.
The current EAS is a national public warning system that requires broadcasters, cable
systems, and other service providers (EAS Participants) to provide communications capabilities that
enable the President to address the public in the event of a national emergency.21 EAS Participants also
distribute, on a voluntary basis, alerts issued by state and local governments, as well as the National
Weather Service (NWS). 22 Although a national EAS alert has never been issued, EAS Participants
deliver well over a thousand alerts issued by state and local governments and the NWS annually, the vast
majority of which are weather-related alerts.23 The Commission, FEMA, and NWS implement the EAS
on the federal level.24 The Commission adopts, administers, and enforces the technical rules for the
EAS.25
7.
The present-day 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,26 a format
identical to the Specific Area Message Encoding (SAME) digital protocol utilized by NWS for weather


21 See Third FNPRM, 26 FCC Rcd 8152-53, para. 3. The history of the EAS is summarized in the first Notice of
Proposed Rulemaking in this docket. See Review of the Emergency Alert System, EB Docket No. 04-296, Notice of
Proposed Rulemaking
, 19 FCC Rcd 15775, 15776-77, paras. 6-8. In addition, an overview of the present
organization and functioning of the EAS system is included in the Second Report and Order. See Second Report
and Order
, 22 FCC Rcd 13275, 13280-83, paras. 11-14.
22 See Third FNPRM, 26 FCC Rcd 8152-53, para. 3.
23 Although the Commission does not require EAS Participants to report the number of EAS alerts they receive from
the NWS or state agencies, the Partnership for Public Warning, in its EAS Assessments noted that 1,448 alerts were
generated in 1990; 1,309 in 1991; and 1,412 in 1992. See the “Emergency Alert System (EAS): An Assessment,”
Partnership for Public Warning, PPW Report 2004-1, February 2004.
24 The respective roles of the Commission, FEMA, and NWS are defined in a series of Executive documents. See
1981 State and Local Emergency Broadcasting System (EBS) Memorandum of Understanding Among the Federal
Emergency Management Agency (FEMA), Federal Communications Commission (FCC), the National Oceanic and
Atmospheric Administration (NOAA), and the National Industry Advisory Committee (NIAC) reprinted as
Appendix K to Partnership for Public Warning Report 2004-1, The Emergency Alert System (EAS): An
Assessment; Assignment of National Security and Emergency Preparedness Telecommunications Functions, Exec.
Order No. 12472, 49 Fed. Reg. 13471 (1984); and Memorandum, Presidential Communications with the General
Public During Periods of National Emergency, The White House (Sept. 15, 1995) (1995 Presidential Statement).
25 See Third FNPRM, 26 FCC Rcd 8154, para. 4 (citing Memorandum, Presidential Communications with the
General Public During Periods of National Emergency, The White House (Sept. 15, 1995)). The responsibilities of
the Commission and FEMA in administering the EAS are also defined in Executive Order 13407. See Exec. Order
No. 13,407, 71 Fed. Reg. 36975 (June 26, 2006) (Executive Order 13407).
26 See 47 C.F.R. § 11.31. Under this 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 id. § 11.31(a). Although the EAS Protocol specifies that the message can be audio, video, or
text, in practice, only audio is sent.
5

Federal Communications Commission

FCC 12-7

alerts (hereinafter, “EAS Protocol” and “SAME” are used interchangeably).27 At the national level, EAS
message distribution starts at Primary Entry Point (PEP) stations, which are designated by FEMA and
tasked with receiving and transmitting “Presidential Level” messages initiated by FEMA.28 The PEP
stations broadcast the SAME-formatted alert to the public as well as to “Local Primary” (LP) stations,
which monitor designated PEP stations for the national level alert. LP stations, in turn, are monitored by
all other EAS Participants.29 At the state level, state governors and state and local emergency operations
managers activate the EAS by utilizing state-designated EAS entry points – specifically, State Primary
stations and “State Relay” stations.30 This process of relaying EAS messages from station to station is
often referred to as the “daisy chain.”31

A.

Second Report and Order

8.
In 2007, the Commission adopted the Second Report and Order in this docket,32 which
revised the Commission’s Part 11 EAS rules to lay the foundation for a state-of-the-art, next-generation
national EAS (Next Generation EAS). To ensure that the Next Generation EAS would be transmitted in
an efficient, rapid, and secure manner over a variety of formats (including text, audio, and video) and via
different means (broadcast, cable, satellite, and other networks), the Commission required that EAS
Participants: (1) be capable of receiving CAP-formatted alert messages no later than 180 days after
FEMA publishes its adoption of the CAP standard;33 (2) adopt Next Generation EAS delivery systems no
later than 180 days after FEMA publicly releases standards for those systems;34 and (3) transmit state and


27 See Third FNPRM, 26 FCC Rcd 8154, para. 5 (citing NOAA Weather Radio SAME Info,
http://www.nws.noaa.gov/nwr/nwrsame.htm; Specific Area Message Encoding (SAME), National Weather Service
Instruction 10-1712 (Feb. 12, 2007), available at http://www.nws.noaa.gov/directives/010/pd01017012b.pdf).
28 See 47 C.F.R. § 11.2(a). As the entry point for national level EAS messages, PEP stations are designated as
“National Primary” (NP) stations. See id. §§ 11.2(f), 11.18(a). FEMA has indicated that it intends to increase the
number of PEP stations from the original 34 to more than 80 stations, thus expanding coverage of the nation’s
population from approximately 67 percent (in 2009) to over 90 percent when these additional stations become
operational. See FEMA, “EAS Modernization and Expansion Project” (Jan. 14, 2011), available at
https://www.fema.gov/emergency/ipaws/projects.shtm.
29 At present, the United States is divided into approximately 550 EAS local areas, each of which contains at least
two Local Primary stations, designated “Local Primary One” (LP1) and “Local Primary Two” (LP2). The LP
stations must monitor at least two EAS sources for Presidential messages (including State Primary stations and in
some cases a regional PEP station) and, as specified in Local EAS Plans, coordinate the carriage of emergency
messages from sources such as the NWS or local emergency management offices to activate the EAS for localized
events such as severe weather alerts. See, e.g., 47 C.F.R. § 11.18(b). All other EAS Participants are designated
Participating National (PN) stations and must monitor at least two EAS sources, including an LP1 and an LP2
station as specified in the state’s EAS plan. See 47 C.F.R. §§ 11.18, 11.52(d).
30 The State Relay Network is composed of State Relay sources, leased common carrier communications facilities,
or any other available communications facilities. In addition to EAS monitoring, state emergency messages may be
distributed by satellites, microwave, FM subcarrier, or any other communications technology. See 47 C.F.R.
§ 11.20. State Relay stations relay both national and state emergency messages to local areas. See 47 C.F.R.
§ 11.18(d).
31 See Third FNPRM, 26 FCC Rcd 8155, para. 6. State transmission systems vary from state to state but can include
“daisy chain” links between broadcast and other terrestrial communications facilities, as well as satellite-based
facilities.
32 See Second Report and Order, supra note 9.
33 See Second Report and Order, 22 FCC Rcd 13275, 13288, para. 26.
34 See id. at 13291, para. 32.
6

Federal Communications Commission

FCC 12-7

local EAS alerts originated by governors or their designees no later than 180 days after FEMA publishes
its adoption of the CAP standard,35 provided that the state has a Commission-approved State EAS Plan
that provides for delivery of such alerts.36 The hallmarks of the Commission’s approach in the Second
Report and Order
are described below.
9.
Maintaining the EAS. For various reasons, including the recognition of the long-standing
and important use of the EAS for state, local, and weather–related emergencies, the Commission
concluded that EAS Participants should maintain the existing EAS.37 To enhance flexibility and
redundancy in message dissemination, however, the Commission also required that EAS Participants
upgrade their networks to the Next Generation EAS while maintaining the existing EAS.38
10.
Using Common Alerting Protocol with the EAS. As explained in the Second Report and
Order, CAP is an open, interoperable standard, developed within the OASIS standards process,39 that
incorporates a language developed and widely used for web documents.40 CAP-formatted alerts can
include audio, video or data files; images; multilingual translations of alerts; and links providing more
detailed information than what is contained in the initial alert (such as streaming audio or video).41 CAP
utilizes standardized fields that facilitate interoperability between and among devices.42 CAP is also
backwards-compatible with SAME to the extent that it can be used to relay SAME data.
11.
Although CAP and SAME both convey data, the two protocols function in entirely
different ways.43 CAP essentially represents an envelope into which data is packaged according to


35 The Mayor of the District of Columbia, as well as the Governors of the Commonwealth of Puerto Rico, the
Commonwealth of the Northern Mariana Islands, the U.S. Virgin Islands, American Samoa, and Guam, are also
required to have this capability. See 47 U.S.C. § 153(58) (“The term ‘state’ includes the District of Columbia and
the Territories and possessions.”).
36 See Second Report and Order, 22 FCC Rcd 13300, para. 55.
37 See id. at 13283-84, paras. 17-18.
38 See id. at 13284, para. 18.
39 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/. 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. A copy of OASIS CAP Standard v1.2 is available at http://www.oasis-open.org/specs/#capv1.2.
40 See http://www.oasis-emergency.org/cap.
41 See Second Report and Order, 22 FCC Rcd 13275, 13285-88, paras. 22-25. See also OASIS Common CAP
Standard v1.2, § 3.2.
42 The CAP standard specifies what fields an alert message can contain and what information can be included in the
particular fields, such as message type, scope, incident, and event information. See OASIS Common CAP Standard
v1.2, § 3.2. As the Commission acknowledged in the Second Report and Order, “any EAS initiator can take
information from a CAP-based message and translate it into any other standard for distribution over a particular
channel, network, or technology,” which is particularly relevant to translating a CAP-formatted message into a
SAME-formatted message. Second Report and Order, 22 FCC Rcd 13275, 13286-87, para. 24.
43 Unlike CAP, SAME only provides information concerning the originator of the alert, the type of alert (or
“event”), the areas affected, the duration of the alert, the time the alert was issued, and the call sign of the EAS
Participant that is transmitting or retransmitting the alert. See 47 C.F.R. § 11.31. Under the SAME/EAS Protocol,
an EAS alert uses a four-part message: (1) preamble and EAS header codes (containing information regarding the
identity of the sender, the type of emergency, its location, and valid time period of the alert); (2) audio attention
signal; (3) message; and (4) preamble and EAS end of message codes. See id. § 11.31(a).
7

Federal Communications Commission

FCC 12-7

predetermined fields and packetized for transmission over various IP-based mediums, such as the
Internet. The SAME protocol is designed to combine specific codes that identify alert data (e.g., type,
origin, and area affected) with an audio message and modulate those onto an RF signal.44 Thus, for
example, CAP conveys an alert’s identifying data in separate fields from the audio or video message
(which may be provided either as a file or a link to a URL); whereas in a SAME-formatted message, the
audio portion of the message is already modulated onto the RF signal along with the EAS codes.45
Accordingly, when the EAS decoder receives a SAME-formatted message, it also receives whatever
audio may be associated with that message. On the other hand, when a CAP-enabled EAS decoder
receives a CAP-formatted message, it may play back the audio file or retrieve streaming audio from
another source.
12.
Next Generation Distribution System. While the Commission elected to maintain the
existing EAS, it also concluded that it should enhance the distribution architecture of the EAS.46 Based
on the record before it, the Commission acknowledged that it could improve the EAS by authorizing the
delivery of alerts through the existing EAS coupled with new redundant distribution systems for EAS,
such as satellite.47 The Commission also concluded, however, that FEMA is best positioned to determine
the types of additional EAS systems that EAS Participants should accommodate.48 Accordingly, the
Commission indicated that “should FEMA announce technical standards for any Next Generation EAS
alert delivery system, EAS Participants must configure their networks to receive CAP-formatted alerts
delivered pursuant to such delivery system, whether wireline, Internet, satellite, or other, within 180 days
after the date that FEMA announces the technical standards for such Next Generation EAS alert
delivery.”49

B.

Subsequent Procedural History

13.
On March 25, 2010, in anticipation of FEMA’s adoption of CAP, the Public Safety and
Homeland Security Bureau (Bureau) released the Part 11 Public Notice, which sought informal comment


44 As explained in the Second Report and Order, SAME was originally developed to be transmitted via broadcast
radio for receipt by relatively simple devices. See Second Report and Order, 22 FCC Rcd 13275, 13284-85, para.
20 (citations omitted).
45 Encoding a SAME-formatted message involves modulating the various codes associated with the SAME protocol
and an audio message onto an RF signal using the audio frequency-shift keying (AFSK) modulation scheme to open
an audio channel in the EAS decoder. Specifically, the EAS decoder is activated by receiving the SAME protocol
preamble codes plus header codes, which are repeated three times consecutively at the start of an EAS message
transmission. The EAS decoder uses bit-by-bit comparison for error detection to ensure that at least two of the three
match. Depending upon the nature of the alert message, this three-time transmission (or “burst”) is followed by a
two-tone Attention Signal (currently, 8-25 seconds in duration), which functions as an audio alert to listeners and
viewers that an emergency message follows. The Attention Signal may be followed by an audio message. At the
end of this message, the preamble plus end of message code is transmitted three consecutive times to signal to the
EAS decoder that the alert message is terminated and to return to regular programming. See 47 C.F.R. § 11.31.
When EAS Participants regenerate, or encode, the message they receive for the benefit of downstream monitoring
stations, they are only encoding the EAS Codes as AFSK tones (and any embedded audio message).
46 See Second Report and Order, 22 FCC Rcd 13275, 13291, para. 32.
47 See id.
48 See id. (citing Executive Order 13407, §§ 2(a)(ii), 3(b)(iii)).
49 See id.
8

Federal Communications Commission

FCC 12-7

regarding what, if any, Part 11 changes the introduction of CAP might necessitate.50 Subsequently, on
September 30, 2010, FEMA announced that it would adopt certain technical standards and requirements
for CAP-formatted EAS alerts, triggering the Commission’s 180 day CAP-adoption deadline.51 FEMA
identified three documents as defining the IPAWS “technical standards and requirements for CAP and its
implementation”: (1) the OASIS CAP Standard v1.2; (2) an IPAWS Specification to the CAP
Standard (CAP v1.2 IPAWS USA Profile v1.0); and (3) the EAS-CAP Industry Group’s
Recommendations for a CAP-EAS Implementation Guide, Version 1.0 (May 17, 2010).52 Taken
together, these documents set forth the standards for distributing a CAP-formatted message through
IPAWS to EAS Participants. Shortly thereafter, on October 7, 2010, the Communications Security,
Reliability, and Interoperability Council (CSRIC) adopted a final report recommending changes to the
Part 11 rules governing EAS Participants’ EAS CAP obligations.53 Responding in part to FEMA’s
adoption of the CAP standard, the CSRIC also recommended that the Commission delay its CAP
adoption deadline, scheduled for March, 2011. On November 18, 2010, the Commission adopted an
order that waived the 180-day deadline, extending it to September 30, 2011.54
14.
On May 25, 2011, we adopted the Third FNPRM, in which we sought comment on a wide
range of tentative conclusions and proposed revisions to the Part 11 rules that would more fully delineate
and integrate into the Part 11 rules the CAP-related mandates adopted in the Second Report and Order.55
The Commission received 30 comments and 12 reply comments in response to the Third FNPRM.
Subsequently, on November 18, 2010, we adopted the Fourth Report and Order in this docket, in which
we amended section 11.56 of our EAS rules to require EAS Participants to be able to receive CAP-
formatted EAS alerts no later than June 30, 2012.56

IV.

DISCUSSION

15.
In this Fifth Report and Order, we adopt several changes to the Part 11 rules in response to
issues and comments raised in the Third FNPRM. The rule revisions we adopt today also streamline Part
11 by eliminating several outdated, confusing, or unnecessary requirements in keeping with the
Commission’s broader effort to eliminate outdated and unnecessary regulations. The specific revisions to
the Part 11 rules are included in Appendix A.


50 See Public Safety and Homeland Security Bureau Seeks Informal Comment Regarding Revisions to the FCC’s
Part 11 Rules Governing the Emergency Alert System Pending Adoption of the Common Alerting Protocol by the
Federal Emergency Management Agency, Public Notice, 25 FCC Rcd 2845 (2010) (Part 11 Public Notice).
51 See FEMA, “FEMA Announces Adoption of New Standard for Emergency Alerts,” Release Number: HQ-10-192
(rel. Sept. 30, 2010), available at http://www.fema.gov/news/newsrelease.fema?id=52880.
52 See id.
53 See Third FNPRM, 26 FCC Rcd 8149, 8160, para. 17 (citing CSRIC, Working Group 5A, CAP Introduction,
Final Report, available at http://www.fcc.gov/pshs/docs/csric/CSRIC%205A%20Working%20Group.pdf) (CSRIC
Final Report
)). As explained in the Third FNPRM, CSRIC was chartered by the Commission, pursuant to the
Federal Advisory Committee Act, 5 U.S.C. Appendix 2, to provide recommendations to the Commission to ensure
optimal security, reliability, operability, and interoperability of communications systems, including public safety,
telecommunications, and media communications systems. See id. at 8159-60, para. 16.
54 See Review of the Emergency Alert System, Order, 25 FCC Rcd 16376, para. 1 (2010) (Waiver Order).
55 See supra note 3.
56 See Fourth Report and Order, 26 FCC Rcd 13710, 13710-11, para. 1.
9

Federal Communications Commission

FCC 12-7

A.

Scope of CAP-Related Part 11 Revisions

16.
As we explained in the Third FNPRM, when the Commission initially adopted the CAP
obligations in the Second Report and Order, it concluded that EAS Participants should maintain the
existing legacy EAS, including use of the SAME protocol, because, among other reasons, alternative and
more robust delivery mechanisms had not been developed or deployed.57 Recognizing that the “daisy-
chain” message distribution process used by the legacy EAS lacks the flexibility and redundancy of
evolving digital communications systems, the Commission required that EAS Participants deploy
equipment capable of receiving CAP messages58 and upgrade their networks to Next Generation EAS as
FEMA adopts standards governing Next Generation EAS distribution systems.59 Accordingly, the
Commission implemented CAP as a parallel mechanism of formatting and distributing alerts to the legacy
system that would be converted into and processed within the existing EAS system as legacy SAME-
formatted alerts. This approach would facilitate a CAP-based Next Generation EAS to be deployed and
operated, at least initially, in parallel to the legacy EAS.
17.
In the Third FNPRM, we explained that while the SAME protocol used by the legacy EAS
is more limited than CAP with respect to its flexibility and the information it can convey,60 the many
benefits of maintaining the legacy EAS previously outlined by the Commission in the Second Report and
Order
continued to be relevant.61 We observed that FEMA has determined that the legacy EAS would
continue to operate as it always had but would also serve as a distribution outlet for IPAWS.62 Finally,
we explained that FEMA has adopted the standards necessary for formatting alert messages into CAP and
translating CAP-formatted messages into SAME-compliant messages; thus, the groundwork for
implementing CAP-formatted alert initiation within the existing EAS system was already in place.63
18.
Based on the foregoing, we tentatively concluded in the Third FNPRM that, for the time
being, we should continue the approach adopted by the Commission in the Second Report and Order and
maintain the existing legacy EAS, including utilization of the SAME protocol.64 We clarified that under
this transitional approach, the CAP-related changes to Part 11 under consideration in the Third FNPRM
were designed to permit EAS Participants to receive and process CAP-formatted messages, but subject to
the technical requirements and limitations of the existing EAS (i.e., the CAP-formatted message would be
converted into and broadcast – and to the extent feasible, encoded [i.e., regenerated] for the benefit of
downstream monitoring stations – in the SAME format).65


57 See Third FNPRM, 26 FCC Rcd 8149, 8162, para. 24 (citing Second Report and Order at 13283-84, paras. 17-
18).
58 See id. (citing Second Report and Order at 13288, para. 26).
59 See id. (citing Second Report and Order at 13283-84, paras. 17-18, 13291, para. 32).
60 See id. at 8163-64, para. 27 (citing, e.g., Second Report and Order at 13284-85, para. 20).
61 See id. (citing Second Report and Order at 13283-84, paras. 17-18).
62 See id.
63 See id. (citing FEMA, “FEMA Announces Adoption Of New Standard For Emergency Alerts,” available at
http://www.fema.gov/news/newsrelease.fema?id=52880).
64 See id. at 8164, para. 28.
65 See id.
10

Federal Communications Commission

FCC 12-7

19.
We sought comment generally on our tentative conclusion to pursue this approach.66 We
asked, for example, whether the deficiencies of SAME relative to CAP previously identified in the record
are significant enough to outweigh the benefits of retaining the legacy EAS system until such time as it
can be replaced by the Next Generation EAS system, how long it might take to switch to a CAP-centric
EAS system, what such a CAP-centric approach might entail, and how it might affect EAS Participants.67
We also sought comment on the relative costs and benefits associated with a CAP-centric EAS system
and how best to tailor any requirements we might consider to impose the least amount of burden on those
affected by the transition to a CAP-centric system.68
20.
The majority of commenters responding to this issue generally supported our proposed
transitional approach. The National Association of Broadcasters (NAB), for example, supported the
transitional approach for the reasons outlined in the Third FNPRM,69 adding that “there is definite value
in retaining the current ‘daisy-chain’ EAS distribution system as a proven, redundant method of
delivering public alerts.”70 The Named State Broadcasters Associations (NSBA) also agreed, noting that
“it makes little sense for the FCC to adopt sweeping Next Generation EAS rule changes at this time when
legacy EAS, as governed by the Commission’s current Part 11 Rules, is going to be around for the
foreseeable future.”71 NSBA also stated that “[t]his approach will provide much needed relief to smaller
EAS Participants in particular, and the State Associations therefore support the Commission’s transitional
proposal to defer a comprehensive revision of its Part 11 rules until its upcoming Notice of Inquiry on
Broadband Alerting, at the earliest.”72
21.
Monroe Electronics, Inc. (Monroe), an EAS equipment manufacturer, concurred: “The
existing legacy EAS can serve a useful role as a backup to the next generational CAP capability, thereby
enhancing a robust, redundant, reliable warning system.”73 In this regard, Monroe observed that “[i]n
most natural disasters the broadcast medium is the last system standing and is unparalleled in the ‘one to
many’ message distribution.”74 Monroe also observed, “While the use of the legacy EAS does not
provide the value-added content of CAP – including expanded warning text, as well as potentially other
multimedia like graphics – it does in itself still convey the basic alert message content.”75 However,
Monroe cautioned against limiting broadcasts of alerts to the SAME requirements, recommending instead
that we “adopt rules that allow EAS participants an option of broadcasting the expanded text, audio and
multimedia that may be contained in CAP formatted alerts.”76


66 See id., para. 29.
67 See id.
68 See id.
69 See NAB Comments at 7.
70 Id. at 7 (internal footnote omitted).
71 Named State Broadcasters Associations Comments, EB Docket 04-296 (filed July 20, 2011) at 9 (NSBA
Comments).
72 NSBA Comments at 9.
73 Monroe Electronics, Inc., Comments, EB Docket 04-296 (filed July 19, 2011) at 3 (Monroe Comments).
74 Id.
75 Id.
76 Id.
11

Federal Communications Commission

FCC 12-7

22.
Sage Alerting Systems, Inc. (Sage) agreed that “for the next few years at least, CAP
messages sent on broadcast outlets and other traditional EAS participants should be viewed in the EAS
context.” 77 Sage explained, “The slow signaling rate imposed by the SAME protocol does not allow the
sending of any of the additional CAP-based information, such as description or instruction,” and
therefore, “a CAP message will always contain more information than can be transmitted in the data of an
EAS message.”78 Sage also observed that “more than half of the EAS participants have already updated
their equipment to handle the reception of CAP messages that are then sent on the air as EAS messages,”
thus “making it harder to jump to something completely different.”79 Sage noted, however, that “[w]hat
is seen and heard by the public is . . . not limited by a combined CAP/EAS system as long as those EAS
participants who have direct access to the CAP information can make use of that information – the entire
system must not be limited by its lowest common denominator fallback in day to day normal operation.”80
In this regard, Sage observed, for example, that “if extended text is available to be placed in a video
crawl, or on HD radio data services, or via RDS, an EAS Participant should be permitted (or required) to
use that information.”81
23.
Some parties supported our proposed approach, but with reservations. The Broadcast
Warning Working Group (BWWG), for example, maintained that “preserving legacy EAS SAME
capability has to be a very short-term solution.”82 BWWG advocated deployment of a resilient and
redundant CAP-enhanced EAS relay system, composed of wired and multipoint wireless distribution
mechanisms so that “local warning centers can distribute CAP and ‘Classic EAS’ messages directly - with
a minimum of [Local Primary station] or other distribution intervention - to as many cable, satellite
entities, and TV and radio station entry points as possible.”83
24.
The Rehabilitation Engineering Research Center on Telecommunications Access and the
National Association of the Deaf (collectively, the RERC-TA) acknowledged that “the expectation of
passing on CAP messages may be unrealistic, due to the costs and effort involved in transitioning the
widely deployed legacy EAS to CAP, and the lack of a mechanism for transmitting CAP-formatted
messages over the air, in contrast to SAME.”84 The RERC-TA indicated its concern, however, that “the
proposed rules allowing EAS participants to meet their CAP-related obligations via converting CAP-
formatted messages into SAME-formatted messages will perpetuate the current state of limited
accessibility to the EAS by people with disabilities.”85 The RERC-TA asserted, “It needs to be made
clear that the conversion of CAP to SAME is only a stopgap measure, and that a fully CAP-capable
alerting network needs to be built from the ground up in parallel.”86 In this regard, the RERC-TA
supported imposition of a sunset date “on broadcasting SAME-formatted messages as an effective


77 Sage Comments at 4.
78 Id.
79 Id. at 5.
80 Id.
81 Id. at 4 (internal footnote omitted).
82 The Broadcast Warning Working Group Comments, EB Docket 04-296 (filed July 19, 2011) at 2 (BWWG
Comments).
83 Id. at 13.
84 The Rehabilitation Engineering Research Center on Telecommunications Access and the National Association of
the Deaf Comments, EB Docket 04-296 (filed July 20, 2011) at 3 (RERC-TA Comments).
85 Id.
86 Id.
12

Federal Communications Commission

FCC 12-7

mechanism to force the transition [to a CAP-centric alerting network] and to ensure that people with
hearing-related disabilities are not left behind.”87
25.
One commenter, Verizon, suggested that Local Primary sources should be required to
“pass on CAP to downstream participants and convert CAP alerts to SAME and hand off to downstream
video distributors in SAME format,” although it did not state how the Local Primary sources would
“pass” such CAP alerts to downstream EAS Participants.88
26.
Decision. We adopt the transitional approach set forth in the Third FNPRM. Specifically,
we will continue the approach adopted by the Commission in the Second Report and Order and maintain
the existing legacy EAS, including utilization of the SAME protocol. Under this transitional approach,
the CAP-related changes to Part 11 we adopt in this order are limited to ensuring that EAS Participants’
EAS equipment will be capable of receiving and converting CAP-formatted messages into a SAME-
compliant message.89 To be clear, EAS Participant stations that are generally charged with encoding (i.e.,
regenerating) the EAS Protocol codes (as AFSK tones) for the benefit of downstream stations monitoring
their transmissions will continue that function with respect to alert messages they receive in the CAP
format – just as they would for alert messages they receive in the SAME format. However, they will be
generating the AFSK tones based upon the relevant EAS Protocol codes contained within the CAP
message, in conformance with the ECIG Implementation Guide, including the audio message contained in
the CAP message, to the extent required under our rules.
27.
As explained in the Third FNPRM, we find that this transitional approach is warranted,
primarily because switching over to a fully CAP-centric EAS system – where EAS messages are inputted
and outputted in CAP format rather than SAME format – at this time is both technically infeasible and
premature, because no such CAP-centric system has been developed. The transitional approach also
makes sense because the many benefits of maintaining the legacy EAS previously outlined by the
Commission in the Second Report and Order continue to be relevant today.90 For example, in
emergencies that result in outages of power, cellular telephone service, or Internet connectivity, IP-based
services like CAP-based alerting systems may not be available, and the broadcast-based legacy EAS may
be the only reliable means of disseminating emergency alerts to the public, because messages can be
received on battery-powered radios and televisions.91 Furthermore, as discussed in the Third FNPRM,
FEMA has indicated that the legacy EAS will continue to provide a nationwide alerting mechanism as
part of its IPAWS system.92 FEMA’s adoption of the standards necessary for formatting alert messages
into CAP and translating such CAP-formatted messages into SAME-compliant messages sets the
groundwork for implementing CAP-formatted alert initiation within the existing EAS system.93 In
addition, the record indicates that EAS equipment manufacturers have designed and have been marketing


87 Id. (internal footnote omitted).
88 Verizon Comments, EB Docket 04-296 (filed July 20, 2011) at 5 (Verizon Comments).
89 As detailed in section IV.B(1) of this order, we are requiring such conversion to be made in conformance with the
ECIG Implementation Guide. See infra para. 36.
90 See Third FNPRM, 26 FCC Rcd 8163-64, para. 27 (citing Second Report and Order at 13283-84, paras. 17-18).
91 See Second Report and Order at 13283, para. 17 (observing that dissemination of emergency alerts via the EAS to
battery-powered AM or FM receivers may be the primary source of emergency information for the general public,
and that broadcast and cable personnel already are familiar with current EAS equipment and are trained in its use).
92 See Third FNPRM, 26 FCC Rcd 8163-64, para. 27.
93 See id. Also, the NWS has indicated that it plans to integrate CAP v1.2 alerting through IPAWS in the fourth
quarter of 2011. See National Weather Service, Public Information Statement, NOUS41 KWBC 221803, (June 22,
2011) at: http://www.nws.noaa.gov/om/notification/pns11cap_wiki.htm.
13

Federal Communications Commission

FCC 12-7

CAP-enabled equipment that conforms to these FEMA-adopted standards, and a significant percentage of
EAS Participants already have procured or contracted for such equipment.94 Accordingly, it is both
practical and cost-efficient for us to adopt this transitional approach.
28.
We also observe that the transitional approach to phasing in CAP capabilities – and the rule
revisions we adopt in this order to facilitate that approach – will not impose or amplify costs for
regulatees, as the obligation to receive CAP messages was adopted in the 2007 Second Report and Order.
Moreover, the transitional approach will provide substantial benefits in the form of making the EAS more
efficient, reliable and informative, improvements that may save lives, protect health, and preserve
property.
29.
While we appreciate the BWWG’s suggestions regarding establishment of wired and
wireless local relay networks or other means of distributing CAP messages to enhance the redundancies,
robustness, and effectiveness of CAP alerting, such changes to the architecture of the EAS are beyond the
scope of this proceeding.95 We reject RERC-TA’s suggestion that we impose a sunset date for the legacy
EAS. 96 This suggestion is inconsistent with FEMA’s stated plan to retain the legacy EAS as a central
element of the IPAWS. Finally, with respect to Verizon’s suggestion to require Local Primary stations to
“pass on CAP to downstream participants,” such a request is beyond the scope of this proceeding, which
is limited to simply ensuring that CAP messages are received, converted into, and processed as SAME-
compliant messages by EAS Participants.
30.
As detailed in section IV.B(1) of this order, while our transitional approach to
implementing CAP requires conversion of CAP-formatted messages into SAME-compliant messages, we
are also persuaded by the many commenters that advocated for allowing EAS Participants to make fuller
use of CAP’s capabilities to convey information. We agree that the CAP-in, SAME-out transitional
approach we adopt here should not be so rigid as to preclude the benefits of CAP’s capacity to convey
information. To the extent it is technically feasible to make use of this capacity within the existing EAS
architecture, such action would inherently enhance public safety and serve the public interest.
Accordingly, we are requiring EAS Participants to create video crawls based upon the enhanced text
contained within the CAP message to the extent that such text files are provided by the alert initiator, in
conformance with the procedures set forth in the ECIG Implementation Guide. We believe that requiring
use of this enhanced CAP functionality will make a significant advance in providing more informative
alerts for all Americans and, in particular, members of the deaf and hard of hearing communities.97

B.

Obligation to Accept CAP Messages

1.

CAP-Formatted Message Conversion to SAME

31.
As we explained in the Third FNPRM, the EAS-CAP Industry Group (ECIG)98 developed


94 See, e.g., Sage comments at 5, 7; Monroe Comments at 17; Monroe Reply Comments at 4.
95 See BWWG Comments at 13-15.
96 See RERC-TA Comments at 3.
97 The Commission is concurrently implementing the Twenty-first Century Communications and Video
Accessibility Act of 2010 (CVAA), which requires, among other things, that televised emergency information is
accessible to individuals who are blind or visually impaired. See Pub. L. No. 111-260 and Pub. L. No. 111-265
(technical amendments to the CVAA).
98 The EAS-CAP Industry Group “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.” EAS-CAP Industry Group, Board of Directors,
(continued….)
14

Federal Communications Commission

FCC 12-7

the ECIG Implementation Guide to ensure consistency across all devices and delivery platforms in how
EAS Participants decode messages formatted pursuant to OASIS CAP Standard v1.2 and CAP v1.2
IPAWS USA Profile v1.0 and present them to the public.99 This guide outlines how to convert CAP-
formatted messages into SAME-compliant messages.100 FEMA announced its adoption of the ECIG
Implementation Guide on September 30, 2010.101
32.
In the Third FNPRM, we tentatively concluded that, for the purpose of ensuring greater
uniformity in the output of devices subject to Part 11, we should amend section 11.56 to require EAS
Participants to convert CAP-formatted EAS messages into SAME-compliant EAS messages in
accordance with the ECIG Implementation Guide.102 We observed that adopting the ECIG
Implementation Guide as the standard for translating CAP-formatted messages into SAME-compliant
messages should harmonize CAP elements with the Part 11 rules.103 We further observed that such action
would ensure that CAP-formatted EAS messages are converted into SAME-compliant messages in a
consistent manner across devices and delivery platforms.104 We sought comment in the Third FNPRM on
whether our revision of the Part 11 rules should include a standardized method of decoding and
translating CAP-formatted messages into SAME-compliant messages to ensure consistency across
devices and delivery platforms in how EAS Participants present these messages to the public.105 We also
asked whether it is enough to specify in section 11.56 that EAS equipment must be capable of outputting
CAP-formatted messages in EAS protocol-compliant form.106
33.
Every commenter responding to this issue generally supported our tentative conclusion to
amend section 11.56 to require EAS Participants to convert CAP-formatted EAS messages into SAME-
compliant EAS messages in accordance with the ECIG Implementation Guide. Sage, for example, in
support of the ECIG Implementation Guide, observed that “[a]dherence to a command standard and
methodology for rendering a CAP message into EAS is necessary to maintain the integrity of the EAS
system, for message validity, and for detection of duplicate messages.”107
34.
NAB stated, “This approach will greatly facilitate the Commission’s goals during the
transition period before full introduction of Next Generation EAS, when EAS Participants need only
accept and translate CAP messages into the legacy EAS Protocol,” adding that “[the approach] is also
consistent with previous instances when the Commission has relied on industry-sponsored standards-
(Continued from previous page)


Comments, EB Docket 04-296 (filed May 17, 2010) at 1-2. See also ECIG’s web site at http://eas-
cap.org/members.htm.
99 See Third FNPRM, 26 FCC Rcd 8165-66, para. 33.
100 See 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 web
site at: http://eas-cap.org/documents.htm).
101 See supra para. 13.
102 See Third FNPRM, 26 FCC Rcd 8166, para. 35.
103 See id.
104 See id.
105 See id.
106 See id.
107 Sage Comments at 6. See also, Trilithic Trilithic Inc. Comments, EB Docket 04-296 (filed July 20, 2011) at 5
(Trilithic Comments).
15

Federal Communications Commission

FCC 12-7

setting work, such as for the digital television transition and HD Radio.”108 NAB observed, however, that
“EAS Participants . . . are not in a position to either (1) examine or (2) verify that their equipment is
ECIG-compliant [but] must instead rely on the expertise and representations of manufacturers.”109
Accordingly, NAB argued that “ensuring compliance with the ECIG Guide should rest with the
equipment manufacturers, as part of their obligation to pass [equipment certification], and any revised
rules should be crafted to reflect this approach.”110
35.
The National Cable & Telecommunications Association (NCTA) “generally supported”
our approach but raised concerns that the ECIG Implementation Guide “does not have the backing of an
accredited standards organization.”111 NCTA asked, for example, “What happens . . . if there are changes
to the CAP protocol[, and] [w]hat is the process for amending the ECIG Implementation Guide going
forward?”112 According to NCTA, “The only way to ensure that stakeholders have a say in EAS-CAP
operation once it is codified in the rules is to manage the document through an ANSI accredited standards
development organization.”113
36.
Decision. We adopt our tentative conclusion in the Third FNPRM to amend section 11.56
to require EAS Participants to convert CAP-formatted EAS messages into SAME-compliant EAS
messages in accordance with the ECIG Implementation Guide,114 except for its provisions on text-to-
speech (described below) and gubernatorial CAP messages.115 As we observed in the Third FNPRM,
adopting the ECIG Implementation Guide as the standard for translating CAP-formatted messages into
SAME-compliant messages will harmonize CAP elements with the Part 11 rules, thus ensuring that CAP-
formatted EAS messages are converted into SAME-compliant messages in a consistent, cost-efficient
manner across devices and delivery platforms.116 Adoption of this requirement has broad support in the
record.117
37.
As indicated above, FEMA has adopted the ECIG Implementation Guide as its benchmark
for processing IPAWS-distributed CAP-formatted messages to the EAS. As detailed below in section
IV.C of this order, many manufacturers have already designed EAS equipment that conforms to the ECIG
Implementation Guide, as demonstrated by their having completed the requirements of FEMA’s IPAWS
Conformity Assessment Program. As further detailed below in section IV.C of this order, EAS
equipment manufacturers may use the Suppliers Declarations of Conformity issued to them upon their


108 NAB Comments at 10.
109 Id. at 11.
110 Id. at 11.
111 National Cable & Telecommunications Association Comments, EB Docket 04-296 (filed July 20, 2011) at 11
(NCTA Comments).
112 Id.
113 Id. at 12.
114 See Third FNPRM, 26 FCC Rcd 8149, 8166, para. 35.
115 Because, as detailed in section IV.D of this order, we are eliminating the mandate to process CAP-formatted
messages initiated by state governors, the issue of conformance with the provisions in the ECIG Implementation
Guide to effect that mandate are moot. See, e.g., ECIG Implementation Guide, §§ 3.4.5.7, 3.7, 6.7.
116 See id.
117 See, e.g. Sage Comments at 6; Trilithic Comments at 5; BWWG Comments at 18; Monroe Comments at 4; TFT,
Inc., Comments, EB Docket 04-296 (filed July 20, 2011) at 3 (TFT Comments); Gary E. Timm Comments, EB
Docket 04-296 (filed July 20, 2011) at 1-2 (Timm Comments).
16

Federal Communications Commission

FCC 12-7

successful completion of FEMA’s IPAWS Conformity Assessment Program to support their application
for FCC certification. We find that the costs of complying with the ECIG Implementation Guide are
minimal, because all new CAP-capable equipment already complies with the ECIG Implementation
Guide’s requirements. Thus, we adopt a streamlined mechanism by which EAS equipment manufacturers
may support their FCC certification applications, which will eliminate uncertainty and the unnecessary
costs that would accompany a requirement that EAS equipment manufacturers demonstrate CAP-to-
SAME conversion on a piecemeal basis.
38.
One area where we deviate from the ECIG Implementation Guide, however, is its
provisions on text-to-speech.118 The ECIG Implementation Guide procedures for constructing the audio
from a CAP message require that “[i]f attached EAS audio is not present, and the EAS device supports
text-to-speech technology, then text-to-speech audio SHALL be rendered . . . and used as the audio
portion of the EAS alert.”119 Although use of text-to-speech technology has some support in the record,120
there are also concerns in the record about whether text-to-speech software is sufficiently accurate and
reliable to deliver consistently accurate and timely alerts to the public.121 Allowing the text-to-speech
conversion to be resolved by EAS equipment software, as opposed to text-to-speech software that the
alert message originator might employ, could result in differing audio messages being broadcast for the
same EAS message, depending upon which software brand and version a given equipment manufacturer
elected to incorporate into its EAS equipment. As indicated in the Third FNRPM, we continue to believe
that discussion of text-to-speech and speech-to-text software is best reserved for a separate proceeding,
and we therefore defer these issues at this time.122
39.
With respect to NAB’s contention that the Part 11 rules should be clarified to make
equipment manufacturers solely responsible for compliance with the ECIG Implementation Guide as
part of the equipment certification process, we do not believe such action is necessary because
manufacturers already are prohibited from marketing non-compliant equipment. Specifically, section


118 While we do not permit the construction of EAS audio from a CAP text message at this time, we encourage CAP
alert message originators to provide both audio and text in their CAP messages to ensure accuracy, consistency, and
accessibility, whether they use text-to-speech devices or other means to generate the audio portion of the CAP
messages they distribute to the EAS. See also infra para. 265, noting that CAP-based alert systems enable message
originators to include transcripts of the audio portions of their messages, which should encourage state and local
alert message originators to craft messages that will provide accessible messaging for persons with hearing or vision
disabilities.
119 ECIG Implementation Guide, § 3.5.1. The ECIG Implementation Guide does not support speech-to-text
conversion.
120 See, e.g., Sage Comments at 3 (recommending “use [of] the CAP text in the crawl, and use [of] Text to Speech
based on that crawl if audio is not available for the alert”); BWWG Comments at 2 (“Radio EAS should use text-to-
speech converters that can automatically convey vital CAP details aurally”).
121 See, e.g., Sage Comments at 23 (contending that “[i]f the originator provides only text, today’s technology allows
for text to speech of sufficient quality to produce audio that matches the text,” but adding the caveat that “[t]here are
limitations with text to speech, primarily in the pronunciation of local area names. There is also a wide variation in
the text to speech engines used by various manufacturers. While the level of intelligibility is nearly the same, the
rendered audio is very different from each. Some jurisdictions will solve this problem by using a Text to Speech
engine at the CAP origination point, or at the CAP server. While the audio is still machine generated, every EAS
participant gets the same audio”).
122 See Third FNPRM, 26 FCC Rcd 8149, 8219-20, para. 195. For example, the use of text-to-speech software may
be discussed further in proceedings to implement the Twenty-first Century Communications and Video Accessibility
Act of 2010 (CVAA), which requires televised emergency information to be accessible to individuals who are blind
or visually impaired. See Pub. L. No. 111-260 and Pub. L. No. 111-265 (technical amendments to the CVAA).
17

Federal Communications Commission

FCC 12-7

11.34 of the Commission’s rules requires that the data submitted for certification of encoders and
decoders “show the capability of the equipment to meet the requirements of [Part 11].”123 This data
necessarily includes compliance with the ECIG Implementation Guide, conformance with which we are
mandating in section 11.56. Further, section 2.803 generally prohibits the marketing of equipment
subject to certification that has not obtained such certification.124 We also decline to make explicit in the
rules that EAS Participants are not responsible for ensuring compliance with the ECIG Implementation
Guide. First, all of the obligations in Part 11 are directed at EAS Participants. Second, because EAS
equipment manufacturers are prohibited from marketing non-compliant equipment, it is highly unlikely
that they would sell EAS Participants non-compliant equipment. Third, once the equipment manufacturer
markets the compliant equipment, it has limited or no control over how the purchaser might operate,
reprogram, or otherwise alter it.
40.
With respect to NCTA’s concerns regarding the ECIG Implementation Guide not being
developed through an accredited standards development organization, we observe that the ECIG
Implementation Guide was developed in a forum composed of a broad coalition of EAS equipment,
software, and service providers.125 As a general matter, we agree that the ECIG Implementation Guide
should be managed in a transparent manner that affords all stakeholders an opportunity to meaningfully
participate in its further development, such as open voting membership status for any interested party and
procedures for amending the ECIG Implementation Guide moving forward. We encourage ECIG to
review, and if necessary amend, its internal processes, bylaws, or other administrative governance
documents to ensure that transparent participation for all interested parties is effectively
institutionalized.126 We will revisit this issue if it becomes a problem in the future.
2.

CAP-Related Monitoring Requirements

41.
Section 11.52 sets forth the basic monitoring requirements that EAS Participants must
follow to facilitate receipt of EAS alert messages.127 This section requires EAS Participants to monitor
two EAS sources, which are assigned in the State EAS Plan.128 In the Third FNPRM, we observed that,
although the Second Report and Order codified in section 11.56 the general obligation of EAS
Participants to receive CAP-formatted EAS alerts, it did not specify any associated monitoring
requirements.129
42.
As we explained in the Third FNPRM, the technical construction and distribution
methodologies of CAP messages are different from SAME messages.130 Specifically, under the current
EAS technical framework, SAME-formatted messages are AFSK-modulated data messages that are
received by monitoring the over-the-air broadcasts of designated broadcast stations.131 By contrast, CAP


123 See 47 C.F.R. § 11.34.
124 See 47 C.F.R. § 2.803.
125 See, e.g., ECIG’s web site at http://eas-cap.org/members.htm.
126 The ECIG Bylaws are available for downloading or viewing at: http://eas-
cap.org/files/ECIG%20Bylaws%202009.pdf.
127 See 47 C.F.R. § 11.52.
128 See id. § 11.52(d).
129 See Third FNPRM, 26 FCC Rcd 8149, 8166-67, para. 36 (citing Second Report and Order, 22 FCC Rcd 13275,
13288, para. 26).
130 See id. at 8167-68, para. 38.
131 See 47 C.F.R. § 11.31(a).
18

Federal Communications Commission

FCC 12-7

messages are IP-based data packets that can be distributed using various distribution models.132 We noted
in the Third FNPRM that FEMA had indicated that the IPAWS system would employ Really Simple
Syndication (version 2.0) (RSS) to distribute CAP-formatted alerts to EAS Participants.133 Based upon
that representation, we tentatively concluded that we should amend section 11.52 to include a requirement
that EAS Participants monitor FEMA’s IPAWS RSS feed(s) for federal CAP-formatted messages.134 We
sought comment generally on this tentative conclusion and posed several questions directed at whether
our proposed approach was sufficient to both ensure that EAS Participants receive federal CAP-formatted
messages and capture the technical elements of monitoring.135 We also sought comment on the costs and
benefits of such an approach and whether there were alternative approaches that would be less
burdensome to equipment manufacturers or EAS Participants that would achieve the same result.136
43.
We also proposed in the Third FNPRM that EAS equipment only be required to use the
same monitoring functionality for state CAP messages that would be required for federal CAP
messages.137 Accordingly, we tentatively concluded that we should amend section 11.52 to include a
requirement that EAS Participants monitor the RSS feed(s) designated by a state as the source of any
CAP alerts initiated by its governor (and identified as such in the state’s EAS Plan submitted to and
approved by the Commission).138
44.
There was broad opposition to our tentative conclusion that we should require RSS-based
monitoring for federal CAP messages, based largely on grounds that technical configurations for
monitoring IPAWS and Internet sources are constantly evolving and thus cannot be tied to a static rule.
Recent events support this argument. Subsequent to adoption of the Third FNPRM, FEMA switched
from RSS-based CAP feeds to the Atom Syndication Format (ATOM) for CAP feeds. Although ATOM
functions similarly to RSS, it is a different application and thus inconsistent with our proposed rules.139
45.
Monroe urged that we “maintain a neutral stance as to specific technical solutions that may
have been adopted, or are being considered, by Federal, State and local jurisdictions.”140 In particular,
Monroe stated that the Commission “should issue guidelines and principles where feasible in lieu of
detailed regulations that inadvertently could pose a risk of freezing technological innovation.”141
According to Monroe, “it is impractical and unrealistic for the Commission to attempt to design, for the


132 See Third FNPRM, 26 FCC Rcd 8167-68, para. 38.
133 See id. (citing http://www.fema.gov/emergency/ipaws/CAP_Feed.shtm).
134 See id.
135 See id. at 8168, para. 39.
136 See id.
137 See id. at 8192-93, para. 116.
138 See id. at 8168-69, para. 40.
139 Atom Syndication Format is the name of an XML-based Web content and metadata syndication format and
includes the Atom Publishing Protocol, an application-level protocol for publishing and editing Web resources. See,
e.g., Atom Enabled Alliance, “Atom Publishing Protocol – Introduction,” available at:
http://www.atomenabled.org/developers/protocol. See also Atom Enabled Alliance, “The Atom Syndication
Format,” available at: http://www.atomenabled.org/developers/syndication/atom-format-spec.php; Atom Enabled
Alliance, “The Atom Syndication Format,” available at: http://www.atomenabled.org/developers/protocol/atom-
protocol-spec.php.
140 Monroe Comments at 6.
141 Id.
19

Federal Communications Commission

FCC 12-7

first time, a[] next generation IP based CAP EAS network by codifying various specific design
parameters, which may not keep pace with technological innovation, and may in fact be in conflict with
system and network design choices already made by a substantial number of state governments around
the United States.”142 Monroe also observed that our tentative conclusion to mandate RSS feeds for
federal CAP monitoring “may already be [in]consistent with FEMA’s IPAWS own decision to deploy an
ATOM web feed, rather than RSS 2.0.”143 According to Monroe, our tentative conclusion to require that
EAS Participants monitor state RSS sources for CAP alerts initiated by the state’s governor was “an
implicit requirement for state and local authorities to redesign or recontract their existing CAP-based
systems, which in a substantial number of cases includes combinations of satellite and Internet-based
distribution.”144
46.
Sage contended that “the FCC should not over-specify exactly how each station will
receive CAP messages.”145 With respect to message distribution mediums, Sage observed that “[t]here
are a variety of alternate means that are now, or will soon be, in place,” adding that “[o]ne way satellite
delivery using traditional IP services, a data stream carried as part of digital TV signals from a satellite or
terrestrial broadcaster, a state provided RF data channel, or a state-provided proxy server are current
examples of running or proposed systems.”146 Sage also stated that “the protocol used to transport CAP
messages should not be carved in stone,” observing in this regard that “[w]hile RSS, as suggested in the
FNPRM in several places is a possible solution, and has been discussed in the past, the current proposed
FEMA design is to use ATOM.”147 Sage also opposed setting monitoring requirements for
gubernatorial CAP messages, observing, among other things, that “[s]everal states already have a CAP
distribution system up and running, but few, if any, are currently using RSS (or ATOM).”148
47.
According to NAB, “the Commission should be agnostic about how . . . messages must be
[monitored], and merely craft the rules in a way that ensures the monitoring of emergency transmissions
provided by federal, state and local emergency operations managers, in whatever form such transmissions
are provided.”149 NAB added, “The rules should be flexible enough to accommodate any technology


142 Id.
143 Id. (emphasis and internal footnotes omitted). See also Timm Comments at 2; Sage Comments at 7.
144 Monroe Comments at 7. AT&T Inc. (AT&T), raised certain network security concerns regarding how RSS 2.0
would be implemented. See AT&T Inc., Comments, EB Docket 04-296 (filed July 20, 2011) at 2-4 (AT&T
Comments).
145 Sage Comments at 7. See also BWWG Comments at 20 (“The BWWG believes that the Commission must not
specify any feed type in Part 11. While ATOM feeds are better than RSS feeds … some new feed format may be
devised next year that is better than ATOM. Knowing that technology is a moving target, the FCC must not hobble
improvements by specifying any type of feed in Part 11.”).
146 Sage Comments at 7. See also Trilithic Comments at 7 (pointing out that “[u]nidirectional data feeds [like one-
way satellite service] can not provide an RSS feed [and, therefore,] if RSS is adopted as a standard, … the
Commission should also adopt, or allow the use of a unidirectional (EG: satellite) based protocol for the
dissemination of CAP messages” and observing that “[t]he CAP protocol itself allows for this possibility by
identifying the in-line encapsulation of resources (derefURI containing audio, etc without using [I]nternet links)”).
147 Sage Comments at 7.
148 Id. at 8.
149 NAB Comments at 14. See also The National Association of Broadcasters Reply Comments, EB Docket 04-296
(filed Aug. 4, 2011) at 6 (NAB Reply Comments) (urging the Commission “to leave these kinds of implementation
details to industry”).
20

Federal Communications Commission

FCC 12-7

changes that may occur in any alert originator’s process for distributing CAP EAS messages.”150 NAB
similarly argued that “[t]he monitoring of state EAS alerts is a matter best addressed in State EAS
Plans”151 and that a “rule that would specify exactly how an EAS Participant must monitor state and local
EAS sources . . . could undermine the effectiveness of . . . existing arrangements [specified in State EAS
Plans] and perhaps impede future state-EAS Participant arrangements by unnecessarily dictating overly
specific terms.”152
48.
NCTA supported the use of RSS 2.0 for monitoring purposes, but raised questions
concerning as to how FEMA would distribute CAP messages, including the Internet access methods that
would be supported, the URL/IP address(es) that would be used, and polling intervals.153 NCTA stated,
“If FEMA decides to distribute IPAWS federal CAP-formatted messages using multiple distribution
methods, EAS participants should only be required to monitor one, not all methods, for federal CAP-
formatted messages in order to meet their monitoring obligation.”154 NCTA also supported establishing
the same baseline monitoring requirement for gubernatorial CAP messages that apply to federal CAP
messages.155 In this regard, NCTA stated that “despite the Commission’s intent that EAS participants
[should] not be required to deploy multiple variations of EAS equipment to meet their basic CAP-related
obligations, this is exactly the situation EAS participants find themselves in today.”156
49.
Some commenters generally supported the monitoring approach set forth in the Third
FNPRM. Google Inc. (Google) noted, “While it is not necessary to mandate that all EAS participants
utilize the same monitoring system, the FCC should ensure that, at a minimum, all CAP alerts (state and
federal) are published via publicly available, Internet-accessible ATOM or RSS feeds.”157 Google also
maintained that “it is vital that the distribution of alerts include authentication through digital signatures
or secure transmission via HTTPS.”158 Trilithic generally indicated support for “the standardization of
transport protocols, and for IP based CAP we prefer RSS,” although it also pointed out that RSS cannot
be used for unidirectional CAP-formatted alerts, such as those that would be delivered by satellite.159
50.
Decision. We are persuaded by the majority of commenters that it is unrealistic to require
that EAS Participants adhere to a specific technical standard for CAP monitoring. The technical
parameters of the IPAWS system are still evolving – and the digital world in which that system operates
is evolving faster still. Trying to keep up with these changes while specifying the technical requirements


150 NAB Comments at 14.
151 Id.
152 Id. at 15.
153 NCTA Comments at 6.
154 Id. at 7.
155 Id. at 8.
156 Id. NCTA further stated, “Our understanding is that many states have already deployed proprietary CAP-based
networks such as EMNet and MyState Net. Consequently, cable operators are faced with purchasing upgrades to
existing EAS equipment, and in some cases, purchasing new EAS equipment to accommodate varying existing and
planned state proprietary systems.” Id.
157 Google Inc. (Google), Reply Comments, EB Docket 04-296 (filed Aug. 4, 2011) at 4 (Google Reply Comments).
Google more specifically suggested using a “subscription/push system (such as [Google’s] PubSubHubbub).” Id. at
5.
158 Id. at 5.
159 Trilithic Comments at 7.
21

Federal Communications Commission

FCC 12-7

for federal CAP monitoring in the Part 11 rules is neither practical nor administratively efficient. The fact
that FEMA changed the methodology for distributing CAP messages from its IPAWS system to the EAS
from RSS 2.0 to ATOM shortly after our adoption of the Third FNPRM bolsters this conclusion. While
we agree with commenters generally that we should not over-specify the technical requirements for CAP
monitoring (or any other aspect of the EAS), we believe that the monitoring obligation requires a level of
specificity sufficient to establish clear and enforceable parameters. Fundamentally, the monitoring
obligation needs to be specific enough to ensure that EAS Participants have a sufficiently clear
understanding of how they are to comply with their obligation to monitor IPAWS for CAP-based alerts,
yet is general enough not to require adherence to a particular interface methodology that FEMA may
change as development of IPAWS evolves. Accordingly, we are amending section 11.52 of our rules to
include a requirement that EAS Participants’ EAS equipment must interface with and monitor (whether
through “pull” interface technologies, such as RSS and ATOM, or “push” interface technologies, such as
instant messaging and e-mail) the IPAWS system to enable distribution of federal CAP-formatted alert
messages from IPAWS to the EAS Participants’ EAS equipment.
51.
We find that the flexible approach to monitoring we adopt here will benefit equipment
manufacturers by allowing them to update their equipment designs as federal CAP message delivery
mechanisms and technology evolve. This approach will also be efficient from an administrative
standpoint, as the Commission will not have to initiate a rulemaking proceeding to implement new
monitoring requirements to match any new standard that might develop. Finally, this approach will not
impose extra costs on EAS Participants because they will not need to replace EAS equipment if the
monitoring requirements change; instead, as Monroe suggests, they can easily update their monitoring
sources via software updates.160
52.
With respect to the monitoring requirement for gubernatorial CAP messages, as indicated
above, we proposed in the Third FNPRM that such monitoring requirements should mirror federal CAP
monitoring requirements.161 For the reasons explained below (in section IV.D of this order), however, we
are eliminating the obligation to receive and process gubernatorial CAP-formatted messages. Absent this
obligation, there is no reason to establish a generally applicable requirement for state CAP message
monitoring. As a result, the monitoring requirements associated with CAP messages initiated via state
(and local) EAS systems will be determined just as the monitoring requirements for SAME-based EAS
message transmissions always have been. Specifically, state (and local) alerting authorities, working with
EAS Participants, will develop state (and local) CAP alert monitoring requirements and set these forth in
their State EAS Plans, to be submitted to and approved by the Commission.
53.
We recognize, as NCTA suggested, that states may have adopted different methodologies
for distributing CAP alert messages over their EAS systems and that as a result, EAS Participants
providing services in multiple states may have some variation in their EAS equipment configurations to
directly interface with each state system.162 However, Monroe indicated that EAS CAP-enabled
equipment designs are sufficiently adaptable that they may be reconfigured (typically via software
changes) to accommodate multiple distribution technologies with minimal disruption and effort.163 We
also observe that states should be able to distribute their alert messages through the IPAWS system,
which EAS Participants will be uniformly monitoring, so there should be a mechanism available for states
to distribute CAP-formatted alerts to in-state EAS Participant stations. Accordingly, we conclude that


160 See Monroe Comments at 6-9; Monroe Reply Comments at 5-6.
161 See Third FNPRM, 26 FCC Rcd 8149, 8168-69, para. 40.
162 See NCTA Comments at 8. See also NAB Comments at 15; Google Reply Comments at 4; Sage Comments at 8.
163 See Monroe Comments at 8-7; Monroe Reply Comments at 5-6.
22

Federal Communications Commission

FCC 12-7

EAS Participants voluntarily electing to meet the monitoring requirements associated with a given state’s
CAP system specifications are unlikely to incur additional costs in meeting such requirements and that
any costs incurred will likely be only minimal.
3.

Next Generation Distribution Systems

54.
In the Second Report and Order, the Commission concluded that it should enhance the
distribution architecture of the existing EAS.164 The Commission indicated that, based on the record
before it, it could improve the EAS by authorizing the delivery of alerts through the existing EAS coupled
with new redundant distribution systems for EAS.165 The Commission concluded, however, that FEMA
is best positioned to determine the types of additional EAS systems that EAS Participants should
accommodate.166 Accordingly, the Commission stated that “should FEMA announce technical standards
for any Next Generation EAS alert delivery system, EAS Participants must configure their networks to
receive CAP-formatted alerts delivered pursuant to such delivery system, whether wireline, Internet,
satellite or other, within 180 days after the date that FEMA announces the technical standards for such
Next Generation EAS alert delivery.”167 The Commission incorporated this obligation into section 11.56,
adopting the following text: “all EAS Participants must be able to receive CAP-formatted EAS alerts …
after FEMA publishes the technical standards and requirements for such FEMA transmissions.”168
55.
In the Third FNPRM, we interpreted the language from the Second Report and Order
regarding receipt of CAP-formatted messages from Next Generation EAS delivery systems as being
intended to put EAS Participants on notice that, should FEMA adopt technical standards covering
delivery of CAP-formatted messages to EAS Participants over specific platforms, such as satellite
systems, EAS Participants would ultimately need to configure their systems to be able to interface with
such systems to meet their existing obligation to process CAP-formatted messages.169 We observed that
the need to specify such technical standards may never arise.170 As we interpreted it, the Commission’s
intent was not to permit FEMA to create or modify existing requirements via publication or adoption of a
particular technical standard but rather to permit initiation and carriage of CAP-based alert messages over
the existing EAS until a Next Generation EAS might be developed.171 In this regard, we indicated that
whatever obligations might arise with respect to the Next Generation EAS would be addressed in future
proceedings.172 We sought comment on whether further clarification of the EAS Participants’ obligation
to receive and process CAP-formatted EAS messages delivered over Next Generation EAS distribution
systems is necessary.173


164 See Second Report and Order, 22 FCC Rcd 13275, 13291, para. 32.
165 See id.
166 See id.
167 Id.
168 See Second Report and Order, 22 FCC Rcd 13275, 13321, Appendix C. The Fourth Report and Order
subsequently revised section 11.56 to currently read: “All EAS Participants must be able to receive CAP–formatted
EAS alerts as required by this part no later than June 30, 2012.” Fourth Report and Order, 26 FCC Rcd 13710,
13722, Appendix.
169 See Third FNPRM, 26 FCC Rcd 8149, 8170, para. 44.
170 See id.
171 See id.
172 See id.
173 See id.
23

Federal Communications Commission

FCC 12-7

56.
Two commenters addressed this issue directly. Trilithic asserted, “We do not understand
how the Commission can expect EAS Participants to be able to receive messages from FEMA, and also
expect FEMA to publish standards and requirements for a new message and delivery mechanism, without
also expecting that these FEMA standards and requirements will modify existing requirements.”174
Trilithic argued, “Since ‘carriage of a CAP-based alert over the existing EAS’ is not possible, the general
understanding of the Commission[’]s rules seems to have been that a new messaging standard would be
designed and implemented by FEMA, and that EAS participants were required to do whatever was
necessary to process messages according to the new standards.”175 Trilithic also stated, “‘Next
Generation EAS distribution systems’ is not clearly defined, though presumably it is a reference to digital
data systems.”176 BWWG suggested that “the Commission leave itself room in Part 11 for completion of
a fully fleshed-out Next Generation EAS strategy that is itself rooted in a national warning strategy that
will require more work by FEMA and the stakeholder community.”177
57.
Decision. We believe that our interpretation of the language from the Second Report and
Order regarding receipt of CAP-formatted messages from Next Generation EAS delivery systems is
accurate. When the Commission adopted its CAP-related obligations in the Second Report and Order, it
understood that FEMA intended ultimately to utilize CAP as its primary alert message format.
Subsequently, FEMA indicated that it would distribute these CAP messages via IPAWS. It remains
unclear, however, what other future distribution platforms and mediums FEMA might establish to
distribute alerts to EAS Participants and whether and how the EAS itself might need to be reconfigured to
be more agile and more fully integrated with whatever national alert aggregation concept FEMA may
develop with IPAWS. Accordingly, as the Third FNPRM indicated, the Commission’s mandate that EAS
Participants would need to configure their networks to receive CAP-formatted alerts delivered pursuant to
any new alert delivery system within 180 days of FEMA’s “announc[ing] technical standards for any
Next Generation EAS alert delivery system” was intended to put EAS Participants on notice that they
ultimately would be required, under rules adopted by the Commission, to configure their systems to be
able to interface with any new systems or methods for distributing CAP-formatted messages that FEMA
might adopt.178 By requiring that EAS Participants configure their systems to interface with IPAWS, we
also adopt an approach that will impose minimal costs on EAS Participants, because we do not require
EAS Participants to assume any obligations inconsistent with our previously required adherence to the
CAP standard.
58.
With respect to Trilithic’s comments on this issue, we have no expectations as to how or
whether FEMA may adopt standards and requirements for new message and delivery mechanisms that
would modify existing requirements.179 We merely clarify that: (i) any such standards or requirements
cannot be enforced with respect to EAS Participants until the requirements are formally integrated into
the Part 11 rules via the rulemaking process, and (ii) we would seek to initiate such a rulemaking process


174 Trilithic Comments at 7.
175 Id.
176 Id. Trilithic contended, “The meaning of this phrase is likely different for any two parties, however it seems
clear to us that a CAP system can only be considered to be ‘Next Generation’. The ability to send messages over
digital networks, that these messages can contain and convey a great deal more information than the current SAME
based EAS, that the content of these messages are not limited by protocol and therefore can grow over time, and that
the messages and delivery networks can be adapted to virtually any information distribution system, can not be
considered to be the same old EAS system.” Id. at 2.
177 BWWG Comments at 22.
178 See Third FNPRM, 26 FCC Rcd 8149, 8170, para. 44.
179 Trilithic Comments at 7.
24

Federal Communications Commission

FCC 12-7

in a timely manner, with the goal of making compliance with such standards or requirements effective
within 180 days of their formal adoption. As for Trilithic’s request for a definition of what constitutes the
Next Generation EAS distribution system, the Commission would properly develop that definition in a
separate proceeding.
4.

Equipment Requirements

59.
Intermediary Devices. In the Third FNPRM, we explained that various parties had
suggested that EAS Participants should be allowed to meet their obligation to receive and process CAP
messages by deploying intermediary devices.180 These devices would carry out the function of receiving
and decoding a CAP-formatted message and converting the message into a SAME-compliant message
that would be inputted into a legacy EAS device for broadcast over the EAS Participant’s transmission
platform.181 We indicated that use of such an intermediary device might provide a cost-effective method
for an EAS Participant to meet its obligations to receive and convert CAP-formatted messages into the
SAME format without having to replace its existing EAS equipment and sought comment on whether we
should permit EAS Participants to meet their CAP-related obligations by deploying such intermediary
devices.182
60.
We further sought comment on whether we should subject intermediary devices to some
or all of the requirements of sections 11.32, 11.33, 11.51, and 11.52 of the Commission’s rules.183 We
also sought comment on whether intermediary devices can be modified via software or firmware to
accommodate future changes to CAP, the SAME protocol, or changes to other Part 11 requirements and
whether intermediary devices provide a cost-effective and efficient method for EAS Participants to meet
the CAP-related obligations.184 We asked whether EAS Participants deploying intermediary devices
would likely have to replace such devices with new CAP-compliant equipment sooner than EAS
Participants that deployed new CAP-compliant equipment to begin with and what, if any, approximate
cost savings would result from deploying an intermediary device instead of replacing legacy EAS
equipment with new CAP-compliant EAS equipment.185
61.
Several commenters addressed these issues. Most indicated outright or conditional support
for the use of intermediary devices. NAB, for example, supported the use of intermediary devices “as a
cost-effective option that will fully satisfy an EAS Participant’s CAP obligations.”186 NAB asserted that
“broadcasters take pride in their unique role as the backbone of EAS, but the federal obligation to upgrade
one’s EAS equipment to a CAP-based system is nevertheless an additional financial challenge that arrives
during difficult economic circumstances.”187 In this regard, NAB observed that “[f]or certain smaller
broadcast stations, and stations in small or rural markets with less financial resources, intermediary
devices are particularly useful alternatives.”188 NAB also observed, “As a practical matter, many


180 See Third FNPRM, 26 FCC Rcd 8149, 8171, para. 45.
181 See id.
182 See id., paras. 45-46.
183 See id., para. 46.
184 See id. at 8171-72, para. 47.
185 See id.
186 NAB Comments at 17.
187 Id.
188 Id.
25

Federal Communications Commission

FCC 12-7

broadcasters have already purchased intermediary equipment and it is deployed in the field.”189 NAB
urged the Commission “not to adopt overly restrictive encoder and decoder rules for intermediary
devices” but instead to “adopt global regulations to specify that intermediary devices are ECIG compliant,
enable EAS Participants to satisfy their obligations to accept and decode a CAP-formatted EAS message
and can translate and encode that message into the SAME-format for retransmission via the existing EAS
path.”190
62.
The Association of Public Television Stations and the Public Broadcasting Service
(collectively, “Public Television”) urged the Commission “to allow EAS participants to meet their CAP-
related obligations through the use of intermediary devices.”191 Public Television argued, “These devices
provide a straightforward, effective, and cost-efficient means of adding CAP capabilities to already-
compliant EAS installations.”192 Public Television estimated that “nearly half of our member stations
have already purchased equipment in response to the Commission’s earlier proceedings and deadlines”193
and that “the vast majority of those have purchased intermediary devices.”194 Public Television
continued, “Any changes to CAP-related obligations that would prohibit or restrict the use of such devices
would create a burden and detriment to public television stations throughout the nation that have worked
diligently to comply and serve their communities when EAS is utilized.”195
63.
The Prometheus Radio Project (“Prometheus”) similarly supported allowing EAS
Participants to meet their CAP-related obligations using intermediary devices, observing that
“[i]ntermediary devices are currently available at prices substantially lower than the cost of all-in-one
CAP-compliant units, representing a significant savings to participants.”196 Prometheus also observed
that “EAS encoders and decoders are among the most durable equipment used in broadcast studios, and
requiring participants to replace them prematurely would waste money, labor, and materials.”197 NCTA
agreed, noting that “depending on the legacy EAS equipment in place, deployment of intermediary
devices may be a cost-effective method for an EAS Participant to meet its obligation to receive and
convert CAP-formatted messages into the SAME format without having to replace its existing EAS
equipment.”198 Verizon also supported allowing EAS Participants to meet their CAP-related obligations
using intermediary devices, observing that “[f]oreclosing this option would not only result in unnecessary
new expense for providers, but also would likely result in additional delay before CAP could be
implemented, given the time required to order, install, configure, and test new equipment.”199
64.
EAS equipment manufacturer TFT also supported the use of intermediary devices, arguing
that “[i]f intermediary devices are not permitted, EAS Participants would need to replace their entire


189 Id. at 18.
190 Id.
191 Public Television Comments at 2.
192 Id. at 4.
193 Id. at 3-4.
194 Id. at 4.
195 Id.
196 The Prometheus Radio Project Comments, EB Docket 04-296 (filed July 20, 2011) at 1 (Prometheus Comments).
197 Id. at 2.
198 NCTA Comments at 10-11.
199 Verizon Comments at 4.
26

Federal Communications Commission

FCC 12-7

complement of EAS equipment.”200 According to TFT, as long as intermediary devices are used with
certified legacy EAS devices, it “will insure that EAS messages transmitted by [EAS] Participants will
meet the protocol requirements and will further screen incoming messages.”201
65.
EAS equipment manufacturer Trilithic supported use of intermediary devices that meet
specific requirements, noting that “[i]ntermediary devices that are (in conjunction with the EAS
Encoder/Decoder) capable of handling the Governor Must Carry requirements, and also capable of
handling the enhanced text of CAP messages (for Broadcast TV, Cable, and Wireline Video systems)
should be allowed.”202 Trilithic also suggested that the Commission revise the definition of intermediary
devices to reflect that “some Intermediary devices do not convert CAP to SAME FSK, but rather
communicate with the EAS Encoder/Decoder through other (non-audio) means.”203 In making this
distinction, Trilithic explained that there are two types of intermediary devices. Specifically, Trilithic
stated that “[i]n one case a device can ingest CAP message and produce EAS FSK, Attention Tone, and
Voice sufficiently to activate the input circuitry of a connected EAS Decoder” and that “[i]n this case the
EAS Decoder does not realize it is connected to a CAP device, and treats the input the same as if it was an
‘off-air’ monitoring assignment.”204 In the second case, according to Trilithic, “the CAP to EAS
Intermediary device and the EAS Encoder/Decoder are designed to work together, allowing the enhanced
CAP text, and the Governor’s Must Carry flag to be processed by the EAS Encoder/Decoder.”205 As
Trilithic further described “Functionally this Intermediary Device and EAS Encoder/Decoder
combination can perform as a single, integrated device.”206 In its comments, Trilithic thus makes the
distinction between intermediary devices capable of delivering alerts with enhanced CAP functionalities,
such as enhanced text, and those that merely extract the legacy EAS data and discard the rest of the alert.
66.
Some parties oppose use of intermediary devices on the grounds that these devices do not
permit use of CAP’s added features. EAS equipment manufacturer Sage, for example, opposed
intermediary devices because “the information available to the device that is actually placing the alert on
the air is always only the legacy EAS information.”207 According to Sage, “If we were willing to accept
legacy EAS as the best we can do, there was no need to move to CAP.”208 Sage further argued, “Legacy
EAS is a backup, to be used when CAP isn’t available ... [s]tations with true CAP reception can do
more.”209 Sage also asserted that use of intermediary devices would degrade EAS performance.210 In this


200 TFT Comments at 2.
201 Id. (internal footnote omitted).
202 Trilithic Comments at 8.
203 Id.
204 Id. at 2.
205 Id.
206 Id.
207 Sage Comments at 9 (emphasis omitted).
208 Id. at 10.
209 Id.
210 Id. at 9-10 (arguing that (i) because legacy EAS devices “typically only handle one EAS message in memory at a
time” whereas “CAP messages can arrive more quickly than [the legacy EAS device] can play them back,” the
legacy EAS device “can drop CAP originated EAS messages”; (ii) because legacy EAS devices “have no concept of
cancellation[,] [a]n intermediary/legacy combination will sometimes put cancelled CAP messages on the air”; (iii)
the legacy EAS device “has no way to receive CAP text from the intermediary device,” and therefore, “CAP text is
unavailable to video crawl or radio text services equipment if driven by the legacy EAS device”; and (iv)
(continued….)
27

Federal Communications Commission

FCC 12-7

regard, Sage noted that the biggest problem with an intermediary device is its inability to handle a
mandatory gubernatorial alert.211 Sage also maintained that intermediary devices are not cost-effective
because the aging legacy EAS equipment they perpetuate will fail and have to be replaced in the near
future.212
67.
Notwithstanding the foregoing, Sage acknowledged, “As a practical matter, though, due to
budget limitations a station may have to choose between a less-desirable hardware solution and total non-
compliance.”213 Sage further observed, “As Intermediary Device products are already on the market, and
some have already been purchased, it would be hard to disallow them altogether at this point.”214 Sage
concluded, however, that intermediary and legacy EAS device configurations must at least be capable of
carrying a mandatory gubernatorial alert and processing the enhanced CAP text for video crawls.215
68.
Similarly, BWWG opposed intermediary devices on grounds that “[n]o matter what the
capability of intermediary CAP converter devices; they all have the effect of ‘dumbing down’
information-rich CAP EAS messages.”216 According to BWWG , intermediary devices are “at best a
patchwork solution that takes that portion of the EAS user experience down a dead end road.”217 BWWG
also stated that there are “known problems in legacy EAS vendor products that have embedded printers,
keep-alive battery memory, external power supplies and more.”218 BWWG acknowledged that “it may be
too late to rectify” the deployment of intermediary devices but argued that “setting a date-certain for
retirement of legacy EAS equipment must be done.”219
69.
Monroe asserted, “‘Intermediary devices may be defined as those which receive CAP
messages and encode the content into to EAS protocol tones.”220 Monroe argued that “if uncertified
CAP-to-EAS encoders meet the specifications under §11.32, and are intended for use in an EAS
Participant site for EAS (as described under §11.11), then we feel that they must be type Certified by the
FCC as required under §11.34(a) [, and] [i]f uncertified CAP-to-EAS encoders do not meet all the
specifications under §11.32, then they should not receive FCC certification, and should not be used for
(Continued from previous page)


“Intermediary devices are not currently required to be Part 11 certified”). Sage also argued, “Since Intermediary
Devices are not Part 11 certified, and are not required to emit valid EAS messages, the legacy device could be
subjected to invalid messages, duplicates, expired messages, and out of area messages to a far greater extent tha[n]
has been possible in the past,” adding that “[t]his could interfere with the reception of proper messages, especially
since legacy devices were required to store only one active message at a time.” Id. at 11.
211 See Id. at 10.
212 See Id. at 11.
213 Id.
214 Id. See also Sage Alerting Systems, Inc., Reply Comments, EB Docket 04-296 (filed Aug. 4, 2011) at 6 (Sage
Reply Comments) (“We don’t know how many Intermediary Devices have been sold, but it is too late to mandate
against them.”).
215 See Sage Comments at 11. See also Sage Reply Comments at 6.
216 BWWG Comments at 22.
217 Id.
218 Id.
219 Id.
220 Monroe Comments at 13.
28

Federal Communications Commission

FCC 12-7

EAS.”221
70.
Decision. Intermediary devices are stand-alone devices that carry out the functions of
monitoring for, receiving, and decoding CAP-formatted messages and converting such messages into a
format that can be inputted into a separate, stand-alone legacy EAS device to produce an output that
complies with the Part 11 rules.222 According to Trilithic, it appears that there are two types of
intermediary devices, which may generally be described as “universal” intermediary devices and
“component” intermediary devices.223 Universal intermediary devices monitor, acquire, and decode CAP
messages, using the relevant CAP data to generate (i.e., encode) the EAS codes (FSK audio tones) and, if
present, an audio message, which can be inputted into legacy EAS devices. Because the SAME-
formatted message output of the universal intermediary device is functionally equivalent to a SAME-
formatted message delivered over the air, it theoretically should be interoperable with all or most legacy
EAS decoders. However, because the output of the universal intermediary device is limited to the EAS
Protocol – which is all that the legacy EAS device can process – the configuration of a universal
intermediary device and legacy EAS device can only generate a SAME-compliant message; it cannot, for
example, use the enhanced CAP text for generating a visual display.
71.
Component intermediary devices, by contrast, are designed to interoperate with specific
legacy EAS device models. Component intermediary devices also monitor for, acquire, and decode CAP
messages, but they are designed to enhance the function of specific legacy EAS devices. Accordingly,
the output of the combined system configuration of these devices is capable of more than simply
generating a SAME-compliant message. As described by Trilithic, such configurations “allow[] the
enhanced CAP text, and the Governor’s Must Carry flag to be processed by the EAS
Encoder/Decoder.”224 According to Trilithic, “[f]unctionally this Intermediary Device and EAS
Encoder/Decoder combination can perform as a single, integrated device.”225 The record indicates that
integrated CAP-capable EAS devices226 can be updated via software or firmware to comply with any
future changes that might be incorporated into the Part 11 rules, the CAP standard, or the ECIG
Implementation Guide.227 However, it is unclear whether or to what extent a combined system


221 Id. at 14. Monroe also contended that “if the intermediary device itself decodes a CAP message and converts to
SAME protocol compliant messages (for consumption by an EAS decoder), then that intermediary device would
appear to clearly fall under the requirements of § 11.32(a), (b), (c) and (d), as well as § 11.34(a).” Id. Monroe
advocated certification under FEMA’s IPAWS Conformity Assessment Program should serve as the basis for FCC
certification but cautioned that “the IPAWS Conformity Assessment for CAP converters (a/k/a intermediary
devices) was marked by such fundamental and serious omissions that those tests cannot be relied upon to
demonstrate full conformance with the ECIG Implementation Guide or CAP standard.” Id. at 12. In particular,
Monroe observed that “the test cases used in the conformity assessment process omitted evaluation of the ability to
process a CAP formatted governors must carry message in intermediary devices.” Id. at 11.
222 See Third FNPRM, 26 FCC Rcd 8149, 8171, para. 45.
223 See, e.g., Trilithic Comments at 2.
224 Id.
225 Id.
226 By “integrated CAP-capable EAS devices,” we mean self-contained, stand-alone devices that combine the CAP-
related functions of decoding CAP-formatted messages and converting such messages into a SAME-compliant
output and processing SAME-formatted messages as encoders and decoders in accordance with the Part 11 rules.
Because integrated CAP-capable EAS devices handle all of the CAP-related and Part 11 functions within a self-
contained unit, they are capable of fully utilizing CAP, such as generating the visual display from CAP’s data fields,
in conformance with the ECIG Implementation Guide.
227 See Monroe Reply Comments at 5-6.
29

Federal Communications Commission

FCC 12-7

configuration of a component intermediary device and its companion legacy EAS device model could be
similarly updated.
72.
Based on the record and the transitional approach we are taking for this proceeding, we
will allow, with the limitations described below, EAS Participants to meet their CAP-related obligations
by using intermediary devices in tandem with their existing legacy EAS equipment. First, the record
indicates that intermediary devices offer a less costly way to meet the requirements we adopt in this
order.228 We understand, as some commenters point out, that any short-term economic benefit that may
accrue from purchasing an intermediary device rather than an integrated CAP-capable EAS device may
be lost for any number of reasons, such as a complete breakdown of the aging legacy EAS device with
which the intermediary device is configured or the inability to update the legacy EAS device to reflect
any additional EAS requirements we might adopt in the future.229 We agree with Verizon, however, that
“providers should be able to weigh for themselves the costs and benefits of using intermediary equipment,
versus more widespread replacement of EAS equipment.”230 Moreover, it is clear that some percentage of
EAS Participants already have purchased and deployed intermediary devices.231 Therefore, not
authorizing the use of intermediary devices would result in significant equipment replacement,
installation, and training costs for these EAS Participants.232 Assuming that these devices meet the
certification and other requirements detailed in section IV.C of this order, imposition of the costs
associated with the purchase of replacement EAS equipment is unnecessary and unjustified,233 a point that
the parties opposing use of intermediary devices on the basis of their limited capability seem to
acknowledge.234
73.
Second, the idea that intermediary devices ensure that the alert information placed on the
air “is always only the legacy EAS information” appears to be inaccurate, at least in the case of
component intermediary devices.235 In any event, as we discuss above, for the time being, we are
requiring only the distribution of legacy EAS information because the current EAS architecture is
incapable of distributing (via the daisy chain process) anything more. At a minimum, therefore, the
information that is generated (encoded) for the benefit of downstream monitoring stations must remain in
the EAS Protocol due to technical limitations in the AFSK modulation process. Thus, with respect to the
alert information that is generated and broadcast for the benefit of downstream monitoring stations, even
EAS Participants with integrated CAP-capable EAS devices will be limited to encoding only the limited


228 See, e.g., NAB Comments at 17; Public Television Comments at 4; Prometheus Comments at 1; NCTA
Comments at 10-11; Verizon Comments at 4.
229 See, e.g., Sage Comments at 11.
230 Verizon Comments at 4.
231 See, e.g., Public Television Comments at 3-4; Sage Comments at 11; NAB Comments at 18.
232 See, e.g., Public Television Comments at 4; Verizon Comments at 4.
233 We agree with Monroe that intermediary devices function as both encoders and decoders within the meaning of
11.34(a) and (b), and are subject to certification on that basis. See Monroe Comments at 13-15. However, to the
extent Monroe is arguing that intermediary devices must perform all of the functions set forth for encoders and
decoders in section 11.32 and 11.33, we disagree. Some of these requirements and functions, such as audio inputs
and code validation, are handled by the legacy EAS device and would make little sense for the intermediary device,
which is merely converting the CAP message into a SAME-compliant message that will be treated like any other
SAME-formatted message monitored by the legacy EAS device. As discussed in section IV.C of this order, we have
taken these functional nuances into account in the certification requirements we adopt for intermediary devices.
234 See, e.g., See Sage Comments at 11; Sage Reply Comments at 6; BWWG Comments at 22.
235 Sage Comments at 9 (emphasis omitted).
30

Federal Communications Commission

FCC 12-7

EAS Protocol codes. The only issue, then, is the extent to which CAP message information (beyond just
the EAS codes, which are encoded as AFSK tones) can be utilized by the EAS Participant that receives
the CAP message (since this information cannot be encoded for further distribution to monitoring stations
via the daisy chain process). As detailed in section IV.B(5) of this order, based upon substantial support
in the record, we will require EAS Participants to meet the visual display requirements in sections
11.51(d), (g)(3), (h)(3), and (j)(2) using the CAP message’s enhanced text, as set forth in section 3.6 of
the ECIG Implementation Guide, to the extent that such text is supplied by the alert initiator. The record
indicates that component intermediary devices can produce such a visual display.236
74.
Accordingly, we will allow EAS Participants to meet the CAP-related obligations we adopt
in this order by using intermediary devices in tandem with their existing legacy EAS equipment, provided
that such configuration can comply with the certification requirements detailed in section IV.C of this
order, as well as with any applicable Part 11 requirements we may adopt in the future. Such action is
consistent with our baseline goal of ensuring that alert messages formatted pursuant to the CAP-related
standards adopted by FEMA will be converted into and outputted as SAME-compliant messages.
However, because we also require that EAS Participants utilize the enhanced text in a CAP message to
provide a visual display, as set forth in section 3.6 of the ECIG Implementation Guide, we will require
that any intermediary devices provide such functionality by June 30, 2015, which is three years from the
June 30, 2012, deadline for overall CAP compliance.
75.
We recognize that it will likely be technically unfeasible for universal intermediary devices
(and possibly some component intermediary devices), as well as the legacy EAS devices with which they
are configured to meet this requirement, which means that such equipment would have to be replaced.
While we acknowledge that there may be costs involved with replacing non-compliant equipment, we do
not believe that such costs are beyond those that EAS Participants may expect in the normal course of
business, particularly as much of the underlying legacy equipment upon which intermediate devices
depend is old and will soon need to be replaced.237 Although no commenters discussed specific figures
for equipment costs, we believe that the approximately three and one half-year window we are providing
for intermediary device users is sufficient to allow EAS Participants to finish depreciating and then


236 See, e.g., Trilithic comments at 2. We do not find the technical arguments against intermediary devices raised by
Sage compelling. Sage argued that because legacy EAS devices “typically only handle one EAS message in
memory at a time,” whereas “CAP messages can arrive more quickly than [the legacy EAS device] can play them
back,” the legacy EAS device “can drop CAP originated EAS messages.” Sage Comments at 9. The EAS,
however, is inherently not capable of broadcasting more than one alert at a time, and the Part 11 rules do not require
storage of multiple EAS messages. Presumably, such storage requirements would be a feature of a CAP-centric,
Next Generation EAS. Sage also argues that because legacy EAS devices “have no concept of cancellation[,] [a]n
intermediary/legacy combination will sometimes put cancelled CAP messages on the air.” Id. at 10. While the
ECIG Implementation Guide provides for CAP message cancellation (see ECIG Implementation Guide, § 3.8.3),
there are no provisions in the Part 11 rules for cancelling valid EAS messages, once received, other than the EOM
code (and the decoder reset function), which intermediary and legacy EAS devices can process. Sage also argued,
“Since Intermediary Devices are not Part 11 certified, and are not required to emit valid EAS messages, the legacy
device could be subjected to invalid messages, duplicates, expired messages, and out of area messages to a far
greater extent tha[n] has been possible in the past,” adding that “[t]his could interfere with the reception of proper
messages, especially since legacy devices were required to store only one active message at a time.” Id. at 11.
However, CAP message validity is addressed in the ECIG Implementation Guide, with which intermediary devices
will be required to adhere. In addition, weeding out duplicate, expired and out-of-area messages takes place in the
legacy EAS device – not the intermediary device.
237 See SAGE comments at 11 (observing that intermediary equipment is only as good as its underlying legacy
devices, most of which are old and near the end of their useful life, expressing the belief that intermediate equipment
is not cost efficient when all costs are considered, and explaining that most of the hidden costs are the continued use
of a non-networked device from last century, which will eventually fail and need to be replaced).
31

Federal Communications Commission

FCC 12-7

replace this aging legacy EAS equipment and to allow equipment manufacturers time to develop possible
workarounds to allow intermediate devices to become compliant with our rules. Among the benefits that
CAP-compliant equipment will bring is an EAS that is more accessible to all Americans, including
Americans with disabilities, who will directly benefit from this new requirement.238 We agree with the
many commenters that argued that using CAP’s capacity for enhanced text would, among other things,
help harmonize the EAS rules with the requirements of section 79.2,239 and thus conclude that requiring
intermediate equipment to comply with these rules by June 30, 2015 is justified.
76.
We also reiterate that the limited functionality of both intermediary devices and the legacy
EAS devices with which they operate may render them unusually susceptible to changes in the Part 11
rules, such as development of new CAP functions and changes to the EAS codes. Whereas the record
indicates that integrated CAP-capable EAS devices are easily updateable to evolve with potential changes
to the CAP standard and any resulting Part 11 requirements, intermediary devices and legacy EAS
equipment may not be so adaptive. Accordingly, there is no guarantee that intermediary or legacy EAS
devices will not have to be replaced earlier than integrated CAP-capable EAS devices.240
77.
Encoder Requirements. The functional requirements for EAS encoders are set forth in
section 11.32.241 In the Third FNPRM, we sought comment on several CAP-related proposals involving
these requirements that were raised by CSRIC and parties responding to the Part 11 Public Notice.
78.
Section 11.32(a). Section 11.32(a) specifies the minimum requirements for encoders.242
This section requires that encoders be capable of encoding the EAS Protocol set forth in section 11.31,
providing the EAS code transmission requirements described in section 11.51, and meeting various other
specifications.243 In the Third FNPRM, we explained that CSRIC had recommended that the Commission
“[m]odify [the] EAS encoder minimum requirement” so that “EAS encoder[s] [are] capable of
[r]endering a fully CAP compliant message.”244 To the extent that CSRIC was proposing that EAS
encoders be required to be capable of encoding a CAP-formatted message (i.e., originating or somehow
transmitting a message in the CAP format as opposed to the SAME format), we sought comment on
whether such a requirement would be necessary or appropriate.245
79.
Commenters indicated that CSRIC’s recommendation was not to require encoding of the
CAP message but rather to revise section 11.32(a) to require that encoders are capable of encoding the
requisite EAS codes as extracted from a CAP message. Monroe, which indicated it was a member of the
CSRIC working group drafting the recommendations. clarified that “[t]he usage of the term ‘render’ in


238 See, e.g., RERC-TA Comments at 14; Wireless RERC Comments at 5; Trilithic Comments at 9.
239 See infra paras. 260-264.
240 For example, to the extent that legacy EAS devices cannot be updated to process new event or originator codes,
any decision to adopt such codes could render existing intermediary and legacy EAS device configurations obsolete.
We observe, in this regard, that NWS has requested the addition of a new event code into the EAS Protocol
covering extreme wind warnings. See National Oceanic and Atmospheric Administration, National Weather Service
Letter to Marlene H. Dortch, Secretary, FCC, EB Docket 04-296 (filed Aug. 4, 2011). Although this request is
beyond the scope of this proceeding, it is likely to be taken up in a separate proceeding in the near future.
241 See 47 C.F.R. § 11.32.
242 See id. § 11.32(a).
243 See id.
244 See Third FNPRM, 26 FCC Rcd 8149, 8172, para. 49 (citing CSRIC Final Report, § 5.1).
245 See id., para. 50.
32

Federal Communications Commission

FCC 12-7

[CSRIC’s recommendation on section 11.32(a)] was that of ‘converting’ or ‘encoding’ a CAP message
into EAS protocol output, in compliance with other Part 11 subsections ... [t]he working group did not
intend for the Commission to infer that ‘rendering’ in this instance meant ‘originating’ or ‘authoring’
CAP for the purposes of transmitting CAP XML content over broadcast media.”246 Other parties pointed
to the infeasibility of encoding anything other than the EAS Protocol components. Trilithic, for example,
explained, “Transmitting CAP messages over FSK is not feasible as it could take several minutes, and
would have to occur without any audio glitches for the entire transmission.”247 Sage observed, “As the
smallest possible CAP message containing EAS is about 13 times larger than a small EAS message,
sending a CAP message over a broadcast station with FSK data is not practical.”248
80.
Decision. We conclude that it is unnecessary to make any changes to the minimum
encoder requirements set forth in section 11.32(a) regarding CAP-to-SAME conversion. The conversion
of CAP-to-SAME is primarily a decoding function that CAP-compliant EAS equipment is designed to
perform. We are not requiring encoders to encode anything other than the relevant EAS Protocol
elements described in section11.31 that they have always been required to encode. This is the case
regardless of whether the relevant EAS Protocol elements are derived from a CAP-formatted message or
a SAME-formatted message. We could not do otherwise, because, as commenters point out, the EAS
encoding (i.e., AFSK modulation) process is incapable of conveying more than the limited EAS Protocol
elements currently required.249 As described above, it is this limitation that largely defines and
necessitates our transitional approach.
81.
Section 11.32(a)(2). Section 11.32(a)(2) specifies the input configuration requirements for
encoders.250 This section currently requires that encoders be configured with two inputs: one for audio
messages and one for data messages (RS–232C with standard protocol and 1200 baud rate).251 In the
Third FNPRM, we sought comment on whether we should modify these input specifications to require
that an encoder be configured with an Ethernet port and, if so, whether a single Ethernet port would be
sufficient to capture data streams from multiple sources and distribution platforms.252 We also asked
whether there are any other types of interface ports, such as a USB port, that we should include in the
configuration requirements.253 We also sought comment on whether we should retain the 1200 baud RS-
232C input requirement.254 Finally, we asked whether any configuration requirements we adopt for
encoder inputs also be applied to encoder outputs.255


246 Monroe Comments at 24. See also Timm Comments at 12-13.
247 Trilithic Comments at 8. See also ECIG Implementation Guide at 31 (“None of the enhanced descriptive
information at the CAP reception node can be inserted into the EAS FSK audio transmission stream by using the
basic standard EAS transmission method.” (italics omitted)).
248 Sage Comments at 12. See also id. at 23-24 (“EAS does not have the capability of sending the CAP text as part
of the EAS message. Even a short message of 500 characters will take 30 seconds of FSK air time when sent in the
EAS format.”).
249 For this reason, we must reject RERC-TA’s argument that “requiring EAS encoders to be capable of fully
encoding CAP-formatted messages (including all message formats) is appropriate.” RERC-TA Comments at 12.
250 See 47 C.F.R. § 11.32(a)(2).
251 See id.
252 See Third FNPRM, 26 FCC Rcd 8149, 8173, para. 52.
253 See id.
254 See id.
255 See id.
33

Federal Communications Commission

FCC 12-7

82.
The majority of comments appeared to favor leaving decisions on input configurations to
manufacturers, based upon market demand. Sage asserted, “While there is a need to tidy up the various
encoder and decoder requirements, these are not near-term problems, and can be deferred until such time
as the FCC contemplates removing the EAS requirement all together,” adding that “[o]ne example is the
deletion of the requirement for a 1200 baud serial port.”256 With respect to requiring data input ports,
Sage recommended, “As it is extremely unlikely that a CAP receiver intended for sale to the broadcast
industry would be built without an IP port, Sage’s recommendation is to not over-specify.”257
83.
With respect to the input configuration requirements of both encoders and decoders,
Monroe advised against eliminating the RS232 requirements on grounds that “there are numerous
broadcast and cable operations that current[ly] still utilize the RS-232C interface for various applications
and services.”258 Monroe added, “At a minimum, the revised rules should not preclude inclusion of RS-
232C interface as an option.”259 Monroe further recommended that the input configuration requirements
for both encoders and decoders “include a requirement for at least one Ethernet port.”260
84.
BWWG suggested there is “value in continuing RS-232 connectivity (and possibly
encouraging USB connectivity) as additional ways to communicate, control and update CAP EAS
devices.”261 BWWG also maintained that “the ultimate decision to incorporate USB ports should be left
to manufacturing stakeholders” and added that “the rules [should] be written in such a way to encourage
development of future improvements.”262 According to BWWG, “as long as a single Ethernet port can be
internally configured to poll multiple CAP servers, one port will suffice.”263
85.
Trilithic stated, “While we do not suggest (or discourage) making it a requirement, we
expect an Ethernet connection to be the input/output of choice for future (and present) EAS
Encoder/Decoders.”264 Regarding the RS232 requirement, Trilithic commented, “We do not see any
utility in the mention of RS232C connections (and 1200 BAUD format) in the current regulations, with or
without the addition of other input/output requirements” and suggested the “complete removal of
references to RS-232 communications.”265
86.
Decision. We agree with commenters that decisions concerning the total number and types
of data input ports configured into encoders are best left to equipment manufacturers, so that they can
respond to both the monitoring requirements of the CAP systems with which EAS equipment may
interface (such as IPAWS and state CAP systems), changes in technology, and costs of compliance. We
also believe that, for the sake of consistency with our transitional approach, the input configuration
requirements should continue to require audio and data connectivity. Accordingly, we are revising
section 11.32(a)(2) to require at least one audio input port and at least one data input port. We are also


256 Sage Comments at 12.
257 Id. See also NAB Comments at 18-19.
258 Monroe Comments at 25 (emphasis omitted).
259 Id.
260 Id. (emphasis omitted).
261 BWWG Comments at 25.
262 Id. See also NAB Comments at 18-19.
263 BWWG Comments at 25.
264 Trilithic Comments at 8.
265 Id.
34

Federal Communications Commission

FCC 12-7

deleting as unnecessary under this minimal requirement references to RS232-C and 1200 baud rate, which
manufacturers may continue to make available, if they so desire. Finally, we will apply this minimal
requirement of at least one audio port and at least one data port to the encoder output port configuration
requirements in section 11.32(a)(3), because the rationale above applies equally to the output ports and
the record strongly supports such application.266 Because commenters generally supported this outcome,
we see no unnecessary cost impact from this requirement.
87.
Decoder Requirements. The functional requirements for EAS decoders are set forth in
section 11.33.267 In the Third FNPRM, we sought comment on certain CAP-related proposals involving
these requirements that were raised by CSRIC and parties responding to the Part 11 Public Notice.
88.
Section 11.33(a). Section 11.33(a) specifies the minimum requirements for decoders.268
This section requires that decoders be capable of decoding the EAS Protocol set forth in section 11.31,
providing the EAS monitoring functions set forth in section 11.52, and meeting various other
specifications.269 In the Third FNPRM, we sought comment on whether the minimum requirements for
decoders in this section should include the capability to decode CAP-formatted messages and convert
them into SAME protocol-compliant messages, as set forth in section 11.56, and whether this requirement
can be met through the deployment of an intermediary device.270 We observed that the fundamental
purpose of decoders is processing EAS messages, whether formatted in the SAME or CAP protocols, and
adding CAP reception to section 11.33(a) would put CAP on the same footing as SAME.271
89.
Commenters generally supported adding a CAP-to-SAME conversion requirement to
section 11.33(a). Trilithic stated, “Given the current requirement to receive CAP formatted messages, we
do suggest that receiving CAP formatted message[s] and converting them to EAS Protocol Text should be
added to the Decoder section of the Commission[’]s rules,” adding that “[u]se of intermediary devices
should be allowed, at least for currently designed EAS Encoder/Decoders.”272 TFT asserted, “Current
decoders and intermediary devices should be required to conform to the current ECIG implementation
Guide.”273 Monroe agreed that the minimum requirements for decoders in section 11.33(a) “should
include the capability to decode CAP-formatted messages and convert them into SAME protocol-
compliant messages, as defined in the ECIG CAP-to-EAS Implementation Guide.”274 Monroe also
maintained, however, that it is not “convinced that this requirement can be fully met through the
deployment of an intermediary device.”275
90.
Decision. We are revising the minimum requirements for decoders in section 11.33(a) to
include the capability to decode CAP-formatted messages and convert them into SAME protocol-
compliant messages, as set forth in section 11.56 (which will require conformance to the ECIG


266 See, e.g., Monroe Comments at 25.
267 See 47 C.F.R. § 11.33.
268 See id. § 11.33(a).
269 See id.
270 See Third FNPRM, 26 FCC Rcd 8149, 8173-74, para. 54.
271 See id.
272 Trilithic Comments at 8.
273 TFT Comments at 3.
274 Monroe Comments at 14.
275 Id.
35

Federal Communications Commission

FCC 12-7

Implementation Guide) and clarify that this requirement can be met through the deployment of an
intermediary device. As we observed in the Third FNPRM, the fundamental purpose of decoders is to
ingest and process EAS messages, whether formatted in the SAME or CAP protocols, and adding CAP
reception to section 11.33(a) will put CAP on the same footing as SAME.276 Commenters addressing this
issue all supported this approach. We also find it appropriate to clarify in section 11.33(a) that
intermediary devices may be used to meet the fundamental decoder requirement of converting CAP
messages into SAME-compliant messages. Because this requirement does not impose a new technical
obligation, we believe the cost impact will be minimal.
91.
Section 11.33(a)(1). Section 11.33(a)(1) specifies the input configuration requirements for
decoders.277 This section currently requires that decoders be configured with “the capability to receive at
least two audio inputs from EAS monitoring assignments” and one data port (RS–232C with standard
protocol and 1200 baud rate).278 In the Third FNPRM, we sought comment on whether we should modify
these input specifications to require that a decoder be configured with an Ethernet port and, if so, whether
a single Ethernet port would be sufficient to capture data streams from multiple sources and distribution
platforms.279 We also asked whether there are any other types of interface ports, such as a USB port, that
we should include in the configuration requirements.280 We further sought comment on whether we
should retain the 1200 baud RS-232C input requirement.281 Finally, we asked whether any configuration
requirements we adopt for decoder inputs should also be applied to decoder outputs.282
92.
Commenters’ responses on the issues related to input (and output) configurations applied
to both decoders and encoders, and as described above, they generally favor leaving decisions on such
configurations to manufacturers, based upon market demand.283 Trilithic, for example, maintained,
“Current decoders should not be mandated to have an Ethernet port.”284 With respect to the RS-232C
issue, Trilithic observed, “Data ports are dynamic,” adding that “‘RS-232C’ is certainly obsolete [and]
‘USB 1.0’ is almost obsolete.”285 According to Trilithic, “[t]he [input and output port] description should
be kept general enough to provide for the functionality.”286
93.
Decision. For the same reasons described above with respect to encoder input
configuration requirements, we are revising section 11.33(a)(1) to require at least one data input port (this
section already requires the capability to receive “at least two audio inputs”).287 We are also deleting as
unnecessary any references to RS232-C and 1200 baud. We are also revising the decoder output
requirements in section 11.33(a)(7) to reflect these changes.


276 See Third FNPRM, 26 FCC Rcd 8149, 8173-74, para. 54.
277 See 47 C.F.R. § 11.33(a)(1).
278 See id.
279 See Third FNPRM, 26 FCC Rcd 8149, 8174, para. 56.
280 See id.
281 See id.
282 See id.
283 See, e.g., Sage Comments at 12-13; Monroe Comments at 25; NAB Comments at 18-19.
284 Trilithic Comments at 3.
285 Id.
286 Id.
287 See 47 C.F.R. § 11.33(a)(1).
36

Federal Communications Commission

FCC 12-7

94.
Section 11.33(a)(4). Section 11.33(a)(4) specifies certain visual display and logging
requirements for decoders.288 This section currently requires, among other things, the development of
visual display information from the EAS header codes, including the originator, event, location, valid
time period of the message, and the local time it was transmitted.289 This section also requires that
existing and new models of EAS decoders manufactured after August 1, 2003, provide a means to permit
the selective display and logging of EAS messages containing header codes for state and local EAS
events.290 In the Third FNPRM, we sought comment on whether messages derived from CAP per the
ECIG Implementation Guide should be added to the log.291
95.
The commenters responding to this issue supported mandatory logging of text derived
from CAP messages. Monroe, for example, stated, “We agreed with the concept that section §11.33(a)(4)
should be modified to require that if an alert message is derived from a CAP-formatted message, the
contents of the text, assembled pursuant to ECIG Implementation Guide, should be added to the EAS
device log.”292
96.
Decision. Based on the record, we are amending section 11.33(a)(4) to include selective
display and logging of the text that was compiled from CAP-formatted messages.293 This revision is
necessary to harmonize CAP-formatted message processing with SAME-formatted message processing.
We observe that our decision is supported by EAS equipment manufacturers, the industry affected by the
rule revision, and that the revision imposes no additional technical obligations or costs either to these
manufacturers or to EAS Participants.
97.
Section 11.33(a)(10). Section 11.33(a)(10) specifies certain error detection and message
validation requirements for decoders.294 This section currently requires, among other things, that
decoders not relay duplicate messages automatically.295 In the Third FNPRM, we indicated that CSRIC
had recommended that this section be revised “to handle duplicate messages [where one is CAP-
formatted] and use [the] CAP message by default,” as specified in the ECIG Implementation Guide.296
We also observed that the duplication concerns raised by CSRIC are addressed in the ECIG
Implementation Guide.297 We tentatively concluded that no revisions to section 11.33(a)(10) would be


288 See 47 C.F.R. § 11.33(a)(4).
289 See id.
290 See id.
291 See Third FNPRM, 26 FCC Rcd 8149, 8174-75, para. 57.
292 Monroe Comments at 25. See also BWWG Comments at 26.
293 We are not specifying in section 11.33(a)(4) that the text to be displayed and logged must have been produced in
conformance with the ECIG Implementation Guide, because we are requiring CAP-to-SAME conversion pursuant
to the ECIG Implementation Guide in section 11.56. To the extent the visual message compiled from the CAP
message is based solely upon the EAS header codes, either because the EAS Participant elected not to follow the
enhanced text procedures in section 3.6.4 of the ECIG Implementation Guide or because the EAS Participant
employs an intermediary device configured with a legacy EAS device to meet its CAP-related obligations that is
incapable of producing such enhanced text, the logged message will look the same as if it had been received in the
SAME format. To the extent that the EAS Participant elects to follow the enhanced text procedures in section 3.6.4
of the ECIG Implementation Guide, the logged message will mirror the enhanced text message.
294 See 47 C.F.R. § 11.33(a)(10).
295 See id.
296 See Third FNPRM, 26 FCC Rcd 8149, 8175, para. 58 (citing CSRIC Final Report, § 5.1).
297 See id. at 8175, para. 59.
37

Federal Communications Commission

FCC 12-7

required if we were to require decoding of CAP messages in conformance with the ECIG Implementation
Guide.298
98.
The comments were split on this issue. Monroe, for example, stated that it “concurred with
the tentative conclusion that there is no basis for revising section §11.33(a)(10) to require processing of
CAP-formatted message[s] by default when duplicate messages are received in both the EAS Protocol
and CAP formats if EAS Participants are required to translate CAP-formatted messages into SAME-
formatted message[s] in conformance with the ECIG Implementation Guide.”299 BWWG, however,
agreed with CSRIC’s recommendation to revise section 11.33(a)(11) to require handling of duplicate
messages as specified in the ECIG Implementation Guide.300
99.
Decision. We adopt our tentative conclusion set forth in the Third FNPRM and decline
CSRIC’s recommendation to revise section 11.33(a)(10) to require use of the CAP-formatted message
where a duplicate SAME-formatted message was also received. As we explained in the Third FNPRM,
the ECIG Implementation Guide includes a process for handling CAP messages where a duplicate
SAME-formatted message also has been received, which prefers (but does not require) use of the CAP
version.301 We are requiring CAP-to-SAME conversion in conformance with the ECIG Implementation
Guide, which should satisfy the underlying thrust of CSRIC’s recommendation. We also observe,
however, that the ECIG Implementation Guide recognizes that in certain circumstances, such as where the
audio file associated with a CAP alert cannot be opened, the SAME version of an alert may be preferable
to the CAP version.302 In addition, preferring CAP-formatted messages over duplicate SAME-formatted
messages may not be feasible in cases where an intermediary device is used to meet the CAP-related
requirements adopted in this order, as the legacy EAS device with which the intermediary device is
configured may not be capable of discerning any difference between the CAP-to-SAME converted
message it receives from the intermediary device and the SAME-formatted message it receives via its
over-the-air monitoring of another station’s broadcast. Accordingly, we do not believe it would be
reasonable to adopt a generally applicable rule requiring use of the CAP-formatted message in cases
where duplicate CAP-formatted and SAME-formatted messages are received, and we decline to do so
now. Because this obligation is consistent with the ECIG Implementation Guide, and thus imposes no
additional technical obligation, we believe that any costs will be minimal.
100. Section 11.33(a)(11). Section 11.33(a)(11) specifies that a header code with the EAN
event code that an EAS Participant receives through any of the audio inputs must override all other
messages.303 In the Third FNPRM, we sought comment as to whether we should update this provision to
include CAP-formatted messages received through a non-audio input, as EAS Participants will not
receive CAP-formatted messages through the audio port.304
101. The majority of commenters responding to this issue supported updating section
11.33(a)(11) to include CAP-formatted EAN messages received through a non-audio input. BWWG


298 See id.
299 Monroe Comments at 25-26. See also Sage Comments at 13.
300 See BWWG Comments at 26. See also Trilithic Comments at 8 (“We agree that duplicate messages should be
handled in accordance with the ECIG implementation recommendations.”).
301 See ECIG Implementation Guide, § 3.11.
302 See id.
303 See 47 C.F.R. § 11.33(a)(11).
304 See Third FNPRM, 26 FCC Rcd 8149, 8175, para. 60.
38

Federal Communications Commission

FCC 12-7

asserted that “this has to be done to be consistent with the existing Part 11 requirement that EAN
messages take absolute and primary priority.”305 Trilithic stated, “The rules should be modified to include
CAP messages (EG: ‘a message with the EAN event code that an EAS Participant receives through any
input must override all other messages’).”306 Sage, however, maintained that “[s]ections dealing with
CAP or EAS message handling need not refer to how the CAP or EAS message was acquired in the first
place,” adding that “the action for an EAN should be the same no matter how it was received.”307
102. Decision. We are revising section 11.33(a)(11) to ensure that EAN messages receive
priority over all other EAS messages, regardless of whether the EAN message was received via the audio
port or data port, or was formatted in SAME or CAP. This action is necessary because as currently
written, section 11.33(a)(11) could be interpreted to require a preference for SAME-formatted EAN
messages received via over-the-air broadcast monitoring over duplicate CAP versions of the same
message received via the data input port.308 In any event, we agree with BWWG that such action is
necessary to ensure that EAS equipment consistently gives EANs priority, regardless of how it receives
them.309 This is a programming issue that should impose minimal costs, if any.
5.

Miscellaneous Rule Changes Related to Fully Implementing CAP

103. Section 11.1. Section 11.1 specifies the purpose of the EAS.310 Among other things, this
section provides that “[t]he EAS may be used to provide the heads of State and local government, or their
designated representatives, with a means of emergency communication with the public in their State or
Local Area.”311 In the Third FNPRM, we explained that CSRIC had recommended that we update this
section “to include new CAP related alert originators.”312 Accordingly, we sought comment on whether
such action is necessary or whether the language currently in section 11.1 is broad enough to capture
these entities so that EAS Participants may or must carry their alert messages.313 The one commenter
addressing this issue, BWWG, opposed specifying governors (or their designees) as CAP originators in
the rules.314
104. Decision. We conclude that the existing definition in section 11.1, which covers federal,
state, and local government users, and their designees, is broad enough to capture all authorized users of
the EAS, whether they initiate SAME-formatted messages or CAP-formatted messages. Accordingly, we
decline to revise section 11.1 to include new CAP-related alert originators, as recommended by CSRIC.
105. Section 11.11. Section 11.11 identifies the various categories of EAS Participants and


305 BWWG Comments at 27.
306 Trilithic Comments at 9.
307 Sage Comments at 13.
308 See 47 C.F.R. § 11.33(a)(11) (“A header code with the EAN Event code specified in § 11.31(c) that is received
through any of the audio inputs must override all other messages.”).
309 See BWWG Comments at 27.
310 See 47 C.F.R. § 11.1.
311 Id.
312 See Third FNPRM, 26 FCC Rcd 8149, 8176, para. 61 (citing CSRIC Final Report, § 5.1).
313 See id.
314 See BWWG Comments at 27-28.
39

Federal Communications Commission

FCC 12-7

specifies their minimum equipment deployment and audio/visual message transmission obligations.315 In
the Third FNPRM, we sought comment on whether we should delete the reference to “analog television
broadcast stations” from section 11.11, and whether we should amend the text of section 11.11(a) to
include as a minimum requirement compliance with the CAP-related requirements in section 11.56.316
Monroe supported both proposed actions.317 BWWG supported amending section 11.11(a) to incorporate
the CAP-related requirements in section 11.56.318
106. Decision. We are amending section 11(a) to delete the reference to “analog television
broadcast stations” and to include as a minimum requirement compliance with the CAP-related
requirements in section 11.56. As we observed in the Third FNPRM, the reference to “analog television
broadcast stations” is obsolete in light of the fact that since June 13, 2009, all full-power U.S. television
stations have broadcast over-the-air signals in digital only.319 Incorporating the CAP-related obligations
in section 11.56 by reference into section 11.11(a) is necessary to put CAP and SAME on an equal
footing in Part 11.
107. Section 11.11 equipment deployment tables. We sought comment in the Third FNPRM on
whether, for CAP purposes, we should amend the equipment deployment tables in section 11.11 by
adding a footnote to the “EAS decoder” entries in the tables, indicating that EAS Participants may elect to
meet their obligation to receive and translate CAP-formatted messages by deploying an intermediary
device in addition to the EAS decoder used to decode messages transmitted in the EAS Protocol.320 We
also observed that all of the effective dates identified in the equipment deployment tables have long
expired, and as a result, some equipment deployment obligations that once were staggered among EAS
Participants now apply equally to all of them.321 Accordingly, we sought comment on whether we should
delete the date references in the equipment deployment tables in section 11.11 (as well as cross-references
to these dates in other sections of Part 11, such as section 11.51(c) and (d)), along with the entry for two-
tone encoders.322 We also sought comment on whether the equipment deployment tables covering analog,
wireless, and digital cable and wireline video systems could be combined into a single table, as well as
any other revisions we could make to section 11.11 to streamline it and make it easier to follow.323
108. Monroe recommended “that the text in the table ‘Analog and Digital Broadcast Stations’
be amended to reflect ‘CAP EAS encoder’ and ‘CAP EAS decoder’.”324 Monroe also recommended that
rather than adding a footnote to the “decoder” entries in the equipment deployment tables to clarify
acceptance of using intermediary devices to meet decoder requirements, all of these tables be eliminated,
and “in their place simply require EAS participants to require a CAP EAS encoder-decoder or CAP EAS
decoder.”325 Trilithic asserted, “We believe that all references to expired effective dates should be


315 See 47 C.F.R. § 11.11.
316 See Third FNPRM, 26 FCC Rcd 8149, 8176-77, para. 63.
317 Monroe Comments at 26.
318 BWWG Comments at 28.
319 See Third FNPRM, 26 FCC Rcd 8149, 8176-77, para. 63.
320 See id. at 8177, para. 64.
321 See id., para. 65.
322 See id.
323 See id.
324 Monroe Comments at 26.
325 Id. at 14-15.
40

Federal Communications Commission

FCC 12-7

removed, and when requirements are identical between (previously) separate participant groups, these
groups should be consolidated.”326 BWWG agreed generally with all of the proposals except for adding a
footnote to decoder entries that would clarify the use of intermediary devices.327
109. Decision. We are adopting the proposals in the Third FNPRM described above.
Specifically, we are amending the equipment deployment tables in section 11.11 by adding a footnote to
the “EAS decoder” entries in the tables to clarify that the obligation to receive and translate CAP-
formatted messages may be met by deploying an intermediary device. As we indicated in the Third
FNPRM
, the equipment deployment obligations are not changing due to CAP, and CAP-related
requirements specific to EAS encoders and decoders are incorporated into the Part 11 sections addressing
these devices (specifically, sections 11.32 and 11.33).328 However, as indicated above, we are allowing
EAS Participants to deploy intermediary devices to meet their CAP-related obligations. As the tables in
section 11.11 already require deployment of EAS decoders, a reference to intermediary devices (which
are stand-alone equipment in their own right) is required for consistency. We also are deleting the date
references in the equipment deployment tables in section 11.11 (as well as cross-references to these dates
in other sections of Part 11, such as section 11.51(c) and (d)), along with the entry for two-tone encoders.
This action also is required for consistency and has support in the record.
110. Finally, we sought comment in the Third FNPRM on whether we should incorporate
monitoring requirements or references thereto into section 11.11.329 No party addressed this issue
directly, and we conclude that incorporating references to section 11.52 in section 11.11 is unnecessary.
As we explained in the Third FNPRM, decoders already are required to meet the monitoring requirements
in section 11.52, which we are amending to include CAP monitoring.330 Accordingly, the basic
requirement to deploy a decoder (or intermediary device) necessarily triggers CAP monitoring
obligations.
111. Section 11.20. Section 11.20 generally describes the functions and architectural elements
of state relay networks.331 Among other things, this section provides that state relay networks distribute
“State EAS messages” and may be composed of “any … communications facilities” and that “any …
communications technology may be used to distribute State emergency messages.”332 As we explained in
the Third FNPRM, CSRIC and parties responding to the Part 11 Public Notice suggested revising the
language in section 11.20 to include CAP sources and the relay of CAP alerts via state CAP relay
networks.333 Accordingly, we sought comment on whether the existing language of section 11.20 requires
a specific reference to CAP in light of the fact that its language broadly covers “EAS messages,” which
could be in the SAME or CAP formats and distributed over “any” communications facility or


326 Trilithic Comments at 9.
327 BWWG Comments at 29.
328 See Third FNPRM, 26 FCC Rcd 8149, 8177, para. 64.
329 See id., para. 66.
330 See id.
331 See 47 C.F.R. § 11.20.
332 Id.
333 See Third FNPRM, 26 FCC Rcd 8149, 8178, para. 68.
41

Federal Communications Commission

FCC 12-7

technology.334 We also sought comment on whether we need to incorporate CAP monitoring into section
11.20.335
112. The majority of commenters addressing this issue appeared to agree that CAP transmission
should be incorporated into section 11.20. BWWG observed, “While the language does seem to cover all
authorized EAS modes, it seems to the BWWG that CAP should be mentioned into this section so there is
no doubt or uncertainty.”336 RERC-TA responded, “From the perspective of people with disabilities,
adding CAP state relay networks would be beneficial, because ... the conversion to SAME entails a loss
of accessibility.”337 Monroe asserted that “the language of section §11.20 should be amended to provide
State Relay Networks with the option of distributing EAS messages in CAP and/or legacy EAS
format.”338 NAB generally supported CSRIC’s recommendation.339 TFT and Sage, on the other hand,
stated that issues of CAP monitoring and distribution should be left to the State EAS Plans.340
113. Decision. We conclude that no changes to section 11.20 are necessary to accommodate the
distribution of CAP messages. Specifically, we conclude that the language in section 11.20 is broad
enough to encompass EAS messages originated in CAP format, to the extent that a given state relay
network is capable of distribution of that state’s EAS alerts in CAP. We agree with RERC-TA that alerts
delivered over CAP-based alerting networks are potentially fully accessible to people with disabilities.
As we discuss in section II.F(6) of this order, we are requiring EAS Participants to display any enhanced
text that an alert initiator supplies in a CAP alert in part as an incentive for state and local alert message
originators to deploy and use CAP-based alert systems. Although we believe that providing state and
local alert message originators with a conduit for the transmission of fully accessible alerts should
facilitate alert originators’ compliance with the CVAA341 and otherwise encourage alert originators to
craft messages that will provide accessible alerting for persons who are sight-impaired or hard of hearing,
requiring states to do so is beyond our purview. It is up to each state to determine whether to deploy a
CAP-based relay network. Moreover, we do not wish to predetermine the manner in which a particular
state may construct its relay network to distribute CAP messages. We agree with Sage’s recommendation
that “the FCC not over specify the way that stations receive state or local messages, but instead defer to a
state [EAS] plan.”342 Accordingly, we will not alter section 11.20, and thus there should not be any costs
associated with this decision. .
114. Section 11.21(a). Section 11.21 generally specifies the contents of State and Local Area
EAS Plans and the FCC Mapbook.343 Among other things, section 11.21(a) indicates that such plans
should identify the “monitoring assignments and the specific primary and backup path for the EAN from


334 See id.
335 See id., para. 69.
336 BWWG Comments at 30.
337 RERC-TA Comments at 13.
338 Monroe Comments at 26.
339 NAB Comments at 19.
340 TFT Comments at 3; Sage comments at 13-14.
341 See infra note 782783 for a more detailed discussion on the requirements of the CVAA.
342 Sage Comments at 14.
343 See 47 C.F.R. § 11.31(a)-(c).
42

Federal Communications Commission

FCC 12-7

the PEP to each station in the plan.”344 In the Third FNPRM, we explained that, with respect to this
section, CSRIC recommended that we “[i]nclude language on EAN distribution via IPAWS.”345 We
tentatively concluded that we should revise the language in section 11.21(a) to make clear that the State
EAS Plans specify the monitoring assignments and the specific primary and backup path for SAME-
formatted EANs and that the monitoring requirements for CAP-formatted EANs are set forth in section
11.52.346 We sought comment on this tentative conclusion.347 TFT responded that “CAP distribution and
assignment should be a function of a State Plan with default to IPAWS-OPEN.”348
115. In the Third FNPRM, we also explained that the State EAS Plan requirements in sections
11.21(a) (and 11.55(a)) specifying the obligation to process CAP-formatted messages initiated by state
governors fail to specify that the obligation applies to CAP-formatted messages.349 We tentatively
concluded that we should amend the text of both sections to make clear that they apply to CAP-formatted
EAS messages and sought comment on this tentative conclusion.350 All commenters addressing this issue
agreed with our tentative conclusion.351
116. Decision. We are amending section 11.21(a) to make clear that the State EAS Plans
specify the monitoring assignments and the specific primary and backup path for SAME-formatted EANs
and that the monitoring requirements for CAP-formatted EANs are set forth in section 11.52. We do not
know what role, if any, state alerting systems may play in disseminating CAP-formatted EANs in the
future. Accordingly, we also include language that to the extent a state may distribute CAP-formatted
EANs to EAS Participants via its state alerting system, its State EAS Plan must include specific and
detailed information describing how such messages will be aggregated and delivered, just as it must for
state CAP-formatted non-EAN messages. This requirement is closely related to what SECCs and LECCs
already do to draft state EAS plans, so the cost in time and resources should be de minimis. The benefit to
the public from this requirement will be significant because State EAS plans drafted pursuant to this
revised rule will clearly indicate the path that an EAN will take within a particular state, thus providing
data that will allow the Commission, FEMA or the individual state to conduct meaningful EAS tests.
117. With respect to clarifying in section 11.21(a) (and 11.55(a)) that the mandate to process
gubernatorial alerts applies to CAP alerts, this issue has become moot in light of our decision to eliminate
the obligation that EAS Participants receive and process CAP-formatted gubernatorial alerts. However,
detailed information describing how state-originated CAP-formatted messages will be aggregated and
distributed to EAS Participants, including applicable monitoring requirements, must be detailed in the
State EAS Plans, just as the equivalent information for SAME-formatted alerts always has been. We are
amending section 11.21(a) to make this clear.
118. Section 11.21(c). Section 11.21(c) defines the FCC Mapbook, specifying that it is based
upon the State and Local Area EAS plans and “organizes all broadcast stations and cable systems


344 47 C.F.R. § 11.31(a). EAS Participants are required to monitor the stations identified in the state plan for federal
EAS message purposes under sections 11.52(d) and 11.54(b)(1), 47 C.F.R. §§ 11.52(d), 11.54(b)(1).
345 See Third FNPRM, 26 FCC Rcd 8149, 8178-79, para. 71 (citing CSRIC Final Report, § 5 .1).
346 See id. at 8179, para. 72.
347 See id.
348 TFT Comments at 4.
349 See Third FNPRM, 26 FCC Rcd 8149, 8179, para. 73.
350 See id.
351 See Monroe comments at 26; BWWG comments at 31-32; Timm comments at 3.
43

Federal Communications Commission

FCC 12-7

according to their State, EAS Local Area, and EAS designation.”352 We sought comment in the Third
FNPRM
on whether and, if so, how we should revise these requirements to identify federal and state CAP
message origination and distribution.353 We also asked whether State and Local EAS Plans are
sufficiently specific or reliably updated at sufficiently regular intervals to be accurately reflected in the
latest version of the FCC Mapbook.354 We sought comment on whether the FCC Mapbook should
provide a simple representation of how EANs are distributed from the PEP/NP stations to the PN/NN
stations within a state as opposed to a list of each individual station within the state.355 We observed that
any State EAS Plan drafted in this manner would lack the data to enable the Commission to assemble a
mapbook beyond the LP level and would not include information concerning many EAS Participants,
including all cable providers.356 We received various comments addressing these issues.357
119. Decision. We defer taking any action on this issue until, at a minimum, we have
completed our review of the test data we will be receiving from EAS Participants as a result of the
November 9, 2011, Nationwide EAS Test.358
120. Section 11.31(a)(3). Section 11.31(a) specifies the components of an EAS message that
comprise the EAS Protocol.359 Section 11.31(a)(3) states that the actual message “may be audio, video or
text.”360 As we explained in the Third FNPRM, TFT, responding to the Part 11 Public Notice, had
asserted that “the provision for video or text in [section 11.31(a)(3)] is no longer necessary” because
“CAP messages have the ability to contain video, audio, graphics and text [and] CAP receiving
equipment may (optionally) have additional features such as text-to-speech.”361 We sought comment on
TFT’s proposal, which appeared to be premised upon changing the EAS Protocol to accommodate CAP’s
capabilities.362 TFT commented, “Rather than change the EAS protocol, flexibility should be permitted to
display visually elements in a CAP-encoded message if those elements are available.”363 No other
commenter directly addressed this issue.
121. Decision. As we indicate above, in this order, we are not altering the EAS Protocol or the
EAS generally but instead are establishing rules to enable a CAP-formatted message to be converted into
the EAS Protocol for transmission over the current EAS architecture. As we explain in section IV.B(5) of


352 47 C.F.R. § 11.21(c).
353 See Third FNPRM, 26 FCC Rcd 8149, 8179-80, para. 74.
354 See id.
355 See id. at 8180, para. 75.
356 See id.
357 See, e.g., BWWG Comments at 32; Timm Comments at 3-4; NCTA Comments at 12-13.
358 As we observed in the Third FNPRM, the National Test Order required EAS Participants to submit various test
data to the Commission, including identification of the monitored station whose EAS broadcast was decoded, which
might aid in preparing accurate information on EAS monitoring assignments. See Third FNPRM, 26 FCC Rcd
8149, 8180, para. 75 (citing the National Test Order).
359 See 47 C.F.R. § 11.31(a).
360 Id. § 11.31(a)(3).
361 See Third FNPRM, 26 FCC Rcd 8149, 8180-81, para. 77 (citing TFT, Inc., Comments, EB Docket 04-296 (filed
June 11, 2010) at 4).
362 See id.
363 TFT Comments at 4.
44

Federal Communications Commission

FCC 12-7

this order, we are also amending the requirements in sections 11.51(d), (g)(3), (h)(3), and (j)(2) to require
EAS Participants to make full use of the rich text data in the CAP message to create the video crawl.
However, such enriched text will only be available to viewers of EAS Participants that receive the CAP
version of the message, as this text cannot be encoded for further distribution in the EAS Protocol format.
Accordingly, the language in section 11.31(a)(3) limiting the EAS Protocol message to audio, video, or
text remains valid.364 As our decision does not alter our rules or the EAS protocol, there should not be
any costs associated with it.
122. Section 11.35(a). Section 11.35(a) specifies certain operational readiness requirements for
EAS equipment.365 This section currently requires, among other things, that EAS Participants install EAS
equipment so that the monitoring and transmitting functions are available during the times that the EAS
Participants’ stations and systems are in operation, that EAS Participants determine the cause of any
failure to receive the required tests or activations during tests, and that EAS Participants make appropriate
log entries indicating reasons why they did not receive any tests.366 We explained in the Third FNPRM
that CSRIC had recommended that we update this section “to include the CAP receiving requirement.”367
We tentatively concluded that it is unnecessary to include a CAP-receiving requirement in section
11.35(a) because the obligation to receive CAP is specified in 11.56, and we proposed to include this as a
minimum requirement in several other rule sections as well.368 We sought comment on this tentative
conclusion.369
123. Two parties addressed this issue. BWWG agreed with our tentative conclusion.370
Monroe, on the other hand, states: “At a minimum, it should be specified that CAP EAS encoder/decoders
fall under the same requirements of §11.35(a), (b) and (c).”371 Monroe added, “to the extent that
intermediary devices are permitted, it is unclear why they would or should be exempt from the
operational readiness requirements set forth under §11.35, as their role as and EAS encoder (certified or
not) would represent a critical vulnerability and potential point of failure.”372
124. Decision. We are amending sections 11.35(a) and (b) to clarify that these subsections
apply to all equipment used as part of the EAS, including all equipment that performs the functions of
decoding and encoding messages formatted in the EAS Protocol and the Common Alerting Protocol. We
observe that sections 11.35(a) and (b) apply to EAS Encoders and Decoders and have terms that are broad
enough to capture both integrated CAP-capable EAS devices as well as intermediary devices. However,
we are clarifying the language in these sections to remove any ambiguity on this issue. Because this
amendment does not alter EAS Participants’ underlying obligations, any costs associated with our
decision should be minimal.


364 As we explained in the Third FNPRM, in practice, only audio is sent. See Third FNPRM, 26 FCC Rcd 8149,
8154-55, note 29.
365 See 47 C.F.R. § 11.35(a).
366 See id.
367 See Third FNPRM, 26 FCC Rcd 8149, 8181, para. 78 (citing CSRIC Final Report, § 5.1).
368 See id.
369 See id.
370 See BWWG comments at 33.
371 Monroe Comments at 26.
372 Id.
45

Federal Communications Commission

FCC 12-7

125. Section 11.45. Section 11.45 prohibits false or deceptive EAS transmissions.373 This
section specifies that “[n]o person may transmit or cause to transmit the EAS codes or Attention Signal,
or a recording or simulation thereof, in any circumstance other than in an actual National, State or Local
Area emergency or authorized test of the EAS.”374 We explained in the Third FNPRM that CSRIC had
recommended that we “[m]odify [the] Prohibition to reference CAP ‘Actual’ status indicators” and noted
that the “actual” status for CAP messages is defined in the ECIG Implementation Guide.375 We observed
that if all EAS Participants are required to translate CAP-formatted messages pursuant to the ECIG
Implementation Guide, any restrictions in the ECIG Implementation Guide against broadcasting CAP-
formatted messages would apply.376 We also observed that the language of section 11.45 prohibiting false
or deceptive EAS transmissions applies regardless of whether such transmissions were initiated by a
CAP-formatted message or a SAME-formatted message.377 We sought comment on whether we should
make any revisions to section 11.45 to accommodate CAP-formatted messages.378
126. We received little comment on this issue. Monroe stated, “We feel that it may make sense
to revise or expand section §11.45 to accommodate CAP-formatted messages.”379 BWWG stated, “To the
knowledge of the BWWG, there have never been any intentionally false EAS transmissions,” adding that
“[t]he errors that we do know about that are also well known to all EAS subject experts are origination
problems in the emergency management domain.”380 Accordingly, BWWG noted that it “saw no need for
further prohibitions.”381
127. Decision. We decline to adopt CSRIC’s recommendation to revise section 11.45 to
prohibit CAP messages lacking “Actual” status indicators. As we observed in the Third FNPRM, the
language in section 11.45 already broadly prohibits the transmission of the EAS codes or attention signal
“in any circumstances other than in an actual National, State or Local area emergency.”382 This language
is sufficiently broad to encompass EAS codes and attention signals generated from the receipt of a
SAME-formatted or CAP-formatted message.383 In addition, the ECIG Implementation Guide – with
which we require conformance for CAP-to-SAME conversion – requires that CAP messages have an
“ACTUAL” status indicator for EAS activation.384
128. Section 11.51. Section 11.51 specifies EAS code and Attention Signal transmission
requirements.385 This section currently lists, among other things, certain basic encoder requirements for


373 See 47 C.F.R. § 11.45.
374 Id.
375 See Third FNPRM, 26 FCC Rcd 8149, 8181, para. 79 (citing CSRIC Final Report, § 5.1).
376 See id. (citing ECIG Implementation Guide, §§ 3.9, 4).
377 See id.
378 See id.
379 Monroe Comments at 26. See also Timm Reply Comments at 5-6.
380 BWWG comments at 34.
381 Id.
382 See Third FNPRM, 26 FCC Rcd 8149, 8181, para. 79 (citing 47 C.F.R. § 11.45).
383 See 47 C.F.R. § 11.45.
384 See ECIG Implementation Guide, §§ 3.9, 4.
385 See 47 C.F.R. § 11.51.
46

Federal Communications Commission

FCC 12-7

the various classes of EAS Participants.386 For example, sections 11.51(g)(1), (h)(1), (i)(1), and (j)(1)
require that the applicable EAS Participants must, among other things, “install, operate, and maintain
equipment capable of generating the EAS codes.”387 In the Third FNPRM, we explained that CSRIC had
recommended changing this language to state that “[e]quipment must be capable of rendering a CAP
compliant message to EAS[,] [a]s opposed to simply generating an EAS code.”388 Assuming that by
“rendering,” CSRIC meant “encoding” a CAP-formatted message – and in light of our transitional
approach, under which EAS Participants would not be required to encode EAS messages in the CAP
format – we tentatively concluded that we should not adopt CSRIC’s recommendation and sought
comment on this tentative conclusion.389 As we discuss above, commenters indicated that CSRIC’s use of
the term “render” did not mean to “encode” the CAP message but rather to “convert” it into a SAME-
compliant message.390
129. Decision. We adopt the tentative conclusion in the Third FNPRM. To the extent CSRIC
meant to revise section 11.51 to ensure conversion of CAP messages into SAME-compliant messages, we
are incorporating that requirement in section 11.56. This is a fundamental requirement that will be cross-
referenced in other sections of Part 11. In addition, as we are not changing the basic output requirements
in section 11.51, including the requirements to generate EAS header codes under our transitional
approach, any costs associated with our decision should be minimal.
130. Sections 11.51(d), (g)(3), (h)(3), and (j)(2) establish when EAS Participants must transmit
visual EAS messages – typically aired in the form of a video crawl – and requires that such messages
contain the originator, event, location, and the valid time period of the EAS message.391 As explained in
the Third FNPRM, parties responding to the Part 11 Public Notice had recommended that we allow EAS
Participants to derive the visual message from the pertinent fields within the CAP message, rather than
the EAS header codes.392 These parties observed that the CAP data allowed for more descriptive alert
information than the EAS header codes.393
131. In the Third FNPRM, we proffered a tentative view that during the interim period until the
Next Generation EAS is fully implemented, the message that EAS Participants transmit to the public
should be uniformly consistent whether it is originated in SAME or CAP, to avoid any possible confusion
that might result if EAS Participants affected by the same alert displayed differing video crawls.394 We
sought comment on whether we should continue to use the SAME-based protocol codes as the baseline
for deriving the visual EAS message requirements in section 11.51.395 We asked, for example, whether
there would be any potential for confusion if the viewers in one area were presented with a video crawl
developed from an EAS message received and formatted in SAME, while viewers in another area were
presented with a video crawl developed from the identical EAS message received and formatted in


386 See id.
387 See 47 C.F.R. § 11.51(g)(1), (h)(1), (i)(1), (j)(1).
388 See Third FNPRM, 26 FCC Rcd 8149, 8181-82, para. 80 (citing CSRIC Final Report, § 5.1).
389 See id. at 8182, para. 81.
390 See supra para. 79.
391 See 47 C.F.R. § 11.51(d), (g)(3), (h)(3), (j)(2).
392 See Third FNPRM, 26 FCC Rcd 8149, 8182, para. 82.
393 See id.
394 See id. at 8182-83, para. 83.
395 See id. at 8183, para. 85.
47

Federal Communications Commission

FCC 12-7

CAP.396 We also asked whether there would be any likelihood of such an occurrence, given that (i) the
default for processing identical SAME- and CAP-formatted EAS messages under the ECIG
Implementation Guide is to process the CAP-formatted message;397 and (ii) the restriction against
processing duplicate messages.398
132. Every commenter addressing this issue opposed our tentative conclusion and instead
favored allowing EAS Participants to construct the video crawl from the enhanced text in CAP per the
ECIG Implementation Guide. Sage, for example, contended that “Part 11 should permit the best
information available to be presented to the audience, and not [the] lowest common denominator EAS
message.”399 According to Sage, “The advantage to the public of allowing the TV station to air either
CAP or EAS+CAP far outweighs any desire to have viewers of one station see the same message as
would the viewers of a station that did not receive the CAP message, or that used an Intermediate device
that could not generate the CAP crawl.”400
133. Citing CAP’s capacity to convey text beyond that which is technically practical under the
EAS Protocol, Monroe supported following the visual display procedures in the ECIG Implementation
Guide, which Monroe observed “describes the method already adopted by industry and FEMA for
constructing the alert display text.”401 Trilithic endorsed substituting the CAP text for the text derived
from the EAS header codes, arguing that “[t]he EAS Protocol Translation text has long been a blemish in
Emergency messaging,” further asserting that “[i]n many instances (particularly Amber alerts) this text is
close to useless.”402 Trilithic also observed that “TV Broadcasters are required to provide the same
information in both the audio and video portions of their programming, and CAP text finally provides a
mechanism for this.”403 Trilithic argued, “While uniformity is extremely important, providing useful
information to the hearing impaired is far more important.”404 Trilithic maintained that “the requirement
to display a translation of the EAS Protocol Text should be dropped for messages received in CAP
format,” on grounds that such requirement “shortens the usable length of the more useful CAP text, and
(assuming the CAP text is allowed) delays the presentation of that text to the viewer.”405
134. Similar to Trilithic, Timm argued that section 11.51 “should be amended to allow the
substitution of the CAP-derived text, when available, in place of the Header Code derived text.”406
Regarding potential confusion from some stations scrolling the CAP-derived text and others scrolling text
derived from the EAS header codes, Timm asserted that “the most confusion currently created in EAS is


396 See id.
397 See id. (citing ECIG Implementation Guide, § 3.11, which provides that “If a CAP-to-EAS device receives an
alert in the EAS domain, and it has a duplicate alert that has been received via CAP, but neither has yet aired, it
SHOULD use the CAP version of the alert.”).
398 See id. (citing 47 C.F.R. § 11.33(a)(10)).
399 Sage Comments at 15.
400 Id.
401 Monroe Comments at 23-24.
402 Trilithic Comments at 9.
403 Id.
404 Id.
405 Id.
406 Timm Comments at 4. See also BWWG Comments at 35.
48

Federal Communications Commission

FCC 12-7

when the Header Code derived message scrolls an evacuation or other warning as being for an entire
county when the audio message is saying it is only for a small portion of the county.”407 Timm
maintained that requiring the CAP-derived text to scroll after the text derived from the EAS header codes
(as specified in the ECIG Implementation Guide) “wastes valuable limited presentation time and truncates
the more precise CAP-derived text.”408
135. NAB asserted that “visual messages developed from a legacy SAME-formatted message
should serve as the baseline amount of information broadcast to viewers, but that no restrictions should be
placed on an EAS Participant’s optional delivery of additional alert-related information in the event a
participant has the ability to encode a CAP-formatted message.”409 According to NAB, “From a
pragmatic standpoint, it makes little sense to prevent the public from receiving video crawls containing
enhanced emergency information, such as evacuation routes, street-by-street closings, car descriptions for
AMBER Alerts, etc., should their EAS Participant be capable of delivering such content.” 410 NAB also
asserted that “concerns about potential confusion among viewers are easily overcome by the public
benefits of providing better, more descriptive emergency warning visual crawls wherever possible, even if
some measure of consistency must be sacrificed.”411 Google agreed with other commenters “that the
benefits of permitting and encouraging transmission of the CAP-enhanced video crawl (per the ECIG
Implementation Guide) outweigh the risk of confusion,” further arguing that “[d]issemination of accurate
and useful information to the public must be the first priority.”412
136. The Wireless RERC also maintained that EAS Participants should be allowed to create the
video crawl from the enhanced text in the CAP message.413 Specifically, the Wireless RERC
recommended “that the Commission permit and encourage the following or similar language ‘If an EAS
participant transmits an EAS text message that has been constructed from a received CAP message, the
EAS participant can also transmit any text from the received CAP message that provides additional
information beyond the required EAS protocol elements.’”414 The Wireless RERC added, “The
additional text relating to the emergency alert would allow for more description which is highly important
to those persons with hearing limitations.”415 The Wireless RERC also recommended that “[i]f the
received CAP message contains audio, then the EAS participant can use speech to text conversion to
provide the additional text information.”416 The Wireless RERC asserted, “the risk of confusing different
segments of the public due to a crawl from one EAS participant (developed from a CAP message) having
more information than a crawl from another EAS participant (developed from an EAS protocol message)
is far outweighed by the importance of providing all of the available information about an emergency to
the public, especially to people with disabilities.”417


407 Timm Comments at 4. See also BWWG Comments at 36.
408 Timm Comments at 4.
409 NAB Comments at 21.
410 Id.
411 Id.
412 Google Reply Comments at 3 (footnote omitted).
413 Wireless RERC Comments at 5.
414 Id.
415 Id.
416 Id.
417 Id.
49

Federal Communications Commission

FCC 12-7

137. The RERC-TA noted, “Having more detailed information than what EAS/SAME currently
allows in the video crawl would be a boon for people who are deaf or hard of hearing, because it would –
if enough information is included in the crawl – free them up from having to obtain additional
information through other channels.”418 The RERC-TA also acknowledged “the potential for confusion
and the risk of duplicate broadcasts if extra information is made available through the CAP-specific fields
in an emergency alert” but maintained that “this drawback is outweighed by the resulting immediate
accessibility improvements for everyone except people who are deaf-blind.”419 The RERC-TA added,
“Improved access results in more lives saved, which should trump all other considerations.”420
138. Decision. We are persuaded by the many commenters that favor more comprehensive use
of CAP to make EAS alerts more fully accessible. We are thus amending sections 11.51(d), (g)(3), (h)(3),
and (j)(2) of the Commission’s rules to require EAS Participants to derive the visual display elements,
including the originator, event, location and the valid time period of the EAS message, from the CAP text
data as described in section 3.6 of the ECIG Implementation Guide. As we observed in the Third
FNPRM
, the ECIG Implementation Guide provides procedures for deriving the video crawl translation of
a CAP-formatted message to include not only the EAS codes required under the Part 11 rules, but also
additional text relating to the event, which we believe would provide more visual information to alert
message viewers.421 The utility of such additional text has never been in question. For example, the
ability to provide additional descriptive information will make alerts more focused, which could be vitally
important for Amber alerts and other alerts that require more specific information than the basic who,
what, when and where that EAS codes provide.422 CAP alert originators will also be able to include in
alerts suggested actions to avoid or prepare for the emergency condition; identify URLs and other sources
of additional information; or provide a textual translation of the audio portion of a message, which would
be particularly beneficial to the deaf and hard of hearing community.423
139. We are also persuaded by the comments that our concern expressed in the Third FNPRM
regarding the potential for confusion that might arise if stations serving the same geographic area
displayed differing video crawls (one based on the SAME elements only and the other based on the
enhanced CAP text) is outweighed by the benefit that the enhanced text provides.424 We observe that
such scenarios would arise only when one (or more) of the stations in the geographic area affected by the
emergency loses its ability to receive CAP messages but continues to receive over-the-air SAME
messages. In addition, as Monroe observed, the ECIG Implementation Guide procedure for displaying
enhanced CAP text has already been adopted by the industry and FEMA.425 Requiring display of
enhanced CAP text will provide an incentive for state and local alert message originators to deploy and
use CAP-based alert systems and integrate such CAP systems with the EAS and FEMA’s IPAWS system.
Finally, we do not believe there are any significant costs associated with this requirement. As we note
above, the capability to provide the text field is inherent in CAP and explicitly provided for in the ECIG


418 RERC-TA Comments at 13.
419 Id. at 14.
420 Id.
421 See Third FNPRM, 26 FCC Rcd 8149, 8183, para. 84 (citing ECIG Implementation Guide, § 3.6.4).
422 See Trilithic Comments at 9; NAB Comments at 21.
423 As explained in the ECIG Implementation Guide, scrolls are limited to 1,800 characters. See ECIG
Implementation Guide, § 3.6.4.4.
424 See, e.g., Sage Comments at 15; RERC-TA Comments at 14; Wireless RERC Comments at 5; Google Reply
Comments at 3; Timm Comments at 4; NAB Comments at 21; BWWG Comments at 36.
425 See Monroe Comments at 23-24.
50

Federal Communications Commission

FCC 12-7

guidelines. Thus, CAP-capable EAS equipment is, by definition, capable of delivering any text that an
alert originator may provide.
140. To be clear, we will continue to use the EAS header codes as the baseline requirement for
the visual display.426 We acknowledge that these codes take up some portion of the 1800 characters
available for scrolling and that the EAS header codes may not always sufficiently describe the alert.427
We nonetheless believe that some measure of uniformity and consistency in how alert messages are
processed over the EAS is necessary.428 In this regard, we observe that the ECIG Implementation Guide
does not specify minimum descriptive information if the baseline requirement to include the EAS header
codes were eliminated.429 Without such a requirement, there is no guarantee that such basic information
would be included by the CAP message originator, and thus the descriptive information could vary
greatly from state to state and locality to locality. In addition, ensuring that the EAS header codes are
included in CAP messages is critical because stations responsible for regenerating (via the AFSK
encoding process) a CAP alert message that has been converted into a SAME-compliant message for the
benefit of downstream monitoring stations can only encode the EAS header codes. Accordingly, EAS
Participants must continue to display the information available in the EAS header code and, to the extent
that an alert initiator has supplied the CAP-based enhanced text, EAS Participants must display that as
well.
141. Section 11.54. Section 11.54 specifies the operational requirements that apply to EAS
Participants during a national level emergency.430 Section 11.54(b) lists the actions an EAS Participant
must take upon receipt of an EAN.431 In the Third FNPRM, we explained that CSRIC had recommended
that we add a new subparagraph to section 11.54(b) specifying that “EAS Messages will be broadcast
only if the scope of CAP alert is ‘Public.’”432 We observed that the ECIG Implementation Guide already
specifies that EAS Participants must ignore CAP-formatted messages with a value in the “scope” field
other than “Public.”433 Therefore, if compliance with the ECIG Implementation Guide were required, any
restrictions against processing CAP-formatted messages without the “Public” value in the scope field
would be satisfied. We sought comment on whether to adopt CSRIC’s recommendation.434 Monroe and


426 We also will not permit EAS Participants to meet the video crawl requirements via speech-to-text software
configured in their EAS devices. There is insufficient support in the record for allowing use of speech-to-text
software. The ECIG Implementation Guide, for example, observed, “ECIG feels there is no reliable software at this
time that can produce text from an audio message at the level of accuracy required for emergency messages.” ECIG
Implementation Guide, §2.2 (footnote omitted). See also Timm Comments at 13.
427 See, e.g., ECIG Implementation Guide, § 3.6.4.4.
428 See Trilithic Comments at 9; Timm Comments at 4.
429 The ECIG Implementation Guide provides that “[t]he FCC Required Text may be dropped as a requirement in
the future. At that time the same kind of information would be presumably included within the other CAP fields.”
ECIG Implementation Guide, § 3.6.4.1. The ECIG Implementation Guide also states that if the required baseline
text “is dropped in the future, then CAP messages SHOULD be constructed to include these relevant details.” Id., §
3.6.3.
430 See 47 C.F.R. § 11.54.
431 See id. § 11.54(b).
432 See Third FNPRM, 26 FCC Rcd 8149, 8184, para. 87 (citing CSRIC Final Report, § 5.1).
433 See id. (citing ECIG Implementation Guide, § 6.7, CAP to EAS Validation Table, entry for Alert Block
<scope>).
434 See id.
51

Federal Communications Commission

FCC 12-7

BWWG supported CSRIC’s recommendation.435
142. We also explained in the Third FNPRM that CSRIC had recommended that we revise
section 11.54(b)(1) to include IPAWS monitoring.436 Section 11.54(b)(1) requires that, immediately upon
receipt of an EAN, EAS Participants monitor the two sources identified in the State EAS Plan.437 We
observed that we had proposed elsewhere in the Third FNPRM to delete section 11.54(b)(1), which would
obviate this issue.438 To the extent that we elected to retain section 11.54(b)(1), however, we sought
comment regarding whether we should revise the language to reflect federal CAP monitoring obligations
by adding a cross-reference to the monitoring requirements in section 11.52.439 BWWG supported
CSRIC’s recommendation.440
143. Decision. We decline to adopt CSRIC’s recommendations. First, we are only requiring
EAS equipment to produce a SAME-compliant output, and there is no requirement in the EAS Protocol,
or more broadly, in the Part 11 rules, to broadcast only “Public” EAS messages. In any event, the ECIG
Implementation Guide, with which we are requiring conformance, already specifies that EAS Participants
must ignore CAP-formatted messages with a value in the “scope” field other than “Public.”441
Accordingly, the restrictions against processing CAP-formatted messages without the “Public” value in
the scope field that CSRIC sought are satisfied. With respect to CSRIC’s proposal to revise section
11.54(b)(1) to include IPAWS monitoring, we observe that, as detailed in section IV.E of this order, we
are deleting section 11.54(b)(1), and therefore this issue is moot.
6.

Waivers

144. In the Third FNPRM, we asked, in the context of setting a new CAP-compliance deadline,
whether we should take into account whether EAS Participants located in rural or underserved areas had
access to broadband Internet access or whether such situations should be addressed on a case-by-case
basis through the standard waiver process.442
145. Several commenters recommended that we should grant waivers from the CAP-related
obligations to EAS Participants that lack Internet access or for whom the cost for such access would be
relatively high. Prometheus, for example, observed that “some broadcasters do not have IP connectivity
at the location where the EAS unit operates,” and “[i]n some rural locations, obtaining connectivity will
be costly and require building new infrastructure.”443 Accordingly, Prometheus recommended with
respect to the CAP compliance deadline that “the Commission consider granting additional waivers on a


435 See Monroe Comments at 5; BWWG Comments at 36-37.
436 See Third FNPRM, 26 FCC Rcd 8149, 8184, para. 88 (citing CSRIC Final Report, § 5.1).
437 See 47 C.F.R. § 11.54(b)(1).
438 See Third FNPRM, 26 FCC Rcd 8149, 8184, para. 88.
439 See id.
440 See BWWG Comments at 37.
441 See, e.g., ECIG Implementation Guide, § 6.7, CAP to EAS Validation Table (entry for Alert Block <scope>).
According to the ECIG Implementation Guide, the requirement to broadcast only “Public” messages was derived
from CAP v1.2 Committee Draft OASIS Emergency Management Technical Committee, March 2010. See id.
442 See Third FNPRM, 26 FCC Rcd 8149, 8191, para. 111.
443 Prometheus Comments at 3.
52

Federal Communications Commission

FCC 12-7

case-by-case basis for participants who face obstacles to obtaining IP connectivity.”444 TFT observed that
“[b]ecause there are some areas in which connection to the Internet is unavailable or extremely expensive,
the Commission could institute a waiver program with an expiration/renewal date to permit EAS
Participants temporary relief.”445 One Ministries, Inc., observed that “remote LPTV stations and even
satellite NCE FM stations often do not have [I]nternet readily available.”446 Accordingly, One Ministries,
Inc., commented that “there should be an exemption for broadcast LPTV stations that don’t have a main
studio location other than a remote transmitter site to have to implement CAP, since they will most of the
time not have [I]nternet service,”447 and “that satellite NCE FM stations should not be required to have
CAP receivers for the satellite stations but should be able to rely on just the CAP systems for their main
station.”448
146. NAB commented that, in the context of monitoring the RSS feeds proposed in the Third
FNPRM and as an alternative to the waiver process, “[t]he Commission should also consider establishing
a simplified notification process for EAS Participants without reliable Internet access.”449 NAB
explained, for example, that “[o]ne possible approach may be to revise the Part 11 rules to include a
‘Notice’ or ‘Self-Certification’ process in which stations can certify to the Commission that they cannot
reliably monitor an RSS feed for CAP-formatted messages due to service availability.”450 NSBA made an
identical proposal.451
147. Monroe maintained that waivers of the CAP obligations may be justified “in selected
cases, such as for genuine economic hardship, or the physical unavailability of IP connectivity.”452
Monroe added, however, that “[r]egardless[] of the availability of IP connectivity, all EAS [P]articipants
should be encouraged to implement the required CAP EAS equipment by the established deadline, to put
[such EAS Participants] in a state of readiness for when IP connectivity becomes available.”453
148. NCTA stated that “small cable systems, owned by both large and small cable operators,
that have no Internet capability . . . should be exempt from new CAP requirements, regardless of the size
of the operator owner.”454 In this regard, NCTA observed that “[c]able customers [of such exempt
systems] will still receive EAS alerts issued in the existing EAS protocol and via broadcast stations
carried on their systems.”455 NCTA also stated that “the Commission should adopt a waiver process for
small systems that demonstrate financial or other hardships with compliance with CAP requirements.”456


444 Id.
445 TFT Comments at 4.
446 One Ministries, Inc., Comments, EB Docket 04-296 (filed June 30, 2011) at 1 (One Ministries Comments).
447 Id.
448 Id.
449 NAB Comments at 16.
450 Id.
451 See NSBA Comments at 16.
452 Monroe Comments at 18.
453 Id. at 19.
454 NCTA Comments at 10.
455 Id.
456 Id.
53

Federal Communications Commission

FCC 12-7

149. The American Cable Association (“ACA”) asserted that “the Commission should no longer
require systems of 500 subscribers or less to be EAS compliant.”457 In this regard, ACA stated that
“[u]nfortunately for these systems, any significant financial investment that is needed to these systems in
the future, including replacing EAS equipment, whether CAP-compliant or not, would likely cause many
of these systems to shut down entirely.”458 ACA observed that “these systems carry broadcast channels
that will be CAP-compliant, thus the impact on the efficacy of EAS in exempting such small systems
from compliance in the future will be minimal” and stated that “[t]he people in the[] small towns [served
by these systems] will be better off having a cable system that carries broadcast stations that offer CAP-
compliant messages, than having no cable service at all.”459
150. ACA further asserted that “[s]ome small cable systems however are simply too small
and/or too rural to support the upgrades necessary to deploy Internet service at their headends.”460 ACA
argued, “A small system that cannot support wired Internet service should not be required to pay
additional costs for constant wireless [I]nternet access solely for [CAP-compliance] purposes.”461
Accordingly, ACA recommended that “a CAP compliance exemption should be provided to systems
lacking wired Internet connections.”462 Finally, ACA recommended that “[t]he Commission should
entertain hardship waivers for CAP-compliance similar to the hardship waiver process used for the initial
deployment of EAS.”463
151. Houston Christian Broadcasters, Inc.; The Moody Bible Institute of Chicago; Augusta
Radio Fellowship Institute, Inc.; Big River Public Broadcasting Corporation; Life on The Way
Communications, Inc.; and The Sister Sherry Lynn Foundation Inc. (the “NEBS Stations”), jointly
requested that “the Commission confirm that in the case of noncommercial educational broadcast satellite
stations operated pursuant to a ‘main studio waiver’ the CAP-based alert messaging equipment must only
be located at the parent station site with the capability of ensuring that CAP-formatted alert messages
entered into the EAS are converted into and processed in the same way as messages formatted in the EAS
Protocol at the satellite stations via equipment at the parent station.”464
152. Decision. As a starting point, we do not believe it would be appropriate to adopt any form
of blanket exemption from the basic obligations of monitoring for, receiving, and processing CAP-
formatted messages. Waivers or exemptions from these requirements are best suited to a case-by-case
analysis under the waiver standard, where the facts and circumstances of each individual case can be
determined on its own merits.465 We observe, however, that the primary method of distributing CAP


457 American Cable Association Comments, EB Docket 04-296 (filed July 20, 2011) at 10 (ACA Comments).
458 Id.
459 Id.
460 Id. at 11.
461 Id.
462 Id.
463 Id. at 12.
464 Houston Christian Broadcasters, Inc., The Moody Bible Institute of Chicago, Augusta Radio Fellowship Institute,
Inc., Big River Public Broadcasting Corporation, Life on The Way Communications, Inc., and The Sister Sherry
Lynn Foundation Inc., Comments, EB Docket 04-296 (filed July 20, 2011) at 4.
465 The Commission may, on its own motion, waive its rules for good cause shown. 47 C.F.R. § 1.3. See, also
Northeast Cellular Telephone Co., L.P. v. FCC
, 897 F.2d 1164, 1166 (D.C. Cir. 1990) (“FCC has authority to waive
its rules if there is “good cause” to do so.”). The Commission may also exercise its discretion to waive a rule where
particular facts would make strict compliance inconsistent with the public interest, and grant of a waiver would not
(continued….)
54

Federal Communications Commission

FCC 12-7

messages will be via a broadband Internet connection. As a result, the physical availability of broadband
Internet access would be a physical predicate for compliance with the requirement that EAS Participants
be able to receive CAP-based alerts. We also observe that the EAS Participants most likely to lack
physical access to broadband Internet access are smaller EAS Participants, for which obtaining CAP
capable EAS equipment would be a relatively larger financial commitment than for a larger provider.
Because it is important that any of our regulatory requirements, particularly where costs are involved,
provide the benefits for which they are designed, we do not believe that it would be appropriate to require
EAS Participants to purchase and install equipment that they could not use. Accordingly, we conclude
that the physical unavailability of broadband Internet service offers a presumption in favor of a waiver.
We also observe, however, that broadband Internet access may become available at some point after a
waiver has been granted, and that alternate means of distributing CAP alert messages, such as satellite
delivery, may also become available, thus obviating the basis for granting the waiver. For this reason, we
believe that any waiver based on the physical unavailability of broadband Internet access likely would not
exceed six months, with the option of renewal if circumstances have not changed. As for whether the cost
of broadband Internet access in a given geographic area (or other potential substitute CAP alert
distribution mechanisms) would constitute grounds for a waiver of the basic CAP-related obligations, any
such determination would be relative to the facts and circumstances of an individual case. In all events,
to the extent a waiver applies, the affected party would be required to continue to operate its legacy EAS
equipment.
153. We reject ACA’s request that we exempt cable systems of 500 subscribers or less from the
Part 11 rules.466 While it is true that meeting the CAP-related obligations generally will require
replacement of legacy EAS equipment, as well as broadband Internet access (or some other CAP alert
distribution method), there is no evidence that the costs associated with these actions would jeopardize
any class of entities subject to the Part 11 rules or are otherwise unreasonable. The primary purpose of
the CAP rules, and more fundamentally, the EAS, is to enable the distribution of Presidential alerts to the
public. The Commission has never exempted any class of licensees or regulatees from that basic
obligation – even stations classified as NN, a status that we eliminate in this order, were required to at
least deploy a decoder under our previous rules. Meeting the CAP-related requirements we adopt in this
order will in most cases require EAS Participants to replace their existing legacy EAS equipment. Even
so, much of this equipment is more than 15 years old, is past its anticipated life cycle, and long ago
depreciated, and therefore likely subject to replacement in the near future even in the absence of the CAP-
related requirements adopted herein. We also observe that the obligation to deploy CAP-enabled EAS
equipment was adopted in 2007, thus, all EAS Participants have had ample time to prepare for equipment
acquisition. In any event, any small cable system or other EAS Participant can request a waiver of the
Part 11 requirements.
154. Finally, in response to the NEBS Stations’ comments, we clarify that noncommercial
educational broadcast satellite stations operating pursuant to a “main studio waiver” need not deploy
CAP-capable EAS equipment, provided that the EAS equipment deployed at the parent (hub) station site
meets all CAP-related and other requirements set forth in this order. Because all of the programming
broadcast by these stations originates at the parent (or hub) station, including all EAS messages, requiring
such stations to deploy CAP-capable EAS equipment would represent an unjustified departure from
established policy, and an unnecessary cost to smaller broadcasters.
(Continued from previous page)


undermine the policy served by the rule. See WAIT Radio v. FCC, 418 F.2d 1153, 1159 (D.C. Cir. 1969), aff’d, 459
F.2d 1203 (D.C. Cir. 1972), cert. denied, 409 U.S. 1027 (1972).
466 ACA Comments at 10.
55

Federal Communications Commission

FCC 12-7

C.

EAS Equipment Certification

155. Section 11.34 of the Part 11 rules requires EAS encoders and decoders to be certified in
accordance with the equipment authorization procedures set forth in Part 2, subpart J, of the
Commission’s rules.467 Among other things, certification under Part 2 requires device testing to
demonstrate compliance with the applicable specifications set forth in the Part 11 rules.468
156. As we explained in the Third FNPRM, unrelated to the Commission’s certification
program, FEMA implemented an IPAWS Conformity Assessment (CA) Program for CAP products
intended to interoperate with the IPAWS system.469 Under this program, manufacturers submitted
software or hardware to FEMA’s designated test laboratory for testing to ensure compliance with CAP
v1.2 USA IPAWS Profile v1.0 and the ECIG Implementation Guide.470 If the equipment passed, the test
laboratory provided a final test report and template Supplier’s Declaration of Conformity (SDoC) to the
manufacturer, who would then post final versions of these documents on a designated web site for public
inspection.471 FEMA discontinued the IPAWS CA program in August 2011.472
157. In the Third FNPRM, we sought comment on whether and how we should incorporate
compliance with respect to CAP functionality into the Commission’s existing certification scheme.473 We
observed that the primary users of the CAP v1.2 USA IPAWS Profile v1.0 standard appear to be CAP-
based alert message originators, as opposed to EAS Participants, and therefore tentatively concluded that
it would be inappropriate to incorporate conformance with the CAP v1.2 USA IPAWS Profile v1.0 into
the Commission’s certification process.474 We sought comment on this tentative conclusion.475
158. With respect to the ECIG Implementation Guide, we asked whether we should certify
conformance with this document, and if so, whether and how we should implement conformance testing
for it.476 If conformance testing is desirable, and assuming that uniform test procedures could be
established, we asked what entity or entities, such as third-party test laboratories, should perform such
tests.477 We asked how, if we were to accept or require IPAWS CA program certification as a
prerequisite to obtaining FCC certification for a CAP-decoding EAS device, manufacturers should
demonstrate IPAWS CA program certification compliance (such as by requiring the inclusion of an


467 See 47 C.F.R. § 11.34.
468 See id. § 11.34(a) (“The data and information submitted must show the capability of the equipment to meet the
requirements of this part as well as the requirements contained in part 15 of this chapter for digital devices.”).
469 See Third FNPRM, 26 FCC Rcd 8149, 8185, para. 90 (citing https://www.nimssc.org/ipawsconform/default.asp).
470 See id. Specifically, under FEMA’s IPAWS CA, manufacturers submitted software and hardware to the SAIC
Incident Management Test and Evaluation Laboratory (IMTEL), located in Somerset, Kentucky. See
https://www.nimssc.org/ipawsconform/faq.asp.
471 The final reports for products that passed IPAWS CA testing were eligible for posting on a Responder
Knowledge Base (RKB) website (https://www.rkb.us/), which provides government officials and other end-users
with access to product test results. See id.
472 See https://www.nimssc.org/ipawsconform/.
473 See Third FNPRM, 26 FCC Rcd 8149, 8186, para. 94.
474 See id.
475 See id.
476 See id. at 8187, para. 97.
477 See id., para. 98.
56

Federal Communications Commission

FCC 12-7

IPAWS CA program SDoC – and possibly the IPAWS CA program test report – along with the other
FCC certification application materials).478
159. The majority of commenters addressing this issue supported incorporation of ECIG
Implementation Guide certification into the FCC certification process. Sage, for example, stated that “the
most expeditious course of action is for the FCC to permit third party accredited labs to use FEMA’s
existing test requirements and procedures for future CAP/EAS certification, and that those labs accept the
test report and SDOC from the 2011 FEMA conformity assessment as sufficient for the current CAP/EAS
devices.”479 Sage also asserted, “If a device has been part 11 certified and FEMA conformance tested,
that should be sufficient,” adding that “[a] number of EAS /CAP devices with Part 11 certification and a
passing grade on the FEMA CAP compliance test are now on the market.”480 Sage further noted that
“[u]nderstanding how to render CAP messages as EAS requires portions of all three documents, the CAP
1.2 Protocol, the IPAWS Profile, and the ECIG Implementation Guide, and therefore, all three documents
should be referenced, and tested for, in any FCC certification efforts.”481
160. Monroe recommended that we “extend existing Part 11 certification requirements to any
equipment that creates EAS protocol tones from a CAP-formatted message, and that this requirement
should apply to both EAS encoder/decoders, as well as intermediary devices” and that we “incorporate
the IPAWS CAP conformance testing of EAS encoder/decoders, as a complete testing of CAP
conformity.”482 According to Monroe, “conformance by EAS encoder/decoders with the ECIG
Implementation guide can be demonstrated via the successful completion for the IPAWS Conformity
Assessment process, insofar as valid Test Results and a Suppliers Declaration of Conformity (SDOC) can
be furnished by the equipment manufacturer” and that the “SDOC and Test Results document could be
submitted directly to the FCC as evidence of ECIG Implementation Guide conformance.”483 Monroe
added that “the current FCC certification process is sufficient for the EAS protocol (SAME)
encoding/decoding functions” and that “[i]n conjunction with the test results described . . . for EAS
encoder/decoders, the Commission should be able to have a definitive assurance of EAS and CAP
compliance.”484
161. Trilithic asserted that “ultimately, CAP conformance testing should be fully integrated into
the existing part 11 certification scheme, however, in the interim the Commission should allow units
qualified under the FEMA Conformity Assessment program to be deployed.”485 Similarly, TFT
supported incorporation of ECIG Implementation Guide certification into the FCC certification process,
stating “conformance testing to the ECIG Implementation Guide should be governed by a certification
program in accordance with the procedures in Part 2, Subpart J of Title 47 C.F.R.”486 Timm commented,
“The FCC needs to closely examine the FEMA testing to determine if it meets the Commission’s needs[,]
[and if it does], the FCC should then simply require presentation of the Suppliers Declaration of


478 See id. at 8188, para. 99.
479 Sage Comments at 16.
480 Id.
481 Id.
482 Monroe Comments at 10.
483 Id. at 12.
484 Id.
485 Trilithic Comments at 3.
486 TFT Comments at 6.
57

Federal Communications Commission

FCC 12-7

Conformity (SDoC) to obtain FCC certification, as alluded to in para. 99 [of the Third FNPRM].”487
162. BWWG also supported incorporation of ECIG Implementation Guide certification into the
FCC certification process, suggesting that “the FCC partner with FEMA to set up an FCC conformance
testing procedure that the BWWG believes should be spelled out clearly in Part 11 language.”488 BWWG
further noted, “This strategy will have the benefit of assuring that any subsequent changes in EAS CAP
equipment, or problems uncovered during the FCC phase of conformance testing, are fully coordinated
between the two agencies that have, like it or not, joint responsibility for various aspects of conformance
and compliance.”489 With respect to the IPAWS CA program, BWWG asserted that “the SdoC procedure
has so far not proven to be terribly informative, easy to use or helpful to buyers of EAS CAP
equipment,”490 and that “the FCC phase of testing should be conducted to simulate the widest possible
range of wired and wireless CAP and SAME relay methods, conditions, and messages.”491 In this regard,
BWWG asserted that “[f]or SAME, all current authorized warning codes should be tested,” as well as
“[e]lements such as assuring that two-minute internal recorders for messages works properly.”492
163. NAB asserted that “there does not seem to be a need for the Commission to separately
certify compliance with CAP or the ECIG Guide” and that “the Commission should largely rely on
FEMA’s conformance testing for determining whether EAS equipment complies with CAP.”493 In this
regard, NAB suggested that “the Commission should merely require that EAS equipment manufacturers
file their Supplier’s Declaration of Conformity from the FEMA testing lab as a prerequisite of obtaining
Commission certification for a CAP-decoding EAS device.”494 In all events, NAB maintained that “the
Commission should not disrupt the already installed universe of FEMA-certified, CAP-compliance EAS
equipment in revising the Part 11 rules.”495
164. Decision. We are incorporating conformance with the ECIG Implementation Guide into
our existing certification process.496 We conclude that EAS equipment must be certified as CAP


487 Timm Comments at 4-5.
488 BWWG Comments at 39.
489 Id.
490 Id. at 40.
491 Id. at 39.
492 Id.
493 NAB Comments at 24. See also NSBA Comments at 16-17.
494 NAB Comments at 24.
495 Id. at 25.
496 As detailed in other sections of this order, we will not allow EAS Participants to use text-to-speech software
configured in their EAS equipment to generate the audio portion of an EAS message, and we are eliminating the
mandate to receive and process CAP-formatted messages initiated by state governors. See supra paras. 36-40 and
191-193. Accordingly, the provisions in the ECIG Implementation Guide that affect these actions are inapplicable
and will not be incorporated into the certification requirements we adopt here. In addition, we observe that the
ECIG Implementation Guide specifies that a location code consisting of all zeros (“000000”) indicates that the
message is intended for the entire United States and U.S. territories. See, e.g., ECIG Implementation Guide, §
3.4.1.3. There is no corresponding national code in the location coding scheme used by the EAS Protocol. See 47
C.F.R. § 11.31(f). We do note, however, that the Commission sought comment on whether to formally adopt
“000000” as the six-digit location code covering the entire United States and its territories in the record of the EAS
Test Order in this docket and received comments in that proceeding that supported our adoption of the 6 zero code.
The Commission did not resolve the question in that proceeding, noting that the EAS equipment that would be in
(continued….)
58

Federal Communications Commission

FCC 12-7

compliant because we are amending Part 11 to require CAP-to-SAME conversion in conformance with
the ECIG Implementation Guide, and thus, as part of the required Part 11 functions, it necessarily falls
under Part 11’s certification requirements.497 While we agree with commenters that FEMA’s IPAWS CA
program has served as a useful mechanism for determining EAS device conformance with the ECIG
Implementation Guide, this program cannot by itself serve as a substitute for the Commission’s
certification procedures. Accordingly, we will require that any EAS device that performs the functions of
converting CAP-formatted messages into a SAME-compliant message, including integrated CAP-capable
EAS devices and, as detailed below, intermediary devices, be certified under our Part 11 rules.
165. In terms of implementation, we agree with commenters that the test procedures developed
and utilized in FEMA’s IPAWS CA program constitute the most logical basis for demonstrating
compliance with the CAP compliance requirement we adopt today.498 As a preliminary mater, therefore,
we conclude that any integrated CAP-capable EAS devices that have passed the conformance testing
performed under FEMA’s IPAWS CA program may use the SDoC issued under that program to
demonstrate CAP-to-SAME conversion in conformance with the ECIG Implementation Guide. For
integrated CAP-capable EAS devices that have already obtained FCC certification, we will require that
the grantee for such certified devices update its existing FCC certification file (via a Class II Permissive
Change filing)499 to include the SDoC authorized under the IPAWS CA program. For integrated CAP-
capable EAS devices that have not obtained FCC certification, we will require that the FCC certification
application materials include a copy of the IPAWS CA program SDoC. In either case, if the device is
already being marketed, the filing must be submitted prior to June 30, 2012, the effective deadline for
overall CAP compliance. We believe that this streamlined approach will allow EAS equipment
manufacturers to comply with our equipment certification rules in a manner that will impose minimal
costs.
166. Integrated CAP-capable EAS devices that have not already passed the conformance testing
performed under FEMA’s IPAWS CA program, and thus do not have an IPAWS CA program-authorized
SDoC, must independently show conformance with the ECIG Implementation Guide to update their
existing FCC certification or obtain FCC certification, as applicable. There are two methods for
demonstrating such conformance. First, we observe that the National Incident Management System
(NIMS) Support Center – Supporting Technology Evaluation Project (STEP) has assumed the role of
testing for CAP and IPAWS profile compliance for EAS devices from the IPAWS CA program, which is
no longer in service.500 The test procedures are overall the same as those employed by the IPAWS CA
(Continued from previous page)


place for the test would not be able to program the 6 zero national code. We are currently in the process of
reviewing test data from the November 9, 2011 Nationwide EAS Test, which may provide insight on this matter.
Accordingly, it would be premature to take any actions with respect to adding a new national EAS location code
until after we have reviewed and processed the test data from the November 9, 2011 Nationwide EAS Test.
Accordingly, we defer taking any action on this matter at this time.
497 See, e.g., section 11.34(a) and (b) (specifying that equipment performing encoding and decoding functions “must
be Certified in accordance with the procedures in part 2, subpart J, of this chapter” and that “[t]he data and
information submitted must show the capability of the equipment to meet the requirements of this part as well as the
requirements contained in part 15 of this chapter for digital devices”).
498 To the extent that FEMA’s IPAWS CA test procedures did not test for conformance with the ECIG
Implementation Guide’s provisions related to processing CAP-formatted messages initiated by state governors, any
such omission is irrelevant because we are eliminating the mandate to receive and process such messages from the
Part 11 rules. See infra para. 191.
499 See, e.g., 47 C.F.R. § 2.1043(b)(2).
500 The program description, application, and other procedures for the STEP testing program are available at:
https://www.ptaccenter.org/step/index.
59

Federal Communications Commission

FCC 12-7

program, and will be made publicly available on the STEP web site on or by the effective date of the rule
amendments adopted in this order. Manufacturers whose EAS devices pass the NIMS testing will be
authorized to issue an SDoC that demonstrates CAP-to-SAME conversion in conformance with the ECIG
Implementation Guide.501 The SDoC issued under the NIMS CAP testing program can be used to update
an existing FCC certification or obtain a new FCC certification, as described above for SDoCs issued
under the IPAWS CA program.
167. The second method for demonstrating compliance with the ECIG Implementation Guide
involves the manufacturer arranging for testing and submitting a copy of the test report in lieu of the
SDoC to complete the process discussed above.502 We again observe that the test procedures developed
and utilized in FEMA’s IPAWS CA program constitute the most logical basis for demonstrating
compliance.503 As detailed below, manufacturers can demonstrate CAP-to-SAME conversion in
conformance with the ECIG Implementation Guide based upon successful completion of such tests. The
procedures and time periods for all cases described above are summarized as follows:
·
For integrated CAP-capable EAS devices that already have FCC certification, the grantee must
submit a Class II Permissive Change filing504 that includes: (i) a cover letter explaining that the
purpose of the filing is to apprise the Commission that the device has been tested for compliance
with the ECIG Implementation Guide pursuant to the procedures adopted in this order and that
the filing is being made to update the device’s existing certification file; (ii) a statement signed
by the grantee of the device’s underlying FCC equipment authorization505 confirming
compliance with section 11.56 of the Commission’s rules; and (iii) a copy of either (a) the
IPAWS CA program SDoC, if tested under FEMA’s program; (b) the NIMS SDoC, if tested
under the NIMS CAP testing program; or (c) for devices tested outside these programs, a copy
of the test report showing that the device passed the test elements.506 If the integrated CAP-
capable EAS device has already been marketed, the Class II Permissive Change filing must be
submitted by June 30, 2012, the effective deadline for overall CAP compliance.
·
For integrated CAP-capable EAS devices that do not already have FCC certification, the grantee
must include with the FCC certification application materials: (i) a cover letter explaining that
the device has been tested for compliance with the ECIG Implementation Guide pursuant to the
procedures adopted in this order; (ii) a statement signed by the grantee confirming compliance
with section 11.56 of the Commission’s rules; and (iii) a copy of either (a) the IPAWS CA
program SDoC, if tested under FEMA’s IPAWS CA program, (b) the NIMS SDoC, if tested
under the NIMS CAP testing program, or (c) for devices tested outside these programs, a copy
of the test report showing that the device passed the test elements.
168. We believe that the streamlined process outlined above will place minimal regulatory and


501 See id.
502 There are no restrictions or requirements as to what entity can perform the device testing.
503 As indicated, these test procedures will be made publicly available on the STEP web site at:
https://www.ptaccenter.org/step/index.
504 A Class II Permissive Change filing involves the submission of the FCC Form 731, a cover letter explaining that
the purpose of the filing, and any required exhibits. See 47 C.F.R. § 2.1043(c). Currently, the filing fee for Class II
Permissive Change applications is $60. See 47 C.F.R. § 2.1033.
505 See 47 C.F.R. §§ 2.931, 2.909(a).
506 The equipment authorization rules generally require all test reports to be signed by the person who performed or
supervised the tests. See 47 C.F.R. §§ 2.911(d) and (e). The party responsible for equipment compliance must
retain a copy of the ECIG Implementation Guide test results, as specified in section 2.938. See 47 C.F.R. § 2.938
60

Federal Communications Commission

FCC 12-7

financial burdens on manufacturers with both previously certified and uncertified devices. In this regard,
we observe that these procedures are generally consistent with other instances in which the Commission
has incorporated into its rules requirements for compliance with device standards unrelated to interference
and with other agency’s certification programs.507 Further, we find that our approach will not cause
disruption to the existing market for and prior purchasers of integrated CAP-capable EAS devices.
169. Intermediary Devices. In the Third FNPRM, we sought comment on whether we should
classify intermediary devices as stand-alone devices as opposed to modifications to existing equipment,
such as software or firmware upgrades. 508 Such classification would make them subject to the same
certification requirements that apply to stand-alone decoders and encoders (i.e., equipment that carries out
all the functions required for an EAS Participant to meet its EAS obligations, including compliance with
any applicable portions of the Part 11 (and Part 15) rules (including compliance with ECIG
Implementation Guide, if required)).509 More broadly, we asked whether intermediary devices should be
subject to certification.510
170. Decision. As a preliminary matter, we agree with commenters that intermediary devices
are stand-alone devices that are subject to certification under our current rules. Specifically, intermediate
devices are stand-alone devices that carry out the functions of monitoring for, receiving, and decoding
CAP-formatted messages and converting such messages into a format that can be inputted into a separate,
stand-alone legacy EAS device to produce an output that complies with the Part 11 rules. As discussed
above, based on the record, there appear to be two types of intermediary devices, which we are
conceptually categorizing as “universal” intermediary devices and “component” intermediary devices.511
These devices perform encoder or decoder functions and as such, clearly are subject to certification under
section 11.34 of our rules.512 Specifically, universal intermediary devices monitor, acquire, and decode
CAP messages, using the relevant CAP data to generate (i.e., encode) the EAS codes (FSK audio tones)
and if present, an audio message, which can be received by the audio input of a legacy EAS device just as
it would receive any other over-the-air SAME-formatted message. Accordingly, universal intermediary
devices are subject to certification both as decoders and encoders under sections 11.34(a) and (b) of our
rules, respectively.513
171. Component intermediary devices also monitor for, acquire, and decode CAP messages, but
because they are configured to interface with a specific legacy EAS device model, they may be capable of
communicating the extracted data to the companion legacy EAS device model in a non-AFSK format and


507 See, e.g., 47 C.F.R. §§ 2.1091(c) and 2.1093(c) (requiring that certification applications for mobile and portable
devices, respectively, associated with various services to include with their certification applications a statement
confirming compliance with applicable radiofrequency radiation exposure limits); 47 C.F.R. § 80.231(e) (requiring
that certification applications for maritime Class B Automatic Identification System equipment include a letter from
the U.S. Coast Guard stating that the device meets certain internationally standardized requirements).
508 See Third FNPRM, 26 FCC Rcd 8149, 8188-89, para. 104 (citing 47 C.F.R. § 2.1043).
509 See id. (citing 47 C.F.R. § 2.1043).
510 See id.
511 See supra paras. 70-71.
512 See 47 C.F.R. § 11.34(a) (“An EAS Encoder used for generating the EAS codes and the Attention Signal must be
Certified in accordance with the procedures in part 2, subpart J, of this chapter.”); 47 C.F.R. § 11.34(b) (“Decoders
used for the detection of the EAS codes and receiving the Attention Signal must be Certified in accordance with the
procedures in part 2, subpart J, of this chapter.”).
513 See id.
61

Federal Communications Commission

FCC 12-7

thus may not themselves be encoding the SAME data.514 Under these circumstances, a component
intermediary device would not be subject to certification as an encoder under section 11.34(a) in its
capacity as a stand-alone device. However, component intermediary devices are designed for and
intended to be operated with specific legacy EAS device models. Accordingly, we find that the output of
the combined system configuration of these devices performs encoding functions which subjects such
configuration to certification under section 11.34(a). In addition, component intermediary devices
perform decoding functions in their capacity as stand-alone devices that subject them to certification
under section 11.34(b).
172. We next turn to incorporating conformance with the ECIG Implementation Guide for
intermediary devices into our existing certification process. Although FEMA’s IPAWS CA program
tested intermediary devices for conformance with the ECIG Implementation Guide, both Monroe and
Sage maintained that such testing was not as extensive as that for integrated CAP-capable EAS devices
and thus was inadequate as a basis for our updated Part 11 certification. Specifically, Monroe asserted
that “the IPAWS Conformity Assessment process contains a number of omissions in regards to the
evaluation of intermediary devices (CAP converters) that severely impair the usefulness of the conformity
assessments of those devices.”515 Monroe added, “Specifically, the test cases used in the conformity
assessment process omitted evaluation of the ability to process a CAP formatted governors must carry
message in intermediary devices, while EAS encoder-decoders were tested in regards to that
functionality.”516
173. Sage asserted, “The FEMA tests allowed Intermediary Devices to use a subset of those
tests for their conformity assessment,” which according to Sage, “did show that the Intermediary device
could ingest CAP messages, [but] may not have shown that a system made up of an Intermediary Device
and a legacy EAS system meets all the requirements of part 11.”517 In particular, according to Sage,
“Intermediary Devices were not pass/fail tested for invalid, expired, or duplicate messages, or for local
area recognition.”518 Accordingly, Sage argued, “[i]f the intent is to use an Intermediary Device and a
legacy device as a pair to meet Part 11 requirements, then the Intermediary Devices should be retested to
the full Part 11 output specifications, and the full CAP processing requirements.”519
174. In response to Monroe’s and Sage’s objections, we observe that while the ECIG
Implementation Guide was designed for integrated CAP-capable EAS devices – and thus assumed that all
of the functions required under sections 11.32 and 11.33 be performed within a single, self-contained unit
– intermediary devices do not function in that manner. Intermediary devices are not designed or intended
to perform all of the functions of decoders or encoders set forth in sections 11.31 and 11.33. For
example, one would not necessarily expect to find an audio input on a universal intermediary device that
is designed solely to receive and decode CAP-formatted messages. Nor would we expect a universal
intermediary device to perform the check for invalid, expired, or duplicate messages or for local area
recognition duplicate message requirements in section 11.32. These functions would be handled by the
FCC-certified legacy EAS device that actually places the message on the air (and, if applicable, encodes
such message for the benefit of downstream monitoring stations). With respect to universal intermediary


514 See Trilithic Comments at 2.
515 Monroe Comments at 11.
516 Id.
517 Sage Comments at 16.
518 Id.
519 Id.
62

Federal Communications Commission

FCC 12-7

devices, we would only expect these devices to output a SAME-compliant message. With respect to
component intermediary devices, it is more difficult to pinpoint a demarcation line between
functionalities handled by the component intermediary device and the legacy EAS device model it is
designed to be configured with, due to the close integration of the two units.
175. Given the nature of the two types of intermediary devices, we conclude that the test
procedures developed and utilized in FEMA’s IPAWS CA program for testing intermediary devices
constitute a sufficient basis for demonstrating compliance with the ECIG Implementation Guide in a way
that would impose minimal costs on the affected parties. We conclude, therefore, that any universal
intermediary devices or component intermediary devices that have passed the conformance testing
performed under FEMA’s IPAWS CA program may use the SDoC issued under that program to
demonstrate CAP-to-SAME conversion in conformance with the ECIG Implementation Guide. We
further conclude that the streamlined certification processes outlined above for integrated CAP-capable
EAS devices are equally suitable for intermediary devices, and as summarized below, we will apply these
same procedures to intermediary devices. This includes testing under the NIMS CAP testing program
and alternative test arrangements made by the manufacturer. However, with respect to certification
testing for ECIG Implementation Guide compliance and Part 11 compliance, because component
intermediary devices are designed and intended to be operated with specific legacy EAS device models,
we will require certification testing for ECIG Implementation Guide compliance and Part 11 compliance
to be performed on the combined system – i.e., the component intermediary device as configured with the
specific legacy EAS device model(s) with which it is marketed and intended to be used. Universal type
intermediary devices can be tested as stand-alone devices.
176. Accordingly, for all cases outlined above, manufacturers will demonstrate compliance as
follows:
·
For intermediary devices that already have FCC certification, the grantee must submit a Class II
Permissive Change filing that includes: (i) a cover letter explaining that the purpose of the filing
is to apprise the Commission that the device has been tested for compliance with the ECIG
Implementation Guide pursuant to the procedures adopted in this order and that the filing is
being made to update the device’s existing certification file; and (ii) a copy of either (a) the
IPAWS CA program SDoC, if tested under FEMA’s IPAWS CA program; (b) the NIMS SDoC,
if tested under the NIMS CAP testing program; or (c) for devices tested outside these programs,
a copy of the test report showing that the device passed the test elements. If the intermediary
device has already been marketed, the Class II Permissive Change filing must be submitted by
June 30, 2012, the effective deadline for overall CAP compliance.
·
For intermediary devices that do not already have FCC certification, the grantee must include
with the FCC certification application materials: (i) a cover letter explaining that the device has
been tested for compliance with the ECIG Implementation Guide pursuant to the procedures
adopted in this order; and (ii) a copy of either (a) the IPAWS CA program SDoC, if tested under
FEMA’s IPAWS CA program; (b) the NIMS SDoC, if tested under the NIMS CAP testing
program; or (c) for devices tested outside these programs, a copy of the test report showing that
the device passed the test elements.
177. Modified Equipment. Section 2.1043 of the Commission’s rules delineates the types of
modifications (or permissive changes) that manufacturers can make to previously certified equipment that
do not require equipment recertification.520 In general, under these rules, manufacturers can permissively


520 See id.
63

Federal Communications Commission

FCC 12-7

make changes that do not degrade radiofrequency characteristics and performance.521 As with all certified
devices, these rules apply to EAS equipment generally. In addition, section 11.34(f) specifies that
modifications to existing authorized EAS equipment that are necessary to implement revisions to the EAS
codes (set forth in section 11.31) or to implement the selective displaying and logging feature for state
and local events are Class I permissive changes.522
178. In the Third FNPRM, we sought comment on the certification requirements that should
apply to modified EAS equipment.523 Specifically, we asked whether the existing rules governing
modifications to certified EAS equipment are sufficient to permit periodic updates to EAS equipment
without overburdening manufacturers or the certification process or whether additions to these rules
would be desirable for EAS equipment.524 We also asked whether there is any point at which changes to
the general CAP standard, CAP v1.2 USA IPAWS Profile v1.0, or the ECIG Implementation Guide
would necessitate recertification of previously certified CAP-enabled equipment.525
179. BWWG, the only commenter addressing this issue directly, observed that “modifications
and improvements to all technology, including CAP EAS devices, are both inevitable and desirable” and
asserted that “[t]he Part 11 rewrite should be flexible enough to allow for future developments.”526 With
respect to whether modifications to the CAP-related standards might necessitate recertification, however,
BWWG noted that “the only way to make sure a future modification will not ‘break’ IPAWS CA program
or IPAWS conformance is to run said equipment through both processes again.”527
180. Decision. We conclude that our existing rules governing modifications to certified
equipment are sufficient to cover CAP-enabled equipment. We cannot anticipate every nuance of
modification that might arise or how it might impact the performance of the EAS device, but in general,
we expect that routine changes to the EAS codes would not constitute major modifications. Accordingly,
we clarify here that modifications to authorized EAS equipment that are necessary to implement revisions
to the EAS event codes, originator codes, or location codes set forth in section 11.31 may be implemented
as Class I permissive changes. With respect to revisions to the CAP-related standards, we are
incorporating by reference the versions of the standards adopted by FEMA. Thus, any future revisions
that may be made to these standards could not become effective in the Part 11 rules absent a rulemaking
proceeding. We believe that this is a cost-effective approach that will allow us to address such instances
if and when they arise.


521 See, e.g., 47 C.F.R. § 2.1043(b)(1); see also id. at § 2.1043(a) (specifying that changes to the software installed in
a transmitter that do not affect the radio frequency emissions do not require a filing with the Commission).
522 See 47 C.F.R. § 11.34(f). This provision was added to Part 11 in the 2002 Report and Order to make clear that
certain new EAS codes and selective display and logging capabilities adopted therein could be implemented as
modifications to existing equipment as Class 1 permissive changes. See Amendment of Part 11 of the
Commission’s Rules Regarding the Emergency Alert System, Report and Order, 17 FCC Rcd 4055, 4074, para. 46
(2002) (2002 Report and Order). All new EAS equipment models manufactured after August 1, 2003, were
required to be capable of transmitting and receiving such codes and selectively displaying and logging messages
with state and local event codes. See id. at para. 47.
523 See Third FNPRM, 26 FCC Rcd 8149, 8190, para. 107.
524 See id.
525 See id.
526 BWWG Comments at 43.
527 Id. TFT also suggested with respect to certification generally, that certification should be tied to the CAP-related
standards “in effect at the time of the date of submission for certification.” TFT Comments at 6.
64

Federal Communications Commission

FCC 12-7

D.

CAP Messages Originated by State Governors

181. In the Second Report and Order, the Commission mandated that all EAS Participants
within a state (other than SDARS and DBS providers) be able to receive and transmit state-level and
geographically targeted CAP-formatted EAS messages when certain conditions are met. These
conditions are (1) that such alerts are aggregated and delivered by the state governor or his/her designee
or by FEMA on behalf of such state governor, within 180 days from the date FEMA adopts CAP, and (2)
that the methodology for such delivery is explicitly described in the State EAS Plan that is submitted to
and approved by the Commission.528 This obligation is codified in sections 11.21(a) and 11.55(a) of Part
11.529
182. As we explained in the Third FNPRM, CSRIC and parties responding to the Part 11 Public
Notice sought clarification with respect to how EAS Participants will compile and process state CAP
messages, how state CAP messages will be implemented within the EAS Protocol coding scheme, what
constitutes a “geographically targeted area EAS message,” who can serve as the governor’s “designee,”
and other related issues.530 We addressed these issues in the Third FNPRM. We tentatively concluded
that the basic obligation to process gubernatorial CAP-formatted messages should apply only where
messages comply with the standards adopted by FEMA for federal CAP messages.531 We sought
comment as to whether we would need to adopt a new origination or event code to implement the
obligation within the existing EAS architecture.532
183. We also sought comment on whether and how the obligation to process gubernatorial
CAP-formatted messages should apply with respect to CAP-formatted messages delivered by the
governor of a state adjacent to the state in which the EAS Participant provides service.533 We tentatively
concluded that the geo-targeting requirement associated with mandatory state gubernatorial alerts be
defined by the location provisions in the EAS Protocol.534 We invited comment on what entities should
be allowed to serve as designees for purposes of initiating gubernatorial CAP-formatted messages;535 how
the obligation to process gubernatorial CAP-formatted messages should apply to NN stations;536 whether
we should revise the automatic reset requirements in section 11.39(a)(9) to accommodate gubernatorial
CAP-formatted messages;537 and whether prioritizing gubernatorial CAP-formatted messages over local
EAS messages is either practical or technically feasible.538 We also asked how we might revise the
minimum EAS transmission requirements in section 11.51(m) to incorporate the obligation to process
CAP-formatted messages initiated by state governors.539


528 Second Report and Order, 22 FCC Rcd 13275, 13300-01, paras. 55-56. See also 47 C.F.R. § 11.55.
529 47 C.F.R. §§ 11.21(a), 11.55(a).
530 See Third FNPRM, 26 FCC Rcd 8149, 8192, para. 113.
531 See id. at 8192-92, para. 116.
532 See id. at 8194, para. 120.
533 See id. at 8195, para. 124.
534 See id. at 8196, para. 126.
535 See id. at 8197, para. 129.
536 See id. at 8198, para. 132.
537 See id., at 8198-99, para. 134.
538 See id. at 8199-8200, para. 136.
539 See id. at 8200, para. 138.
65

Federal Communications Commission

FCC 12-7

184. Commenters raised several concerns with implementing the mandate to carry gubernatorial
CAP messages, and there was considerable support for eliminating the mandate. Sage commented that
the “major issue with the Governors Must Carry is with EAS relay, and it exposes the major problem with
Intermediary Devices.”540 Specifically, Sage pointed out that its legacy EAS devices “have no way to be
told that the EAS message is from the governor, and therefore no way to effectively interface with the
Intermediary Device for the Governors Must Carry function,” unless a new originator code is adopted and
added as a ROM update.541 Sage noted three difficulties with the mandatory gubernatorial alert: First, if
the gubernatorial CAP mandate is limited to only the EAS Participant that receives the CAP message,542
then “[universal] [i]ntermediary Devices would not meet the Part 11 requirements in states where must
carry is in the state plan”; second, if “the FCC wants Intermediary Devices to be used[,] ... a new event or
originator code MUST be added to the EAS specification, and legacy devices must implement it”; third, if
the “the FCC wants the [gubernatorial CAP] must carry rules to include relay of alerts through the legacy
EAS system[,] . . . a new event or originator code MUST be added to the EAS specification, and all EAS
devices, CAP/EAS and legacy EAS must be updated.”543
185. Sage also stated that adding a new originator code for the mandatory gubernatorial alert is
“far more preferable to adding a new Event code.”544 Sage pointed out that “some stations specializing in
children’s programming do not carry Amber Alerts due to the nature of the alerts and their audience” and
accordingly suggested that “[a] limited opt-out for some types of must carry should be considered by the
Commission.”545 According to Sage, implementing priority status for a mandatory gubernatorial CAP
message would be problematic, observing that “many legacy devices, and new devices derived from
them, still use a two minute audio buffer for incoming EAS alerts, and the only way to handle a higher
priority EAS message is to abort an outgoing, lower priority message.”546 Presumably, the messages
subject to being aborted would be non-gubernatorial state, local, and NWS messages.
186. TFT stated, “Adoption of new Originator or Event codes will only complicate the
availability of equipment, unduly require legacy EAS equipment to be modified at considerable expense
to the EAS Participant and to manufacturers, and unnecessarily complicate the process for emergency
managers to distribute emergency messages.”547 TFT argued generally, “If the system is so complicated
that it cannot be used quickly and efficiently to alert the public to emergencies, then the system will
ultimately fail.”548 On that basis, TFT recommended that “[t]he ‘Governor’s Must Carry’ aspect should
be eliminated entirely and rules relating thereto deleted.”549
187. Monroe recommended that the requirement to receive and process gubernatorial CAP-


540 Sage Comments at 17.
541 Id. at 17-18.
542 In this case, the CAP message would not be converted into and broadcast in the EAS Protocol for the benefit of
downstream monitoring stations but rather the EAS Participant would create a video display based upon he CAP text
and broadcast any audio message that might be included.
543 Sage Comments at 18.
544 Id.
545 Sage Reply Comments at 5.
546 Sage Comments at 20.
547 TFT Comments at 8.
548 Id. at 7.
549 Id. (internal footnote omitted). See also TFT Reply Comments at 3.
66

Federal Communications Commission

FCC 12-7

formatted messages should be limited to the EAS Participant that receives the gubernatorial CAP
message, as specified in the ECIG Implementation Guide.550 Monroe argued, “Issuance of an alert using
a new gubernatorial code for legacy EAS alongside a CAP-conformant gubernatorial alert will inevitably
lead to confusion over multiple messages with differing audio and textual information, not only between
the two alerts, but even within each alert itself.”551 In this regard, Monroe also observed, “[a]dding a new
event or origination code [to make it possible to relay the gubernatorial message in the EAS domain]
would add ambiguity, as the textual display of such a message would (1) contain little if any effective
information about the actual event, and (2) the audio would likely substantially differ from the textual
portion, particularly in the case where legacy EAS equipment may somehow still be supported.”552
188. Timm stated that “it is unclear whether the FCC would intend to replace the CAP EAS-
Must-Carry indication [utilized in the ECIG Implementation Guide to facilitate the mandatory carriage of
a gubernatorial CAP message] with a legacy EAS code or add the EAS code in addition to the CAP
indication.”553 Timm asked, “If the legacy EAS Governor code is added, must both that code and the
CAP indication be used together, or either one alone indicates the Governor?”554 Timm observed, “In any
event, adding a legacy EAS Governor code would require a revision of the ECIG Implementation Guide,
which could create issues on FEMA’s end having already adopted it as is.”555 Timm also pointed out
problems in defining which state governors’ alerts an EAS Participant must carry and problems in
defining which geo-targeted area designations would encompass an EAS Participant, triggering the must-
carry mandate. 556 Timm further observed that these issues cannot be resolved by the states in the state
EAS plans because these would constitute mandatory requirements, whereas SECCs “have no real
authority to impose carriage determinations.”557
189. NSBA recommended that “The Commission should delete the gubernatorial preemptive
override requirement.”558 According to NSBA, “Notably absent from the record is any demonstrated
basis for a gubernatorial preemptive override right.”559 In this regard, NSBA asserted that “the
willingness of broadcasters to respond when called upon by state and local emergency managers has
never been an issue,” adding that “[n]o one has ever suggested that broadcaster cooperation turns on who
is issuing an alert about an emergency situation.”560 NSBA also observed that “of the many ways that
local broadcasters serve the public interest, nothing is more important to them than preserving the safety
of their viewers and listeners.”561 NSBA also observed that state governors “already work[] through the
state emergency management and public safety authorities . . . [and] [a]ll of those authorities work very


550 Monroe Comments at 19-20.
551 Id. at 20.
552 Id. Monroe added, “This also raises the difficulty of making emergency communication information equally
available for those who rely on textual displays rather than audio.” Id.
553 Timm Comments at 5.
554 Id.
555 Id.
556 Id. at 6-7.
557 Id. at 6.
558 NSBA Comments at ii.
559 Id. at 10.
560 Id.
561 Id.
67

Federal Communications Commission

FCC 12-7

cooperatively with broadcast stations, cable systems and others.”562 NSBA complimented the
Commission “for its desire to involve the Offices of Governor around the country” but argued that
“giving them a right for which there is no emergency-based need and which complicates and confuses an
already difficult emergency-focused coordination situation is simply not in the public interest.”563
190. BWWG stated that “emergencies are ‘event driven’ and that imposing a mandatory
requirement that broadcasters carry a governor’s message makes no sense.”564 BWWG argued, “[s]trictly
speaking, governor mandatory CAP is NOT a warning in the strict definition of what warnings really are
and should not be made a part of Part 11 by the Commission.”565
191. Decision. We conclude that the mandate to receive and transmit CAP-formatted messages
initiated by state governors is not necessary at this time and is potentially detrimental to effective
deployment of CAP-based alerts. Accordingly, we eliminate the mandate from Part 11. We base this
determination on several factors. First, as commenters pointed out, there are a number of practical
problems associated with implementing the mandate within the existing EAS system architecture, and
overcoming these problems would likely impose significant costs on and disruption to our transitional
approach for accommodating CAP within the EAS. Perhaps the most significant of these is whether and
how the gubernatorial CAP-formatted message could be converted into an EAS Protocol-formatted
message for the benefit of downstream monitoring stations. While the ECIG Implementation Guide
provides a procedure for identifying a CAP message as being from a governor – thus ensuring that its
audio message (if any) will be broadcast along with the creation of a video crawl – this only works for an
EAS Participant that receives the CAP message, as the CAP-formatted gubernatorial alert cannot be
converted and encoded as an existing EAS Protocol-formatted message. Further, as Timm observed,
adopting a new originator code for the legacy EAS Protocol so that the gubernatorial CAP message could
be converted into an EAS Protocol-formatted message would run afoul of the ECIG Implementation
Guide procedures, thus requiring a revision of the ECIG Implementation Guide to harmonize it with
whatever was adopted for the EAS Protocol.566
192. Adding a new originator code to make the gubernatorial CAP mandate operational within
the legacy EAS domain presents other problems.567 As Sage pointed out, such a revision to the EAS
Protocol would require updates to every integrated CAP-capable EAS device, intermediary device, and
legacy EAS device.568 In the case of legacy EAS devices, some of these may not be capable of being
updated and would have to be replaced -- along with any intermediary device with which they might be
configured. Commenters note that implementing the mandatory gubernatorial alert as part of our revised
EAS rules would present other equally troubling issues for which there are no ready or obvious technical
solutions. These problems include implementing priority status within CAP for a gubernatorial alert569
and mandating broadcast of a category of messages that do not specify an actual emergency. Such an


562 Id. at 12.
563 Id.
564 BWWG Comments at 4.
565 Id.
566 See Timm Comments at 5.
567 We agree with commenters that event codes are inappropriate for designating a message being from a governor,
and the existing CIV originator code is not appropriate because it is currently used for state and local EAS alerts.
See, e.g., Sage Comments at 18-19; Timm Comments at 5-6; TFT Comments at 8; Monroe Comments at 20.
568 See, e.g., Sage Comments at 18.
569 See, e.g., id. at 20.
68

Federal Communications Commission

FCC 12-7

open ended mandate might, in some cases, allow the issuance of a mandatory message that may be
inappropriate for an alert.570 We presumably could avoid some of these problems by limiting the
applicability of the gubernatorial CAP mandate to the EAS Participant that receives the CAP message
(i.e., the gubernatorial CAP message would not be encoded in the EAS Protocol and broadcast for the
benefit of downstream monitoring stations). However, even if we applied such a limitation, only
integrated CAP-capable EAS devices and some component intermediary device and legacy EAS device
configurations would be capable of implementing the gubernatorial CAP mandate. Legacy EAS devices
not capable of being configured with a component intermediary device would have to be replaced (as
would any universal intermediary device with which they might be configured).571 We do not believe
such a result is warranted nor, as explained below, is such a result necessary.
193.
While implementing the mandate to receive and process gubernatorial CAP messages
would impose the technical difficulties discussed above, it is not clear whether it would provide any
tangible benefit. The Commission adopted the mandatory gubernatorial alert requirement in 2007 as an
incentive to encourage and facilitate state use of the EAS network.572 The Commission also concluded
that states would be “more inclined to deploy the necessary resources to upgrade to Next Generation
EAS, including the ability to simultaneously transmit multiple and differentiated CAP-formatted
messages, if the states have a particular – and FCC enforceable – stake in the EAS during state and local
emergencies.”573 It does not appear that this rationale applies today. First, approximately twenty-four
states (including one territory) have either deployed CAP systems or are in the planning stages of
deploying CAP systems.574 Second, given the current economic climate, it seems unlikely that states that
have not already deployed or begun plans to deploy CAP systems will do so simply because of an
enforceable mandate to carry CAP-formatted gubernatorial messages. Moreover, as NSBA points out,
there is near universal voluntary participation by EAS Participants in carrying state and local EAS
messages.575 Thus, having an enforceable means to guarantee such carriage seems unnecessary. We also
observe that use of the enhanced CAP text to generate the video crawl will provide a significant incentive
for states and localities to utilize both CAP and the EAS to disseminate more effective alert warnings to
their populations. Finally, we note that FEMA’s IPAWS will provide a means for a State governor, or the
governor’s authorized representative, to issue targeted CAP-based alerts, not only over the EAS, but over
mobile devices as well. The mandatory gubernatorial alerts we are discarding today duplicate features
offered by the IPAWS and could interfere with its effective deployment. Eliminating the mandatory
gubernatorial alert will also have the salutary effect of eliminating any costs associated with upgrading
EAS equipment to comply with this requirement.

E.

Revising the Procedures for Processing EANs

194. As we detailed in the Third FNPRM, the Part 11 rules specify that the Emergency Action
Termination (EAT) message is used to terminate an EAN. More specifically, as set out in section 11.13,
the EAN is the notice to EAS Participants that the EAS has been activated for a national emergency,


570 See, e.g., Sage Reply Comments at 5.
571 We recognize that replacement of intermediary devices will have to occur by June 30, 2015, as we are requiring
that EAS Participants using intermediary devices must be capable of using the enhanced CAP text to meet the visual
display requirements in sections 11.51(d), (g)(3), (h)(3), and (j)(2) , in conformance with section 3.6 of the ECIG
Implementation Guide by that date. See supra paras. 138-140.
572 See Second Report and Order, 22 FCC Rcd 13275, 13299-13300, para. 54.
573 Id. at 13300, para. 55.
574 See CSRIC Final Report, § 4.1.2.
575 See NSBA Comments at 10-12.
69

Federal Communications Commission

FCC 12-7

while the EAT is the notice to EAS Participants that the EAN has terminated.576 This process is described
in section 11.54, which specifies the actions an EAS Participant must take upon receiving an EAN.577
Under these provisions, the EAN commences a “National Level emergency” condition, during which
EAS Participants must discontinue regular programming, make certain announcements set forth in the
EAS Operating Handbook, and broadcast a “common emergency message,” as prioritized under section
11.44.578 EAS Participants are required to follow this process until receipt of the EAT.579
195. In the Third FNPRM, we sought comment on whether the procedures set forth in section
11.54 for processing EATs and EANs are problematic and technically impractical for automated
operation.580 We explained that the framework for manually processing EANs described in section 11.54
was derived from the former EBS rules, under which EAS Participants processed all EAS alerts manually
and EANs were distributed to broadcast and cable entities via a separate, dedicated network.581 We also
explained that such a manual approach for processing of EANs does not translate well into an automated
system, which anticipates that EAS equipment will automatically preempt programming upon receipt of
an EAN, and automatically allow programming to resume upon receipt of an End of Message (EOM)
code.582
196. As explained in the Third FNPRM, while the EAS rules permit manual operation of EAS
equipment, which theoretically would allow EAS Participants to better follow the procedures in section
11.54(b), there is no indication that EAS Participants actually operate EAS equipment manually.583 As
we observed from comments in the Third FNPRM, the record indicated that “[t]he EAT was implemented
with the vision that most broadcast stations are manned, which is no longer the case.”584 We also
observed that whereas section 11.54 establishes an indeterminate time period during which EAS
Participant facilities are reserved for airing various EAS messages, whether in automated or manual
mode, EANs can simply terminate with the EOM, which would allow for resumption of regular
programming until another EAS message arrives.585 We also observed that the obsolescence of the EAT,
and by extension, the framework for processing EANs in section 11.54, was confirmed by the January
2010 Alaska EAN test, during which EAS equipment returned to normal operating status despite the fact
that no EAT was sent.586
197. We therefore sought comment regarding whether we should substantially simplify the
procedures for processing EANs set forth in section 11.54 and related Part 11 rule sections so that EAS


576 See Third FNPRM, 26 FCC Rcd 8149, 8200-01, para. 139 (citing 47 C.F.R. § 11.13).
577 See 47 C.F.R. § 11.54.
578 See id. § 11.54(b)(3). The EAS Participants display standby script when not airing “common emergency
messages.” See id. § 11.54(b)(4).
579 See id. § 11.54(b)(3).
580 See Third FNPRM, 26 FCC Rcd 8149, 8202-03, para. 143.
581 See id.
582 See id. at 8203-04, para. 144.
583 See id.
584 See id. (citing Gary E. Timm Reply Comments, EB Docket 04-296 (filed June 7, 2010) at 8).
585 See id.
586 See id.
70

Federal Communications Commission

FCC 12-7

Participants process EANs like any other EAS message, only on a mandatory and priority basis.587 We
explained that under this streamlined EAN processing approach, whether EAS Participants operate their
EAS equipment in automated or manual mode, receipt of an EAN would effectively open an audio
channel between the originating source and the EAS Participant’s facilities until the EAS Participant
receives an EOM.588 After the EAS Participant receives the EOM, the EAS equipment would return to
regular programming until receipt of the next EAS message. If that message is another EAN, then the
process would repeat; if that message is a state or local EAS message, then that message would be aired in
accordance with the specifications in the State or Local Area EAS Plan.589 We also invited comment on
whether we should eliminate the option for EAS Participants to manually process EANs (but not state or
local EAS messages).590 Finally, because the EAT would serve no purpose under our streamlined,
message-by-message processing approach for EANs, we sought comment on whether we should
eliminate the EAT and replace it where necessary with the EOM in the Part 11 rules.591
198. The majority of commenters addressing these issues supported message-by-message
processing of EANs and elimination of the EAT. Timm, for example, observed that the “only current
purpose the EAT code serves is for use by NN stations, which … should also be eliminated.”592 Sage
asserted, “In our modern times, especially in radio, many stations are unattended by staff capable of
manual EAN operation for some portion of the day.”593 As a result, according to Sage, “EAN procedures
that refer to actions that require human assistance are not practical.”594 Accordingly, Sage recommended
that “The EAN rules should be rewritten (and greatly simplified) to more closely match what is possible
in the normal case, unattended operation,” adding that “[t]he FCC’s concept of ‘message by message
EAN processing’ is the correct approach.”595 BWWG, Trilithic, and Monroe similarly supported
simplifying the rules governing EANs and eliminating the EAT.596 BWWG also stated that “that there is
a definite public warning benefit to eliminating the manual mode for EAN to eliminate possible
intentional or accidental local use.”597
199. On the other hand, TFT stated that the EAT should be retained “as a failsafe to unlock the
EAS distribution system if an EAS message with event code EAN were sent without a subsequent End-
of-Message code.”598 TFT also argued that EAS Participants should have the option of manual
processing of EANs, on grounds that “[i]f a better, clearer audio source is available, an operator would be
able to switch to that source so that the public could more easily understand the message transmitted” and
[m]andating automatic processing of EAN messages will burden EAS Participants and manufacturers to


587 See id. at 8204, para. 145.
588 See id.
589 See id.
590 See id., para. 146.
591 See id. at 8204-05, para. 147.
592 Timm Comments at 9.
593 Sage Comments at 20.
594 Id.
595 Id. at 21.
596 See BWWG Comments at 56-57; Trilithic Comments at 10; Monroe Comments at 22.
597 BWWG Comments at 57.
598 TFT Reply Comments at 4. See also Brancato Comment at 1.
71

Federal Communications Commission

FCC 12-7

replace firmware/software or install new equipment.”599
200. Walker stated that eliminating the EAT would force “equipment to not only play the
attached message audio associated with the alert … but also continuously analyze it to look for the AFSK
EOM tones.”600 Walker added, “This would add another level of complexity to equipment that is
downloading and playing the audio over the [I]nternet.”601
201. Decision. We are amending the rules so that EANs will be processed on a message-by-
message basis, like any other EAS message, only on a mandatory and priority basis. As part of this rule
simplification, we are eliminating the EAT. As we explained in the Third FNPRM, receipt of an EAN
will effectively open an audio channel between the originating source and the EAS Participant’s facilities
until the EAS Participant receives an EOM.602 After the EAS Participant receives the EOM, the EAS
equipment would return to regular programming until receipt of the next EAS message. If that message is
another EAN, then the process would repeat; if that message is a state or local EAS message, then that
message would be aired in accordance with the specifications in the State or Local Area EAS Plan. We
conclude that revising the rules governing EAN processing is necessary because they were designed to
accommodate the EAN Network, which was phased out in 1995, and purely manual operation.603 As we
explained in the Third FNPRM, these rules do not translate well for automated operation, are confusing,
and in some cases, inconsistent with other Part 11 rules.604 While we appreciate the concept of retaining
the EAT as a failsafe, we doubt there would ever be a need for that function. In any event, as we
observed in the Third FNPRM, in both 2010 and 2011 we performed statewide tests of the EAN in Alaska
without using an EAT, and no problems with the EAN were reported in those tests.605 While the EAT is
used to alert NN stations that an EAN condition has terminated, the EOM can serve that purpose and, in
any event, as explained below, we are eliminating NN status.606 Because CAP-compliant EAS equipment
may be programmed to operate without the EAT, we do not expect that complying with this requirement
will have any significant cost impact on EAS Participants.
202. With respect to the question of whether to eliminate the option for EAS Participants to
manually process EANs (but not state or local EAS messages), we observe that we are in the process of
reviewing test data from the November 9, 2011, Nationwide EAS Test, which may provide insight on this
matter. It would be premature to take any actions with respect to eliminating the option to manually
process EANs until after we have reviewed and processed the test data from the November 9, 2011,
Nationwide EAS Test. Accordingly, we defer taking any action on this matter at this time.
203. Revising Section 11.54. With respect to the procedures in section 11.54, we observed in
the Third FNPRM that adopting message-by-message processing of EANs would render sections
11.54(b)(1), (3), (4), (10), and 11.54(c) superfluous.607 Specifically, section 11.54(b)(1) sets forth


599 TFT Comments at 9.
600 Walker Comments at 5.
601 Id.
602 See Third FNPRM, 26 FCC Rcd 8149, 8204, para. 145 (citing, e.g., 47 C.F.R. § 11.52(e)).
603 See id. at 8202-03, para. 143, note 337.
604 See id. at 8203-04, para. 144.
605 See id., at 8152-53, para. 3, note 22; 8203-04, para. 144, note 340.
606 See infra para. 215.
607 See Third FNPRM, 26 FCC Rcd 8149, 8205, para. 148.
72

Federal Communications Commission

FCC 12-7

monitoring requirements which are already spelled out in section 11.52(d) and the State EAS Plan.608
Section 11.54(b)(3) and (10) establishes “common emergency message” procedures that we are
eliminating by adopting message-by-message EAN processing.609 Section 11.54(b)(4) requires airing of
certain standby scripts in between airing common emergency messages, which has no relevance if section
11.54(b)(3) is eliminated.610 And Section 11.54(b)(c) requires adherence to the termination procedures in
the EAS Operating Handbook upon receipt of an EAT, which we are eliminating.611 Accordingly, we
sought comment on whether these sections should be deleted.612 We asked whether, if we were to delete
sections 11.54(b)(1), (3), (4), (10), and 11.54(c), we would need to make any additional revisions to the
Part 11 rules to facilitate manual processing of EANs on a message-by-message basis.613 We also asked
whether deletion of these provisions would have any impact on CAP-to-SAME translation or legacy EAS
devices.614 Only one commenter, Trilithic, addressed this issue directly, stating its “‘full[] support’ for
deletion of these provision[s].”615
204. Decision. We are deleting sections 11.54(b)(1), (3), (4), (10), and 11.54(c) from the Part
11 rules. As we observed in the Third FNPRM, these provisions are superfluous in the context of
message-by-message processing we are adopting for the EAN.616 Because our removal of these
unnecessary code sections does not affect the obligations of EAS Participants, it should have no cost
impact on EAS Participants.
205. Deleting Section 11.42. Section 11.42(b) specifies that the EAT is used to apprise
“communications common carriers” that they must disconnect certain temporary connections between
EAS Participants and selected “Test Centers.”617 In the Third FNPRM, we explained that the provisions
in section 11.42 were carried over from the former EBS rules and were designed to facilitate the
transmission of EANs via landlines.618 We also observed that the EAS Participants no longer use test
provisions and transmission paths facilitated by section 11.42.619 We therefore sought comment on


608 See 47 C.F.R. §§ 11.54(b)(1), 11.52(d), 11.21(a).
609 See id. § 11.54(b)(3), (10).
610 See id. § 11.54(b)(4).
611 See id. § 11.54(c).
612 See Third FNPRM, 26 FCC Rcd 8149, 8205, para. 149.
613 See id.
614 See id.
615 Trilithic Comments at 3.
616 See Third FNPRM, 26 FCC Rcd 8149, 8205, para. 148 (observing that section 11.54(b)(1) sets forth monitoring
requirements which are already spelled out in section 11.52(d) and the State EAS Plan; Section 11.54(b)(3) and (10)
establishes “common emergency message” procedures that we are eliminating in favor of message-by-message EAN
processing; Section 11.54(b)(4) requires airing of certain standby scripts in between airing common emergency
messages, which has no relevance if section 11.54(b)(3) is eliminated; and Section 11.54(b)(c) requires adherence to
the termination procedures in the EAS Operating Handbook upon receipt of an EAT, which we are eliminating).
617 See 47 C.F.R. § 11.43(b).
618 See Third FNPRM, 26 FCC Rcd 8149, 8205-06, para. 151.
619 See id.
73

Federal Communications Commission

FCC 12-7

whether we should delete section 11.42.620 Only one commenter, Trilithic, addressed this issue directly,
stating its “‘full[] support’ for deletion of these provisions.”621
206. Decision. We are deleting section 11.42 from the Part 11 rules because, as explained in the
Third FNPRM, this section no longer serves any purpose.622 Because our removal of these unnecessary
code section does not affect the obligations of EAS Participants, it should have no cost impact on EAS
Participants.
207. Eliminating the EAS Operating Handbook. As specified in section 11.15, the FCC issues
the EAS Operating Handbook, which summarizes the actions personnel at EAS Participant facilities must
take upon receipt of an EAN, EAT, tests, and state and local area alerts.623 EAS Participants are required
to maintain a copy of the handbook at their facilities for manual processing of EAS messages.624 In the
Third FNPRM, we observed that the various procedures and announcements set forth in the EAS
Operating Handbook were developed for the manual processing of EANs during the National Level
emergency condition outlined in section 11.54.625 Thus they would be largely superfluous if EANs were
processed on a message-by-message basis.626 Accordingly, we sought comment on whether, if we were
to adopt message-by-message processing of EANs, we should eliminate the EAS Operating Handbook
and whether we should require EAS Participants to maintain within their facilities a copy of the current,
FCC-filed and approved versions of the State and Local Area EAS Plans.627 We also observed that if we
were to eliminate the EAS Operating Handbook, the related provisions in section 11.54(a), (b)(2), and
(5)-(8) would become superfluous.628 Accordingly, we asked whether, if we eliminated the EAS
Operating Handbook, we should also delete section 11.54(a), (b)(2), and (5)-(8).629
208. The majority of comments addressing this issue opposed elimination of the EAS Operating
Handbook. NCTA stated, “As a concise reference document for operators on the national EAS
requirements, we believe that the handbook is still necessary and should be updated to reflect changes in
Part 11 rather than eliminated or substituted with state plans.”630 NCTA added, “The EAS handbook
further serves as a reliable training and resource tool for EAS participants and covers areas that may not
be included in the state plans.”631 With respect to replacing the EAS Operating Handbook with State EAS
Plans, NTA asserted, “state plans lack consistency, need updating, and some states have no plan on


620 See id.
621 Trilithic Comments at 3.
622 See Third FNPRM, 26 FCC Rcd 8149, 8205-06, para. 151.
623 See 47 C.F.R. § 11.15.
624 Id.
625 See Third FNPRM, 26 FCC Rcd 8149, 8207, para. 154.
626 See id.
627 See id., para. 155.
628 See id. at 8208, para. 157.
629 See id., para. 158.
630 NCTA Comments at 13.
631 Id.
74

Federal Communications Commission

FCC 12-7

record.”632 NAB expressed essentially the same views.633 AT&T opposed elimination of the EAS
operating Handbook on grounds that it “provides much needed uniformity to the EAS system.”634
209. Monroe stated, “Regarding the EAS Operating Handbook, we do not feel it should be
deleted, however it if is retained, the EAS Operating Handbook must be updated to correct a range of
ambiguities, inconsistencies and errors.”635 Trilithic stated that the EAS Operating Handbook should be
“relegated to informational-only status.”636 Trilithic also supported deletion of sections 11.54(a), (b)(2),
and (5)-(8).637 Kenneth Evans (Evans) stated, “While I have used the FCC EAS Handbook to help train
broadcast station employees, . . . I feel it might be more efficient to just provide a Quick Guide to cover
the basic needed information.”638 Evans added, “Such a sheet could provide the basic information in a
concise form to provide an over all understanding of the rules from Part 11.”639
210. Decision. With respect to the question of whether we should eliminate the EAS Operating
Handbook, we observe that the test data from the November 9, 2011, Nationwide EAS Test, which we are
in the process of reviewing, may provide insight on this matter. It would be premature to make any
decisions on eliminating the EAS Operating Handbook until after we have reviewed and digested the test
data we have received from the November 9, 2011, Nationwide EAS Test. Accordingly, we defer taking
any action on this issue at this time.
211. However, we are deleting sections 11.54(a), (b)(2), and (5)-(8). These provisions all refer
to procedures set forth in the EAS Operating Handbook designed to implement the National Emergency
Condition, which we are eliminating.640 Although we do not decide whether to retain the EAS Operating
Handbook here, if we elect to retain it, as most commenters support, it will at most serve as an
informational document to aid EAS Participant personnel in handling EAS messages manually. It will
not itself establish any procedures (such as on-air announcements) that must be followed.641 Sections
11.54(a), (b)(2), and (5)-(8) serve no purpose under the approach we are adopting for handling EANs, and
thus we delete them from the Part 11 rules. Because our removal of these unnecessary code sections does
not affect the obligations of EAS Participants, it should have no cost impact on EAS Participants.
212. Non-Participating National (NN) Sources. As we explained in the Third FNPRM, the Part
11 rules permit EAS Participants to request FCC authorization not to participate fully in the national level
EAS activation.642 Essentially, these non-participating stations follow all of the EAN-related


632 Id.
633 See NAB Comments at 22-23.
634 AT&T Comments at 5.
635 Monroe Comments at 27.
636 Trilithic Comments at 4.
637 Id. at 3.
638 Kenneth Evans Comments, EB Docket 04-296 (filed July 20, 2011) at 4 (Evans Comments).
639 Evans Comments at 4.
640 As outlined in the Third FNPRM, section 11.54(a) indicates that the EAS Operating Handbook summarizes the
procedures to be followed upon receipt of an EAN and EAT; section 11.54(b)(2) requires EAS Participants to follow
EAS Operating Handbook procedures; section 11.54(b)(5)-(8) sets forth certain requirements related to the
announcements contained in the EAS Operating Handbook. See Third FNPRM, 26 FCC Rcd 8149, 8208, para. 157.
641 See, e.g., Trilithic Comments at 4.
642 See Third FNPRM, 26 FCC Rcd 8149, 8197, para. 130 (citing 47 C.F.R. §§ 11.18(f), 11.19, 11.41(b)).
75

Federal Communications Commission

FCC 12-7

requirements except broadcasting the Presidential audio message.643
213. In the Third FNPRM, we sought comment on whether we should eliminate NN status
altogether, in which case all EAS Participants would be required to broadcast the Presidential EAS
message.644 In this regard, we observed that there are relatively few NN stations in existence, they are
already required to deploy a decoder that complies with all EAS message processing requirements, and
they already follow most of the EAN processing requirements.645
214. Commenters supported elimination of NN status. Timm, for example, noting that there are
few NN stations in existence, commented that the “NN status should be eliminated, and all EAS
Participants would then be required to carry the President’s [ ] messages.”646 BWWG agreed, stating that
“CAP, for all practical purposes, eliminates most if not all of the problems that led to the NN
designation.”647 BWWG argued that “it is time for the NN to go[,] [except that a] CAP-specific NN
waiver of some sort may be necessary if the Commission grants compliance relief to broadcasters or cable
systems that cannot achieve IP connectivity, and can prove it.”648 NSBA stated that “retaining NN Status
is largely unnecessary given that there are so few NN Stations, and, in any event, such stations are already
required to deploy a decoder that complies with all EAS message and EAN processing requirements.”649
NSBA further stated, “Given the changes in the broadcast industry since the advent of the NN Status, the
Commission should consider eliminating the NN Status altogether.”650
215. Decision. We are eliminating NN status on the grounds that it is not necessary.
Accordingly, we are deleting references to NN status from sections 11.18, 11.41, 11.54, and 11.55 of the
Commission’s rules,651 and we are deleting section 11.19 altogether.652 We will require any existing
stations operating under NN status to meet the full message-by-message EAN processing requirements,
and CAP-related requirements, by the June 30, 2012, general deadline for processing CAP-formatted
messages. We find that elimination of NN status is warranted because it does not appear to serve any
purpose today, as NN entities already are required to deploy a decoder that complies with all EAS
message processing requirements,653 and they follow all of the EAN processing requirements, except
broadcasting the audio message.654 Further, as we observed in the Third FNPRM, there are relatively few
NN stations.655 Moreover, no entity with or without NN status filed comments objecting to our proposed


643 See 47 C.F.R. §§ 11.18(f), 11.54(b)(2)(ii).
644 See Third FNPRM, 26 FCC Rcd 8149, 8198, para. 132.
645 See id. (citing 47 C.F.R. §§ 11.11, 11.18(f)).
646 Timm Comments at 7.
647 BWWG Comments at 51.
648 Id.
649 NSBA Comments at 17 (footnote omitted).
650 Id.
651 See 47 C.F.R. §§ 11.18(f), 11.41, 11.54(b)(2)(ii) and (b)(11), and 11.55(c)(3).
652 See 47 C.F.R. § 11.19.
653 See 47 C.F.R. § 11.11.
654 See 47 C.F.R. § 11.18(f).
655 See Third FNPRM, 26 FCC Rcd 8149, 8198, para. 132. According to our records, fewer than fifty stations have
applied for NN status since the EAS rules were adopted in 1995 and most of these made their applications shortly
after we adopted our rules. We also observe that a number of NNs changed their status to PNs during the
(continued….)
76

Federal Communications Commission

FCC 12-7

action.
216. We believe that, at most, there are minimal costs associated with the elimination of NN
status, given that all NN stations must already comply with all equipment and operating requirements
save for broadcasting the actual Presidential audio message. On the other hand, there are considerable
benefits to eliminating NN status. Most importantly, by eliminating NN status, we add to the number of
entities that will be available to broadcast national-level emergency information to the public. Moreover,
elimination of this outmoded provision will increase administrative efficiency.
217. Deleting Section 11.44. Section 11.44 sets forth the priority scheme for EAS message
transmissions during the period of national emergency triggered by an EAN and terminated by an EAT,
as set forth in section 11.54.656 According to section 11.44, during this period, EANs take priority over
and preempt all other EAS messages.657 Section 11.44(b) specifies that when a Presidential message is
not being transmitted, EAS Participants are required to transmit all other EAS messages in the following
order: first, Local Area Messages; second, State Messages; and, third, National Information Center (NIC)
Messages.658 Section 11.44(d) specifies that “[d]uring a national emergency, the facilities of all EAS
Participants must be reserved exclusively for distribution of Presidential Messages,” and “NIC messages
received from national networks which are not broadcast at the time of original transmission must be
recorded locally by LP sources for transmission at the earliest opportunity consistent with the message
priorities in [section 11.44(b)].”659
218. As we explained in the Third FNPRM, the priority scheme set forth in section 11.44 was
intended to apply during the National Level emergency condition codified in section 11.54, which is
initiated by the EAN and terminated by the EAT.660 We also explained that if section 11.54 were revised
to reflect a streamlined, message-by-message processing approach, as we proposed, section 11.44 would
become superfluous.661 Accordingly, we sought comment on whether we should delete section 11.44.662
We also asked whether the existing provisions in other sections of Part 11 sufficiently confer priority
status to EANs and whether we should make any changes to existing provisions to ensure that EANs
maintain primary status.663
219. Timm recommended deletion of section 11.44 based largely on the reasoning set forth in
(Continued from previous page)


preparation for the November 9, 2011 Nationwide EAS Test. See email from Glinda M. Corbin, Esq., dated October
20, 2011 (noting change of status of 35 television broadcast stations from NN to PN).
656 See 47 C.F.R. §§ 11.44, 11.54(b)(3).
657 See 47 C.F.R. § 11.44(a).
658 See id. § 11.44(b).
659 Id. § 11.44(d).
660 See Third FNPRM, 26 FCC Rcd 8149, 8208-09, para. 160.
661 See id. at 8209, para. 162.
662 See id. at 8209-10, para. 163.
663 See id. (citing, e.g., 47 C.F.R. § 11.33(a)(11) (requiring, with respect to decoders, that “[a] header code with the
EAN Event code specified in § 11.31(c) that is received through any of the audio inputs must override all other
messages”); 47 C.F.R. § 11.51(m)(2), (n) (requiring that encoders air EANs “immediately” whether operating in
automatic or manual mode); and 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))).
77

Federal Communications Commission

FCC 12-7

the Third FNPRM.664 Trilithic supported deletion of this section, except 11.44(a), providing for EAN
priority and preemption over any other type of EAS message, which it stated “should be retained or
moved to another section (unless it is already contained elsewhere).”665 Sage supported basically the
same position as Trilithic.666
220. Decision. We are deleting section 11.44 from the Part 11 rules. As we observed in the
Third FNPRM, this section is superfluous under the message-by-message approach for processing EANs
we adopt in this order.667 Although priority for EANs already is provided for in the other sections of Part
11,668 we agree with commenters that the explicit language on EAN preemption and priority in section
11.44(a) is worthwhile to retain, and we therefore will incorporate it into the definition of the EAN in
section 11.2. Because our removal of these unnecessary code sections does not affect the obligations of
EAS Participants, it should have no cost impact on EAS Participants.
221. Revising Section 11.53. Section 11.53 specifies how EANs are initiated at the federal,
state, and local levels for purposes of triggering the national level emergency procedures in section
11.54.669 In particular, this section indicates that, at the national level, EAN messages are sent from a
government origination point to broadcast stations and other entities participating in the PEP system and
then disseminated by EAS Participants.670 This section further requires that EAN messages originate
from state and local governments in accordance with State and Local Area EAS plans.671 In the Third
FNPRM
, we sought comment as to whether this section has any relevance in the streamlined EAN
processing model we proposed.672 We also sought comment on whether, to the extent section 11.53 is
relevant in its own right and should be retained, we should revise it to incorporate CAP-formatted EAN
messages, such as by including a cross-reference to section 11.52 to capture the federal CAP-formatted
EAN origination process.673 We also observed that, to the extent states might originate CAP-formatted
EAN messages, the methodology would be described in the State EAS Plan, just as the SAME-based
distribution method is today.674 Accordingly, we sought comment on whether the existing language
regarding state EAN origination would be sufficient to capture CAP-formatted EANs originated by state
CAP systems.675
222. Monroe, the only commenter addressing this issue, observed that “FEMA IPAWS has not
yet issued requirements for a CAP-formatted EAN message,” and “[s]ince it is anticipated that EAN
messages will be delivered over the current legacy EAS system for the foreseeable future, it would seem


664 See Timm Comments at 7-8.
665 Trilithic Comments at 3.
666 See Sage Comments at 19.
667 See Third FNPRM, 26 FCC Rcd 8149, 8209, para. 162.
668 See supra note 663.
669 47 C.F.R. § 11.53.
670 See id.
671 See id. § 11.53(b).
672 See Third FNPRM, 26 FCC Rcd 8149, 8210, para. 164.
673 See id., para. 65.
674 See id.
675 See id.
78

Federal Communications Commission

FCC 12-7

that § 11.53 remains relevant in its current form.”676
223. Decision. We are deleting section 11.53 from the Part 11 rules. As we observed in the
Third FNPRM, section 11.53 specifies how EANs are initiated at the federal, state, and local levels for
purposes of triggering the national level emergency procedures in section 11.54.677 Because we are
deleting almost all of section 11.54, and implementing message-by-message processing for the EAN,
section 11.53 is largely superfluous. However, we will, for informational purposes, incorporate the
relevant language in section 11.53(a) and (b), describing federal, state, and local origination of the EAN,
into the definition of EAN in section 11.2 and clarify that such origination applies only to EANs
formatted and transmitted in accordance with the EAS Protocol requirements in section 11.31. Because
our removal of these unnecessary code sections and clarification of sections 11.53 (a) and (b) does not
affect the obligations of EAS Participants, it should have no cost impact on EAS Participants.
224. Revising Section 11.11(a). In the Third FNPRM, we also sought comment on whether, if
we were to streamline EAN processing, we should revise section 11.11(a) to remove the references
therein to “participating broadcast networks, cable networks and program suppliers; and other entities and
industries operating on an organized basis during emergencies at the National, State and local levels.”678
No commenter addressed this issue directly.
225. Decision. We are revising section 11.11(a) to remove the references therein to
“participating broadcast networks, cable networks and program suppliers; and other entities and industries
operating on an organized basis during emergencies at the National, State and local levels.”679 As we
explained in the Third FNPRM, these references are a holdover from the EBS rules and serve no purpose
in the streamlined version of EAN processing we are adopting here.680 Because our removal of these
unnecessary code sections does not affect the obligations of EAS Participants, it should have no cost
impact on EAS Participants.
226. Deleting Section 11.16. Section 11.16 describes the “National Control Point Procedures,”
which are “written instructions issued by the FCC to national level EAS control points,” covering
National Level EAS Activation, EAS Test Transmissions, and the National Information Center (NIC).681
In the Third FNPRM, we explained that these instructions (and this rule section) essentially are the
standard operating procedures that were used in the EBS for manually activating, terminating, and testing
national-level messages (i.e., EANs).682 We also explained that the Commission developed these
procedures for manual processing of EANs sent over the EAN Network, which no longer has any
relevance.683 Accordingly, we sought comment on whether we should delete section 11.16, along with
section 11.54(b)(12), which requires LP (i.e., PEP) stations to adhere to the National Control Point
Procedures following receipt of an EAN.684 Trilithic and BWWG supported deletion of the sections as


676 Monroe Comments at 23.
677 See Third FNPRM, 26 FCC Rcd 8149, 8210, para. 164.
678 See id at 8210-11, para. 166.
679 See 47 C.F.R. § 11.11(a).
680 See Third FNPRM, 26 FCC Rcd 8149, 8210-11, para. 166.
681 47 C.F.R. § 11.16.
682 See Third FNPRM, 26 FCC Rcd 8149, 8211, para. 167.
683 See id.
684 See id.
79

Federal Communications Commission

FCC 12-7

proposed in the Third FNPRM.685
227. Decision. With respect to the question of whether we should delete section 11.16, we
observe that the test data from the November 9, 2011, Nationwide EAS Test, which we are in the process
of reviewing, may provide insight on this matter. Accordingly, we defer taking any action on this issue at
this time. We are, however, deleting section 11.54(b)(12) and incorporating its requirement for PEP
stations to follow the National Control Point Procedures into Section 11.16.

F.

Part 11 Revisions Not Related to CAP

228. In the Third FNPRM, we sought comment on potential revisions to various provisions in
Part 11 that are not related to CAP. These issues are addressed below.
1.

Definitions

229. LP-1 Definition. In the Third FNPRM, we asked whether we should revise the definition
for LP-1 stations in section 11.2(b) to reflect that these stations can be a radio or a TV station.686 BWWG
supported this change.687 No other commenter addressed this issue directly.
230. Decision. We are revising section 11.2(b) to reflect that LP-1 stations can be either radio
or TV stations. Our assessment of State EAS Plans confirms that there are both radio and TV stations
serving as LP-1 stations, and thus, this rule revision is necessary to reflect these factual circumstances.
We do not believe that this rule clarification will have any significant cost impact on EAS Participants.
231. PEP Definition. As we explained in the Third FNPRM, section 11.2(a) currently defines
the PEP system as “a nationwide network of broadcast stations and other entities connected with
government activation points” that is used to “distribute the EAN, EAT, and EAS national test messages
and other EAS messages.”688 The definition also explains that “FEMA has designated 34 of the nation’s
largest radio broadcast stations as PEPs,” which are “designated to receive the Presidential alert from
FEMA and distribute it to local stations.”689 The PEP system is also defined in section 11.14, which
mirrors most of the language in section 11.2(a).690 We tentatively concluded in the Third FNPRM that we
should delete section 11.14 from the Part 11 rules because it mirrors the definition in section 11.2(a).691
With respect to the PEP system definition in section 11.2(a), we sought comment on whether the use of
actual numbers to reflect the number of PEP stations is so inflexible that it requires revision via an
amendment to the rule every time FEMA adds another station to the PEP system and whether we should
delete the numerical reference.692 We also sought comment on whether we should revise the language in


685 See Trilithic Comments at 3, BWWG Comment at 61.
686 See Third FNPRM, 26 FCC Rcd 8149, 8211-12, para. 169.
687 BWWG Comments at 61.
688 Third FNPRM, 26 FCC Rcd 8149, 8212, para. 170 (citing 47 C.F.R. § 11.2(a)).
689 47 C.F.R. § 11.2(a)).
690 Specifically, section 11.14 reprints the first two sentences in section 11.2(a). Compare 47 C.F.R. § 11.2(a) with
47 C.F.R. § 11.14.
691 See Third FNPRM, 26 FCC Rcd 8149, 8212, para. 172.
692 See id., para. 173.
80

Federal Communications Commission

FCC 12-7

section 11.2(a) to clarify that the PEP stations distribute the EAN, EAS national test messages, and other
EAS messages in accordance with the EAS Protocol requirements in section 11.31.693
232. BWWG supported our proposal to delete section 11.14.694 With respect to revising the
language in section 11.2(a) to make clear that the PEP stations originate EAS messages in accordance
with the EAS Protocol requirements, BWWG responded: “[A] better definition of the program would be,
‘The FEMA Primary Entry Point program (PEP) is [the] last ditch means for the President to
communicate with the largest possible percentage of the American public to communicate reassurance of
government continuity if traditional means for broadcast video and audio communication are disabled or
otherwise not available. The majority of PEP outlets are AM radio stations, but network and other
broadcast resources are used for backup and fill in.”695 No other commenter addressed these issues
directly.
233. Decision. We are deleting section 11.14 from the Part 11 rules because it mirrors the
definition in section 11.2(a) and is therefore superfluous. We are also revising section 11.2(a) to delete
the numerical reference to the actual number of PEP stations in existence. As we explained in the Third
FNPRM
, FEMA is in the process of increasing the number of PEP stations, and thus it is neither practical
nor administratively efficient to try to keep the current number codified in Part 11.696 We also revise the
language in section 11.2(a) to clarify that the PEP stations distribute EAS messages in accordance with
the EAS Protocol requirements in section 11.31. This revision simply makes clear that PEP stations do
not originate or distribute alert messages in CAP format and thus helps to differentiate SAME distribution
from CAP distribution. We do not believe that this rule clarification will have any significant cost impact
on EAS Participants.
234. EAN and EAT Definitions. Section 11.13 defines the EAN and EAT.697 In the Third
FNPRM, we sought comment on whether we should delete section 11.13 and fold the definition for the
EAN currently in section 11.13 into section 11.2.698 BWWG and Monroe agree that if the EAT is
removed from the Part 11 rules, it should be deleted from section 11.13.699 Accordingly we are deleting
section 11.13 from the Part 11 rules and folding the definition for the EAN currently in section 11.13 into
section 11.2. Because we are deleting the EAT, section 11.13(b) is superfluous. As we indicated in the
Third FNPRM, the proper location in Part 11 for the EAN definition, currently at section 11.13(a), is the
definitions section in section 11.2.700 We therefore relocate the EAN definition to section 11.2 and delete
section 11.13 altogether. We do not believe that these clarifications will have any cost impact on EAS
Participants
2.

Miscellaneous Rule Changes

235. Geographic Codes. Section 11.31(c) specifies the message formatting requirements for the


693 See id.
694 BWWG Comments at 61.
695 Id. at 62.
696 See Third FNPRM, 26 FCC Rcd 8149, 8155, para. 6, note 31.
697 See 47 C.F.R. § 11.13.
698 See Third FNPRM, 26 FCC Rcd 8149, 8213, para. 174.
699 See BWWG Comments at 62; Monroe Comments at 23.
700 See Third FNPRM, 26 FCC Rcd 8149, 8213, para. 174.
81

Federal Communications Commission

FCC 12-7

EAS Protocol, including the formatting of the location code.701 This section (and section 11.31(f))
currently indicates that the location code “uses the Federal Information Processing Standard (FIPS)
numbers as described by the U.S. Department of Commerce in National Institute of Standards and
Technology publication FIPS PUB 6–4.FIPS number codes.”702 As we explained in the Third FNPRM,
the FIPS publication has been replaced by American National Standards Institute (ANSI) Codes INCITS
31.200x (Formerly FIPS 6-4), Codes for the Identification of Counties and Equivalent Entities of the
United States, its Possessions, and Insular Areas.703 Accordingly, we tentatively concluded that we
should change the references to the FIPS standard in section 11.31 (and 11.34(d)) to reflect the ANSI
standard that superseded it.704 We sought comment on this tentative conclusion.705 Monroe and BWWG
supported our tentative conclusion.706 No other commenter addressed this issue directly.
236. Decision. We are changing the references to the FIPS standard in sections 11.31 and
11.34(d) to reflect the ANSI standard that superseded it. As we explained in the Third FNPRM, the FIPS
standard is outdated and requires revision to keep the Part 11 rules current.707 We do not believe that this
rule clarification will have any significant cost impact on EAS Participants.
237. LPTV and LPFM. In the Third FNPRM, based upon our review of the EAS rules covering
Low Power TV (LPTV) and Low Power FM (LPFM) stations, we observed that the analog and digital
broadcast station equipment deployment table in section 11.11(a) incorrectly identifies “LPFM” in the
column that is supposed to contain Class A TV708 and incorrectly identifies “LPTV” in the column that
should contain “LPFM.”709 We also observed that the term “LPFM” had been inadvertently omitted from
the test requirements in section 11.61(a)(1)(i) (LPFM stations are only required to transmit test script, just
like LPTV stations) and section 11.61(a)(2)(ii) (LPFM stations are only required to log receipt of the test,
just like LPTV stations).710 We tentatively concluded that we should correct these omissions, and we
sought comment on this tentative conclusion.711 BWWG agreed with our tentative conclusion.712 No
other commenter addressed this issue directly.
238. Decision. We are revising the analog and digital broadcast station equipment deployment
table in section 11.11(a) to correctly identify LPFM and LPTV in their respective columns and are
revising sections 11.61(a)(1)(i) and 11.61(a)(2)(ii) to include LPFM stations. These are corrections to
ensure that the rules reflect prior decisions, and thus we do not believe that they will have any significant


701 See 47 C.F.R. § 11.31(c).
702 Id.
703 See Third FNPRM, 26 FCC Rcd 8149, 8213, para. 175.
704 See id.
705 See id.
706 Monroe Comments at 27; BWWG Comments at 62.
707 See Third FNPRM, 26 FCC Rcd 8149, 8213, para. 175.
708 See id. at 8216, para 187. Specifically, we observed that “[t]he “LPFM” category should be on the right-hand
side of the column header shown for “FM class D,” which itself should be on the left-hand side (and the column
header itself should be two separate headers rather than a single header covering two columns.” Id. at note 425.
709 See id.
710 See id.
711 See id.
712 BWWG Comments at 65.
82

Federal Communications Commission

FCC 12-7

cost impact on EAS Participants.
3.

Attention Signal

239. Section 11.32(a)(9) sets forth specifications regarding, among other things, tone
frequencies, harmonic distortion limit, and transmission time period for Attention Signal generators in
encoders.713 Section 11.33(b) specifies Attention Signal requirements for decoders.714 As we explained
in the Third FNPRM, the Commission derived the Attention Signal specifications in sections 11.32(a)(9)
and 11.33(b) from the Attention Signal specifications in the EBS rules, where they were used both to
initiate processing of emergency alerts and to alert the public that an EAS Participant was about to air an
emergency message.715 In the current EAS architecture, however, the Attention Signal is used exclusively
for alerting the public that an EAS Participant is about to air an emergency audio message.716 Given the
limited purpose of the Attention Signal in the EAS, we sought comment on whether we can delete most of
the current provisions relating to the Attention Signal in sections 11.32(9) and 11.33(b) in favor of the
minimal standard currently set forth in the EAS Protocol (at section 11.31(a)(2)).717 We asked which, if
any, of the equipment-related Attention Signal requirements in sections 11.32(9) and 11.33(b) we should
incorporate into section 11.31(a)(2).718 We also asked whether we should modify the duration limits for
the Attention Signal, currently set at between 8 and 25 seconds, or whether we should delete the Attention
Signal from the Part 11 rules altogether.719 In addition, we observed that section 11.12, which specifies
that EBS Attention Signal encoders and decoders can remain in operation until January 1, 1998, is
obsolete.720 Accordingly, we tentatively concluded that we should delete section 11.12 from Part 11. We
sought comment on this tentative conclusion.721
240. The majority of commenters addressing these issues opposed elimination of the Attention
Signal but supported limiting its duration to eight seconds. Sage agreed that “the rules should be updated
to remove all uses of the attention signal other than to alert the public.”722 Sage added, “Devices still need
to detect the presence of the Attention Signal so that it can be removed from the incoming audio, the
definition and accuracy of the tone must be retained in section 11.31(a)(2) and 11.32(a)(9).”723 According
to Sage, “[t]he use of the Attention Signal should be maintained – as a notice to the public that something


713 See 47 C.F.R. § 11.32(a)(9).
714 See 47 C.F.R. § 11.33(b).
715 See Third FNPRM, 26 FCC Rcd 8149, 8214, para. 178. Specifically, PEP stations broadcast the Attention
Signal, along with an audio message. The Attention Signal served two functions: (i) it triggered circuitry within
decoders deployed at stations monitoring the PEP stations to activate an audio alarm that alerted station personnel
that an incoming EBS audio message was arriving (the station personnel would in turn broadcast an Attention
Signal, using an Attention Signal generator, and rebroadcast the EBS audio message originally broadcast by the PEP
station); and (ii) it served as an audio alert signal to listeners and viewers that an EAS Participant was about to air an
emergency broadcast. See id., note 407 (citing 1994 Report and Order at 10 FCC Rcd 1790, para. 8).
716 See id. (citing 1994 Report and Order at 10 FCC Rcd 1814-15, para. 81).
717 See id.
718 See id., para. 179.
719 See id.
720 See id. at 8215, para. 181.
721 See id.
722 Sage Comments at 21.
723 Id.
83

Federal Communications Commission

FCC 12-7

important is about to be heard.”724 However, Sage added that “[t]o lessen audience fatigue, the length of
the signal for required monthly tests could be reduced to two or four seconds, and kept at a maximum of
eight seconds for real alerts.”725
241. Timm opposed deletion of the Attention Signal, stating that it “has become a familiar
public notification that ‘official information’ is coming.”726 Timm also observed that the Commercial
Mobile Alert System [now the Personal Localized Alerting Network (PLAN)] uses the same signal tones
to alert mobile handset users of an alert, arguing that “[r]etaining the Attention Signal for EAS will
further validate future alerts received via CMAS.”727 Timm agreed that the Attention Signal should be
shortened and suggested that “the duration be amended to be from 4 to 8 seconds.”728
242. The Wireless RERC recommended “retention of the 8 seconds of the EAS two tone
Attention Signal and that it be transmitted in all EAS messages containing an audio message.”729 The
Wireless RERC further contended that “[t]he three bursts of digital signal at the start of an EAS message
(usually about 3 or 4 seconds) is not of sufficient loudness or length for hearing impaired people to
respond to and listen to the audio message especially since the audio message is usually transmitted only
once.”730 The Wireless RERC also noted that “the public is familiar with the Attention Signal which has
been in use since 1975,” and observed that PLAN uses the same signal.731
243. The BWWG opposed deletion of the Attention Signal on grounds that it “serves a useful
purpose as a necessary preamble to prepare the public to hear a warning.”732 In this regard, BWWG noted
that “[w]e have trained generations of people to understand that the attention signal means that they are
about to hear critical information,” adding that “the attention signal provides a useful aural warning to
those people at risk who are visually impaired.”733 BWWG also explained that “[i]f the attention signal is
eliminated, marketers will use it to sell their wares, confusing the public while we try to educate them
about whatever sound we decide should replace the attention signal.”734 With respect to the Attention
Signal duration, BWWG asserted that “[m]ost (if not all) stations now use the 8 second signal so
shortening the attention signal to a maximum length of 8 seconds in Part 11 will serve to limit the amount
of time spent on this function while preserving the function’s benefits.”735 BWWG supported deleting
section 11.12 from the Part 11 rules.736


724 Id.
725 Id.
726 Timm Comments at 10.
727 Id.
728 Id.
729 Wireless RERC Comments at 6.
730 Id.
731 Id. at 7.
732 BWWG Comments at 63.
733 Id.
734 Id.
735 Id.
736 Id.
84

Federal Communications Commission

FCC 12-7

244. Walker, Pavlica, and Gorman also support retention of the Attention Signal solely to alert
the public, noting the public’s longstanding familiarity with the tone.737 Gorman also stated that the
“decoder filtering for 853 Hz and 960 Hz should be narrowed to [+/-] 2 Hz” to increase ease of filtering738
and that “Part 11 should require that the decoder filter out the attention tone before the audio recording is
turned on” to prevent it from limiting time for playing the audio recording.739
245. Trilithic recommended “the complete elimination of the Attention Signal requirements.”740
Trilithic added, “Detection and Demuting outside of an EAS message no longer serve a purpose,”741 and
that the “frequency tolerance, harmonic distortion requirements, output level requirements, and additional
software/firmware support increase the cost of testing and producing EAS equipment.”742 Trilithic also
argued that “[t]he public no[w] identifies the FSK bursts with emergency messaging so the Attention
Signal is no longer needed as an aural indicator for the public.”743
246. Decision. We are persuaded by commenters that the Attention Signal continues to serve a
useful purpose in the EAS framework as an audio notification to the general public that an alert is about
to be aired, and we therefore will retain the Attention Signal in the Part 11 rules. We are also persuaded
that the duration of the Attention Signal should be limited to no more than eight seconds. Because we are
not lowering the existing 8-second minimum duration for the signal, this will result in a uniform
requirement that the Attention Signal be eight seconds in duration. BWWG indicated that most stations
only air the Attention Signal for eight seconds, thus establishing an 8-second duration requirement for the
signal will codify what has become common practice and ensure that when the signal is aired, it is done in
a consistent manner.744 We are also persuaded that we should retain the technical parameters established
for the Attention Signal in sections 11.31(a)(2) and 11.32(a)(9), but we are deleting section 11.33(b),
which establishes Attention Signal requirements for decoders, as these were used for demuting and
activation functions that do not apply to the EAS.745 We are also deleting section 11.12, which specifies
that EBS Attention Signal encoders and decoders can remain in operation until January 1, 1998, as this
section is obsolete. We do not believe that these revisions will have any significant cost impact on EAS
Participants.
4.

Equipment Issues

247. In the Third FNPRM, we addressed the following issues unrelated to CAP that involve the
current encoder and decoder requirements.


737 See Walker Comments at 5; Pavlica Comments at 2; Gorman Comments at 1.
738 Gorman Comments at 1.
739 Id. at 2.
740 Trilithic Comments at 4.
741 Id.
742 Id.
743 Id.
744 See BWWG Comments at 63.
745 See Third FNPRM, 26 FCC Rcd 8149, 8214, para. 178. With respect to Sage’s contention that decoders must
still be capable of detecting the presence of the Attention Signal, we observe that Section 11.32(a) generally requires
decoders to be capable of decoding the EAS Protocol, thus, decoders are required to detect the Attention Signal
independent of section 11.33(a)(9). See Sage Comments at 21.
85

Federal Communications Commission

FCC 12-7

248. Section 11.33(a)(9). Section 11.33(a)(9) allows EAS Participants to set their decoders to
automatically reset to the monitoring state if the decoder does not receive an EOM for any given EAS
message within a predetermined minimum time frame (not less than two minutes).746 This reset function
does not apply to EANs. In the Third FNPRM, we explained that this provision essentially allows EAS
Participants to establish a maximum duration for state and local EAS messages that their equipment will
air automatically (by ensuring that their EAS equipment will automatically reset for any state or local
EAS messages exceeding such time period).747 We further explained that the reset activation in section
11.33(a)(9) applies only when the EOM for a given EAS message has not arrived within the specified
time period.748 We also described how transmitting an EOM is a minimum requirement for encoders and
that because there is no EOM associated with an EAS message that has been canceled via reset, there is
no EOM for the encoder to transmit.749 Under this interpretation of the rules, the encoder should not
transmit an EAS message that has been canceled via reset.750 We sought comment on whether we should
amend the rules to make this clearer or whether we should allow encoders to air EAS messages that have
been canceled via reset.751 We observed that airing an EAS message that does not have an EOM runs the
risk of airing a partial message that may cause confusion among listeners and viewers but that a partial
alert message may be better than none.752
249. Sage observed that there are “several reasons for an alert to be received without a proper
EOM,” including an “EOM sent slightly after the two minute limit on a message that lasts exactly two
minutes due to minor variations in transmission times, ambiguity in when the two minute time starts and
ends, etc.[;] EOM not aired due to a hardware or software or human fault at the monitored location[;]
[and] EOM not received due to bad reception.”753 Sage also observed that the receiving device has no
way of discerning which of these instances represents a valid EAS message.754 Sage indicated that its
equipment “does relay the alert . . . to provide consistent results for messages that are relayed in real-time
vs. messages that are stored, and relayed at a later time.”755 Sage observed that “[w]aiting for a message
to be received in its entirety and then relayed, would delay the transmission of the alert by as much as two
minutes,” which can be a significant in a time-sensitive alert situation, such as a tornado warning.756 Sage
also observed that “[m]any EAS manufacturers can start the relay of an alert as soon as the audio portion
of the incoming message starts but before reception of the EOM, reducing delivery latency” and that
“[t]hese messages will always be relayed, even if an EOM is not received.”757 Sage recommended that
“the FCC should clarify the desired action, which we recommend should be to air the alert as if an EOM


746 See 47 C.F.R. § 11.33(a)(9).
747 See Third FNPRM, 26 FCC Rcd 8149, 8215, para. 183.
748 See id. at 8215-16, para. 184.
749 See id.
750 See id.
751 See id.
752 See id.
753 Sage Comments at 22.
754 Id.
755 Id.
756 Id.
757 Id.
86

Federal Communications Commission

FCC 12-7

had been received at the two minute time limit.”758
250. Gorman and Timm similarly support allowing EAS Participants to broadcast and encode a
message that may have been shortened or cut off by reset.759 BWWG indicated “qualified” support for
Sage’s position, apparently on the basis that “it is technically possible that new CAP-EAS devices can be
‘patched’ with a routine that will turn a defective warning that is just missing its EOM to recognize that
fact and insert an EOM.”760
251. Decision. We agree with commenters that EAS Participants should be allowed to relay, for
the benefit of downstream monitoring stations, messages they received that did not include an EOM
within the reset time limit set on their decoder (presumably, two minutes). When a non-EAN alert
exceeds that two minute mark, the EAS Participant’s EAS device should be allowed to generate an EOM
to make up for the EOM that was not received with the original message. Sage and Timm indicate that
current EAS equipment already functions in this manner, although it is not clear whether the EAS
equipment generates the EOM for the EOM-missing message directly after the audio message (if any) or
at the two-minute mark when the reset value triggers.761 As Sage pointed out, there are many reasons
why an EOM might not arrive before the reset value triggers that have nothing to do with the reliability of
the message.762 In addition, the only way to ensure that an EOM did arrive for a given EAS message
prior to the reset value would be to delay relay of that message until the entire message and its EOM has
been received, which could take up to two minutes (or more). We agree with Sage that incurring such
delays for time-sensitive information would not be prudent where,763 for example, the incoming EAS
message that lacked the EOM was brief and the receiving station waited until the two minute reset mark
to generate the EOM.764 We also observe that these events are likely to be rare, and the alternative is to
delay relaying such messages until the entire message and its EOM have arrived, a result which is not in
the public interest. We do not believe that programming EAS equipment to meet this requirement will
have any significant cost impact on EAS Participants.
252. Section 11.33(a)(3)(ii). Section 11.33(a)(3)(ii) specifies certain header code storage
requirements for decoders.765 Among other things, this section requires storage of the header codes of the
last ten valid messages received by the decoder that still have valid time periods and deletion of header
codes as their valid time periods expire.766 In the Third FNPRM, we explained that TFT, responding to
the Part 11 Public Notice, urged that we eliminate the requirement to delete messages upon expiration of
their time periods because “there are cases in which such expired messages should be transmitted.”767 By


758 Id. at 23.
759 Gorman Comments at 2; Timm Reply Comments at 1-2.
760 BWWG Reply Comments at 6.
761 See Sage Comments at 22; Timm Comments at 11.
762 See Sage Comments at 22.
763 See id.
764 For example, if the monitored station did not generate an EOM for such message until the two-minute mark, the
message relayed to downstream monitoring stations could contain a very brief audio message, followed by more
than a minute of static or, according to Sage, the monitored station’s regular programming. See id.
765 See 47 C.F.R. § 11.33(a)(3)(ii).
766 Id.
767 See Third FNPRM, 26 FCC Rcd 8149, 8216, para. 185 (citing TFT, Inc., Comments, EB Docket 04-296 (filed
May 14, 2010) at 5).
87

Federal Communications Commission

FCC 12-7

way of example, TFT suggested that “a Tornado Warning may be received by an EAS Participant with a
minimum validity and circumstances, [that] in the judgment of the EAS Participant, may warrant
transmission of the message although expired or retransmission of the message.”768
253. In the Third FNPRM, we explained that the storage and deletion requirements in section
11.33(a)(3)(ii) facilitate comparison of incoming EAS messages, which among other things should help
prevent the automatic relay of duplicate messages.769 The alert message originator – not the EAS
Participant – determines the valid time period specified for an alert.770 We observed that while some
might agree that an EAS Participant should be able to determine in its own judgment that an expired EAS
message is valid for the listeners or viewers in its area, others might argue that such determinations are
best left to the state and local public safety authorities, whose purpose, training, information, and
resources are designed to facilitate such determinations.771 Accordingly, we sought comment on whether
we should revise 11.33(a)(3)(ii) as proposed by TFT.772 Specifically, we asked whether we should allow
EAS Participants to air alert messages after expiration of the effective time period set by the alert message
originator.773 BWWG supported TFT’s position.774 No other commenter addressed this issue directly.
254. Decision. We conclude that the valid time period should continue to be set by the message
originator. This decision keeps the choice of when an alert should initiate or terminate in the hands of the
party most responsible for the public’s safety, the alert initiator. EAS Participants have repeatedly
stressed that they do not want the responsibility of alert origination, and allowing them to air expired
alerts effectively puts them in that role. Because we leave the decision with the alert initiator rather than
imposing a new technical obligation on the EAS Participant, we do not believe that this rule revision will
have any significant cost impact on EAS Participants.
5.

Training

255. In the Third FNPRM, we observed that some parties responding to the Part 11 Public
Notice called for the federal government to provide EAS training for state and local emergency
managers.775 We indicated that while we are committed to aiding FEMA in its efforts to develop training
and public outreach programs for EAS Participants; state, local, and tribal alert warning authorities; and
the public generally, the Commission lacks the authority to raise or distribute funds for EAS-related
purposes.776 We therefore tentatively concluded that the Commission cannot provide training for state


768 See id.
769 See id., para. 186.
770 See id. (citing 47 C.F.R. § 11.31(c) and explaining that the time period is one of the EAS Header Codes
contained in the EAS Protocol).
771 See id.
772 See id.
773 See id.
774 See BWWG Comments at 64.
775 See Third FNPRM, 26 FCC Rcd 8149, 8217, para. 188.
776 See id. We observed that Executive Order 13407 directs the Secretary of Homeland Security to conduct training
related to the EAS, including “public education efforts so that State, territorial, tribal, and local governments, the
private sector, and the American people understand the functions of the public alert and warning system and how to
access, use, and respond to information from the public alert and warning system.” See id., note 427 (citing
Executive Order 13407
, § 2(a)(vii) and 2(a)(viii)).
88

Federal Communications Commission

FCC 12-7

and local emergency managers, and we sought comment on this tentative conclusion.777 In making this
tentative conclusion, we drew the distinction between EAS (and other alert system training, such as that
which FEMA will do for IPAWS) and the workshops and summits that the Commission holds as part of
its outreach mission.778
256. BWWG concurred that FEMA is the federal authority empowered to carry out such
training.779 No other commenter addressed this issue directly.
257. Decision. We reiterate that the Commission lacks the authority to raise or distribute funds
for EAS-related purposes and therefore cannot provide training for state and local emergency managers.
We can, however, hold workshops and summits as part of our outreach mission. In addition, as indicated
above, we plan to examine the relative merits of making the FCC Mapbook and EAS Operator Handbook
more informative and useful for EAS Participants and their personnel.
6.

Persons with Disabilities

258. As indicated in section IV.B(5) of this order, the Part 11 rules require an EAS Participant
to create a visual message (typically aired in the form of a video crawl) that conveys certain basic
information that is derived from the EAS header codes for the originator, event, location, and valid time
period of the EAS message but do not require a textual transcription of the audio portion of an EAS
message.780 In the Third FNPRM, we acknowledged that the resulting message may not convey as much
in the visual alert as in the audio portion due to the technical limitations inherent in the EAS. This would
be in tension with Federal statutory obligations781 and with the Commission’s policy that all members of


777 See id.
778 See id.
779 BWWG Comments at 65.
780 See 47 C.F.R. § 11.51(d), (g)(3), (h)(3), (j)(2). This is because visual EAS messages are typically pre-determined
phrases programmed into the EAS equipment that correspond to specific EAS codes. For example, the visual
depiction of the affected location described for the alert could be a county, whereas the subject matter of the alert
may actually be limited to an area within that county. As a consequence, the information that is conveyed visually
typically only reports the basic “who,” “what,” “when,” and “where” associated with an audio EAS message and
may not provide the specificity of the audio portion of an EAS message.
781 See, e.g., 47 U.S.C. § 613 (video programming accessibility); 47 C.F.R. § 79.1 (closed captioning); 47 C.F.R. §
79.2 (visual access to emergency programming); 47 C.F.R. Part 11 (emergency alert system); Twenty-first Century
Communications and Video Accessibility Act of 2010 (CVAA), Pub. L. No. 111-260 and Pub. L. No. 111-265
(technical amendments to the CVAA) (requiring the Commission to promulgate rules to make emergency
information provided by video providers, distributors, and owners to be accessible to people who are blind or
visually impaired); Rehabilitation Act of 1973, Pub. L. No. 93-112, as amended, § 504, 29 U.S.C. § 794 (prohibiting
discrimination against individuals with disabilities under any program or activity that either receives Federal
financial assistance or is conducted by any Executive agency or the United States Postal Service); and § 508, 29
U.S.C. § 794d (requiring Federal electronic and information technology to be accessible to people with disabilities,
including employees and members of the public); Americans with Disabilities Act of 1990, Pub. L. No. 101-336, as
amended (covering in Title II all activities of State and local governments regardless of the government entity’s size
or receipt of Federal funding); Executive Order 13347, 69 Fed. Reg. 44573 (July 26, 2004) (creating the Interagency
Coordinating Council on Emergency Preparedness and Individuals with Disabilities “to ensure that the Federal
Government appropriately supports safety and security for individuals with disabilities in situations involving
disasters, including earthquakes, tornadoes, fires, floods, hurricanes, and acts of terrorism”); Executive Order 13407,
71 Fed. Reg. 36975 (June 26, 2006) (including in the public alert and warning system the capability to alert and
warn all Americans, including those with disabilities).
89

Federal Communications Commission

FCC 12-7

the public receive equal access to emergency alerts.782 We also acknowledged that the inconsistency
between the broadcast audio and visual portions of an EAS alert message may not fulfill the intent of
section 79.2, which requires that video programming distributors provide emergency information in both
visual and audio formats.783
259. We sought comment on how the introduction of CAP into the EAS might enhance the
accessibility of emergency alerts to people with disabilities.784 In this regard, we sought comment on
whether there is in CAP some functionality that would allow EAS Participants to broadcast the same
information in the visual portion (i.e., the text crawl) of an EAS alert as is contained within the audio
portion (if any).785 We also sought comment on whether it is technically feasible for the existing EAS
system or EAS Participant facilities to broadcast anything in lieu of an audio message.786 We asked
whether the equipment that EAS Participants will be using to receive CAP-based EAS alerts can
simultaneously accommodate both an audio and textual message that can be delivered over the EAS.787
We also invited initial comment on the effectiveness of speech-to-text software and how EAS Participants
might use it in a manner that neither delays nor inaccurately interprets an EAS alert message.788

260. The Wireless RERC recommended that EAS Participants should be allowed to create the
video crawl from the enhanced text in the CAP message,789 adding that “[t]he additional text relating to
the emergency alert would allow for more description which is highly important to those persons with


782 See Third FNPRM, 26 FCC Rcd 8149, 8217, para. 189.
783 See id. Section 79.2 of the Commission’s rules requires video programming distributors to provide individuals
who are deaf, hard of hearing, blind, or visually impaired with equal access to emergency information that such
distributors provide to their viewers. Emergency information is defined as information about a current emergency
that is intended to further the protection of life, health, safety, and property. See id., note 429 (citing 47 C.F.R. §
79.2(a)(2)). Critical details that must be provided in an accessible format include, but are not limited to, specific
details regarding the areas that will be affected by the emergency, evacuation orders, detailed descriptions of areas to
be evacuated, specific evacuation routes, approved shelters or the way to take shelter in one’s home, instructions on
how to secure personal property, road closures, and how to obtain relief assistance. See id. (citing Note to 47 C.F.R.
§ 79.2(a)(2)). In addition, section 79.2 requires emergency information provided in the video portion of
programming that is not a regularly scheduled newscast, or a newscast that interrupts regular programming, to be
accompanied by an aural tone for people who are blind or visually impaired. See 47 C.F.R. § 79.2 (b)(1)(ii). The
CVAA instructed the Commission to improve the ability of this population to obtain emergency information by
directing the promulgation of regulations that will require video programming providers, distributors, and owners to
convey emergency information in a manner that is accessible to people who are blind or visually impaired. See Pub.
L. No. 111-260 § 202 (a), amending 47 U.S.C. § 613(g). Over the past year, the Commission’s Video Programming
Accessibility Advisory Committee, also created by the CVAA, has been working to develop recommendations to
address such access, which will be delivered to the Commission in April 2012. See id. at §201. The Commission’s
rules are due one year after receiving this report.
784 See Third FNPRM, 26 FCC Rcd 8149, 8217-18, para. 190.
785 See id., para. 194. We recognized that enhancing the visual information broadcast by EAS Participants would
not address instances in which no audio portion is included for state and local (and NWS) messages, either because
the EAS message originator did not provide one or because the EAS Participant elected not to broadcast it. See id.,
note 439 (citing 47 C.F.R. § 11.51(b), which states that EAS Participants are not required to provide the audio
portion of state and local EAS messages).
786 See id. at 8219-20, para. 195.
787 See id.
788 See id.
789 Wireless RERC Comments at 5.
90

Federal Communications Commission

FCC 12-7

hearing limitations.”790 Wireless RERC also recommended that “[i]f the received CAP message contains
audio, then the EAS participant can use speech to text conversion to provide the additional text
information,” observing that “[t]his will begin to bridge the gap between Part 11 and Part 79.2.”791
261. The Wireless RERC also observed that, “[e]nsuring that plans include instructions on how
to alert the public, including individuals with disabilities, facilitates an understanding of how accessibility
contributes to reduction in loss of life and/or property.”792 The Wireless RERC added, “Between 2007
and 2009 the Wireless RERC reviewed 44 state and 64 local EAS plans,” and “[o]f the plans reviewed,
only one state plan addressed the needs of people with disabilities; one local plan provided procedures for
sending text; and one local plan provided a note on captioning.”793 The Wireless RERC reiterated that
“including explicit instructions on notifying people with disabilities would vastly improve the
accessibility and receipt of emergency information,” adding that “[p]eriodic updates at least every other
year should be required, as officers change, stations are bought and sold, technologies are converged, and
emerging technologies are adopted.”794
262. The RERC-TA asserted, “With respect to the tension between Part 11 and Section 79.2, we
note that it would cease to exist if accessible textual descriptions, which are supported by CAP in the
[description field], were not effectively stripped from the alert during the conversion from CAP to
SAME.”795 The RERC-TA added that “the rules in Part 11 would merely need to stipulate that the TV
station is allowed, and required, to make complete use of the textual information in the video crawl.”796
263. The RERC-TA acknowledged that although “it is premature to consider speech-to-text
systems in lieu of authoring and propagating accessible textual information, . . . they should not be ruled
out for future use.”797 The RERC-TA added, “Such systems’ accuracy leaves much to be desired – even
95 to 98% accuracy is not sufficient if it results in critical information being lost.”798 The RERC-TA
offered that “[a] more catastrophic, scenario is a speech recognition error that goes undetected and results
in a fundamental alteration of the meaning of the message – such as seeking shelter directly in the path of
a tornado, rather than away from it.”799 The RERC-TA maintained that “[i]n such cases, no information
is greatly preferable to incorrect information, because the person with a disability at least is aware that he
or she needs to obtain additional information.”800


790 Id.
791 Id.
792 Id. at 4.
793 Id.
794 Id. at 5.
795 RERC-TA Comments at 15.
796 Id.
797 Id. at 16-17.
798 Id. at 17.
799 Id.
800 Id.
91

Federal Communications Commission

FCC 12-7

264. According to Timm, “[a]llowing CAP-derived-text-only visual crawls is in the public
interest, and will rectify the FCC Rule 79.2 conflict.”801 Timm also commented, “Current EAS CAP units
do not include [speech-to-text] capability, and this would appear to be a complicated hardware upgrade
not a simple software solution.”802 Timm added, “While all current EAS CAP units on the market offer
[text-to-speech], the Commission should think long and hard before considering mandating [speech-to-
text].”803 BWWG suggested that “CAP easily has within it the capability of being able to tell devices at
cable systems and television stations anything that can be envisioned to enhance accessibility.”804
BWWG added, “All we have to do is tell audio, video display devices for radio, television and cable what
[to] do with CAP messages to best benefit all the disabled communities.”805
265. Decision. As detailed in section IV.B(5) of this order, we are requiring EAS Participants
to meet the video display requirements in section 11.51(d), (g)(3), (h)(3), and (j)(2) by using the enhanced
text in the CAP message, as outlined in the ECIG Implementation Guide. Because CAP alert message
originators will be capable of providing a transcript of the audio message, we agree with commenters that
this action helps harmonize the EAS rules with the requirements of section 79.2. As indicated above, the
ECIG Implementation Guide procedure for displaying enhanced CAP text has already been adopted by
industry and FEMA and has been implemented in integrated CAP-capable EAS devices and at least some
component intermediary devices.806 Moreover, the record suggests widespread adoption by EAS
Participants.807 We also observe that requiring display of enhanced CAP text will provide an incentive for
state and local alert message originators to deploy and use CAP-based alert systems. Providing state and
local alert message originators with a conduit for the transmission of transcripts of the audio portions of
their messages should encourage alert originators to craft messages that will provide accessible alerting
for persons with hearing and vision disabilities. As we discussed in section IV.B(5) of this order, CAP
compliant EAS equipment is already capable of delivering the enhanced text, if provided by the alert
initiator. Thus, we do not believe that this rule revision will have any significant cost impact on EAS
Participants.
7.

Proposals Beyond the Scope of this Order

266. A few commenters addressed issues that were not raised in the Third FNPRM. Because
the issues raised were not raised in the Third FNPRM, we will not resolve them in this order. We will,
however, briefly address them in turn.
267. Adrienne Abbott-Gutierrez (Gutierrez) stated that the current exemption in section
11.11(b) from deploying EAS equipment for analog and digital stations that operate as satellite stations or
repeaters of hub stations should be eliminated in favor of requiring deployment of CAP-enabled
equipment.808 Section 11.11(b) exempts such stations from having to deploy EAS equipment because


801 Timm Comments at 12. See also Trilithic Comments at 9 (“TV Broadcasters are required to provide the same
information in both the audio and video portions of their programming, and CAP text finally provides a mechanism
for this.”).
802 Id.
803 Id.
804 BWWG Comments at 66.
805 Id.
806 See supra para. 139.
807 See supra para. 132-137.
808 Adrienne Abbott-Gutierrez Comments, EB Docket 04-296 (filed July 18, 2011) at 2-3 (Gutierrez Comments).
92

Federal Communications Commission

FCC 12-7

these stations do not originate any programming but instead rebroadcast 100 percent of the hub station’s
programming.809 Gutierrez observed, “The full power radio and TV originating stations are not licensed
to serve these remote areas [served by the satellite or translator stations]’,” and thus “EAS activations that
are heard on translators and ‘hub’ stations are meant for communities hundreds of miles away from the
community served by the translator or ‘hub’ station.”810 According to Gutierrez, “[i]n some cases, the
rural audience is hearing activations that were issued for other states and in different time zones.”811
Gutierrez continued that, “[w]ith the CAP technology, new EAS equipment could be added to translators
or transmitters for ‘hub’ stations and activations could be issued by the local emergency managers for
their specific areas without interrupting programming in other communities.”812
268. Translators and satellite stations currently are exempted by section 11(b) from having to
install EAS equipment because such equipment is not necessary for them to carry a Presidential alert,
which they receive from their hub station. The Third FNPRM did not seek comment on the use of
translators or satellite stations to carry state or local alerts, whether in the CAP or SAME formats, and
thus the record is insufficient for us to resolve this issue in this order. We note, however, that in response
to the November 9, 2011, Nationwide EAS Test, the Commission will be receiving data on the use of
translators to provide the EAN to areas that a full power radio or television signal cannot reach, which
may provide insight on this matter. It would be premature to take any actions with respect to the use of
translators until after we have reviewed and processed the test data from the November 9, 2011,
Nationwide EAS Test.
269. There were a number of comments on the manner in which State EAS plans are filed, as
well as how State Emergency Communications Committees (SECC), the entities that draft most State
EAS plans, are chosen and trained.
270. The Wireless RERC argued that “[the] rules should make it mandatory to develop and file
state and/or local EAS plans and establish guidelines for the structure of plans.”813
271. In addition, some commenters suggested that the Commission define the role and makeup
of SECCs. Timm observed, “With the now increased responsibilities of updating the State EAS Plan to
include CAP distribution, actually building those state CAP networks, interfacing to the FEMA IPAWS
network, bringing the governor and designees up to speed on originating CAP messages, and
incorporating any changes brought on by the proposed new rules, it would seem if these are intended
duties of the SECC that the SECC should be more evident in Part 11.”814 Timm added, “While the
structure and composition of the SECC is probably best left to each state to determine, general guidance,
and at least acknowledgement of the SECC’s existence, seem appropriate.”815 Timm proposed various


809 See 47 C.F.R. § 11.11(b) (specifying that “[a]nalog and digital broadcast stations that operate as satellites or
repeaters of a hub station (or common studio or control point if there is no hub station) and rebroadcast 100 percent
of the programming of the hub station (or common studio or control point) may satisfy [their EAS-related]
requirements . . . through the use of a single set of EAS equipment at the hub station (or common studio or control
point) which complies with §§ 11.32 and 11.33”).
810 Gutierrez Comments at 3.
811 Id.
812 Id.
813 Wireless RERC Comments at 4.
814 Timm Comments at 15.
815 Id. at 16.
93

Federal Communications Commission

FCC 12-7

rules covering SECC governance and responsibilities for inclusion into Part 11.816
272. NSBA acknowledged that “neither FEMA nor the FCC have the authority to compel the
various states and territories to fund, implement, or train their personnel for the conversion to CAP, or
even to assist in the updating of statewide EAS plans” but nonetheless suggested that the Commission
“re-establish[] its commitment to, and the authority and stature of, the [SECCs].”817 NSBA proposed
various requirements concerning the establishment, governance structure, and responsibilities that SECCs
would have to follow to be “recognized” by the Commission.818
273. BWWG stated, “[we] find[] it ironic that while the Commission and its Enforcement
Bureau rely on local and state volunteer efforts to write plans that are the basis of assessing compliance,
yet do not currently spell out who appoints members of local and state committees, nor what the proper
composition of these committees should be to best meet the needs of the EAS.”819 In this regard, BWWG
observed that the Commission has not established a process by which Local Emergency Communications
Committee and SECC Chairs may update their committees, particularly procedures for processing
resignations and new appointments.820 BWWG maintained that “the Commission needs to address this
vital issue as part of the Part 11 re-write.”821
274. We note at the outset that NSBA is correct that the states implement EAS on a voluntary
basis. We note, however, that State EAS Plans, if filed, must comply with FCC guidelines and be
approved by the Chief of the Public Safety and Homeland Security Bureau.822 Although a review of the
manner in which state EAS Plans are constructed and filed is outside of the purview of this rulemaking,
we note that the efficacy of State EAS Plans was very much an issue in the November 9, 2011,
Nationwide EAS Test. The Commission will be receiving data on how well state EAS Plans operated as
a tool for the effective propagation of the EAN. We believe that it would be premature to take any action
with respect to state EAS Plans until after we have reviewed and processed the test data from the
November 9, 2011, Nationwide EAS Test.
275. Commenters also raised concerns with the Part 11 test requirements. BWWG proposed
that we eliminate the Required Weekly Test (RWT) specified in section 11.61(a)(2). According to
BWWG, “under the LP system, other stations monitor very few non-LP stations” and thus “the alert tones
do not trigger anything ‘down the line.’”823 BWWG added, “The only benefit that the RWT would have
is to ensure the station’s ENDEC actually works once a week.”824 BWWG also observed that “RWTs do
not contain any audio message as would a real EAS message” and “broadcast, television and cable
entities with very few exceptions never issue real EAS warnings.”825 BWWG proposed that the RWT be
rep[laced by “a full regional test, based on the current [RMT] on an area-wide or statewide basis,” which


816 See id. at 16-17.
817 NSBA Comments at 5.
818 See id. at 5-8.
819 BWWG Comments at 10 (internal footnote omitted).
820 Id.
821 Id.
822 See 47 C.F.R. § 11.21.
823 Id. at 6.
824 Id.
825 Id. at 6-7.
94

Federal Communications Commission

FCC 12-7

BWWG indicated “could be done on a different schedule than RMT’s, perhaps every three weeks,
perhaps twice a month, with the SECC collecting information as to the performance of the system.”826
276. Evans stated that “Part 11 might define the purpose of the RMT so that our state plans can
build a better model to test the system itself.”827 In this regard, Evans indicated, “[b]asically the question
is, “Who should start the RMT?”828 Evans further indicated, “In my opinion the RMT is designed to test
the system from start to finish . . . from the daisy chain, to the state relay, and even NOAA Weather
Radio.”829
277. Testing the EAS was not an issue raised in the Third FNPRM. We note, however, that the
EAS testing regime may be examined as part of the Commission’s review of the November 9, 2011,
Nationwide EAS Test data. We will therefore defer any consideration of EAS testing matters until after
we have completed that review.

V.

PROCEDURAL MATTERS

A.

Accessible Formats

278. To request materials in accessible formats for people with disabilities (Braille, large print,
electronic files, audio format), send an e-mail to fcc504@fcc.gov or call the Consumer & Governmental
Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (TTY).

B.

Regulatory Flexibility Analysis

279. As required by the Regulatory Flexibility Act of 1980, see 5 U.S.C. § 603, the Commission
has prepared a Final Regulatory Flexibility Analysis (FRFA) of possible significant economic impact on
small entities of the policies and rules addressed in this document. The FRFA is set forth in Appendix B.

C.

Paperwork Reduction Act Analysis

280. This Fifth Report and Order adopts modified information collection requirements subject
to the Paperwork Reduction Act of 1995 (PRA), Public Law 104-13. These modified requirements will
be submitted to the Office of Management and Budget (OMB) for review under Section 3507(d) of the
PRA. OMB, the general public, and other Federal agencies are invited to comment on the new or
modified information collection requirements contained in this proceeding. In addition, we note that
pursuant to the Small Business Paperwork Relief Act of 2002, Public Law 107-198, see 44 U.S.C.
3506(c)(4), we previously sought specific comment on how the Commission might further reduce the
information collection burden for small business concerns with fewer than 25 employees.
281. In this present document, we have assessed the effects of revisions to current Part 11
reporting, recordkeeping, or compliance requirements as set forth in this Fifth Report and Order, and do
not expect these revisions to alter the recordkeeping burden of any EAS Participants to any appreciable
degree. There are no results specific to businesses with fewer than 25 employees.

D.

Congressional Review Act

282. The Commission will send a copy of this Fifth Report and Order to Congress and the


826 Id. at 7.
827 Evans Comments at 4.
828 Id.
829 Id.
95

Federal Communications Commission

FCC 12-7

Government Accountability Office pursuant to the Congressional Review Act (“CRA”), see 5 U.S.C. §
801(a)(1)(A).

VI.

ORDERING CLAUSES

283. Accordingly, IT IS ORDERED that pursuant to sections 1, 2, 4(i), 4(o), 301, 303(r),
303(v), 307, 309, 335, 403, 624(g),706, and 715 of the Communications Act of 1934, as amended, 47
U.S.C. §§ 151, 152, 154(i), 154(o), 301, 303(r), 303(v), 307, 309, 335, 403, 544(g), 606, and 615, this
Fifth Report and Order IS ADOPTED.
284. IT IS FURTHER ORDERED that the rules adopted herein WILL BECOME EFFECTIVE
thirty (30) days after the date of their publication in the Federal Register, except for any reporting,
recordkeeping or third-party collection requirements that contain new or modified information
collections. Those rules will become effective on the date specified in a Commission notice published in
the Federal Register announcing their approval under the Paperwork Reduction Act by the Office of
Management and Budget.
285. IT IS FURTHER ORDERED that the Commission’s Consumer and Governmental Affairs
Bureau, Reference Information Center, SHALL SEND a copy of this Fifth Report and Order, including
the Regulatory Flexibility Analysis, to the Chief Counsel for Advocacy of the Small Business
Administration.
FEDERAL COMMUNICATIONS COMMISSION
Marlene H. Dortch
Secretary
96

Federal Communications Commission

FCC 12-7

APPENDIX A

Final Rules

For the reasons discussed in the preamble, the Federal Communications Commission amends 47 CFR
Part 11 to read as follows:

PART 11 – EMERGENCY ALERT SYSTEM (EAS)

1.
The authority citation for part 11 continues to read as follows:
Authority: 47 U.S.C. 151, 154 (i) and (o), 303(r), 544(g) and 606.
2.
Revise § 11.2 to read as follows:
§ 11.2 Definitions.
The definitions of terms used in part 11 are:
(a) Emergency Action Notification (EAN). The Emergency Action Notification is the notice to all EAS
Participants and to the general public that the EAS has been activated for a national emergency. EAN
messages that are formatted in the EAS Protocol (specified in §11.31) are sent from a government
origination point to broadcast stations and other entities participating in the PEP system, and are
subsequently disseminated via EAS Participants. Dissemination arrangements for EAN messages that are
formatted in the EAS Protocol (specified in §11.31) at the State and local levels are specified in the State
and Local Area plans (defined at §11.21). A national activation of the EAS for a Presidential message
with the Event code EAN as specified in §11.31 must take priority over any other message and preempt it
if it is in progress.
(b) Primary Entry Point (PEP) System. The PEP system is a nationwide network of broadcast stations and
other entities connected with government activation points. It is used to distribute EAS messages that are
formatted in the EAS Protocol (specified in §11.31), including the EAN and EAS national test messages.
FEMA has designated some of the nation’s largest radio broadcast stations as PEPs. The PEPs are
designated to receive the Presidential alert from FEMA and distribute it to local stations.
(c) Local Primary One (LP-1). The LP-1 is a radio or TV station that acts as a key EAS monitoring
source. Each LP-1 station must monitor its regional PEP station and a back-up source for Presidential
messages.
(d) EAS Participants. Entities required under the Commission’s rules to comply with EAS rules, e.g.,
analog radio and television stations, and wired and wireless cable television systems, DBS, DTV,
SDARS, digital cable and DAB, and wireline video systems.
(e) Wireline Video System. The system of a wireline common carrier used to provide video programming
service.
(f) Participating National (PN). PN stations are broadcast stations that transmit EAS National, state, or
local EAS messages to the public.
(g) National Primary (NP). Stations that are the primary entry point for Presidential messages delivered
by FEMA. These stations are responsible for broadcasting a Presidential alert to the public and to State
Primary stations within their broadcast range.
97

Federal Communications Commission

FCC 12-7

(h) State Primary (SP). Stations that are the entry point for State messages, which can originate from the
Governor or a designated representative.
(i) Intermediary Device. An intermediary device is a stand-alone device that carries out the functions of
monitoring for, receiving and/or acquiring, and decoding EAS messages formatted in the Common
Alerting Protocol (CAP) in accordance with §11.56, and converting such messages into a format that can
be inputted into a separate EAS decoder, EAS encoder, or unit combining such decoder and encoder
functions, so that the EAS message outputted by such separate EAS decoder, EAS encoder, or unit
combining such decoder and encoder functions, and all other functions attendant to processing such EAS
message, comply with the requirements in this part.
3.
Amend § 11.11 by revising paragraphs (a) and (d) to read as follows:
§ 11.11 The Emergency Alert System (EAS).
(a) The EAS is composed of analog radio broadcast stations including AM, FM, and Low-power FM
(LPFM) stations; digital audio broadcasting (DAB) stations, including digital AM, FM, and Low-power
FM stations; Class A television (CA) and Low-power TV (LPTV) stations; digital television (DTV)
broadcast stations, including digital CA and digital LPTV stations; analog cable systems; digital cable
systems which are defined for purposes of this part only as the portion of a cable system that delivers
channels in digital format to subscribers at the input of a Unidirectional Digital Cable Product or other
navigation device; wireline video systems; wireless cable systems which may consist of Broadband Radio
Service (BRS), or Educational Broadband Service (EBS) stations; DBS services, as defined in §25.701(a)
of this chapter (including certain Ku-band Fixed-Satellite Service Direct to Home providers); and
SDARS, as defined in §25.201 of this chapter. These entities are referred to collectively as EAS
Participants in this part, and are subject to this part, except as otherwise provided herein. At a minimum
EAS Participants must use a common EAS protocol, as defined in §11.31, to send and receive emergency
alerts, and comply with the requirements set forth in §11.56, in accordance with the following tables:

Table 1:

Analog and Digital Broadcast Station Equipment Deployment
Requirements

EAS
AM &
Digital AM
Analog &
Analog
DTV
Analog &
Analog & Digital
equipment
FM
& FM
Digital FM
&
Digital Class
LPTV
requirement
Class D
Digital
A TV
LPFM
EAS decoder1
Y
Y
Y
Y
Y
Y
Y
EAS encoder
Y
Y
N
N
Y
Y
N
Audio
Y
Y
Y
Y
Y
Y
Y
message
Video
N/A
N/A
N/A
N/A
Y
Y
Y
message
1 EAS Participants may comply with the obligations set forth in §11.56 to decode and convert CAP-formatted messages into EAS
Protocol-compliant messages by deploying an Intermediary Device, as specified in §11.56(b).

Analog Cable Systems

98

Federal Communications Commission

FCC 12-7

Analog cable systems are subject to the requirements in Table 2 below. Analog cable systems serving
fewer than 5,000 subscribers from a headend may either provide the National level EAS message on all
programmed channels including the required testing, or comply with the requirements in Table 2.

Table 2: Analog Cable System Equipment Deployment Requirements

EAS equipment requirement
≥5,000 subscribers
<5,000 subscribers
EAS decoder1
Y
Y
EAS encoder
Y
Y2
Audio and Video EAS Message on all
channels
Y
N
Video interrupt and audio alert message
on all channels;3 Audio and Video
EAS message on at least one channel
N
Y
1 EAS Participants may comply with the obligations set forth in §11.56 to decode and convert CAP-formatted messages into EAS
Protocol-compliant messages by deploying an Intermediary Device, as specified in §11.56(b).
2 Analog cable systems serving <5,000 subscribers are permitted to operate without an EAS encoder if they install an FCC-certified
decoder.
3 The Video interrupt must cause all channels that carry programming to flash for the duration of the EAS emergency message. The
audio alert must give the channel where the EAS messages are carried and be repeated for the duration of the EAS message. [
Note: Programmed channels do not include channels used for the transmission of data such as interactive games.]

Wireless Cable Systems (BRS/EBS Stations)

Wireless cable systems are subject to the requirements in Table 3 below. Wireless cable systems serving
fewer than 5,000 subscribers from a single transmission site must either provide the National level EAS
message on all programmed channels including the required testing, or comply with the requirements in
Table 3.

Table 3: Wireless Cable System Equipment Deployment Requirements

EAS equipment requirement
≥5,000 subscribers
<5,000 subscribers
EAS decoder1
Y
Y
EAS encoder
Y
Y2
Audio and Video EAS Message on all
channels3
Y
N
Video interrupt and audio alert message
on all channels;4 Audio and Video EAS
message on at least one channel
N
Y
1 EAS Participants may comply with the obligations set forth in §11.56 to decode and convert CAP-formatted messages into EAS
Protocol-compliant messages by deploying an Intermediary Device, as specified in §11.56(b).
2 Wireless cable systems serving <5,000 subscribers are permitted to operate without an EAS encoder if they install an FCC-
certified decoder.
99

Federal Communications Commission

FCC 12-7

3 All wireless cable systems may comply with this requirement by providing a means to switch all programmed channels to a
predesignated channel that carries the required audio and video EAS messages.
4 The Video interrupt must cause all channels that carry programming to flash for the duration of the EAS emergency message. The
audio alert must give the channel where the EAS messages are carried and be repeated for the duration of the EAS message.
[Note: Programmed channels do not include channels used for the transmission of data services such as Internet.]

Digital Cable Systems and Wireline Video Systems

Digital cable systems and Wireline Video Systems must comply with the requirements in Table 4 below.
Digital cable systems and Wireline Video Systems serving fewer than 5,000 subscribers from a headend
must either provide the National level EAS message on all programmed channels including the required
testing, or comply with the requirements in Table 4.

Table 4: Digital Cable System and Wireline Video System Equipment Deployment

Requirements

EAS equipment requirement
≥5,000 subscribers
<5,000 subscribers
EAS decoder1
Y
Y
EAS encoder
Y
Y2
Audio and Video EAS Message on all
channels3
Y
N
Video interrupt and audio alert message
on all channels;4 Audio and Video EAS
message on at least one channel
N
Y
1 EAS Participants may comply with the obligations set forth in §11.56 to decode and convert CAP-formatted messages into EAS
Protocol-compliant messages by deploying an Intermediary Device, as specified in §11.56(b).
2 Digital cable systems and wireline video systems serving <5,000 subscribers are permitted to operate without an EAS encoder if
they install an FCC-certified decoder.
3 All digital cable systems and wireline video systems may comply with this requirement by providing a means to switch all
programmed channels to a predesignated channel that carries the required audio and video EAS messages.
4 The Video interrupt must cause all channels that carry programming to flash for the duration of the EAS emergency message. The
audio alert must give the channel where the EAS messages are carried and be repeated for the duration of the EAS message.
[Note: Programmed channels do not include channels used for the transmission of data services such as Internet access.]
SDARS and DBS
EAS equipment requirement
SDARS
DBS
EAS decoder1
Y
Y
EAS encoder
Y
Y
Audio message on all channels2
Y
Y
Video message on all channels2
N/A
Y
100

Federal Communications Commission

FCC 12-7

1 EAS Participants may comply with the obligations set forth in §11.56 to decode and convert CAP-formatted messages into EAS
Protocol-compliant messages by deploying an Intermediary Device, as specified in §11.56(b).
2 All SDARS and DBS providers may comply with this requirement by providing a means to switch all programmed channels to a
predesignated channel that carries the required audio and video EAS messages or by any other method that ensures that viewers of
all channels receive the EAS message.
* * * * *
(d) Local franchise authorities may use any EAS codes authorized by the FCC in any agreements.
* * * * *
4.
§ 11.12 [Removed].
Remove § 11.12.
5.
§ 11.13 [Removed].
Remove § 11.13.
6.
§ 11.14 [Removed].
Remove § 11.14.
7.
Amend § 11.18 by removing paragraph (f) as follows:
§ 11.18 EAS Designations.
* * * * *
(f) [removed]
8.
§ 11.19 [Removed].
Remove § 11.19.
9.
Amend § 11.21 by revising paragraph (a) to read as follows:
§ 11.21 State and Local Area plans and FCC Mapbook.
* * * * *
(a) The State EAS Plan contains procedures for State emergency management and other State officials,
the NWS, and EAS Participants’ personnel to transmit emergency information to the public during a State
emergency using the EAS. State EAS Plans should include a data table, in computer readable form,
clearly showing monitoring assignments and the specific primary and backup path for emergency action
notification (“EAN”) messages that are formatted in the EAS Protocol (specified in §11.31), from the
PEP to each station in the plan. If a state’s emergency alert system is capable of initiating EAS messages
formatted in the Common Alerting Protocol (CAP), its State EAS Plan must include specific and detailed
information describing how such messages will be aggregated and distributed to EAS Participants within
the state, including the monitoring requirements associated with distributing such messages.
101

Federal Communications Commission

FCC 12-7

* * * * *
10.
Amend § 11.31 by revising paragraphs (c), (e) and (f) to read as follows:
§ 11.31 EAS protocol.
* * * * *
(c) The EAS protocol, including any codes, must not be amended, extended or abridged without FCC
authorization. The EAS protocol and message format are specified in the following representation.
Examples are provided in FCC Public Notices.
[PREAMBLE]ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-(one second pause)
[PREAMBLE]ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-(one second pause)
[PREAMBLE]ZCZC-ORG-EEE-PSSCCC+TTTT-JJJHHMM-LLLLLLLL-(at least a one second
pause)
(transmission of 8 to 25 seconds of Attention Signal)
(transmission of audio, video or text messages)
(at least a one second pause)
[PREAMBLE]NNNN (one second pause)
[PREAMBLE]NNNN (one second pause)
[PREAMBLE]NNNN (at least one second pause)
[PREAMBLE] This is a consecutive string of bits (sixteen bytes of AB hexadecimal [8 bit byte
10101011]) sent to clear the system, set AGC and set asynchronous decoder clocking cycles. The
preamble must be transmitted before each header and End of Message code.
ZCZC--This is the identifier, sent as ASCII characters ZCZC to indicate the start of ASCII code.
ORG--This is the Originator code and indicates who originally initiated the activation of the EAS. These
codes are specified in paragraph (d) of this section.
EEE--This is the Event code and indicates the nature of the EAS activation. The codes are specified in
paragraph (e) of this section. The Event codes must be compatible with the codes used by the NWS
Weather Radio Specific Area Message Encoder (WRSAME).
PSSCCC--This is the Location code and indicates the geographic area affected by the EAS alert. There
may be 31 Location codes in an EAS alert. The Location code uses the codes described in the American
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”). Each state is assigned an SS number as specified in paragraph (f) of this section. Each county
and some cities are assigned a CCC number. A CCC number of 000 refers to an entire State or Territory.
102

Federal Communications Commission

FCC 12-7

P defines county subdivisions as follows: 0 = all or an unspecified portion of a county, 1 = Northwest, 2 =
North, 3 = Northeast, 4 = West, 5 = Central, 6 = East, 7 = Southwest, 8 = South, 9 = Southeast. Other
numbers may be designated later for special applications. The use of county subdivisions will probably be
rare and generally for oddly shaped or unusually large counties. Any subdivisions must be defined and
agreed to by the local officials prior to use.
+TTTT--This indicates the valid time period of a message in 15 minute segments up to one hour and then
in 30 minute segments beyond one hour; i.e., +0015, +0030, +0045, +0100, +0430 and +0600.
JJJHHMM--This is 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).
LLLLLLLL--This is the identification of the EAS Participant, NWS office, etc., transmitting or
retransmitting the message. These codes will be automatically affixed to all outgoing messages by the
EAS encoder.
NNNN--This is the End of Message (EOM) code sent as a string of four ASCII N characters.
* * * * *
(e) The following Event (EEE) codes are presently authorized:
Nature of Activation
Event Codes
National Codes (Required):
Emergency Action Notification (National only)
EAN
National Information Center
NIC
National Periodic Test
NPT
Required Monthly Test
RMT
Required Weekly Test
RWT
State and Local Codes (Optional):
Administrative Message
ADR
Avalanche Warning
AVW1
Avalanche Watch
AVA1
Blizzard Warning
BZW
Child Abduction Emergency
CAE1
Civil Danger Warning
CDW1
Civil Emergency Message
CEM
Coastal Flood Warning
CFW1
Coastal Flood Watch
CFA1
Dust Storm Warning
DSW1
Earthquake Warning
EQW1
Evacuation Immediate
EVI
Fire Warning
FRW1
Flash Flood Warning
FFW
Flash Flood Watch
FFA
Flash Flood Statement
FFS
Flood Warning
FLW
Flood Watch
FLA
Flood Statement
FLS
Hazardous Materials Warning
HMW1
High Wind Warning
HWW
High Wind Watch
HWA
Hurricane Warning
HUW
Hurricane Watch
HUA
Hurricane Statement
HLS
103

Federal Communications Commission

FCC 12-7

Law Enforcement Warning
LEW1
Local Area Emergency
LAE1
Network Message Notification
NMN1
911 Telephone Outage Emergency
TOE1
Nuclear Power Plant Warning
NUW1
Practice/Demo Warning
DMO
Radiological Hazard Warning
RHW1
Severe Thunderstorm Warning
SVR
Severe Thunderstorm Watch
SVA
Severe Weather Statement
SVS
Shelter in Place Warning
SPW1
Special Marine Warning
SMW1
Special Weather Statement
SPS
Tornado Warning
TOR
Tornado Watch
TOA
Tropical Storm Warning
TRW1
Tropical Storm Watch
TRA1
Tsunami Warning
TSW
Tsunami Watch
TSA
Volcano Warning
VOW1
Winter Storm Warning
WSW
Winter Storm Watch
WSA
1 Effective May 16, 2002, analog radio and television broadcast stations, analog cable systems and wireless cable systems may
upgrade their existing EAS equipment to add these event codes on a voluntary basis until the equipment is replaced. All models of
EAS equipment manufactured after August 1, 2003 must be capable of receiving and transmitting these event codes. EAS
Participants that install or replace their EAS equipment after February 1, 2004 must install equipment that is capable of receiving
and transmitting these event codes.
(f) The State, Territory and Offshore (Marine Area) ANSI number codes (SS) are as follows. County
ANSI numbers (CCC) are contained in the State EAS Mapbook.
ANSI#
State:
AL
01
AK
02
AZ
04
AR
05
CA
06
CO
08
CT
09
DE
10
DC
11
FL
12
GA
13
HI
15
ID
16
IL
17
IN
18
IA
19
KS
20
KY
21
LA
22
ME
23
MD
24
MA
25
MI
26
MN
27
MS
28
104

Federal Communications Commission

FCC 12-7

MO
29
MT
30
NE
31
NV
32
NH
33
NJ
34
NM
35
NY
36
NC
37
ND
38
OH
39
OK
40
OR
41
PA
42
RI
44
SC
45
SD
46
TN
47
TX
48
UT
49
VT
50
VA
51
WA
53
WV
54
WI
55
WY
56
Terr.:
AS
60
FM
64
GU
66
MH
68
MH
68
PR
72
PW
70
UM
74
78
Offshore (Marine Areas)1:
Eastern North Pacific Ocean, and
along U.S. West Coast from
Canadian border to Mexican border
57
North Pacific Ocean near Alaska,
and along Alaska coastline, including
the Bering Sea and the Gulf of
Alaska
58
Central Pacific Ocean, including
Hawaiian waters
59
South Central Pacific Ocean,
including American Samoa waters
61
Western Pacific Ocean, including
Mariana Island waters
65
Western North Atlantic Ocean, and
along U.S. East Coast, from
Canadian border south to Currituck
Beach Light, N.C
73
Western North Atlantic Ocean, and
along U.S. East Coast, south of
Currituck Beach Light, N.C.,
following the coastline into Gulf of
Mexico to Bonita Beach, FL.,
75
105

Federal Communications Commission

FCC 12-7

including the Caribbean
Gulf of Mexico, and along the U.S.
Gulf Coast from the Mexican border
to Bonita Beach, FL
77
Lake Superior
91
Lake Michigan
92
Lake Huron
93
Lake St. Clair
94
Lake Erie
96
Lake Ontario
97
St. Lawrence River above St. Regis
98
1 Effective May 16, 2002, analog radio and television broadcast stations, analog cable systems and wireless cable systems may
upgrade their existing EAS equipment to add these marine area location codes on a voluntary basis until the equipment is replaced.
All models of EAS equipment manufactured after August 1, 2003, must be capable of receiving and transmitting these marine area
location codes. EAS Participants that install or replace their EAS equipment after February 1, 2004, must install equipment that is
capable of receiving and transmitting these location codes.
11.
Amend § 11.32 by revising paragraphs (a)(2), (a)(3) and 11.32(a)(9)(iv) as follows:
§ 11.32 EAS Encoder.
(a) * * *
(2) Inputs. The encoder shall have at least one input port used for audio messages and at least one input
port used for data messages.
(3) Outputs. The encoder shall have at least one audio output port and at least one data output port.
* * *
(9) * * *
(iv) Time Period for Transmission of Tones. The encoder shall have timing circuitry that automatically
generates the two tones simultaneously for a time period of 8 seconds.
* * * * *
12.
Amend § 11.33 by revising paragraph (a) introductory text, (a)(1), (a)(4), (a)(7) and (a)(11),
removing paragraph (b), and re-designating paragraph (c) as new paragraph (b) to read as follows:
§ 11.33 EAS Decoder.
(a) An EAS Decoder must at a minimum be capable of providing the EAS monitoring functions described
in §11.52, decoding EAS messages formatted in accordance with the EAS Protocol described in §11.31,
and converting Common Alerting Protocol (CAP)-formatted EAS messages into EAS alert messages that
comply with the EAS Protocol, in accordance with §11.56(a)(2), with the exception that the CAP-related
monitoring and conversion requirements set forth in §§11.52(d)(2) and 11.56(a)(2) can be satisfied via an
Intermediary Device, as specified in §11.56(b), provided that all other requirements set forth in this part
are met. An EAS Decoder also must be capable of the following minimum specifications:
(1) Inputs. Decoders must have the capability to receive at least two audio inputs from EAS monitoring
assignments, and at least one data input. The data input(s) may be used to monitor other communications
modes such as Radio Broadcast Data System (RBDS), NWR, satellite, public switched telephone
network, or any other source that uses the EAS protocol.
106

Federal Communications Commission

FCC 12-7

* * * * *
(4) Display and logging. For received alert messages formatted in both the EAS Protocol and Common
Alerting Protocol, a visual message shall be developed from any valid header codes for tests and national
activations and any preselected header codes received. The message shall at a minimum include the
Originator, Event, Location, the valid time period of the message and the local time the message was
transmitted. The message shall be in the primary language of the EAS Participant and be fully displayed
on the decoder and readable in normal light and darkness. The visual message developed from received
alert messages formatted in the Common Alerting Protocol must conform to the requirements in
§§11.51(d), (g)(3), (h)(3), and (j)(2) of this part. All existing and new models of EAS decoders
manufactured after August 1, 2003 must provide a means to permit the selective display and logging of
EAS messages containing header codes for state and local EAS events. Effective May 16, 2002, analog
radio and television broadcast stations, analog cable systems and wireless cable systems may upgrade
their decoders on an optional basis to include a selective display and logging capability for EAS messages
containing header codes for state and local events. EAS Participants that install or replace their decoders
after February 1, 2004 must install decoders that provide a means to permit the selective display and
logging of EAS messages containing header codes for state and local EAS events.
* * * * *
(7) Outputs. Decoders shall have at least one data port where received valid EAS header codes and
received preselected header codes are available, at least one audio port that is capable of monitoring each
decoder audio input, and an internal speaker to enable personnel to hear audio from each input.
* * * * *
(11) A header code with the EAN Event code specified in §11.31(c) that is received through any of the
audio or data inputs must override all other messages.
(b) Decoders shall be capable of operation within the tolerances specified in this section as well as those
in §11.32(b), (c) and (d).
13.
Amend § 11.34 by revising paragraph (d) as follows:
§ 11.34 Acceptability of the equipment.
* * * * *
(d) Manufacturers must include instructions and information on how to install, operate and program an
EAS Encoder, EAS Decoder, or combined unit and a list of all State and county ANSI numbers with each
unit sold or marketed in the U.S.
14.
Amend § 11.35 by revising paragraphs (a) and (b) as follows:
§ 11.35 Participation in EAS.
(a) EAS Participants are responsible for ensuring that EAS Encoders, EAS Decoders, Attention Signal
generating and receiving equipment, and Intermediate Devices used as part of the EAS to decode and/or
encode messages formatted in the EAS Protocol and/or the Common Alerting Protocol are installed so
that the monitoring and transmitting functions are available during the times the stations and systems are
107

Federal Communications Commission

FCC 12-7

in operation. Additionally, EAS Participants must determine the cause of any failure to receive the
required tests or activations specified in §11.61(a)(1) and (a)(2). Appropriate entries indicating reasons
why any tests were not received must be made in the broadcast station log as specified in §§73.1820 and
73.1840 of this chapter for all broadcast streams and cable system records as specified in §§76.1700,
76.1708, and 76.1711 of this chapter. All other EAS Participants must also keep records indicating
reasons why any tests were not received and these records must be retained for two years, maintained at
the EAS Participant’s headquarters, and made available for public inspection upon reasonable request.
(b) If an EAS Encoder, EAS Decoder or Intermediary Device used as part of the EAS to decode and/or
encode messages formatted in the EAS Protocol and/or the Common Alerting Protocol becomes
defective, the EAS Participant may operate without the defective equipment pending its repair or
replacement for 60 days without further FCC authority. Entries shall be made in the broadcast station log,
cable system records, and records of other EAS Participants, as specified in paragraph (a) of this rule,
showing the date and time the equipment was removed and restored to service. For personnel training
purposes, the required monthly test script must still be transmitted even though the equipment for
generating the EAS message codes, Attention Signal and EOM code is not functioning.
* * * * *

15.
Amend § 11.41 by removing paragraphs (a)-(c) and adding introductory text as follows:
§ 11.41 Participation in EAS.
All EAS Participants specified in §11.11 are categorized as Participating National (PN) sources, and must
have immediate access to an EAS Operating Handbook.
(a) [removed]
(b) [removed]
(c) [removed]
16.
§ 11.42 [Removed].
Remove § 11.42.
17.
§ 11.44 [Removed].
Remove § 11.44.
18.
Amend § 11.51 by revising paragraphs (a), (c), (d), (g)(3), (h)(3), (i) introductory text, (j)
introductory text, (j)(2), and paragraph (m) introductory text to read as follows:
§ 11.51 EAS code and Attention Signal Transmission requirements.
(a) Analog and digital broadcast stations must transmit, either automatically or manually, national level
EAS messages and required tests by sending the EAS header codes, Attention Signal, emergency message
and End of Message (EOM) codes using the EAS Protocol. The Attention Signal must precede any
emergency audio message.
* * * * *
108

Federal Communications Commission

FCC 12-7

(c) All analog and digital radio and television stations shall transmit EAS messages in the main audio
channel. All DAB stations shall also transmit EAS messages on all audio streams. All DTV broadcast
stations shall also transmit EAS messages on all program streams.
(d) Analog and digital television broadcast stations shall transmit a visual message containing the
Originator, Event, Location and the valid time period of an EAS message. Effective June 30, 2012, visual
messages derived from CAP-formatted EAS messages shall contain the Originator, Event, Location and
the valid time period of the message and shall be constructed in accordance with §3.6 of the EAS-CAP
Industry Group’s (ECIG) Recommendations for a CAP EAS Implementation Guide, Version 1.0 (May
17, 2010), except that if the EAS Participant has deployed an Intermediary Device to meet its CAP-
related obligations, this requirement shall be effective June 30, 2015, and until such date shall be subject
to the general requirement to transmit a visual message containing the Originator, Event, Location and the
valid time period of the EAS message. If the message is a video crawl, it shall be displayed at the top of
the television screen or where it will not interfere with other visual messages.
* * * * *
(g) * * *
(3) Shall transmit a visual EAS message on at least one channel. The visual message shall contain the
Originator, Event, Location, and the valid time period of the EAS message. Effective June 30, 2012,
visual messages derived from CAP-formatted EAS messages shall contain the Originator, Event, Location
and the valid time period of the message and shall be constructed in accordance with §3.6 of the EAS-
CAP Industry Group’s (ECIG) Recommendations for a CAP EAS Implementation Guide, Version 1.0
(May 17, 2010), except that if the EAS Participant has deployed an Intermediary Device to meet its CAP-
related obligations, this requirement shall be effective June 30, 2015, and until such date shall be subject
to the general requirement to transmit a visual message containing the Originator, Event, Location and the
valid time period of the EAS message. If the visual message is a video crawl, it shall be displayed at the
top of the subscriber’s television screen or where it will not interfere with other visual messages.
* * * * *
(h) * * *
(3) Shall transmit the EAS visual message on all downstream channels. The visual message shall contain
the Originator, Event, Location, and the valid time period of the EAS message. Effective June 30, 2012,
visual messages derived from CAP-formatted EAS messages shall contain the Originator, Event, Location
and the valid time period of the message and shall be constructed in accordance with §3.6 of the EAS-
CAP Industry Group’s (ECIG) Recommendations for a CAP EAS Implementation Guide, Version 1.0
(May 17, 2010), except that if the EAS Participant has deployed an Intermediary Device to meet its CAP-
related obligations, this requirement shall be effective June 30, 2015, and until such date shall be subject
to the general requirement to transmit a visual message containing the Originator, Event, Location and the
valid time period of the EAS message. If the visual message is a video crawl, it shall be displayed at the
top of the subscriber’s television screen or where it will not interfere with other visual messages.
* * * * *
(i) SDARS licensees shall transmit national audio EAS messages on all channels in the same order
specified in paragraph (a) of this section.
(1) * * *
(2) * * *
* * * * *
109

Federal Communications Commission

FCC 12-7

(j) DBS providers shall transmit national audio and visual EAS messages on all channels in the same
order specified in paragraph (a) of this section.
(1) * * *
(2) The visual message shall contain the Originator, Event, Location, and the valid time period of the EAS
message. Effective June 30, 2012, visual messages derived from CAP-formatted EAS messages shall
contain the Originator, Event, Location and the valid time period of the message and shall be constructed
in accordance with §3.6 of the EAS-CAP Industry Group’s (ECIG) Recommendations for a CAP EAS
Implementation Guide, Version 1.0 (May 17, 2010), except that if the EAS Participant has deployed an
Intermediary Device to meet its CAP-related obligations, this requirement shall be effective June 30,
2015, and until such date shall be subject to the general requirement to transmit a visual message
containing the Originator, Event, Location and the valid time period of the EAS message. If the visual
message is a video crawl, it shall be displayed at the top of the subscriber’s television screen or where it
will not interfere with other visual messages.
(3) * * *
* * * * *
(m) EAS Participants are required to transmit all received EAS messages in which the header code
contains the Event codes for Emergency Action Notification (EAN) and Required Monthly Test (RMT),
and when the accompanying location codes include their State or State/county. These EAS messages shall
be retransmitted unchanged except for the LLLLLLLL-code which identifies the EAS Participant
retransmitting the message. See §11.31(c). If an EAS source originates an EAS message with the Event
codes in this paragraph, it must include the location codes for the State and counties in its service area.
When transmitting the required weekly test, EAS Participants shall use the event code RWT. The location
codes are the state and county for the broadcast station city of license or system community or city. Other
location codes may be included upon approval of station or system management. EAS messages may be
transmitted automatically or manually.
* * * * *
19.
Amend § 11.52 by revising paragraphs (a), (d), (e) introductory text and (e)(2) to read as follows:
§ 11.52 EAS code and Attention Signal Monitoring requirements.
(a) EAS Participants must be capable of receiving the Attention Signal required by §11.31(a)(2) and
emergency messages of other broadcast stations during their hours of operation. EAS Participants must
install and operate during their hours of operation, equipment that is capable of receiving and decoding,
either automatically or manually, the EAS header codes, emergency messages and EOM code, and which
complies with the requirements in §11.56.
* * * * *
(d) EAS Participants must comply with the following monitoring requirements:
(1) With respect to monitoring for EAS messages that are formatted in accordance with the EAS Protocol,
EAS Participants must monitor two EAS sources. The monitoring assignments of each broadcast station
and cable system and wireless cable system are specified in the State EAS Plan and FCC Mapbook. They
are developed in accordance with FCC monitoring priorities.
110

Federal Communications Commission

FCC 12-7

(2) With respect to monitoring EAS messages formatted in accordance with the specifications set forth in
§11.56(a)(2), EAS Participants’ EAS equipment must interface with the Federal Emergency Management
Agency’s Integrated Public Alert and Warning System (IPAWS) to enable (whether through “pull”
interface technologies, such as Really Simple Syndication (RSS) and Atom Syndication Format
(ATOM), or “push” interface technologies, such as instant messaging and e-mail) the distribution of
Common Alert Protocol (CAP)-formatted alert messages from the IPAWS system to EAS Participants’
EAS equipment.
(3) Monitoring specifications associated with the distribution of CAP-formatted alert messages by state
alert message systems are described in the State EAS Plan, as set forth in §11.21(a).
(4) If the required EAS message sources cannot be received, alternate arrangements or a waiver may be
obtained by written request to the Chief, Public Safety and Homeland Security Bureau. In an emergency,
a waiver may be issued over the telephone with a follow up letter to confirm temporary or permanent
reassignment.
(5) The management of EAS Participants shall determine which header codes will automatically interrupt
their programming for State and Local Area emergency situations affecting their audiences.
(e) EAS Participants are required to interrupt normal programming either automatically or manually when
they receive an EAS message in which the header code contains the Event codes for Emergency Action
Notification (EAN) or the Required Monthly Test (RMT) for their State or State/county location.
(1) * * *
(2) Manual interrupt of programming and transmission of EAS messages may be used. EAS messages
with the EAN Event code must be transmitted immediately and Monthly EAS test messages within 60
minutes. All actions must be logged and recorded as specified in §§11.35(a) and 11.54(a)(3). Decoders
must be programmed for the EAN Event header code and the RMT and RWT Event header codes (for
required monthly and weekly tests), with the appropriate accompanying State and State/county location
codes.
20.
§ 11.53 [Removed].
Remove § 11.53.
21.
Amend § 11.54 by deleting paragraphs (a), (b)(1)-(8), (b)(10), (b)(12) and (c), and revising and
re-designating paragraphs (b) introductory text, (b)(9), (b)(11), (b)(13), (d) and (e) as paragraphs (a)
introductory text, (a)(1), (a)(2), (a)(3), (b) and (c) to read as follows:
§ 11.54 EAS operation during a National Level emergency.
(a) Immediately upon receipt of an EAN message, EAS Participants must comply with the following
requirements, as applicable:
(1) Analog and digital broadcast stations may transmit their call letters and analog cable systems, digital
cable systems and wireless cable systems may transmit the names of the communities they serve during
an EAS activation. State and Local Area identifications must be given as provided in State and Local
Area EAS Plans.
(2) Analog and digital broadcast stations are exempt from complying with §§73.62 and 73.1560 of this
111

Federal Communications Commission

FCC 12-7

chapter (operating power maintenance) while operating under this part.
(3) The time of receipt of the EAN shall be entered by analog and digital broadcast stations in their logs
(as specified in §§73.1820 and 73.1840 of this chapter), by analog and digital cable systems in their
records (as specified in §76.1711 of this chapter), by subject wireless cable systems in their records (as
specified in §21.304 of this chapter), and by all other EAS Participants in their records as specified in
§11.35(a).
(b) EAS Participants originating emergency communications under this section shall be considered to
have conferred rebroadcast authority, as required by section 325(a) of the Communications Act of 1934,
47 U.S.C. 325(a), to other EAS Participants.
(c) During a national level EAS emergency, EAS Participants may transmit in lieu of the EAS audio feed
an audio feed of the President’s voice message from an alternative source, such as a broadcast network
audio feed.
22.
Amend § 11.55 by revising paragraph (a) introductory text, paragraph (c) introductory text, and
paragraph (c)(3), (c)(4), (c)(7) and (c)(8) and add new paragraph (d) to read as follows:
§ 11.55 EAS operation during a State or Local Area emergency.
(a) The EAS may be activated at the State and Local Area levels by EAS Participants at their discretion
for day-today emergency situations posing a threat to life and property. Examples of natural emergencies
which may warrant state EAS activation are: Tornadoes, floods, hurricanes, earthquakes, heavy snows,
icing conditions, widespread fires, etc. Man-made emergencies warranting state EAS activation may
include: toxic gas leaks or liquid spills, widespread power failures, industrial explosions, and civil
disorders.
(1) * * *
(2) * * *
* * * * *
(c) Immediately upon receipt of a State or Local Area EAS message that has been formatted in the EAS
Protocol, EAS Participants participating in the State or Local Area EAS must do the following:
(1) * * *
(2) * * *
(3) Participating National (PN) sources monitor the Local Area LP sources for instructions.
(4) EAS Participants participating in the State or Local Area EAS must discontinue normal programming
and follow the procedures in the State and Local Area Plans. Analog and digital television broadcast
stations must transmit all EAS announcements visually and aurally as specified in §11.51(a) through (e)
and 73.1250(h) of this chapter, as applicable; analog cable systems, digital cable systems, and wireless
cable systems must transmit all EAS announcements visually and aurally as specified in §11.51(g) and
(h); and DBS providers must transmit all EAS announcements visually and aurally as specified in
§11.51(j). EAS Participants providing foreign language programming should transmit all EAS
announcements in the same language as the primary language of the EAS Participant.
112

Federal Communications Commission

FCC 12-7

* * * * *
(7) The times of the above EAS actions must be entered in the EAS Participants’ records as specified in
§§11.35(a) and 11.54(a)(3).
(8) Use of the EAS codes or Attention Signal automatically grants rebroadcast authority as specified in
§11.54(b).
* * * * *
(d) Immediately upon receipt of a State or Local Area EAS message that has been formatted in the
Common Alerting Protocol, EAS Participants must do the following:
(1) EAS Participants participating in the State or Local Area EAS must follow the procedures in for
processing such messages in the State and Local Area Plans.
(2) Analog and digital television broadcast stations must transmit all EAS announcements visually and
aurally as specified in §11.51(a) through (e) and 73.1250(h) of this chapter, as applicable; analog cable
systems, digital cable systems, and wireless cable systems must transmit all EAS announcements visually
and aurally as specified in §11.51(g) and (h); and DBS providers must transmit all EAS announcements
visually and aurally as specified in §11.51(j). EAS Participants providing foreign language programming
should transmit all EAS announcements in the same language as the primary language of the EAS
Participant.
(3) Resume normal operations upon conclusion of the message.
(4) The times of the above EAS actions must be entered in the EAS Participants’ records as specified in
§§11.35(a) and 11.54(a)(3).
23.
Amend § 11.56 by revising the section heading and the section to read as follows:
§ 11.56 Obligation to Process CAP-Formatted EAS Messages.
(a) On or by June 30, 2012, EAS Participants must have deployed operational equipment that is capable
of the following:
(1) Acquiring EAS alert messages in accordance with the monitoring requirements in §11.52(d)(2);
(2) Converting EAS alert messages that have been formatted pursuant to the (i) Organization for the
Advancement of Structured Information Standards (OASIS) Common Alerting Protocol Version 1.2 (July
1, 2010), and (ii) Common Alerting Protocol, v. 1.2 USA Integrated Public Alert and Warning System
Profile Version 1.0 (Oct. 13, 2009), into EAS alert messages that comply with the EAS Protocol, such
that the Preamble and EAS Header Codes, audio Attention Signal, audio message, and Preamble and EAS
End of Message (EOM) Codes of such messages are rendered equivalent to the EAS Protocol (set forth in
§11.31), in accordance with the technical specifications governing such conversion process set forth in the
EAS-CAP Industry Group’s (ECIG) Recommendations for a CAP EAS Implementation Guide, Version
1.0 (May 17, 2010) (except that any and all specifications set forth therein related to using text-to-speech
technology and gubernatorial “must carry” shall not be followed). The Director of the Federal Register
approves this incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. Copies of
these standards can be inspected at the Federal Communications Commission, 445 12th Street, SW.,
Washington, DC (Reference Information Center). The OASIS Common Alerting Protocol Version 1.2
113

Federal Communications Commission

FCC 12-7

(July 1, 2010) and Common Alerting Protocol, v. 1.2 USA Integrated Public Alert and Warning System
Profile Version 1.0 (Oct. 13, 2009), also are available for viewing and retrieval on the OASIS web site at:
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf and http://docs.oasis-
open.org/emergency/cap/v1.2/ipaws-profile/v1.0/cap-v1.2-ipaws-profile-v1.0.pdf
, respectively. The
ECIG Recommendations for a CAP EAS Implementation Guide, Version 1.0 (May 17, 2010) is available
for viewing and retrieval on the ECIG web site at: http://www.eas-cap.org/ECIG-CAP-to-
EAS_Implementation_Guide-V1-0.pdf
; and
(3) Processing such converted messages in accordance with the other sections of this part.
(b) EAS Participants may comply with the requirements of this section by deploying an Intermediary
Device. If an EAS Participant elects to meet the requirements of this section by deploying an
Intermediary Device, it shall be required to construct visual messages from CAP-formatted EAS
messages in accordance with §3.6 of the EAS-CAP Industry Group’s (ECIG) Recommendations for a
CAP EAS Implementation Guide, Version 1.0 (May 17, 2010), as set forth in §§11.51(d), (g)(3), (h)(3),
and (j)(2) of this part, on or by June 30, 2015.
24.
Amend § 11.61 by revising paragraphs (a) introductory text, (a)(1)(i), (a)(2)(ii) and (b) as
follows:
§ 11.61 Tests of EAS procedures.
(a) EAS Participants shall conduct tests at regular intervals, as specified in paragraphs (a)(1) and (a)(2) of
this section. Additional tests may be performed anytime. EAS activations and special tests may be
performed in lieu of required tests as specified in paragraph (a)(4) of this section.
(1) * * * * *
(i) Tests in odd numbered months shall occur between 8:30 a.m. and local sunset. Tests in even numbered
months shall occur between local sunset and 8:30 a.m. They will originate from Local or State Primary
sources. The time and script content will be developed by State Emergency Communications Committees
in cooperation with affected EAS Participants. Script content may be in the primary language of the EAS
Participant. These monthly tests must be transmitted within 60 minutes of receipt by EAS Participants in
an EAS Local Area or State. Analog and digital class D non-commercial educational FM, analog and
digital LPFM stations, and analog and digital LPTV stations are required to transmit only the test script.
* * * * *
(2) * * *
(ii) DBS providers, analog and digital class D non-commercial educational FM stations, analog and
digital LPFM stations, and analog and digital LPTV stations are not required to transmit this test but must
log receipt, as specified in §11.35(a) and 11.54(a)(3).
* * * * *
(b) Entries shall be made in EAS Participant records, as specified in §11.35(a) and 11.54(a)(3).
114

Federal Communications Commission

FCC 12-7

APPENDIX B

Final Regulatory Flexibility Analysis

1.
As required by the Regulatory Flexibility Act of 1980, as amended (RFA),1 an Initial
Regulatory Flexibility Analysis (IRFA) was incorporated into the Third Further Notice of Proposed
Rulemaking (Third FNPRM) in this proceeding.2 The Commission sought written comment on the
proposals in the Third FNPRM, including comment on the IRFA. This Final Regulatory Flexibility
Analysis (FRFA) conforms to the RFA.3

A.

Need for, and Objectives of, the Fifth Report and Order

2.
This Fifth Report and Order adopts changes to the Commission’s Part 11 rules governing
the Emergency Alert System (EAS) to codify the obligation to process alert messages formatted in the
Common Alerting Protocol (CAP)4 and to streamline and clarify these rules generally to enhance their
effectiveness.5
3.
Specifically, the Fifth Report and Order:
·
Clarifies that the scope of the CAP-related obligations addressed in this order are limited to
those necessary to ensure that CAP-formatted alert messages distributed to EAS Participants
will be converted into and processed in the same way as messages formatted in the current
EAS Protocol.
·
Amends § 11.56 of the Commission’s rules to require EAS Participants to convert CAP-
formatted EAS messages into messages that comply with the EAS Protocol requirements,
following the procedures for such conversion set forth in the EAS-CAP Industry Group’s
(ECIG) ECIG Implementation Guide.6
·
Amends § 11.52 of the Commission’s rules to require that EAS Participants monitor FEMA’s
Integrated Public Alert and Warning System (IPAWS) for federal CAP-formatted alert
messages using whatever interface technology is appropriate.
·
Clarifies that the language from the Second Report and Order (Second Report and Order) in


1 See 5 U.S.C. § 603. The RFA, see 5 U.S.C. §§ 601-612, has been amended by the Small Business Regulatory
Enforcement Fairness Act of 1996 (SBREFA), Pub. L. No. 104-121, Title II, 110 Stat. 857 (1996).
2 See Review of 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, ET Docket No. 04-296, Third Further Notice of Proposed Rulemaking, 26 FCC
Rcd 8149 (2011) (Third FNPRM).
3 See 5 U.S.C. § 604.
4 See Third FNPRM, 26 FCC Rcd 8157-60, paras. 11-15, for a desription of CAP.
5 See Appendix B for a description of the rules the Commission adopted in the Fifth Report and Order.
6 See 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 web site
at: http://eas-cap.org/documents.htm).
115

Federal Communications Commission

FCC 12-7

this docket7 regarding receipt of CAP-formatted messages from Next Generation EAS
delivery systems was intended to put EAS Participants on notice that, should FEMA adopt
technical standards covering delivery of CAP-formatted messages to EAS Participants over
specific platforms, such as satellite systems, EAS Participants would ultimately need to
configure their systems to be able to interface with such systems to meet their existing
obligation to process CAP-formatted messages.
·
Permits EAS Participants to use intermediary devices to meet their CAP-related obligations,
provided that all intermediary devices must provide that capability of utilizing the enhanced
text in a CAP message to meet the visual display requirements in section 11.51(d), (g)(3),
(h)(3), and (j)(2) of the Commission’s rules, as set forth in section 3.6 of the ECIG
Implementation Guide, by June 30, 2015.
·
Declines to make any changes to the minimum encoder requirements set forth in section
11.32(a) regarding CAP-to-EAS Protocol conversion.
·
Revises the input and output configuration requirements in §§ 11.32(a)(2) and (a)(3) of the
Commission’s rules to require at least one audio port and at least one data port, and to delete
references to RS232-C and 1200 baud rate.
·
Revises the minimum requirements for decoders in section 11.33(a) to include the capability
to decode CAP-formatted messages and convert them into EAS Protocol-compliant
messages, as set forth in section 11.56 and clarifies that this requirement can be met through
the deployment of an intermediary device.
·
Revises the input and output configuration requirements in §§ 11.33(a)(1) and (a)(7) of the
Commission’s rules to require at least one audio port and at least one data port, and to delete
references to RS232-C and 1200 baud rate.
·
Amends section 11.33(a)(4) of the Commission’s rules to include selective display and
logging of text that was compiled from CAP-formatted messages be added to the EAS device
log.
·
Declines to revise § 11.33(a)(10) of the Commission’s rules to require processing of CAP-
formatted message by default when duplicate messages are received in both the EAS Protocol
and CAP formats, as recommended in the Communications Security, Reliability, and
Interoperability Council (CSRIC) Final Report (CSRIC Final Report).8


7 See Review of 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, Second Report and Order and Further Notice of Proposed Rulemaking, 22 FCC
Rcd 13275 (2007) (Second Report and Order).
8 On October 7, 2010, CSRIC adopted a final report recommending changes to the Part 11 rules governing EAS
Participants’ EAS CAP obligation. See Third FNPRM, 26 FCC Rcd 8149, 8160, para. 17 (citing CSRIC, Working
Group 5A, CAP Introduction, Final Report, available at
http://www.fcc.gov/pshs/docs/csric/CSRIC%205A%20Working%20Group.pdf) (CSRIC Final Report)). As
explained in the Third FNPRM, CSRIC was chartered by the Commission, pursuant to the Federal Advisory
Committee Act, 5 U.S.C. Appendix 2, to provide recommendations to the Commission to ensure optimal security,
(continued….)
116

Federal Communications Commission

FCC 12-7

·
Revises section 11.33(a)(11) of the Commission’s rules to ensure that Emergency Action
Notification (EAN) messages receive priority over all other EAS messages, regardless of
whether the EAN message was received via the audio port or data port, or was formatted in
EAS Protocol or CAP.
·
Declines to revise section 11.1 of the Commission’s rules to include new CAP-related alert
originators, as recommended in the CSRIC Final Report.
·
Revises the text of § 11.11(a) of the Commission’s rules to include as a minimum
requirement compliance with the CAP-related requirements in § 11.56 of the Commission’s
rules, and to delete the reference to “analog television broadcast stations.”
·
Revises the equipment deployment tables in § 11.11 of the Commission’s rules by adding a
footnote to the “EAS decoder” entries in the tables to clarify that the obligation to receive and
translate CAP-formatted messages may be met by deploying an intermediary device, and by
deleting the date references in the equipment deployment tables in section 11.11 (as well as
cross-references to these dates in other sections of Part 11, such as section 11.51(c) and (d)),
along with the entry for two-tone encoders. Declines to incorporate references to the
monitoring requirements in section 11.52 in section 11.11.
·
Declines to revise the language of § 11.20 of the Commission’s rules to require a specific
reference to CAP alerts, CAP relay networks, or CAP monitoring requirements.
·
Revises § 11.21(a) of the Commission’s rules to make clear that the State EAS Plans specify
the monitoring assignments and the specific primary and backup path for EAS Protocol-
formatted EANs and that the monitoring requirements for CAP-formatted EANs are set forth
in section 11.52, and to make clear that to the extent a state may distribute CAP-formatted
EANs to EAS Participants via its state alerting system, its State EAS Plan must include
specific and detailed information describing how such messages will be aggregated and
delivered, just as it must for state CAP-formatted non-EAN messages.
·
Defers taking any action with respect to revising § 11.21(c) of the Commission’s rules until,
at a minimum, review of the test data received from EAS Participants as a result of the
November 9, 2011, nationwide EAS test has been completed.9
·
Declines to revise the language in § 11.31(a) of the Commission’s rules to better reflect
CAP’s capabilities.
·
Amends sections 11.35(a) and (b) of the Commission’s rules to clarify that these subsections
apply to all equipment used as part of the EAS, including all equipment that performs the
functions of decoding and encoding messages formatted in the EAS Protocol and the
Common Alerting Protocol.
(Continued from previous page)


reliability, operability, and interoperability of communications systems, including public safety,
telecommunications, and media communications systems. See id. at 8159-60, para. 16.
9 See Public Safety and Homeland Security Bureau Announces that First Ever Nationwide Diagnostic Test of the
Emergency Alert System Will Occur on November 9, 2011 at 2 PM EST
, Public Notice, 26 FCC Rcd 8398 (PSHSB
2011).
117

Federal Communications Commission

FCC 12-7

·
Declines to revise § 11.45 of the Commission’s rules to prohibit CAP messages lacking
“Actual” status indicators, as recommended in the CSRIC Final Report.
·
Declines to revise § 11.51 of the Commission’s rules to require EAS Participants to transmit
(or “render”) a CAP-compliant message, as recommended in the CSRIC Final Report.
·
Amends sections 11.51(d), (g)(3), (h)(3), and (j)(2) of the Commission’s rules to require EAS
Participants to derive the visual display elements, including the originator, event, location and
the valid time period of the EAS message, from the CAP text data as described in section 3.6
of the ECIG Implementation Guide (intermediary devices must provide for such functionality
by June 30, 2015).
·
Declines to revise section 11.54(b) of the Commission's rules to mandate that CAP-formatted
messages be broadcast only if the scope of the alert is “Public,” and to include IPAWS
monitoring, as recommended in the CSRIC Final Report.
·
Clarifies that it would be inappropriate to adopt any form of blanket exemption from the basic
obligations of monitoring for, receiving, and processing CAP-formatted messages, but
concludes that the physical unavailability of broadband Internet service offers a presumption
in favor of a waiver.
·
Incorporates conformance with the ECIG Implementation Guide into the Commission’s
existing certification scheme.
·
Amends section 11.55 of the Commission’s rules to eliminate the requirement that EAS
Participants receive and transmit CAP-formatted messages initiated by state governors.
·
Amends the procedures for processing EANs set forth in § 11.54 of the Commission’s rules
and related Part 11 rule sections so that EAS Participants process EANs like any other EAS
message, only on a mandatory and priority basis. To effect these changes, deletes §§ 11.16,
11.42, 11.44, 11.53, 11.54(a), (b)(1)-(8), (b)(10), (b)(12) and (c) of the Commission’s rules,
as well as the Emergency Action Termination event code.
·
Eliminates Non-Participating National (NN) deleting references to status, and in this regard,
revise sections 11.18, 11.41, 11.54, and 11.55 of the Commission’s rules to remove
references to NN status, and deletes section 11.19 altogether.
·
Seeks comment on whether the option for EAS Participants to manually process EANs (but
not state or local EAS messages) should be eliminated.
·
Defers taking any action with respect to the EAS Operating Handbook until, at a minimum,
review of the test data received from EAS Participants as a result of the November 9, 2011,
nationwide EAS test has been completed.
·
Revises section 11.11(a) of the Commission’s rules to remove the references therein to
“participating broadcast networks, cable networks and program suppliers; and other entities
and industries operating on an organized basis during emergencies at the National, State and
local levels.”
·
Revises the definition for LP-1 station in § 11.2(b) of the Commission’s rules to reflect that
118

Federal Communications Commission

FCC 12-7

these stations can be a radio or TV station.
·
Deletes § 11.14 of the Commission’s rules.
·
Revises section 11.2(a) to delete the numerical reference to the actual number of Primary
Entry Point (PEP) stations in existence, and to clarify that PEP stations distribute EAS
messages in accordance with the EAS Protocol requirements in section 11.31.
·
Deletes section 11.13 of the Commission's rules and folds the definition for the EAN
currently in section 11.13 into section 11.2.
·
Revises §§ 11.31 and 11.34(d) of the Commission’s rules to replace the references to the
Federal Information Processing Standard (FIPS) numbers with references to the American
National Standards Institute (ANSI) Codes INCITS 31.200x (Formerly FIPS 6-4), Codes for
the Identification of Counties and Equivalent Entities of the United States, its Possessions,
and Insular Areas standard.
·
Revises the analog and digital broadcast station equipment deployment table in § 11.11(a) of
the Commission’s rules so that “LPFM” and “LPTV” are identified with the columns listing
the requirements for those categories, and revises §§ 11.61(a)(1)(i) and 11.61(a)(2)(ii) of the
Commission’s rules to include “LPFM” stations.
·
Revises section 11.32(a)(9)(iv) of the Commission’s rules to limit the duration of the
Attention Signal to no more than eight seconds, and deletes as obsolete sections 11.33(b) and
11.12.
·
Clarifies that EAS Participants may relay, for the benefit of downstream monitoring stations,
messages they received that did not include an EOM within the reset time limit set on their
decoder.
·
Declines to revise § 11.33(a)(3)(ii) of the Commission’s rules to eliminate the requirement to
delete messages upon expiration of their time periods, thus allowing EAS Participants to air
alert messages after expiration of the effective time period set by the alert message originator.
·
Reiterates that the Commission lacks the authority to raise or distribute funds for EAS-related
purposes and therefore cannot provide training for state and local emergency managers.
·
Observes that the decision to require EAS Participants to meet the video display requirements
in section 11.51(d), (g)(3), (h)(3), and (j)(2) by using the enhanced text in the CAP message,
as outlined in the ECIG Implementation Guide, will help harmonize the EAS rules with the
requirements of section 79.2.
·
Identifies several proposals raised in the comments submitted in response to the Third
FNPRM
as being outside the scope of the Third FNPRM and thus not taken up by the Fifth
Report and Order
.

B.

Summary of Significant Issues Raised by Public Comments in Response to the IRFA

4.
SBA filed no comments in this proceeding, and there were no other comments
specifically addressed to the IRFA.

C.

Description and Estimate of the Number of Small Entities to Which Rules Will

119

Federal Communications Commission

FCC 12-7

Apply

5.
The RFA directs agencies to provide a description of and, where feasible, an estimate of,
the number of small entities that may be affected by the rules adopted herein.10 The RFA generally
defines the term “small entity” as having the same meaning as the terms “small business,” “small
organization,” and “small governmental jurisdiction.”11 In addition, the term “small business” has the
same meaning as the term “small business concern” under the Small Business Act.12 A “small business
concern” is one which: (1) is independently owned and operated; (2) is not dominant in its field of
operation; and (3) satisfies any additional criteria established by the Small Business Administration
(SBA).13
6.
Small Businesses, Small Organizations, and Small Governmental Jurisdictions. Our
action may, over time, affect small entities that are not easily categorized at present. We therefore
describe here, at the outset, three comprehensive, statutory small entity size standards.14 First,
nationwide, there are a total of approximately 27.5 million small businesses, according to the SBA.15 In
addition, a “small organization” is generally “any not-for-profit enterprise which is independently owned
and operated and is not dominant in its field.”16 Nationwide, as of 2007, there were approximately
1,621,315 small organizations.17 Finally, the term “small governmental jurisdiction” is defined generally
as “governments of cities, towns, townships, villages, school districts, or special districts, with a
population of less than fifty thousand.”18 Census Bureau data for 2011 indicate that there were 89,476
local governmental jurisdictions in the United States.19 We estimate that, of this total, as many as 88, 506
entities may qualify as “small governmental jurisdictions.”20 Thus, we estimate that most governmental


10 5 U.S.C. § 604(a)(3).
11 5 U.S.C. § 601(6).
12 5 U.S.C. § 601(3) (incorporating by reference the definition of “small-business concern” in the Small Business
Act, 15 U.S.C. § 632). Pursuant to 5 U.S.C. § 601(3), the statutory definition of a small business applies “unless an
agency, after consultation with the Office of Advocacy of the Small Business Administration and after opportunity
for public comment, establishes one or more definitions of such term which are appropriate to the activities of the
agency and publishes such definition(s) in the Federal Register.” 5 U.S.C. § 601(3).
13 15 U.S.C. § 632.
14 See 5 U.S.C. §§ 601(3)–(6).
15 See SBA, Office of Advocacy, “Frequently Asked Questions,” web.sba.gov/faqs (last visited May 6,2011;
figures are from 2009).
16 5 U.S.C. § 601(4).
17 INDEPENDENT SECTOR, THE NEW NONPROFIT ALMANAC & DESK REFERENCE (2010).
18 5 U.S.C. § 601(5).
19 U.S. CENSUS BUREAU, STATISTICAL ABSTRACT OF THE UNITED STATES: 2011, Table 427 (2007)
20 The 2007 U.S Census data for small governmental organizations are not presented based on the size of the
population in each such organization. There were 89, 476 small governmental organizations in 2007. If we assume
that county, municipal, township and school district organizations are more likely than larger governmental
organizations to have populations of 50,000 or less, , the total of these organizations is 52,125. If we make the same
assumption about special districts, and also assume that special districts are different from county, municipal,
township, and school districts, in 2007 there were 37,381 special districts. Therefore, of the 89,476 small
governmental organizations documented in 2007, as many as 89,506 may be considered small under the applicable
standard. This data may overestimate the number of such organizations that has a population of 50,000 or less. U.S.
(continued….)
120

Federal Communications Commission

FCC 12-7

jurisdictions are small.
7.
Television Broadcasting. The SBA defines a television broadcasting station as a small
business if such station has no more than $14.0 million in annual receipts.21 Business concerns included
in this industry are those “primarily engaged in broadcasting images together with sound.”22 The
Commission has estimated the number of licensed commercial television stations to be 1,390.23
According to Commission staff review of the BIA Kelsey Inc. Media Access Pro Television Database
(BIA) as of January 31, 2011, 1,006 (or about 78 percent) of an estimated 1,298 commercial television
stations24 in the United States have revenues of $14 million or less and, thus, qualify as small entities
under the SBA definition. The Commission has estimated the number of licensed noncommercial
educational (NCE) television stations to be 391.25 We note, however, that, in assessing whether a
business concern qualifies as small under the above definition, business (control) affiliations26 must be
included. Our estimate, therefore, likely overstates the number of small entities that might be affected by
our action, because the revenue figure on which it is based does not include or aggregate revenues from
affiliated companies. The Commission does not compile and otherwise does not have access to
information on the revenue of NCE stations that would permit it to determine how many such stations
would qualify as small entities.
8.
In addition, an element of the definition of “small business” is that the entity not be
dominant in its field of operation. We are unable at this time to define or quantify the criteria that would
establish whether a specific television station is dominant in its field of operation. Accordingly, the
estimate of small businesses to which rules may apply do not exclude any television station from the
definition of a small business on this basis and are therefore over-inclusive to that extent. Also, as noted,
an additional element of the definition of “small business” is that the entity must be independently owned
and operated. We note that it is difficult at times to assess these criteria in the context of media entities
and our estimates of small businesses to which they apply may be over-inclusive to this extent.
9.
Radio Stations. The rules and policies adopted in the Fifth Report and Order potentially
(Continued from previous page)


CENSUS BUREAU, STATISTICAL ABSTRACT OF THE UNITED STATES 2011, Tables 427, 426 ( Data cited
therein are from 2007).
21 See 13 C.F.R. § 121.201, NAICS Code 515120 (2007).
22 Id. This category description continues, “These establishments operate television broadcasting studios and
facilities for the programming and transmission of programs to the public. These establishments also produce or
transmit visual programming to affiliated broadcast television stations, which in turn broadcast the programs to the
public on a predetermined schedule. Programming may originate in their own studios, from an affiliated network, or
from external sources.” Separate census categories pertain to businesses primarily engaged in producing
programming. See Motion Picture and Video Production, NAICS code 512110; Motion Picture and Video
Distribution, NAICS Code 512120; Teleproduction and Other Post-Production Services, NAICS Code 512191; and
Other Motion Picture and Video Industries, NAICS Code 512199.
23 See News Release, “Broadcast Station Totals as of December 31, 2010,” 2011 WL 484756 (F.C.C.) (dated Feb.
11, 2011) (“Broadcast Station Totals”); also available at
http://www.fcc.gov/Daily_Releases/Daily_Business/2011/db0211/DOC-304594A1.pdf.
24 We recognize that this total differs slightly from that contained in Broadcast Station Totals, supra, note 15;
however, we are using BIA’s estimate for purposes of this revenue comparison.
25 See Broadcast Station Totals, supra, note 15.
26 “[Business concerns] are affiliates of each other when one concern controls or has the power to control the other
or a third party or parties controls or has to power to control both.” 13 C.F.R. § 121.103(a)(1).
121

Federal Communications Commission

FCC 12-7

will apply to all AM and FM radio broadcasting applicants, and proponents for new FM allotments, who
qualify for the Tribal Priority adopted in the First Report and Order in this proceeding. The “Radio
Stations” Economic Census category “comprises establishments primarily engaged in broadcasting aural
programs by radio to the public. Programming may originate in their own studio, from an affiliated
network, or from external sources.”27 The SBA has established a small business size standard for this
category, which is: such firms having $7 million or less in annual receipts.28 According to BIA/Kelsey,
MEDIA Access Pro Database on January 13, 2011, 10,820 (97%) of 11,127 commercial radio stations
have revenue of $7 million or less. Therefore, the majority of such entities are small entities. We note,
however, that in assessing whether a business concern qualifies as small under the above size standard,
business affiliations must be included.29 In addition, to be determined to be a “small business,” the entity
may not be dominant in its field of operation.30 We note that it is difficult at times to assess these criteria
in the context of media entities, and our estimate of small businesses may therefore be over-inclusive.
10.
Cable and Other Program Distribution. Since 2007, these services have been defined
within the broad economic census category of Wired Telecommunications Carriers; that category is
defined as follows: “This industry comprises establishments primarily engaged in operating and/or
providing access to transmission facilities and infrastructure that they own and/or lease for the
transmission of voice, data, text, sound, and video using wired telecommunications networks.
Transmission facilities may be based on a single technology or a combination of technologies.”31 The
SBA has developed a small business size standard for this category, which is: all such firms having 1,500
or fewer employees.32 According to Census Bureau data for 2007, there were a total of 955 firms in this
previous category that operated for the entire year.33 Of this total, 939 firms had employment of 999 or
fewer employees, and 16 firms had employment of 1000 employees or more.34 Thus, under this size
standard, the majority of firms can be considered small entities.
11.
Cable System Operators (Rate Regulation Standard). The Commission has developed its
own small business size standards, for the purpose of cable rate regulation. Under the Commission’s
rules, a “small cable company” is one serving 400,000 or fewer subscribers, nationwide.35 Industry data


27 http://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=515112&search=2007%20NAICS%20Search.
28 NAICs Code 515112, 13 C.F.R 121.201.
29 15. USC 632.
30 Id.
31 U.S. Census Bureau, 2007 NAICS Definitions, “517110 Wired Telecommunications Carriers” (partial definition),
http://www.census.gov/naics/2007/def/ND517110.HTM#N517110.
32 13 C.F.R. § 121.201, NAICS code 517110 (2007).
33 U.S. Census Bureau, 2007 Economic Census, Subject Series: Information, Table 5, Employment Size of Firms for
the United States: 2007, NAICS code 5171102 (issued Nov. 2010).
34 See id.
35 See 47 C.F.R. § 76.901(e). The Commission determined that this size standard equates approximately to a size
standard of $100 million or less in annual revenues. See Implementation of Sections of the 1992 Cable Television
Consumer Protection and Competition Act: Rate Regulation
, MM Docket Nos. 92-266, 93-215, Sixth Report and
Order and Eleventh Order on Reconsideration, 10 FCC Rcd 7393, 7408 para. 28 (1995).
122

Federal Communications Commission

FCC 12-7

indicate that, of 1,076 cable operators nationwide, all but eleven are small under this size standard.36 In
addition, under the Commission’s rules, a “small system” is a cable system serving 15,000 or fewer
subscribers.37 Industry data indicate that, of 7,208 systems nationwide, 6,139 systems have under 10,000
subscribers, and an additional 379 systems have 10,000-19,999 subscribers.38 Thus, under this second
size standard, most cable systems are small and may be affected by rules adopted pursuant to the Notice.
12.
Cable System Operators (Telecom Act Standard). The Act also contains a size standard
for small cable system operators, which is “a cable operator that, directly or through an affiliate, serves in
the aggregate fewer than 1 percent of all subscribers in the United States and is not affiliated with any
entity or entities whose gross annual revenues in the aggregate exceed $250,000,000.”39 The Commission
has determined that an operator serving fewer than 677,000 subscribers shall be deemed a small operator,
if its annual revenues, when combined with the total annual revenues of all its affiliates, do not exceed
$250 million in the aggregate.40 Industry data indicate that, of 1,076 cable operators nationwide, all but
ten are small under this size standard.41 We note that the Commission neither requests nor collects
information on whether cable system operators are affiliated with entities whose gross annual revenues
exceed $250 million,42 and therefore we are unable to estimate more accurately the number of cable
system operators that would qualify as small under this size standard.
13.
Open Video Services. The open video system (“OVS”) framework was established in
1996, and is one of four statutorily recognized options for the provision of video programming services
by local exchange carriers.43 The OVS framework provides opportunities for the distribution of video
programming other than through cable systems. Because OVS operators provide subscription services,44
OVS falls within the SBA small business size standard covering cable services, which is “Wired


36 These data are derived from R.R. BOWKER, BROADCASTING & CABLE YEARBOOK 2006, “Top 25 Cable/Satellite
Operators,” pages A-8 & C-2 (data current as of June 30, 2005); WARREN COMMUNICATIONS NEWS, TELEVISION &
CABLE FACTBOOK 2006, “Ownership of Cable Systems in the United States,” pages D-1805 to D-1857.
37 See 47 C.F.R. § 76.901(c).
38 WARREN COMMUNICATIONS NEWS, TELEVISION & CABLE FACTBOOK 2006, “U.S. Cable Systems by Subscriber
Size,” page F-2 (data current as of Oct. 2005). The data do not include 718 systems for which classifying data were
not available.
39 47 U.S.C. § 543(m)(2); see also 47 C.F.R. § 76.901(f) & nn.1–3.
40 47 C.F.R. § 76.901(f); see FCC Announces New Subscriber Count for the Definition of Small Cable Operator,
Public Notice, 16 FCC Rcd 2225 (Cable Services Bureau 2001).
41 These data are derived from R.R. BOWKER, BROADCASTING & CABLE YEARBOOK 2006, “Top 25 Cable/Satellite
Operators,” pages A-8 & C-2 (data current as of June 30, 2005); WARREN COMMUNICATIONS NEWS, TELEVISION &
CABLE FACTBOOK 2006, “Ownership of Cable Systems in the United States,” pages D-1805 to D-1857.
42 The Commission does receive such information on a case-by-case basis if a cable operator appeals a local
franchise authority’s finding that the operator does not qualify as a small cable operator pursuant to § 76.901(f) of
the Commission’s rules.
43 47 U.S.C. § 571(a)(3)-(4). See Annual Assessment of the Status of Competition in the Market for the Delivery of
Video Programming
, MB Docket No. 06-189, Thirteenth Annual Report, 24 FCC Rcd 542, 606 para. 135 (2009)
(“Thirteenth Annual Cable Competition Report”).
44 See 47 U.S.C. § 573.
123

Federal Communications Commission

FCC 12-7

Telecommunications Carriers.”45 The SBA has developed a small business size standard for this
category, which is: all such firms having 1,500 or fewer employees. According to Census Bureau data
for 2007, there were a total of 3,188 firms in this previous category that operated for the entire year.46 Of
this total, 3,144 firms had employment of 999 or fewer employees, and 44 firms had employment of 1000
employees or more.47 Thus, under this size standard, most cable systems are small and may be affected
by rules adopted pursuant to the Notice. In addition, we note that the Commission has certified some
OVS operators, with some now providing service.48 Broadband service providers (“BSPs”) are currently
the only significant holders of OVS certifications or local OVS franchises.49 The Commission does not
have financial or employment information regarding the entities authorized to provide OVS, some of
which may not yet be operational. Thus, again, at least some of the OVS operators may qualify as small
entities.
14.
Wired Telecommunications Carriers. The 2007 North American Industry Classification
System (“NAICS”) defines “Wired Telecommunications Carriers” as follows: “This industry comprises
establishments primarily engaged in operating and/or providing access to transmission facilities and
infrastructure that they own and/or lease for the transmission of voice, data, text, sound, and video using
wired telecommunications networks. Transmission facilities may be based on a single technology or a
combination of technologies. Establishments in this industry use the wired telecommunications network
facilities that they operate to provide a variety of services, such as wired telephony services, including
VoIP services; wired (cable) audio and video programming distribution; and wired broadband Internet
services. By exception, establishments providing satellite television distribution services using facilities
and infrastructure that they operate are included in this industry.”50 The SBA has developed a small
business size standard for wireline firms within the broad economic census category, “Wired
Telecommunications Carriers.”51 Under this category, the SBA deems a wireline business to be small if it
has 1,500 or fewer employees. Census data for 2007, which supersede data from the 2002 Census, show
that 3,188 firms operated n 2007 as Wired Telecommunications Carriers. 3,144 had 1,000 or fewer
employees, while 44 operated with more than 1,000 employees.52
15.
Broadband Radio Service and Educational Broadband Service (FCC Auction Standard).
The established rules apply to Broadband Radio Service (“BRS,” formerly known as Multipoint
Distribution Systems, or “MDS”) operated as part of a wireless cable system. The Commission has


45
U.S. Census Bureau, 2007 NAICS Definitions, “517110 Wired Telecommunications Carriers”;
http://www.census.gov/naics/2007/def/ND517110.HTM#N517110.
46 U.S. Census Bureau, 2007 Economic Census, Subject Series: Information, Table 5, Employment Size of Firms for
the United States: 2007, NAICS code 5171102 (issued Nov. 2010).
47 See id.
48 A list of OVS certifications may be found at http://www.fcc.gov/mb/ovs/csovscer.html.
49 See Thirteenth Annual Cable Competition Report, 24 FCC Rcd at 606-07 para. 135. BSPs are newer firms that
are building state-of-the-art, facilities-based networks to provide video, voice, and data services over a single
network.
50 See U.S. Census Bureau, 2007 NAICS Definitions, “517110 Wired Telecommunications Carriers,”
http://www.census.gov/naics/2007/def/ND517110.HTM#N517110 (last visited May 11, 2011).
51 13 C.F.R. § 121.201 (NAICS code 517110).
52 See http://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-_skip=900&-ds_name=EC0751SSSZ4&;-
_lang=en (last visited May 11, 2011).
124

Federal Communications Commission

FCC 12-7

defined “small entity” for purposes of the auction of BRS frequencies as an entity that, together with its
affiliates, has average gross annual revenues that are not more than $40 million for the preceding three
calendar years.53 The SBA has approved this definition of small entity in the context of MDS auctions.54
The Commission completed its MDS auction in March 1996 for authorizations in 493 basic trading areas.
Of 67 winning bidders, 61 qualified as small entities. At this time, we estimate that of the 61 small
business MDS auction winners, 48 remain small business licensees. In addition to the 48 small
businesses that hold BTA authorizations, there are approximately 392 incumbent BRS licensees that are
considered small entities.55 After adding the number of small business auction licensees to the number of
incumbent licensees not already counted, we find that there are currently approximately 440 BRS
licensees that are defined as small businesses under either the SBA or the Commission’s rules. In 2009,
the Commission conducted Auction 86, which offered 78 BRS licenses.56 Auction 86 concluded with ten
bidders winning 61 licenses.57 Of the ten, two bidders claimed small business status and won 4 licenses;
one bidder claimed very small business status and won three licenses; and two bidders claimed
entrepreneur status and won six licenses.58
16.
The rules and policies adopted in the Fifth Report and Order would also apply to
Educational Broadband Service (“EBS,” formerly known as Instructional Television Fixed Service, or
“ITFS”) facilities operated as part of a wireless cable system. The SBA definition of small entities for
pay television services, Cable and Other Subscription Programming, also appears to apply to EBS.59
There are presently 2,032 EBS licensees. All but 100 of these licenses are held by educational
institutions. Educational institutions are included in the definition of a small business.60 However, we do
not collect annual revenue data for EBS licensees and are not able to ascertain how many of the 100 non-
educational licensees would be categorized as small under the SBA definition. Thus, we tentatively
conclude that at least 1,932 are small businesses and may be affected by the rules and policies adopted in
the Fifth Report and Order.


53 47 C.F.R. § 21.961(b)(1).
54 See Amendment of Parts 21 and 74 of the Commission’s Rules With Regard to Filing Procedures in the Multipoint
Distribution Service and in the Instructional Television Fixed Service and Implementation of Section 309(j) of the
Communications Act – Competitive Bidding
, MM Docket No. 94-131 and PP Docket No. 93-253, Report and Order,
10 FCC Rcd 9589 (1995).
55 47 U.S.C. § 309(j). The Commission licensed hundreds of stations to incumbent MDS licensees prior to
implementation of Section 309(j) of the Communications Act of 1934, 47 U.S.C. § 309(j). For these pre-auction
licenses, the applicable standard is SBA’s small business size standard.
56 Auction 86 Procedures Public Notice, 24 FCC Rcd at 8280.
57 “Auction of Broadband Radio Service Licenses Closes, Winning Bidders Announced for Auction 86, Down
Payments Due November 23, 2009, Final Payments Due December 8, 2009, Ten-Day Petition to Deny Period,”
Public Notice, 24 FCC Rcd 13,572 (WTB 2009).
58 The Commission’s standards for small business bidding credits for BRS are set forth in section 27.1218, 47
C.F.R. § 27.1218. See also “Auction of Broadband Radio Service (BRS) Licenses, Scheduled for October 27, 2009,
Notice and Filing Requirements, Minimum Opening Bids, Upfront Payments, and Other Procedures for Auction
86,” Public Notice, 24 FCC Rcd 8277, 8296 (WTB 2009) (Auction 86 Procedures Public Notice).
59 13 C.F.R. § 121.201, NAICS code 515210.
60 5 U.S.C. § 601(3).
125

Federal Communications Commission

FCC 12-7

17.
Wireless Telecommunications Carriers (except Satellite). Since 2007, the Census Bureau
has placed wireless firms within this new, broad, economic census category.61 Prior to that time, such
firms were within the now-superseded categories of “Paging” and “Cellular and Other Wireless
Telecommunications.”62 Under the present and prior categories, the SBA has deemed a wireless business
to be small if it has 1,500 or fewer employees.63 For the category of Wireless Telecommunications
Carriers (except Satellite), Census data for 2007, which supersede data contained in the 2002 Census,
show that there were 1,383 firms that operated that year.64 Of those 1,383, 1,368 had fewer than 100
employees, and 15 firms had more than 100 employees. Thus under this category and the associated
small business size standard, the majority of firms can be considered small. Similarly, according to
Commission data, 413 carriers reported that they were engaged in the provision of wireless telephony,
including cellular service, Personal Communications Service (PCS), and Specialized Mobile Radio
(SMR) Telephony services.65 Of these, an estimated 261 have 1,500 or fewer employees and 152 have
more than 1,500 employees.66 Consequently, the Commission estimates that approximately half or more
of these firms can be considered small. Thus, using available data, we estimate that the majority of
wireless firms can be considered small.
18.
Incumbent Local Exchange Carriers (LECs). We have included small incumbent LECs in
this IRFA analysis. As noted above, a “small business” under the RFA is one that, inter alia, meets the
pertinent small business size standard (e.g., a telephone communications business having 1,500 or fewer
employees) and “is not dominant in its field of operation.”67 The SBA’s Office of Advocacy contends
that, for RFA purposes, small incumbent LECs are not dominant in their field of operation because any
such dominance is not “national” in scope.68 We have therefore included small incumbent local exchange
carriers in this RFA analysis, although we emphasize that this RFA action has no effect on Commission
analyses and determinations in other, non-RFA contexts. Neither the Commission nor the SBA has
developed a small business size standard specifically for incumbent local exchange services. The
appropriate size standard under SBA rules is for the category Wired Telecommunications Carriers. Under


61 U.S. Census Bureau, 2007 NAICS Definitions, “Wireless Communications Carriers (Except Satellite), NAICS
code 517210”; http://www.census.gov/naics/2007/def/ND517210.HTM#N517210.
62 U.S. Census Bureau, 2002 NAICS Definitions, “517211 Paging”;
http://www.census.gov/epcd/naics02/def/NDEF517.HTM.; U.S. Census Bureau, 2002 NAICS Definitions, “517212
Cellular and Other Wireless Telecommunications”; http://www.census.gov/epcd/naics02/def/NDEF517.HTM.
63 13 C.F.R. § 121.201, NAICS code 51
7210 (2007 NAICS). The now-superseded, pre-2007 C.F.R. citations were 13 C.F.R. § 121.201, NAICS codes
517211 and 517212 (referring to the 2002 NAICS).
64 U.S. Census Bureau, 2007 Economic Census, Sector 51, 2007 NAICS code 517210 (rel. Oct. 20, 2009),
http://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-fds_name=EC0700A1&-_skip=700&;-
ds_name=EC0751SSSZ5&-_lang=en.
65 See Trends in Telephone Service at Table 5.3.
66 See id.
67 15 U.S.C. § 632.
68 Letter from Jere W. Glover, Chief Counsel for Advocacy, SBA, to William E. Kennard, Chairman, FCC (May 27,
1999). The Small Business Act contains a definition of “small-business concern,” which the RFA incorporates into
its own definition of “small business.” See 15 U.S.C. § 632(a) (Small Business Act); 5 U.S.C. § 601(3) (RFA).
SBA regulations interpret “small business concern” to include the concept of dominance on a national basis. See 13
C.F.R. § 121.102(b).
126

Federal Communications Commission

FCC 12-7

that size standard, such a business is small if it has 1,500 or fewer employees.69 According to
Commission data,70 1,303 carriers have reported that they are engaged in the provision of incumbent local
exchange services. Of these 1,303 carriers, an estimated 1,020 have 1,500 or fewer employees, and 283
have more than 1,500 employees. Consequently, the Commission estimates that most providers of
incumbent local exchange service are small businesses that may be affected by the rules and policies
adopted in the Fifth Report and Order.
19.
Competitive (LECs), Competitive Access Providers (CAPs), “Shared-Tenant Service
Providers,” and “Other Local Service Providers.” Neither the Commission nor the SBA has developed a
small business size standard specifically for these service providers. The appropriate size standard under
SBA rules is for the category Wired Telecommunications Carriers. Under that size standard, such a
business is small if it has 1,500 or fewer employees.71 According to Commission data,72 769 carriers have
reported that they are engaged in the provision of either competitive access provider services or
competitive local exchange carrier services. Of these 769 carriers, an estimated 676 have 1,500 or fewer
employees, and 93 have more than 1,500 employees. In addition, 12 carriers have reported that they are
“Shared-Tenant Service Providers,” and all 12 are estimated to have 1,500 or fewer employees. In
addition, 39 carriers have reported that they are “Other Local Service Providers.” Of the 39, an estimated
38 have 1,500 or fewer employees, and one has more than 1,500 employees. Consequently, the
Commission estimates that most providers of competitive local exchange service, competitive access
providers, “Shared-Tenant Service Providers,” and “Other Local Service Providers” are small entities.
20.
Satellite Telecommunications Providers. Two economic census categories address the
satellite industry. The first category has a small business size standard of $15 million or less in average
annual receipts, under SBA rules.73 The second has a size standard of $25 million or less in annual
receipts.74
21.
The category of Satellite Telecommunications “comprises establishments primarily
engaged in providing telecommunications services to other establishments in the telecommunications and
broadcasting industries by forwarding and receiving communications signals via a system of satellites or
reselling satellite telecommunications.”75 Census Bureau data for 2007 show that 512 Satellite
Telecommunications firms that operated for that entire year.76 Of this total, 464 firms had annual receipts
of under $10 million, and 18 firms had receipts of $10 million to $24,999,999.77 Consequently, the
majority of Satellite Telecommunications firms can be considered small entities.
22.
The second category, i.e. “All Other Telecommunications” comprises “establishments


69 13 C.F.R. § 121.201, NAICS code 517110.
70 Trends in Telephone Service, Table 5.3.
71 13 C.F.R. § 121.201, NAICS code 517110.
72 Trends in Telephone Service, Table 5.3.
73 13 C.F.R. § 121.201, NAICS code 517410.
74 13 C.F.R. § 121.201, NAICS code 517919.
75 U.S. Census Bureau, 2007 NAICS Definitions, “517410 Satellite Telecommunications.”
76 See http://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-_skip=900&-ds_name=EC0751SSSZ4&;-
_lang=en.
77 See http://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-_skip=900&-ds_name=EC0751SSSZ4&;-
_lang=en
127

Federal Communications Commission

FCC 12-7

primarily engaged in providing specialized telecommunications services, such as satellite tracking,
communications telemetry, and radar station operation. This industry also includes establishments
primarily engaged in providing satellite terminal stations and associated facilities connected with one or
more terrestrial systems and capable of transmitting telecommunications to, and receiving
telecommunications from, satellite systems. Establishments providing Internet services or voice over
Internet protocol (VoIP) services via client-supplied telecommunications connections are also included in
this industry.”78 For this category, Census Bureau data for 2007 show that there were a total of 2,383
firms that operated for the entire year.79 Of this total, 2,347 firms had annual receipts of under $25
million and 12 firms had annual receipts of $25 million to $49, 999,999.80 Consequently, the Commission
estimates that the majority of All Other Telecommunications firms are small entities that might be
affected by our action.
23.
Direct Broadcast Satellite (“DBS”) Service. DBS service is a nationally distributed
subscription service that delivers video and audio programming via satellite to a small parabolic “dish”
antenna at the subscriber’s location. DBS, by exception, is now included in the SBA’s broad economic
census category, “Wired Telecommunications Carriers,”81 which was developed for small wireline firms.
Under this category, the SBA deems a wireline business to be small if it has 1,500 or fewer employees.82
To gauge small business prevalence for the DBS service, the Commission relies on data currently
available from the U.S. Census for the year 2007. According to that source, there were 3,188 firms that in
2007 were Wired Telecommunications Carriers. Of these, 3,144 operated with less than 1,000
employees, and 44 operated with more than 1,000 employees. However, as to the latter 44 there is no
data available that shows how many operated with more than 1,500 employees. Based on this data, the
majority of these firms can be considered small.83 Currently, only two entities provide DBS service,
which requires a great investment of capital for operation: DIRECTV and EchoStar Communications
Corporation (“EchoStar”) (marketed as the DISH Network).84 Each currently offers subscription services.
DIRECTV85 and EchoStar86 each report annual revenues that are in excess of the threshold for a small


78 http://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=517919&search=2007%20NAICS%20Search
79 U.S. Censhttp://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-_skip=900&;-
ds_name=EC0751SSSZ4&-_lang=en.
80http://factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-_skip=900&-ds_name=EC0751SSSZ4&;-
_lang=en .
81 See 13 C.F.R. § 121.201, NAICS code 517110 (2007). The 2007 NAICS definition of the category of “Wired
Telecommunications Carriers” is in paragraph 7, above.
82 13 C.F.R. § 121.201, NAICS code 517110 (2007).
83 See http://www.factfinder.census.gov/servlet/IBQTable?_bm=y&-geo_id=&-fds_name=EC0700A1&;-
_skip=600&-ds_name=EC0751SSSZ5&-_lang=en.
84 See Annual Assessment of the Status of Competition in the Market for the Delivery of Video Programming,
Thirteenth Annual Report,, 24 FCC Rcd 542, 580, ¶ 74 (2009) (“13th Annual Report”). We note that, in 2007,
EchoStar purchased the licenses of Dominion Video Satellite, Inc. (“Dominion”) (marketed as Sky Angel). See
Public Notice, “Policy Branch Information; Actions Taken,” Report No. SAT-00474, 22 FCC Rcd 17776 (IB 2007).
85 As of June 2006, DIRECTV is the largest DBS operator and the second largest MVPD, serving an estimated
16.20% of MVPD subscribers nationwide. See 13th Annual Report, 24 FCC Rcd at 687, Table B-3.
86 As of June 2006, DISH Network is the second largest DBS operator and the third largest MVPD, serving an
estimated 13.01% of MVPD subscribers nationwide. Id. As of June 2006, Dominion served fewer than 500,000
subscribers, which may now be receiving “Sky Angel” service from DISH Network. See id. at 581, ¶ 76.
128

Federal Communications Commission

FCC 12-7

business. Because DBS service requires significant capital, we believe it is unlikely that a small entity as
defined by the SBA would have the financial wherewithal to become a DBS service provider.

D.

Description of Projected Reporting, Recordkeeping, and Other Compliance

Requirements

24.
There are revisions to current Part 11 reporting, recordkeeping, or compliance
requirements set forth in the Fifth Report and Order. Specifically, the Fifth Report and Order:
·
Revises section 11.33(a)(4) to require that if an alert message is derived from a CAP-
formatted message, the contents of the text, assembled pursuant to ECIG Implementation
Guide, should be added to the EAS device log. This revision merely applies a current
reporting requirement to a new technical protocol and we do not expect it to alter the
reporting burden to any appreciable degree.
·
Revises section 11.21(a) to make clear that the State EAS Plans specify the monitoring
assignments and the specific primary and backup path for SAME-formatted EANs. This
revision merely applies a current reporting requirement to a new technical protocol and we do
not expect it to alter the reporting burden to any appreciable degree. The revision will ensure
the accuracy of EAS operational documents and thus contribute to public safety.
Accordingly, the Commission believes the revision to be necessary.
·
Adopts streamlined procedures for equipment certification that take into account standards
and testing procedures adopted by FEMA. This revision merely applies a current
certification requirement to equipment that complies with a new technical protocol and we do
not expect it to alter the certification burden to any appreciable degree.
25.
These requirements are intended to advance our public safety mission and enhance the
performance of the EAS while reducing regulatory burdens wherever possible.

E.

Steps Taken to Minimize the Significant Economic Impact on Small Entities, and

Significant Alternatives Considered

26.
The RFA requires an agency to describe any significant alternatives that it has considered
in developing its approach, which may include the following four alternatives (among others): “(1) the
establishment of differing compliance or reporting requirements or timetables that take into account the
resources available to small entities; (2) the clarification, consolidation, or simplification of compliance
and reporting requirements under the rule for such small entities; (3) the use of performance rather than
design standards; and (4) an exemption from coverage of the rule, or any part thereof, for such small
entities.”87
27.
EAS Participants already are required to comply with the CAP-related obligations set forth
in sections 11.55 and 11.56. The Fifth Report and Order adopts dozens of revisions to Part 11 of the
Commission’s rules that are necessary in order for EAS Participants to meet these existing obligations
and, more generally, to streamline and make more efficient the operation of the EAS. The majority of the
rule revisions are not designed to introduce new obligations that do not already exist, but rather, more
clearly identify and effect within Part 11 the CAP obligations previously adopted in the Second Report
and Order
. In all instances, we chose the least costly, technically feasible option. In this regard, these
revisions are designed to minimally impact all EAS Participants, including small entities, to the extent


87 5 U.S.C. § 603(c)(1) – (c)(4).
129

Federal Communications Commission

FCC 12-7

feasible, while at the same time protecting the lives and property of all Americans. This confers a direct
benefit on small entities. For example, the rule revisions maintain the existing EAS architecture and
permit affected parties to meet their CAP-related obligations via intermediary devices, which potentially
may alleviate the need to obtain new EAS equipment for many EAS Participants. Similarly, the revisions
to EAN processing make the Part 11 rules simpler both to understand and implement within equipment
designs.
28.
Removing redundant or obsolete sections from the EAS rules not only streamlines EAS
operation, but also decreases costs to all involved in the functioning of the EAS. Moreover, the CAP-
related amendments that we make to our EAS rules are designed to minimize costs. For example, the
Fifth Report and Order removes the obligation to receive and process CAP-formatted alerts messages
initiated by state governors. This will eliminate the costs of upgrading EAS equipment to comply with
this requirement.
29.
Commenters were invited to suggest steps that the Commission may take to further
minimize any significant economic impact on small entities. When considering proposals made by other
parties, commenters were also invited to propose alternatives that serve the goal of minimizing the impact
on small entities. Virtually all commenters agreed that incorporation of CAP into the Part 11 rules will
significantly benefit both public safety officials and the public by creating a more efficient, reliable and
effective EAS. The new rules require EAS Participants to monitor FEMA’s IPAWS system for federal
CAP-formatted alert messages using whatever interface technology is appropriate. This approach marks
an alternative from the Commission’s proposal in the Third FNPRM and is in response to comments
received in response to the Third FNPRM that advocated for more flexibility for this requirement.
Moreover, the new rules permit, with certain limitations, EAS Participants to use intermediary devices to
meet their CAP-related obligations. The approach taken in the Fifth Report and Order strikes a balance
by allowing use of these devices by EAS Participants – many of whom are small or are non-commercial –
but only to the extent such devices can comply with the rules adopted today by June 30, 2015. This is a
significantly less costly alternative to requiring immediate compliance.
30.

Report to Congress:

The Commission will send a copy of the Fifth Report and Order,
including this FRFA, in a report to be sent to Congress and the Government Accountability Office
pursuant to the Congressional Review Act.88 In addition, the Commission will send a copy of the Fifth
Report and Order
, including this FRFA, to the Chief Counsel for Advocacy of the SBA. A copy of the
Fifth Report and Order and FRFA (or summaries thereof) will also be published in the Federal Register.89


88 See 5 U.S.C. § 801(a)(1)(A).
89 See 5 U.S.C. § 604(b).
130

Note: We are currently transitioning our documents into web compatible formats for easier reading. We have done our best to supply this content to you in a presentable form, but there may be some formatting issues while we improve the technology. The original version of the document is available as a PDF, Word Document, or as plain text.

close
FCC

You are leaving the FCC website

You are about to leave the FCC website and visit a third-party, non-governmental website that the FCC does not maintain or control. The FCC does not endorse any product or service, and is not responsible for, nor can it guarantee the validity or timeliness of the content on the page you are about to visit. Additionally, the privacy policies of this third-party page may differ from those of the FCC.