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; 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 ) ) ) ) ) ) ) ) ) ) ) EB Docket No. 04-296 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 2 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. Federal Communications Commission FCC 12-7 3 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. Federal Communications Commission FCC 12-7 4 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). Federal Communications Commission FCC 12-7 5 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. Federal Communications Commission FCC 12-7 6 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. Federal Communications Commission FCC 12-7 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). Federal Communications Commission FCC 12-7 8 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. Federal Communications Commission FCC 12-7 9 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. Federal Communications Commission FCC 12-7 10 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. Federal Communications Commission FCC 12-7 11 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. Federal Communications Commission FCC 12-7 12 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. Federal Communications Commission FCC 12-7 13 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. Federal Communications Commission FCC 12-7 14 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….) Federal Communications Commission FCC 12-7 15 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). Federal Communications Commission FCC 12-7 16 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). Federal Communications Commission FCC 12-7 17 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). Federal Communications Commission FCC 12-7 18 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). Federal Communications Commission FCC 12-7 19 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. Federal Communications Commission FCC 12-7 20 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”). Federal Communications Commission FCC 12-7 21 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. Federal Communications Commission FCC 12-7 22 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. Federal Communications Commission FCC 12-7 23 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. Federal Communications Commission FCC 12-7 24 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. Federal Communications Commission FCC 12-7 25 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. Federal Communications Commission FCC 12-7 26 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. Federal Communications Commission FCC 12-7 27 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….) Federal Communications Commission FCC 12-7 28 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. Federal Communications Commission FCC 12-7 29 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. Federal Communications Commission FCC 12-7 30 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). Federal Communications Commission FCC 12-7 31 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). Federal Communications Commission FCC 12-7 32 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. Federal Communications Commission FCC 12-7 33 [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. Federal Communications Commission FCC 12-7 34 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. Federal Communications Commission FCC 12-7 35 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. Federal Communications Commission FCC 12-7 36 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). Federal Communications Commission FCC 12-7 37 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. Federal Communications Commission FCC 12-7 38 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. Federal Communications Commission FCC 12-7 39 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. Federal Communications Commission FCC 12-7 40 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. Federal Communications Commission FCC 12-7 41 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. Federal Communications Commission FCC 12-7 42 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). Federal Communications Commission FCC 12-7 43 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. Federal Communications Commission FCC 12-7 44 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. Federal Communications Commission FCC 12-7 45 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. Federal Communications Commission FCC 12-7 46 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. Federal Communications Commission FCC 12-7 47 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. Federal Communications Commission FCC 12-7 48 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. Federal Communications Commission FCC 12-7 49 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. Federal Communications Commission FCC 12-7 50 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. Federal Communications Commission FCC 12-7 51 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 ). 434 See id. Federal Communications Commission FCC 12-7 52 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 ). 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. Federal Communications Commission FCC 12-7 53 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. Federal Communications Commission FCC 12-7 54 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….) Federal Communications Commission FCC 12-7 55 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. Federal Communications Commission FCC 12-7 56 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. Federal Communications Commission FCC 12-7 57 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. Federal Communications Commission FCC 12-7 58 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….) Federal Communications Commission FCC 12-7 59 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. Federal Communications Commission FCC 12-7 60 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 Federal Communications Commission FCC 12-7 61 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. Federal Communications Commission FCC 12-7 62 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. Federal Communications Commission FCC 12-7 63 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. Federal Communications Commission FCC 12-7 64 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. Federal Communications Commission FCC 12-7 65 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. Federal Communications Commission FCC 12-7 66 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. Federal Communications Commission FCC 12-7 67 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. Federal Communications Commission FCC 12-7 68 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. Federal Communications Commission FCC 12-7 69 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. Federal Communications Commission FCC 12-7 70 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. Federal Communications Commission FCC 12-7 71 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. Federal Communications Commission FCC 12-7 72 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. Federal Communications Commission FCC 12-7 73 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. Federal Communications Commission FCC 12-7 74 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. Federal Communications Commission FCC 12-7 75 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)). Federal Communications Commission FCC 12-7 76 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….) Federal Communications Commission FCC 12-7 77 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))). Federal Communications Commission FCC 12-7 78 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. Federal Communications Commission FCC 12-7 79 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. Federal Communications Commission FCC 12-7 80 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. Federal Communications Commission FCC 12-7 81 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. Federal Communications Commission FCC 12-7 82 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. Federal Communications Commission FCC 12-7 83 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. Federal Communications Commission FCC 12-7 84 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. Federal Communications Commission FCC 12-7 85 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. Federal Communications Commission FCC 12-7 86 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. Federal Communications Commission FCC 12-7 87 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). Federal Communications Commission FCC 12-7 88 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)). Federal Communications Commission FCC 12-7 89 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). Federal Communications Commission FCC 12-7 90 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. Federal Communications Commission FCC 12-7 91 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. Federal Communications Commission FCC 12-7 92 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). Federal Communications Commission FCC 12-7 93 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. Federal Communications Commission FCC 12-7 94 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. Federal Communications Commission FCC 12-7 95 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. Federal Communications Commission FCC 12-7 96 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 Federal Communications Commission FCC 12-7 97 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. Federal Communications Commission FCC 12-7 98 (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 equipment requirement AM & FM Digital AM & FM Analog & Digital FM Class D Analog & Digital LPFM DTV Analog & Digital Class A TV Analog & Digital LPTV EAS decoder1 Y Y Y Y Y Y Y EAS encoder Y Y N N Y Y N Audio message Y Y Y Y Y Y Y Video message N/A N/A N/A N/A Y Y 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). Analog Cable Systems Federal Communications Commission FCC 12-7 99 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. Federal Communications Commission FCC 12-7 100 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 Federal Communications Commission FCC 12-7 101 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. Federal Communications Commission FCC 12-7 102 * * * * * 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. Federal Communications Commission FCC 12-7 103 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 Federal Communications Commission FCC 12-7 104 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 Federal Communications Commission FCC 12-7 105 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 Federal Communications Commission FCC 12-7 106 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. Federal Communications Commission FCC 12-7 107 * * * * * (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 Federal Communications Commission FCC 12-7 108 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. * * * * * Federal Communications Commission FCC 12-7 109 (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) * * * * * * * * Federal Communications Commission FCC 12-7 110 (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. Federal Communications Commission FCC 12-7 111 (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 Federal Communications Commission FCC 12-7 112 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. Federal Communications Commission FCC 12-7 113 * * * * * (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 Federal Communications Commission FCC 12-7 114 (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). Federal Communications Commission FCC 12-7 115 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). Federal Communications Commission FCC 12-7 116 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….) Federal Communications Commission FCC 12-7 117 · 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). Federal Communications Commission FCC 12-7 118 · 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 Federal Communications Commission FCC 12-7 119 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 Federal Communications Commission FCC 12-7 120 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….) Federal Communications Commission FCC 12-7 121 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). Federal Communications Commission FCC 12-7 122 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). Federal Communications Commission FCC 12-7 123 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. Federal Communications Commission FCC 12-7 124 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). Federal Communications Commission FCC 12-7 125 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). Federal Communications Commission FCC 12-7 126 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). Federal Communications Commission FCC 12-7 127 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 Federal Communications Commission FCC 12-7 128 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. Federal Communications Commission FCC 12-7 129 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). Federal Communications Commission FCC 12-7 130 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).